I searched the forums with no luck so If this has already been asked plis link me to the topic.
I was wondering if someone knows how long does the cauldron/crucible/kiln take to burn/cook/smelt a single process. I know it depends on the amount of hibachis you have below with a minimun of 1 and a maximun of 9.
Are there any other dependencies?
Could you FC share the formula they use?
Does the cauldron/crucible output any kind of redstone signal when all is cooked as the hoppers do when they are nearly full?
Does a buddy block detect smelting/cooking?
The main goal of this information gathering is to make an automatic mob-trap-drop processing and storage and for it I need to smelt tools and armor into ingots, bows into sticks and string, rotten arrows into flint, and rotten flesh + sugar + previouslly grinded bones into kibble and I would like to be able to use the emptying ability from both of them when applying mechanical power to storage it after cooked. The kiln data is mainly for my autokiln design but as it also works with hibachis I thought I could it include it in the same topic. It does make sense, doesn't it?
P.S.: I would test some of the features myself (as the redstone signal or the buddy block one) but I don't have my computer abailable.
3: no. However, you can either control the imput (via a dispenser) and time it precisely, or you can make it empty every now and then (cauldrons and such have a big inventory) based solely on timing.
4: i don't think so.
Look, items decay after 5 minutes. that's more than enough time to put a piston above your crucible to stop the input, make it tip to empty, and get it back up and retract the piston to make it fill up again.
It strongly depends on the amount of items that enter your system tho, and i don't think you can do the timing system without at least some inefficiencies. (unless you alter between two crucibles and thus leave ample time to cook/render/smelt all the resources before it has to tip again)
devak wrote:No, processing time is only dependent on hibachi Perfect, one less thin to worry about.
2: i don't think he will Will wait for his answer if he wills to
3: no. However, you can either control the imput (via a dispenser) and time it precisely, or you can make it empty every now and then (cauldrons and such have a big inventory) based solely on timing. There si a problem here, you could have a vDispenser with no items making the system think he input the right ammount when that is false, making the output to not be the desired one.
For avoiding this you could try to count the items your vDispenser have, what will need quite huge counter that can go forward and backward. BD based-counter won't work as it can go bacward and redstone-based counter would be just huge. Furthermore, even you can assure that a vDispenser will only output one item per pulse and you could detect it with a DB easily but the vDispenser input won't be single items, for example arrows usually come in pairs so that would make the dispenser to count wrongly. So the counting how many items are in the dispenser method is inpractical.
Another way would be counting the items in the cauldron. vDispenser hooked to a clock. A DB detects the output of the dispenser. It is attached to a BD that counts how many the dispenser has to shoot (if you need n items from that dispenser, n-1 slabs and a block with a redstone torch below where this items are placed by the DB). This output is send to the set wire of an RS Latch, that turns off the clock and turns on the timer for the cook/burn/smelt process. When the fool cook/burn/smelt-turn crucible/cauldron-turn it back process has finished you reset the RS Latch reactivating the clock. If you have a multiple items recipe, the cook/burn/smelt process will only start when all the items are in the crucible/cauldron (all RS latches to an AND gate).
This method is my option B if I don't find any other better way to do it but I would like to find an easier way.
4: i don't think so. Was pretty sure it didn't but just wondering if someone with minecraft available could test it.
Look, items decay after 5 minutes. that's more than enough time to put a piston above your crucible to stop the input, make it tip to empty, and get it back up and retract the piston to make it fill up again. I know this, I was just wondering what kind of system should I use to start this loop. A timer, a reactive system (redstone signal, BB. etc), etc
It strongly depends on the amount of items that enter your system tho, and i don't think you can do the timing system without at least some inefficiencies. (unless you alter between two crucibles and thus leave ample time to cook/render/smelt all the resources before it has to tip again)
You could just go for a "dumb" system and use two crucibles and have the input alternate between the two:
Crucible 1 receives a certain amount of iron tools and stuff
after 1 minute the input switches to Crucible 2
The average output per minute should be known, so you can calculate the alternation time. in 1 minute it can smelt a standard amount of items, and since the output alternates, it has roughly 50 seconds of smelting added to the previous 1 minute. (i really hope this makes sense)
Crucible 2 receives metal stuff and starts smelting, while Crucible 1 is still smelting the metal it received.
After a set amount of time, before the input switches again, Crucible 1 tips and empties.
Crucible 1 is now empty, the input switches from Crucible 2 to Crucible 1.
Crucible 2 continues smelting what it received, Crucible 1 is filling up and smelting as it goes along.
etc.
Downside: the input speed can not be much higher than 1 crucible can smelt. This is due to inefficiencies in the 1st minute (the crucible can be left without smeltables for some time, so it looses capacity).
This is slightly more difficult for stuff like making kibble, but here you need millstones to process the bones anyway so you get a more or less stable output buffer.
Siege Wizard wrote:[*]Could you FC share the formula they use?
Don't wait on that, he won't ;)
Just make a quick test with the maximum number of Hibachis you could put in your setup, I usually use 8 as it's fairly quick and leave some room for extracting the output in the most compact way.
Siege Wizard wrote:[*]Could you FC share the formula they use?
Don't wait on that, he won't ;)
Just make a quick test with the maximum number of Hibachis you could put in your setup, I usually use 8 as it's fairly quick and leave some room for extracting the output in the most compact way.
i'm actually building up in resources to run the test, but until know I threw all my rotten arrows in a cauldron so I'll have to get a couple of stacks first so that I get a good aproximation.
About the 8 hibachi set up, if you turn your cauldron/crucible, won't it get burned due to the near stoked fire while falling down? Or does it only burn down items in the blocks where the fire is?
Some tests with cobble to smooth in a crucible in a 9 hibachi set up says that each unit last 7.5 sec, or what is the same, 8 units/min. The crucible actually is not that important as it will only get armor/tools to smelt and they shouldn't drop too many of them, and by too many I mean 8 tools/armor per minute, so closing the input, waiting for 15 secs (just in case you just got two of them in that instant), applying mechanical power, unpowering it and opening the input again and you shouldn't have any kind of problem. I'm more worried about the cauldron as rotten flesh, bones and rotten arrows are much more common. Will test them when I build some amount of arrows or when I finish the bone/arrow string/scroll sorting.
My last mob trap processing design I simply didn't bother with a gate to stop item flow. I had a secondary filter to dump any unprocessed bows into a chest that either didn't get finished when the cauldron got tipped or dropped while it was tipped. I cleared it out manually every 4 hours in game or so as that was when I usually grabbed the xp anyway.
I was intending to create a better and fully auto system above using a 4 minute timer on the cauldron with a 20 sec delay to opening a gate but my semi auto solution was adequate while I worked on other projects.
