I did actually think of that. But I need to put a stack of items in the retriever, and those need to be real items, because otherwise a player could take them out.
Say you make a table that decompresses diamond blocks into 9 diamonds, and put it in retriever mode. Then every time it activates the retriever, you open the retriever's GUI and take out a stack of diamond blocks... see the problem?
Maybe it could have a separate 3x3 grid for extra items that it can use to retrieve.
It would probably trigger the retriever itself similar to the buffer. To stop it I suppose I could make a completely useless item that the table could spawn in the retriever's inventory just to stop it from accepting other items. If I made the retriever side have no slots, the retriever would accept one more item stack before stopping.
Ok, here it is, bit by bit. I could look up the exact syntax to make this into code that you can just paste in, but I'm not sure I've sold you on the idea, yet. I have thought of solutions to every problem.
if {modloaded (Redpower.Machine)} //We can't reference the retriever class to see if it exists if machine is not loaded
{
If{TickCounter % 200 == 0) //do this every 10 seconds real time
{
if{ GetBlock( x, y, z+1) instanceof (Eloraam.Machine.Retriever)) //check 1 block above (or any arbitrary side) to find a retriever.
{
InitializeRecipeVector(blahvector())
TotalUpRecipeCounts(blahvector()); //Check every slot in the entire ACT II. If the item in the slot matches one of the items in the recipe, increment an array. This starts with a vector like this [0 0 0 0 0 0 0 0 0], compares it to the recipe, so you end up with a vector like this [ 1 1 -1 -1 -1 -1 -1 -1 -1 ] if there was just 2 stone at the top of the recipe. Now, it checks the count. Suppose there is 28 stone in our ACT II's slots : then when this function returns it will look like this [ 29 1 -1 -1 -1 -1 -1 ]. It stops counting if there's more than 64, so if there was 10 stacks of stone in the ACT II, then it would return this [64 64 -1 -1 -1 -1 -1 -1 -1]
for (loop over the vector)
{ if(blahvector[x].Count > 2 && blahvector[x].Count < 64)
ItemNeeded = blahvector[x];
MoveSpecialSlotTOMainInventory() //The special slot is the ONE slot the retriever is allowed to access. We only ever move the contents of this slot to the main inventory, emptying it, if we need the retriever to get us an item.
}
if (ItemNeeded == Null)
{ RedistributeCounts(); Return(); } // This makes sure there is at least TWO of each item type kept in reserve in the recipe slot. That way there is 1 to stick in the retriever, and one
//to hold in reserve. It makes sure each recipe slot has at least 2 items (sticking excess back in the main storage) if the items exist in inventory. Once we have done this, we return, we'll see if there's an item to retrieve next time;
MoveRetrieverInventoryToMainStorage (); // this finds the main inventory slots of the retriever by cheating on the side it is looking from, takes everything out of the retriever's main inventory, and puts it in the inventory of the ACT II.
MoveToRetriever(ItemNeeded.Count-2) //all but 2 of the item needed, up to a maximum of 1 full stack, are moved into the retriever.
UpdateRedstone(); //Turn on redstone for the ACT II which will activate the retriever
SetFlag(); // This flag when turned on means that later the ACT II will turn off the redstone it is emitting when a few ticks have passed.
GetISidedInventory
{
Case Top : ReturnSpecialSlot
}
else ThrowException //Redpower was not loaded
Here's why it works : If and only if we have less than 64 of a needed item for a crafting recipe for a particular slot of that recipe (or 1 item if the item is not stackable), AND if we have at least 2 items, we stick one of the items we need into the retrievers slot and send a pulse to that retriever every 10 seconds. We make as big of a stack as we can of that needed item, up to a full stack, in the slot of the otherwise empty retriever. (we empty it into the ACT II)
Once we have at least a stack of that item in the ACT II, we either move a different item into the retriever, or shut it down.
This method means that AT MOST, you would have 2-3 full stacks of each item in the crafting recipe for an item present in the ACT-II. You can never have more than that retrieved automatically, because the retriever only can place items into a single slot. You also need a couple of extra slots just in case, but the ACT-II would work fine with a total of 27 storage slots + 1 slot for the output.
Thinking about it (there are a few cases I only thought of when I typed this, and there's some issues with my pseudo-code code related to performance and edge cases), I realize that it really needs a prototype and to be tested heavily. However, this code isn't all that complex : it doesn't have to store any information to disk, it doesn't have to remember prior states, all it has to do to work is to figure out what the ACT-II needs the most, right now.
I think the most elegant implementation would be to stick an item shuffling robot that would go on the side of a retriever and somehow be linked to a corresponding ACT-II. You stick a copy of the recipe into this robot, giving it anywhere from 1 item for each recipe element to a full stack. (if the player gives it a full stack, that means the retriever will grab a full stack at a time).
The robot has exactly 9 inventory slots, and it checks a 4x4 area around itself for a corresponding ACT-II that has a matching recipe. It will link to the first one it finds that has a matching recipe, telling the player it found one in the GUI.
The robot is the one that needs a blulectric motor in it. So this robot + a retriever + an ACT-II == Logistic Pipe + BC table.
Thanks for developing this wonderful addition to Redpower.
That said, is there any chance that you would consider making your crafting tables "screwdriver-compatible"?
Also, is there any plans to have your crafting tables make use of items that are inside inventories attached to the table (Similar to how BC's Crafting Table is able to use items from inventories attached to it)?
i have an issue in smp in wich the stubestuff mod is loading before both redpower and buildcraft and thus you are unable to craft the the buffer or the automatic crafting table. i though that modloader loaded the mod in aphabetical order and thus the tube stuff should load after well after redpower and buildcraft, weird, renaming to ztubestuff_49.0.0_for_1.2.5-server works though
edit: it seems more like it randomly decides to enable or disable the recipe every time the server restarts :S
Thanks for developing this wonderful addition to Redpower.
That said, is there any chance that you would consider making your crafting tables "screwdriver-compatible"?
Also, is there any plans to have your crafting tables make use of items that are inside inventories attached to the table (Similar to how BC's Crafting Table is able to use items from inventories attached to it)?
Have fun!
Hmm, I thought I replied to this post ages ago, but apparently the forum ate it.
There are no plans to make the screwdriver work with the crafting table, but it may or may not in the future.
There are no plans to make the crafting table take items from chests, because each side except the top acts like a mini-chest - why do you need it? There's probably some reason I've overlooked.
Also, released 49.0.2. Includes the incinerator (requested by Kane_Hart as an easy way to prevent lag-causing item overflow) and the duplicator (Admin only; requested by ElectroBot so his dungeon will never run out of reward items)
49.0.2 version just broke the game. Log: java.lang.ArrayIndexOutOfBoundsException: 3
at fr.a(CraftingManager.java:135)
at ModLoader.addRecipe(ModLoader.java:401)
at immibis.tubestuff.SharedProxy.ModsLoaded(SharedProxy.java:220)
at mod_TubeStuff.modsLoaded(mod_TubeStuff.java:93)
at ModLoader.init(ModLoader.java:899)
at ModLoader.addAllRenderers(ModLoader.java:189)
at ahu.<init>(RenderManager.java:86)
at ahu.<clinit>(RenderManager.java:14)
at net.minecraft.client.Minecraft.a(Minecraft.java:394)
at net.minecraft.client.Minecraft.run(Minecraft.java:732)
at java.lang.Thread.run(Unknown Source)
--- END ERROR REPORT 5d8072d ----------
Rollback Post to RevisionRollBack
Hello, I'm only studying english so forgive my grammar errors.
Hmm, I thought I replied to this post ages ago, but apparently the forum ate it.
There are no plans to make the screwdriver work with the crafting table, but it may or may not in the future.
There are no plans to make the crafting table take items from chests, because each side except the top acts like a mini-chest - why do you need it? There's probably some reason I've overlooked.
Also, released 49.0.2. Includes the incinerator (requested by Kane_Hart as an easy way to prevent lag-causing item overflow) and the duplicator (Admin only; requested by ElectroBot so his dungeon will never run out of reward items)
Awesome! Thanks.
Now off to design more outposts/dungeons with PvP arena areas for the Industrialcraft PvP server.
Just played a bit in single player and I've found that the duplicator (NEI'ed it in) doesn't remember what it needs to duplicate if you unload and reload the world.
not real good with java but judging by the things written in the error report (and the fact that removing your mod works fine) I'm guessing it's your business stuff...
Minecraft has stopped running because it encountered a problem.
--- BEGIN ERROR REPORT e4a729f4 --------
Generated 06/06/12 18.30
Minecraft: Minecraft 1.2.5
OS: Windows 7 (amd64) version 6.1
Java: 1.6.0_31, Sun Microsystems Inc.
VM: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Sun Microsystems Inc.
LWJGL: 2.4.2
OpenGL: ATI Radeon HD 5670 version 4.1.10750 Compatibility Profile Context, ATI Technologies Inc.
java.lang.NullPointerException
at pb.<init>(Block.java:263)
at agy.<init>(BlockContainer.java:7)
at immibis.core.BlockCombined.<init>(BlockCombined.java:35)
at immibis.tubestuff.BlockTubestuff.<init>(BlockTubestuff.java:17)
at mod_TubeStuff$1.registerBlock(mod_TubeStuff.java:40)
at immibis.core.CoreProxy.RegisterBlockID(CoreProxy.java:31)
at mod_TubeStuff.load(mod_TubeStuff.java:37)
at cpw.mods.fml.common.modloader.ModLoaderModContainer.init(ModLoaderModContainer.java:319)
at cpw.mods.fml.common.Loader.modInit(Loader.java:262)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:591)
at cpw.mods.fml.client.FMLClientHandler.onLoadComplete(FMLClientHandler.java:230)
at net.minecraft.client.Minecraft.a(Minecraft.java:426)
at hq.a(MinecraftImpl.java:34)
at net.minecraft.client.Minecraft.run(Minecraft.java:735)
at java.lang.Thread.run(Unknown Source)
--- END ERROR REPORT df548809 ----------
I'm using the latest vers of forge... could be that the issue?
not real good with java but judging by the things written in the error report (and the fact that removing your mod works fine) I'm guessing it's your business stuff...
Minecraft has stopped running because it encountered a problem.
--- BEGIN ERROR REPORT e4a729f4 --------
Generated 06/06/12 18.30
Minecraft: Minecraft 1.2.5
OS: Windows 7 (amd64) version 6.1
Java: 1.6.0_31, Sun Microsystems Inc.
VM: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Sun Microsystems Inc.
LWJGL: 2.4.2
OpenGL: ATI Radeon HD 5670 version 4.1.10750 Compatibility Profile Context, ATI Technologies Inc.
java.lang.NullPointerException
at pb.<init>(Block.java:263)
at agy.<init>(BlockContainer.java:7)
at immibis.core.BlockCombined.<init>(BlockCombined.java:35)
at immibis.tubestuff.BlockTubestuff.<init>(BlockTubestuff.java:17)
at mod_TubeStuff$1.registerBlock(mod_TubeStuff.java:40)
at immibis.core.CoreProxy.RegisterBlockID(CoreProxy.java:31)
at mod_TubeStuff.load(mod_TubeStuff.java:37)
at cpw.mods.fml.common.modloader.ModLoaderModContainer.init(ModLoaderModContainer.java:319)
at cpw.mods.fml.common.Loader.modInit(Loader.java:262)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:591)
at cpw.mods.fml.client.FMLClientHandler.onLoadComplete(FMLClientHandler.java:230)
at net.minecraft.client.Minecraft.a(Minecraft.java:426)
at hq.a(MinecraftImpl.java:34)
at net.minecraft.client.Minecraft.run(Minecraft.java:735)
at java.lang.Thread.run(Unknown Source)
--- END ERROR REPORT df548809 ----------
I'm using the latest vers of forge... could be that the issue?
That's a weird error. Try recommended Forge, since latest has some issues. (That means you'd need ModLoader, since the recommended build was before FML went client side)
Just played a bit in single player and I've found that the duplicator (NEI'ed it in) doesn't remember what it needs to duplicate if you unload and reload the world.
That is a weird error.
That's a weird error. Try recommended Forge, since latest has some issues. (That means you'd need ModLoader, since the recommended build was before FML went client side)
that's bad I can't use the recommended Forge the last Forestry update requires the quite last forge vers... also I'm guessing you'll have to make some compatibility for it in the future so why not now?
that's bad I can't use the recommended Forge the last Forestry update requires the quite last forge vers... also I'm guessing you'll have to make some compatibility for it in the future so why not now?
Actually, looking at recent Forge changes I think I see the problem - it's not a bug in Forge, just a change that accidentally broke compatibility.
I did actually think of that. But I need to put a stack of items in the retriever, and those need to be real items, because otherwise a player could take them out.
Say you make a table that decompresses diamond blocks into 9 diamonds, and put it in retriever mode. Then every time it activates the retriever, you open the retriever's GUI and take out a stack of diamond blocks... see the problem?
Maybe it could have a separate 3x3 grid for extra items that it can use to retrieve.
It would probably trigger the retriever itself similar to the buffer. To stop it I suppose I could make a completely useless item that the table could spawn in the retriever's inventory just to stop it from accepting other items. If I made the retriever side have no slots, the retriever would accept one more item stack before stopping.
Ok, here it is, bit by bit. I could look up the exact syntax to make this into code that you can just paste in, but I'm not sure I've sold you on the idea, yet. I have thought of solutions to every problem.
if {modloaded (Redpower.Machine)} //We can't reference the retriever class to see if it exists if machine is not loaded
{
If{TickCounter % 200 == 0) //do this every 10 seconds real time
{
if{ GetBlock( x, y, z+1) instanceof (Eloraam.Machine.Retriever)) //check 1 block above (or any arbitrary side) to find a retriever.
{
InitializeRecipeVector(blahvector())
TotalUpRecipeCounts(blahvector()); //Check every slot in the entire ACT II. If the item in the slot matches one of the items in the recipe, increment an array. This starts with a vector like this [0 0 0 0 0 0 0 0 0], compares it to the recipe, so you end up with a vector like this [ 1 1 -1 -1 -1 -1 -1 -1 -1 ] if there was just 2 stone at the top of the recipe. Now, it checks the count. Suppose there is 28 stone in our ACT II's slots : then when this function returns it will look like this [ 29 1 -1 -1 -1 -1 -1 ]. It stops counting if there's more than 64, so if there was 10 stacks of stone in the ACT II, then it would return this [64 64 -1 -1 -1 -1 -1 -1 -1]
for (loop over the vector)
{ if(blahvector[x].Count > 2 && blahvector[x].Count < 64)
ItemNeeded = blahvector[x];
MoveSpecialSlotTOMainInventory() //The special slot is the ONE slot the retriever is allowed to access. We only ever move the contents of this slot to the main inventory, emptying it, if we need the retriever to get us an item.
}
if (ItemNeeded == Null)
{ RedistributeCounts(); Return(); } // This makes sure there is at least TWO of each item type kept in reserve in the recipe slot. That way there is 1 to stick in the retriever, and one
//to hold in reserve. It makes sure each recipe slot has at least 2 items (sticking excess back in the main storage) if the items exist in inventory. Once we have done this, we return, we'll see if there's an item to retrieve next time;
MoveRetrieverInventoryToMainStorage (); // this finds the main inventory slots of the retriever by cheating on the side it is looking from, takes everything out of the retriever's main inventory, and puts it in the inventory of the ACT II.
MoveToRetriever(ItemNeeded.Count-2) //all but 2 of the item needed, up to a maximum of 1 full stack, are moved into the retriever.
UpdateRedstone(); //Turn on redstone for the ACT II which will activate the retriever
SetFlag(); // This flag when turned on means that later the ACT II will turn off the redstone it is emitting when a few ticks have passed.
GetISidedInventory
{
Case Top : ReturnSpecialSlot
}
else ThrowException //Redpower was not loaded
Here's why it works : If and only if we have less than 64 of a needed item for a crafting recipe for a particular slot of that recipe (or 1 item if the item is not stackable), AND if we have at least 2 items, we stick one of the items we need into the retrievers slot and send a pulse to that retriever every 10 seconds. We make as big of a stack as we can of that needed item, up to a full stack, in the slot of the otherwise empty retriever. (we empty it into the ACT II)
Once we have at least a stack of that item in the ACT II, we either move a different item into the retriever, or shut it down.
This method means that AT MOST, you would have 2-3 full stacks of each item in the crafting recipe for an item present in the ACT-II. You can never have more than that retrieved automatically, because the retriever only can place items into a single slot. You also need a couple of extra slots just in case, but the ACT-II would work fine with a total of 27 storage slots + 1 slot for the output.
Thinking about it (there are a few cases I only thought of when I typed this, and there's some issues with my pseudo-code code related to performance and edge cases), I realize that it really needs a prototype and to be tested heavily. However, this code isn't all that complex : it doesn't have to store any information to disk, it doesn't have to remember prior states, all it has to do to work is to figure out what the ACT-II needs the most, right now.
I think the most elegant implementation would be to stick an item shuffling robot that would go on the side of a retriever and somehow be linked to a corresponding ACT-II. You stick a copy of the recipe into this robot, giving it anywhere from 1 item for each recipe element to a full stack. (if the player gives it a full stack, that means the retriever will grab a full stack at a time).
The robot has exactly 9 inventory slots, and it checks a 4x4 area around itself for a corresponding ACT-II that has a matching recipe. It will link to the first one it finds that has a matching recipe, telling the player it found one in the GUI.
The robot is the one that needs a blulectric motor in it. So this robot + a retriever + an ACT-II == Logistic Pipe + BC table.
I already do.
Thanks for developing this wonderful addition to Redpower.
That said, is there any chance that you would consider making your crafting tables "screwdriver-compatible"?
Also, is there any plans to have your crafting tables make use of items that are inside inventories attached to the table (Similar to how BC's Crafting Table is able to use items from inventories attached to it)?
Have fun!
edit: it seems more like it randomly decides to enable or disable the recipe every time the server restarts :S
Hmm, I thought I replied to this post ages ago, but apparently the forum ate it.
There are no plans to make the screwdriver work with the crafting table, but it may or may not in the future.
There are no plans to make the crafting table take items from chests, because each side except the top acts like a mini-chest - why do you need it? There's probably some reason I've overlooked.
Also, released 49.0.2. Includes the incinerator (requested by Kane_Hart as an easy way to prevent lag-causing item overflow) and the duplicator (Admin only; requested by ElectroBot so his dungeon will never run out of reward items)
java.lang.ArrayIndexOutOfBoundsException: 3
at fr.a(CraftingManager.java:135)
at ModLoader.addRecipe(ModLoader.java:401)
at immibis.tubestuff.SharedProxy.ModsLoaded(SharedProxy.java:220)
at mod_TubeStuff.modsLoaded(mod_TubeStuff.java:93)
at ModLoader.init(ModLoader.java:899)
at ModLoader.addAllRenderers(ModLoader.java:189)
at ahu.<init>(RenderManager.java:86)
at ahu.<clinit>(RenderManager.java:14)
at net.minecraft.client.Minecraft.a(Minecraft.java:394)
at net.minecraft.client.Minecraft.run(Minecraft.java:732)
at java.lang.Thread.run(Unknown Source)
--- END ERROR REPORT 5d8072d ----------
Ok, that'll be fixed in 49.0.3 once it's reobfuscated and uploaded (usually takes around 10 minutes)
Edit: Done
Awesome! Thanks.
Now off to design more outposts/dungeons with PvP arena areas for the Industrialcraft PvP server.
Thanks
Optifine OptiFine_1.2.5_HD_MT_C2
Minecraft Forge 3.2.5.124
FML v2.2.22.121
Forge Mod Loader version 2.2.22.121 for Minecraft 1.2.5
mod_CodeChickenCore : Initialized (minecraft.jar)
mod_MinecraftForge : Initialized (minecraft.jar)
mod_NotEnoughItems : Initialized (minecraft.jar)
mod_ReiMinimap : Initialized ([1.2.5]ReiMinimap_v3.1.zip)
mod_BrewGuide : Initialized (BrewGuide.zip)
mod_CraftGuide : Initialized (CraftGuide-1.4.4.zip)
mod_EE : Initialized (EE2ClientV1.4.5.1.jar)
mod_ImmibisCore : Initialized (immibis-core_49.0.2_for_1.2.5-client.jar)
mod_IC2 : Initialized (industrialcraft-2-client_1.95b.jar)
mod_AddonTimeMachine : Initialized (mod_Fossil.zip)
mod_Fossil : Initialized (mod_Fossil.zip)
mod_RedPowerControl : Initialized (RedPowerControl-2.0pr5b2.zip)
mod_RedPowerCore : Initialized (RedPowerCore-2.0pr5b2.zip)
mod_RedPowerLighting : Initialized (RedPowerLighting-2.0pr5b2.zip)
mod_RedPowerLogic : Initialized (RedPowerLogic-2.0pr5b2.zip)
mod_RedPowerMachine : Initialized (RedPowerMachine-2.0pr5b2.zip)
mod_RedPowerWiring : Initialized (RedPowerWiring-2.0pr5b2.zip)
mod_RedPowerWorld : Initialized (RedPowerWorld-2.0pr5b2.zip)
mod_TubeStuff : Pre-initialized (tubestuff_49.0.3_for_1.2.5-client.jar)
Balkon's WeaponMod : Pre-initialized (WeaponMod.zip)
mod_Forestry : Pre-initialized (zzz-forestry-client-A-1.4.6.2.jar)
mod_BuildCraftZFP : Pre-initialized (zzz-forestry-client-A-1.4.6.2.jar)
mod_ThaumCraft : Pre-initialized (ThaumCraft2.1.6b.zip)
Minecraft has crashed!
----------------------
Minecraft has stopped running because it encountered a problem.
--- BEGIN ERROR REPORT e4a729f4 --------
Generated 06/06/12 18.30
Minecraft: Minecraft 1.2.5
OS: Windows 7 (amd64) version 6.1
Java: 1.6.0_31, Sun Microsystems Inc.
VM: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Sun Microsystems Inc.
LWJGL: 2.4.2
OpenGL: ATI Radeon HD 5670 version 4.1.10750 Compatibility Profile Context, ATI Technologies Inc.
java.lang.NullPointerException
at pb.<init>(Block.java:263)
at agy.<init>(BlockContainer.java:7)
at immibis.core.BlockCombined.<init>(BlockCombined.java:35)
at immibis.tubestuff.BlockTubestuff.<init>(BlockTubestuff.java:17)
at mod_TubeStuff$1.registerBlock(mod_TubeStuff.java:40)
at immibis.core.CoreProxy.RegisterBlockID(CoreProxy.java:31)
at mod_TubeStuff.load(mod_TubeStuff.java:37)
at cpw.mods.fml.common.modloader.ModLoaderModContainer.init(ModLoaderModContainer.java:319)
at cpw.mods.fml.common.Loader.modInit(Loader.java:262)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:591)
at cpw.mods.fml.client.FMLClientHandler.onLoadComplete(FMLClientHandler.java:230)
at net.minecraft.client.Minecraft.a(Minecraft.java:426)
at hq.a(MinecraftImpl.java:34)
at net.minecraft.client.Minecraft.run(Minecraft.java:735)
at java.lang.Thread.run(Unknown Source)
--- END ERROR REPORT df548809 ----------
That's a weird error. Try recommended Forge, since latest has some issues. (That means you'd need ModLoader, since the recommended build was before FML went client side)
Fixed in 49.0.4.
that's bad I can't use the recommended Forge the last Forestry update requires the quite last forge vers... also I'm guessing you'll have to make some compatibility for it in the future so why not now?
Actually, looking at recent Forge changes I think I see the problem - it's not a bug in Forge, just a change that accidentally broke compatibility.
Download
I don't know anything about Bukkit, not even how to install it normally. But this runs fine in Eclipse as far as I can tell.
You fracking troll I can't click that haha.
Check out my Let's Play Series: