[Question]-[Crafty]-[Turtle]Crafty crafting

Has anyone built an ultimate crafting setup that can make anything? Let's see what the challenges are.

A turtle only knows about the items in its inventory and all it knows is, is this the same as some other item in its inventory. This is a huge problem, but it's solvable.

It needs a way of populating specific slots with specific items, e.g. a charcoal in slot 1 and a stick in slot 5.

It needs to know where to get charcoal, and where to get sticks.

You need a chest dedicated to each item, and the turtle needs to know where to go to find the chest. How many chests is that? Well, I reckon a few hundred should do. An 8x8 grid of iron chests or alternating wood and iron should do, two layers with a gap in between for turtle acces, that's 128 which should do for a start. A database recording what chest each item contains, and an input chest for new items which would then be moved into an empty chest.

So then what? You just go to a chest that contains an item needed, suck a stack into Slot 16, spit the surplus back into the chest, transfer the material to the right slot, repeat for entire pattern, and then craft(), right? Seems so simple really. Someone must have done this already. Setting up all the patterns is most of the work, there must be a pattern list that could be used for that.

What have I missed?

Oh, yes, some items are not consumed such as water buckets and minium stones so it needs to refill and/or return those. And if it's going to craft more than one then it needs to go to an infinite water (or milk!) source and do the crafting and refilling there, that's definitely advanced mode. Probably the first version will just dump the bucket in a chest for a dedicated refilling turtle to deal with. But how does the refilling turtle know if it's a milk bucket or a water bucket… two dump chests, one next to water and one next to bessie?

Anything else I need to do?

Ooh, need to check that the chest hasn't run out of materials. And maybe craft some if it has. Need a proper crafting queue really. A stack, in computing terms, but that is an overloaded term in a Minecraft context.

Have you thought of if the turtle would be the one to get the resources when low, or would that require Steve, or quarry, input?
Because if the turtle gets the resources it would also need an understanding of how/where, like sticks from planks from wood from trees from that sapling I planted over there where I might need to hit it with bonemeal if I dig the first item and it has no crafting result

I once made a big part of this for the 'The Competition'. The goals were slightly different though. The turtle gather resources, applied some simple tests and knowledge to keep track of which item is which. Then it went to a docking station to craft necessary items. He did this by fetching the recipe from a look-up table. It worked recursive, so if I wanted to craft torches but was out of sticks, it would try to craft sticks from planks. If it was out of planks it would craft it from wood and if it had no wood it would chop down a tree… Never came to finish the project though, it consumed an awful lot of my time. I never came to isolate the crafting process from the rest of the code either, you're motivating me to do it after all. :)/>

Maybe using Misc Peripherals' inventory module?

Doyle3694, on 01 February 2013 - 01:08 AM said:

Maybe using Misc Peripherals' inventory module?

Or OpenCCSensor's one. :D/>

TheOriginalBIT, on 01 February 2013 - 12:01 AM said:

Have you thought of if the turtle would be the one to get the resources when low, or would that require Steve, or quarry, input?

No, I think that would be separate. You could link up your forestry and quarrying turtles to the system so they dump their loot in an input chest, which then routes ores to the macerator and furnaces, convert half the logs to planks and the other half to sticks, etc. and then automatically re-fill the crafting storage with the output, but at the moment I'm just thinking about the crafting side. When a new material is required, it would prompt you to dump as much as you like into an input chest and the system would allocate an unused chest in the 8x8 area and move it all to there and then it would pick up what it needed and the rest would be available for any crafting in future.

The problem with automatically refilling the chests is, the turtle doing the refilling has no idea what it just picked up and so has to traverse the entire storage area looking for a chest with the same item in it. This is impossible if that chest has run out of materials. Therefore whenever materials are stored away, the system needs to be told what that material is.

Orwell, on 01 February 2013 - 12:34 AM said:

I once made a big part of this for the 'The Competition'… I never came to isolate the crafting process from the rest of the code either, you're motivating me to do it after all. :)/>/>

So the principle is sound, then? Any "gotchas" that I haven't thought of? I'll have to have a look at the inventory add-on, that's present in FTB Direwolf20 which is what I'm using so I can use that. Hopefully it won't make it too easy, designing workarounds for the shortcomings of turtles is part of the fun of the challenge.

Multiple recipes might be tricky. I guess I'll only have one "Torch" recipe using Charcoal, and not the Coal variant. Maybe two separate recipes with different names, "Torch (Coal)" and "Torch (Charcoal)".

