I have run into this error when trying to instal Tubestuff on my server:
Not sure what is causing it, since I know for a fact that I have RP2 machine installed.
mod_TubeStuff: RP2 Machine doesn't seem to be installed
java.lang.NullPointerException
at kp.<init>(SourceFile:42)
at immibis.tubestuff.SharedProxy.ModsLoaded(SharedProxy.java:143)
at mod_TubeStuff.modsLoaded(mod_TubeStuff.java:72)
at cpw.mods.fml.server.ModLoaderModContainer.postInit(ModLoaderModContai
ner.java:277)
at cpw.mods.fml.common.Loader.postModInit(Loader.java:236)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:540)
at cpw.mods.fml.server.FMLServerHandler.onLoadComplete(FMLServerHandler.
java:127)
at net.minecraft.server.MinecraftServer.s(MinecraftServer.java:203)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:411)
at dn.run(SourceFile:492)
2012-05-12 15:14:28 [SEVERE] Unexpected exception
java.lang.NullPointerException
at kp.<init>(SourceFile:42)
at immibis.tubestuff.SharedProxy.ModsLoaded(SharedProxy.java:143)
at mod_TubeStuff.modsLoaded(mod_TubeStuff.java:72)
at cpw.mods.fml.server.ModLoaderModContainer.postInit(ModLoaderModContai
ner.java:277)
at cpw.mods.fml.common.Loader.postModInit(Loader.java:236)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:540)
at cpw.mods.fml.server.FMLServerHandler.onLoadComplete(FMLServerHandler.
java:127)
at net.minecraft.server.MinecraftServer.s(MinecraftServer.java:203)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:411)
at dn.run(SourceFile:492)
Nvm, it was an issue with the block ids not generating.
There is a rare mythical button called "Search" that likes to answer questions; however, due to its nature, it often blends in with its surroundings so as to remain hidden.
mod_TubeStuff: RP2 Machine doesn't seem to be installed
java.lang.NullPointerException
at kp.<init>(SourceFile:42)
at immibis.tubestuff.SharedProxy.ModsLoaded(SharedProxy.java:143)
at mod_TubeStuff.modsLoaded(mod_TubeStuff.java:72)
at cpw.mods.fml.server.ModLoaderModContainer.postInit(ModLoaderModContai
ner.java:277)
at cpw.mods.fml.common.Loader.postModInit(Loader.java:236)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:540)
at cpw.mods.fml.server.FMLServerHandler.onLoadComplete(FMLServerHandler.
java:127)
at net.minecraft.server.MinecraftServer.s(MinecraftServer.java:203)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:411)
at dn.run(SourceFile:492)
2012-05-12 15:14:28 [SEVERE] Unexpected exception
java.lang.NullPointerException
at kp.<init>(SourceFile:42)
at immibis.tubestuff.SharedProxy.ModsLoaded(SharedProxy.java:143)
at mod_TubeStuff.modsLoaded(mod_TubeStuff.java:72)
at cpw.mods.fml.server.ModLoaderModContainer.postInit(ModLoaderModContai
ner.java:277)
at cpw.mods.fml.common.Loader.postModInit(Loader.java:236)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:540)
at cpw.mods.fml.server.FMLServerHandler.onLoadComplete(FMLServerHandler.
java:127)
at net.minecraft.server.MinecraftServer.s(MinecraftServer.java:203)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:411)
at dn.run(SourceFile:492)
Nvm, it was an issue with the block ids not generating.
That's an actual bug that can only happen if Core loads after Tubestuff and the block ID isn't already set. Shouldn't be hard to fix.
--- BEGIN ERROR REPORT 362ee647 --------
Generated 5/12/12 5:19 PM
Minecraft: Minecraft 1.2.5
OS: Mac OS X (x86_64) version 10.7.2
Java: 1.6.0_29, Apple Inc.
VM: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Apple Inc.
LWJGL: 2.8.3
OpenGL: NVIDIA GeForce 9400 OpenGL Engine version 2.1 NVIDIA-7.12.9, NVIDIA Corporation
java.lang.NoClassDefFoundError: immibis/core/CompatibleBaseMod
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at ModLoader.addMod(ModLoader.java:289)
at ModLoader.readFromModFolder(ModLoader.java:1276)
at ModLoader.init(ModLoader.java:887)
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(Thread.java:680)
Caused by: java.lang.ClassNotFoundException: immibis.core.CompatibleBaseMod
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 20 more
--- END ERROR REPORT f0a50216 ----------
This is my error report. I am able to run just the immbis core by itself but if i run the tubestuff part as well it crashes. I am using 48.2.1 for both core and mod. Any thoughts?
Normally that means you didn't install Core, but if you did then that obviously isn't the problem.
Maybe it's a load order problem. Are you on Windows or Linux or Mac (or something else), and did you rename either mod's jar file?
I am running into an issue with rp2 machines jamming when trying to send materials to the ACT.
Images
Still Plenty of room.
Runs 1 time and then the transposer(filter jams too) next to the alchemical chest jams. You can tell by the fact that the bellow is still down, even so there is no signal.
After watching a bit more closely. It appears you have left over buffer code in the act. Each side, excluding the top and bottom has its own buffer, the combined sizes of which, appear to be smaller then the actual inventory shown in the top.
Secondly. I had trouble crafting the ACT. When trying to remove the block from the crafting table, it would constantly flicker back to the output slot, much like it would if the block ids did not match. But as you can see from the pictures showing the jamming issue, the block ids between server and client do match since I was able to spawn it in directly with NEI.
There is a rare mythical button called "Search" that likes to answer questions; however, due to its nature, it often blends in with its surroundings so as to remain hidden.
I am running on a Mac with OS 10.7.2 if that helps any. I am however using the MultiMC program. However what i do is i install the core into the jar file, run the game, (it works every time) then i install the tubestuff mod, which is where it crashes.
No, i did not alter/rename either in any way.
So from what i understand, Core should be installed before the actual mod is, but MultiMC might install everymod every time it load up or something. I really dont know
I think if you put a mod in the jar file when it should be in the mods folder, it gets loaded after mods from the mods folder. Try putting both in mods.
After watching a bit more closely. It appears you have left over buffer code in the act. Each side, excluding the top and bottom has its own buffer, the combined sizes of which, appear to be smaller then the actual inventory shown in the top.
Each side is only supposed to use one row of the inventory. If each side isn't using its own row, that's a bug.
Secondly. I had trouble crafting the ACT. When trying to remove the block from the crafting table, it would constantly flicker back to the output slot, much like it would if the block ids did not match. But as you can see from the pictures showing the jamming issue, the block ids between server and client do match since I was able to spawn it in directly with NEI.
Check the load order, perhaps. Tubestuff should load after BC and/or RP (whichever you have) on both sides.
I think if you put a mod in the jar file when it should be in the mods folder, it gets loaded after mods from the mods folder. Try putting both in mods.
Each side is only supposed to use one row of the inventory. If each side isn't using its own row, that's a bug.
Check the load order, perhaps. Tubestuff should load after BC and/or RP (whichever you have) on both sides.
Ah I see now. I was being confused by the bottom buffer and how it forms a diagonal line in the inventory.
I have tubes inputting cobble on all sides except top and bot. For some reason the buffer for bot is spread out along the last 4 lines of inventory.
Could you add a button that makes it act like one huge inventory? That way one does not need to surround the the bottom and sides with tubes to fill it all the way.
There is a rare mythical button called "Search" that likes to answer questions; however, due to its nature, it often blends in with its surroundings so as to remain hidden.
In Tubestuff i wish i could turn off Buffer since Redpower has one and its Causesing my OCD to drive me insane.
Rollback Post to RevisionRollBack
IM NOT BLUE XEPHOS I ACCIDENTLY NAMED MY SELF CLOSE... I DIDENT KNOW XEPHOS EXISTED UNTIL LATER IN MY ACCOUNT (i honestly dident know some one with 2 letters off from me existed when i started my account.).
Ah I see now. I was being confused by the bottom buffer and how it forms a diagonal line in the inventory.
I have tubes inputting cobble on all sides except top and bot. For some reason the buffer for bot is spread out along the last 4 lines of inventory.
Could you add a button that makes it act like one huge inventory? That way one does not need to surround the the bottom and sides with tubes to fill it all the way.
O_o. It's not supposed to do that. I'll look at it when I have time.
Compiling an untested fix for the diagonal gaps. It *should* work since I only changed one number, but experience says anything I don't test probably won't work. This will be TS 48.2.2
Yes. Filters and transposers only suck items out of things they're actually touching.
Also I can't reobfuscate and upload the new TS now, since it's 12:30 AM and that can take 40 minutes. Sorry. At least it's not a major bug.
Can you help me out with the design? I want to make an iron ingot and a piece of flint make a flint and steel but I don't understand the advance mechanics. All I want is for the flint and iron ingot to go in, get crafted and a flint and steel to come out. Not very simple for me.
Can you help me out with the design? I want to make an iron ingot and a piece of flint make a flint and steel but I don't understand the advance mechanics. All I want is for the flint and iron ingot to go in, get crafted and a flint and steel to come out. Not very simple for me.
ಥ_ಥ
The output filter/transposer needs to be go right on top of the crafting table - there can't be a tube in between. Also, make sure the side with the big hole is facing down, and make sure to give it a redstone signal each time you want it to take out a crafted item. (Filters take any number of items at a time, transposers only take one; since the recipe for flint and steel makes one item and it's unstackable anyway, it doesn't make a difference here)
Here's a video where I use it heavily. I discovered one limitation when using it in this way : the output slot for items can get stuff placed into it by redpower tubes. Is there any way you can make the output slot not EVER allow an item to be placed in it? One trick would be that if the slot ever becomes empty, report to Forge that the slot no longer exists or something. Or that it contains a fake item that the player cannot take.
Or, the easiest way : if there is an item in the output slot, blocking crafting, move said item to the reject bin.
Is there any way you can make the output slot not EVER allow an item to be placed in it? One trick would be that if the slot ever becomes empty, report to Forge that the slot no longer exists or something.
Latest Update did some serious weirdness. The same autocrafting tables, which were working just fine with the previous edition of tubestuff, now act like this. The 4 input sides no longer "start" in the same place in the GUI, and they are no longer the same stack size, either. Breaking and replacing the tables does not help.
They do still function, more or less, just look messy and no longer have the same number of stacks available to each side.
I wanted to fix the bug with the diagonal slots before doing this, but apparently I've changed too much stuff (TubeStuff is not the only thing I have in MCP, but most of what I've made isn't good enough to release) to compile my MCP workspace in 1.1 and 1.2.3.
So this is the end of 1.1 and 1.2.3 support.
The previous download page is still up, exactly the same as before, although it has a new URL.
Unrelated, how would you guys feel about crafting tables needing blutric motors for the RP recipe? Too expensive? (Pretend the BC recipe doesn't exist; this is supposed to be balanced to RP, the BC recipe is balanced to BC)
Edit: A test version that's fully ported to 1.2.5 will be here in a moment when it finishes reobfuscating. It probably has bugs, but it does at least work in singleplayer (SMP mostly untested so far). Disclaimer because FuzzyPurp: 49.0.0 is a prerelease, it's not tested in SMP and barely in SSP, and I'm just throwing it up here for people who are so annoyed by the diagonal gaps and/or just like finding bugs for some reason.
Unrelated, how would you guys feel about crafting tables needing blutric motors for the RP recipe? Too expensive? (Pretend the BC recipe doesn't exist; this is supposed to be balanced to RP, the BC recipe is balanced to BC)
This gives me an idea. Right now, as I mentioned to you in IRC, the problem with autocrafting in RP is that it's too hard to get the ingredients needed to the tables when they need them. It CAN be done, but it is nowhere near as elegant as say, Logistics pipes. LPs ask for what they actually need to perform the autocrafting.
So I have an idea to fix this that would not take you very long to develop. You create an advanced crafting table II, perhaps with a regulator and some red doped wafers as well as that blutric motor in the recipe. (dunno if you keep the old one, maybe). This table does something special if and only if there is a RETRIEVER directly adjacent to it.
The table accesses the retriever's inventory through Forge (I'm talking about the 3x3 grid that can be accessed from the side, although sneaky pipes prove that you can access any side if you need to). Whichever crafting ingredient for the recipe in the table is MOST NEEDED is placed into the retrievers inventory slot. Everything else in the retriever's inventory is removed as if it had been placed into a table. (so mismatched items go into the reject slot)
Every few seconds, you code sees what is most needed by the table's recipe, and swaps a stack of that into the retriever's retrieval slot. The table also emits a redstone pulse whenever it does this.
Each time it does this swap around, it also switches which slot the retriever can place items into. The retriever would go into a special side on this table (probably the top), and you map this side to whichever slot in the recipe most needs something.
Once a recipe is full satisfied (meaning you have at least 1 stack of everything needed in a recipe), you stop the retriever somehow so it will not accept anything. (probably just leave the key item in the retriever's slot (aka an item from the recipe being made) and map the side the retriever is on to have no slots exposed at all.
Latest Update did some serious weirdness. The same autocrafting tables, which were working just fine with the previous edition of tubestuff, now act like this. The 4 input sides no longer "start" in the same place in the GUI, and they are no longer the same stack size, either. Breaking and replacing the tables does not help.
They do still function, more or less, just look messy and no longer have the same number of stacks available to each side.
That's the bug I was going to fix when I decided to stop supporting 1.1 and 1.2.3 with the next version. If you're in 1.2.5, version 49.0.0 from the link in my last post fixed that... but only if you want to try an unstable test version. It won't corrupt worlds, it just might not work properly in all cases (especially SMP) since I fully ported it to 1.2.5's new Forge code.
Will my idea work? I have it all worked out in my head, if you're interested I can write it all out here, line by line, in pseudocode.
If you'll let me see the source for the tileentity autocrafting table I could give a crack at writing at myself, even. I've ported a few mods and made a few upgrades to existing mods before.
This gives me an idea. Right now, as I mentioned to you in IRC, the problem with autocrafting in RP is that it's too hard to get the ingredients needed to the tables when they need them. It CAN be done, but it is nowhere near as elegant as say, Logistics pipes. LPs ask for what they actually need to perform the autocrafting.
So I have an idea to fix this that would not take you very long to develop. You create an advanced crafting table II, perhaps with a regulator and some red doped wafers as well as that blutric motor in the recipe. (dunno if you keep the old one, maybe). This table does something special if and only if there is a RETRIEVER directly adjacent to it.
The table accesses the retriever's inventory through Forge (I'm talking about the 3x3 grid that can be accessed from the side, although sneaky pipes prove that you can access any side if you need to). Whichever crafting ingredient for the recipe in the table is MOST NEEDED is placed into the retrievers inventory slot. Everything else in the retriever's inventory is removed as if it had been placed into a table. (so mismatched items go into the reject slot)
Every few seconds, you code sees what is most needed by the table's recipe, and swaps a stack of that into the retriever's retrieval slot. The table also emits a redstone pulse whenever it does this.
Each time it does this swap around, it also switches which slot the retriever can place items into. The retriever would go into a special side on this table (probably the top), and you map this side to whichever slot in the recipe most needs something.
Once a recipe is full satisfied (meaning you have at least 1 stack of everything needed in a recipe), you stop the retriever somehow so it will not accept anything. (probably just leave the key item in the retriever's slot (aka an item from the recipe being made) and map the side the retriever is on to have no slots exposed at all.
This seems like a good idea. Perhaps a project table should be included in the recipe too instead of the basic crafting table
Not sure what is causing it, since I know for a fact that I have RP2 machine installed.
Nvm, it was an issue with the block ids not generating.
Make sure Tubestuff loads after RP2.
That's an actual bug that can only happen if Core loads after Tubestuff and the block ID isn't already set. Shouldn't be hard to fix.
Normally that means you didn't install Core, but if you did then that obviously isn't the problem.
Maybe it's a load order problem. Are you on Windows or Linux or Mac (or something else), and did you rename either mod's jar file?
Images
Still Plenty of room.
Runs 1 time and then the transposer(filter jams too) next to the alchemical chest jams. You can tell by the fact that the bellow is still down, even so there is no signal.
Secondly. I had trouble crafting the ACT. When trying to remove the block from the crafting table, it would constantly flicker back to the output slot, much like it would if the block ids did not match. But as you can see from the pictures showing the jamming issue, the block ids between server and client do match since I was able to spawn it in directly with NEI.
I think if you put a mod in the jar file when it should be in the mods folder, it gets loaded after mods from the mods folder. Try putting both in mods.
Each side is only supposed to use one row of the inventory. If each side isn't using its own row, that's a bug.
Check the load order, perhaps. Tubestuff should load after BC and/or RP (whichever you have) on both sides.
Ah I see now. I was being confused by the bottom buffer and how it forms a diagonal line in the inventory.
I have tubes inputting cobble on all sides except top and bot. For some reason the buffer for bot is spread out along the last 4 lines of inventory.
O_o. It's not supposed to do that. I'll look at it when I have time.
Am I doing something wrong?
http://imgur.com/EFv1E
Yes. Filters and transposers only suck items out of things they're actually touching.
Also I can't reobfuscate and upload the new TS now, since it's 12:30 AM and that can take 40 minutes. Sorry. At least it's not a major bug.
Can you help me out with the design? I want to make an iron ingot and a piece of flint make a flint and steel but I don't understand the advance mechanics. All I want is for the flint and iron ingot to go in, get crafted and a flint and steel to come out. Not very simple for me.
ಥ_ಥ
The output filter/transposer needs to be go right on top of the crafting table - there can't be a tube in between. Also, make sure the side with the big hole is facing down, and make sure to give it a redstone signal each time you want it to take out a crafted item. (Filters take any number of items at a time, transposers only take one; since the recipe for flint and steel makes one item and it's unstackable anyway, it doesn't make a difference here)
Here's a video where I use it heavily. I discovered one limitation when using it in this way : the output slot for items can get stuff placed into it by redpower tubes. Is there any way you can make the output slot not EVER allow an item to be placed in it? One trick would be that if the slot ever becomes empty, report to Forge that the slot no longer exists or something. Or that it contains a fake item that the player cannot take.
Or, the easiest way : if there is an item in the output slot, blocking crafting, move said item to the reject bin.
Sneaky. And it might actually work, too.
They do still function, more or less, just look messy and no longer have the same number of stacks available to each side.
So this is the end of 1.1 and 1.2.3 support.
The previous download page is still up, exactly the same as before, although it has a new URL.
Unrelated, how would you guys feel about crafting tables needing blutric motors for the RP recipe? Too expensive? (Pretend the BC recipe doesn't exist; this is supposed to be balanced to RP, the BC recipe is balanced to BC)
Edit: A test version that's fully ported to 1.2.5 will be here in a moment when it finishes reobfuscating. It probably has bugs, but it does at least work in singleplayer (SMP mostly untested so far). Disclaimer because FuzzyPurp: 49.0.0 is a prerelease, it's not tested in SMP and barely in SSP, and I'm just throwing it up here for people who are so annoyed by the diagonal gaps and/or just like finding bugs for some reason.
This gives me an idea. Right now, as I mentioned to you in IRC, the problem with autocrafting in RP is that it's too hard to get the ingredients needed to the tables when they need them. It CAN be done, but it is nowhere near as elegant as say, Logistics pipes. LPs ask for what they actually need to perform the autocrafting.
So I have an idea to fix this that would not take you very long to develop. You create an advanced crafting table II, perhaps with a regulator and some red doped wafers as well as that blutric motor in the recipe. (dunno if you keep the old one, maybe). This table does something special if and only if there is a RETRIEVER directly adjacent to it.
The table accesses the retriever's inventory through Forge (I'm talking about the 3x3 grid that can be accessed from the side, although sneaky pipes prove that you can access any side if you need to). Whichever crafting ingredient for the recipe in the table is MOST NEEDED is placed into the retrievers inventory slot. Everything else in the retriever's inventory is removed as if it had been placed into a table. (so mismatched items go into the reject slot)
Every few seconds, you code sees what is most needed by the table's recipe, and swaps a stack of that into the retriever's retrieval slot. The table also emits a redstone pulse whenever it does this.
Each time it does this swap around, it also switches which slot the retriever can place items into. The retriever would go into a special side on this table (probably the top), and you map this side to whichever slot in the recipe most needs something.
Once a recipe is full satisfied (meaning you have at least 1 stack of everything needed in a recipe), you stop the retriever somehow so it will not accept anything. (probably just leave the key item in the retriever's slot (aka an item from the recipe being made) and map the side the retriever is on to have no slots exposed at all.
That's the bug I was going to fix when I decided to stop supporting 1.1 and 1.2.3 with the next version. If you're in 1.2.5, version 49.0.0 from the link in my last post fixed that... but only if you want to try an unstable test version. It won't corrupt worlds, it just might not work properly in all cases (especially SMP) since I fully ported it to 1.2.5's new Forge code.
If you'll let me see the source for the tileentity autocrafting table I could give a crack at writing at myself, even. I've ported a few mods and made a few upgrades to existing mods before.
This seems like a good idea. Perhaps a project table should be included in the recipe too instead of the basic crafting table