OvermindDL1

You are also multipying by xMod/zMod, no clue what those are or what the surrounding code looks like?

Root directory of your zip/jar.

Is anything printed to the terminal? You can use the instructions linked from the stickied post in this board to get that.

Oh, in that case just get the cos/sin of the axis, multiply it by the distance away, and add all of that to the central X/Z point.

What mods? Full logs? Etc...?

That is actually quite a fascinating mod, never ran across it before. Kind of like an 'at a distance' version of RP's basic machines and logic, with more. I worry about balance though (tear down enemy place remotely and distance mining), but would be very nice on a creative MP server. I quite like the looks of this. EDIT: Also, on your topic name can you prepend it with [1.2.5] or so? Just to mark what MC version it works with.

Not an error in Forge, it is the buildcraft.additionalpipes mod that is crashing, specifically its buildcraft.additionalpipes.util.SaveManager class. Might want to ask them.

It was installed wrong. Either you did not merge the directories together in the zip (common with the default Mac zip program, which you are not on)? Or you used a broken modding program (like MCPatcher, others like MultiMC work fine), or ModLoader was installed and Forge was in the mods directory (wrong, Forge *is* a ModLoader, thus ModLoader is not needed). How did you install it? Remember, only Forge should be in the jar, nothing else should be in the jar.

Forge includes hooks to handle chunk unloading (and keeping them from being unloaded), if you want fine grained control over it near your villages.

You have milk in the game, perhaps add irish creme, make a Brain Hemorrhage drink.

This: java.lang.IllegalArgumentException: Slot 216 is already occupied by ExplosivesPlusBlockInverter@20ca29b when adding ic2.common.BlockScaffold@b876f2a Means that block ID 216 from ExplosivesPlusBlockInverter is conflicting with block ID 216 from ic2.common.BlockScaffold. In other words they have the same IDs, blocks cannot have the same IDs, change one to an unused ID. Very very very common error.

Well that error does still mean that some mod is throwing an exception during its own construction (could even be as something as a block ID conflict), but without seeing its exception then we do not know what. Have you tried the debug bat file listing in the link in the stickied post?

Tried inverting the addition to pull in. And add an addition inside the trig functions to rotate?

What about the ForgeModLoader log? Can you paste the whole thing here? In a code tag, and a secret tag.

That is all of the stacktrace? When that one appears there is usually at least one more around it too, or maybe in a log?

That is all of the stacktrace? When that one appears there is usually at least one more around it too, or maybe in a log?

Meh, no real point anymore honestly, unless you are dynamically creating things like RP2's microblocks, we have 4096 IDs now. And if we are lucky then 1.3 or 1.4 will drop metadata (wishful thinking anyway).

You're right. Too bad Buildcraft, IC2 and Forestry each have their own wrench (and same for my mod) and they are all not compatible with each other! Often the wrenches do different things though, especially based on various states. What they *should* do it make a mod that includes a few tools like wrenches or screwdrivers or whatever and have their mod require it, but you know how well that works. Or at least an API they can include that does that but only loads one copy from all mods...

I still really enjoy using Risugami's Recipe book, wish there was an option inside NEI for Risugami's GUI 'look' for recipe mode. CB has actually been looking for interface ideas, suggest it. The Risugami's GUI takes a long time to scroll through though, NEI's hitting r/u is far more simple in my opinion.

In other words, making my mod multiplayer now will make the transition to 1.3 easier? If so I might do so, but on the last minute. I always feel that multiplayer slows my development speed down. In that case, do not make a single player, just make multiplayer. Won't be able to debug lol... I'm glad that there won't be this variable called World.isRemote anymore.... Debugging is easy still.

For common items is fine, but for items that run code it is exceedingly difficult.

Remember these: Forge contains FML, which is an implementation of ModLoader, as such ModLoader is no longer needed. Nothing should be installed in the jar but Forge (maybe PlayerAPI and Optifine and NEI if you need them, but you do not have those), and it looks like you are putting everything in the jar, do not do that. Also, TooManyItems and RecipeBook are kind of crappy compared to NEI, you should get NEI, it replaces both and is far far better.

In other words, making my mod multiplayer now will make the transition to 1.3 easier? If so I might do so, but on the last minute. I always feel that multiplayer slows my development speed down. In that case, do not make a single player, just make multiplayer.

Think of it this way. It will be easier to port your multiplayer capable mod, then it will be a single player only mod (since you will have to make it support the multiplayer code, whether multiplayer or not).

Depends on how the obfuscation is done.