How to select the item to craft? Enter the full exact name? A menu? Search function?

Also, do I start writing it as a standalone program for a single turtle, or do I make a central computer that instructs one or more turtles to do what's necessary? If I make the inventory multi-storey then one turtle per storey delivering materials to a master crafter turtle would make sense, and the player can monitor progress from the console.

PhilHibbs, on 01 February 2013 - 03:30 AM said:

Orwell, on 01 February 2013 - 12:34 AM said:

So the principle is sound, then? Any "gotchas" that I haven't thought of? I'll have to have a look at the inventory add-on, that's present in FTB Direwolf20 which is what I'm using so I can use that. Hopefully it won't make it too easy, designing workarounds for the shortcomings of turtles is part of the fun of the challenge.

I guess its sound.. There's not that much too it.. It's just a hassle to do the set-up. :P/> I would personally keep it vanilla CC, that's the only part that's challenging IMO.

PhilHibbs, on 01 February 2013 - 03:30 AM said:

Multiple recipes might be tricky. I guess I'll only have one "Torch" recipe using Charcoal, and not the Coal variant. Maybe two separate recipes with different names, "Torch (Coal)" and "Torch (Charcoal)".

How to select the item to craft? Enter the full exact name? A menu? Search function?

Create a database that can differentiate and identify all recipes in some way. Let the crafting code depend entirely on them as entities (by using the tables as index, or by using an id as index, …). Then how you select the recipes is purely a matter of interfacing, supporting selection/search methods is a piece of cake then. You could support all criteria to select/search for recipes that way without much work.

PhilHibbs, on 01 February 2013 - 03:30 AM said:

Also, do I start writing it as a standalone program for a single turtle, or do I make a central computer that instructs one or more turtles to do what's necessary? If I make the inventory multi-storey then one turtle per storey delivering materials to a master crafter turtle would make sense, and the player can monitor progress from the console.

My advise on this one is a bit the same as on the previous question. Make it modular; use abstraction.
E.g. create an API that supports crafting of any arbitrary recipe given that it has an interface (another API/metatable probably) that it can query for items. Calling the methods on that interface will ensure delivery of the items in known slots. Whether the interface will do this by fetching the items from chests itself, or by commanding other turtles to bring them doesn't matter at this point.
Then you can create two (or more) APIS that implement this interface, one that commands slave turtles, one that does all the work itself.
Then you create a solid database for all recipes, make all entries unique and make them all have every relevant piece of info on a recipe you can think of.
Next you could create the wrapper that can query the database for recipes, passes the specified transportation interface to the crafting API and passes the recipe retrieved from the database to the crafting API.

If you follow a design like this and you decide to implement only one of the transportation methods, that's fine. It's a minimal amount of work to implement more transportation API's later and they are totally independent of the rest of the code. And best of all, following a solid design like this will probably even make easier to code it all.

I don't want to act like you couldn't think(/haven't though) of this yourself, I just got a bit carried away. :D/> (I will need to hold myself in order to not start on it myself. :P/>)

Orwell, on 01 February 2013 - 05:05 AM said:

I don't want to act like you couldn't think(/haven't though) of this yourself, I just got a bit carried away. :D/>/>/> (I will need to hold myself in order to not start on it myself. :P/>/>/>)

My design skills are severely rusty so it's good to get this input. It's been a long time since I've done any significant amount of object-oriented programming, I've mostly been using package tools and patching the gaps with little Perl scripts for the last 15 years or so.

The biggest problem is that I'm impatient, I want to see something happening right away, so I tend to bodge things together and code myself into a corner.

PhilHibbs, on 01 February 2013 - 05:12 AM said:

Orwell, on 01 February 2013 - 05:05 AM said:

I don't want to act like you couldn't think(/haven't though) of this yourself, I just got a bit carried away. :D/>/> (I will need to hold myself in order to not start on it myself. :P/>/>)

My design skills are severely rusty so it's good to get this input. It's been a long time since I've done any significant amount of object-oriented programming, I've mostly been using package tools and patching the gaps with little Perl scripts for the last 15 years or so.

You've been in the game for a long time it seems. :P/> I'd love to get some feedback on the design if you have the time to think about it. If you could find any hick-ups or errors, we could improve this to the point of an optimal design. :)/> (doesn't mean I want to interfere with your coding though)

Orwell, on 01 February 2013 - 05:18 AM said:

You've been in the game for a long time it seems.

I wrote my first program in 1977 or 1978. I was 9 years old.