LexManos

That sounds like the jist of it yes.

The way you execute forge on the server has nothing to do with this. And FML now includes sanity checks for IDs when you connect to servers. Typically ID conflicts cause corrupt worlds, crashes, and the sky exploding. So it tries to prevent you from doing that. However, if you try the latest versions, the ID check has been modified to be a little more lenient, so you shouldn't have issues anymore.

Its not an issue... What gives you the idea that it is supposed to be a 9 in length? The recipies are just fine, you're just not understanding how crafting works, this isn't a issue. Note how in minecraft you can craft a hoe like this: This is because those spaces are not there.

Interesting, I can not figure out how your mod is initalizing things differently on the client and server. I've spoken to xcomp, and he is now aware that the way he is doing things is... stupid However, on all of my local tests, I can not repeat this with the client and server having the same version of mystcraft... Either backdate, or go speak with xcomp and your server admin to figure out why this is happening...

You're NOT using the latest as this has been fixed the issue is that the eclipse workspace is not being copied over. Get the Latest and it should work fine, or manually copy fml/eclipse to mcp/eclipse.

http://lmgtfy.com/?q=java+random+number&l=1

We know, Go bitch at jenkins to fix it: https://issues.jenkins-ci.org/browse/JENKINS-15704

You're not using the latest forge. Else provide logs.

You may wanna look at the RenderWolrdLast handler. Its been used by many mods to render overlays onto the world, and your paintball thing just sounds like a overlay on the block to me.

Post full logs as this shouldnt happen if the configs are the same, however, it appers to be that the server has something that you do not that is trying to iniatalize the mystactraft items to early.

If you're going that deep down, just replace the vanilla blocks. Vanilla blocks are what they are, we will change some functionality a little to play more nicely with mods, but we're not gunna change dirt to cheese. Its something you can do in your own and would be really really bad for us to do generically in forge.

Short answer is we're not gunna hack a walrus into the room to address the wobbely table. We would have to figure a way to delay the creation of the world until we get the proper id, basically, this is a bitch. Its not hard for the proxy to deal with, and if MC used a proper packet header it'd be a different issue Its a non-issue, nothing that you'd be concerned with. Basically, things are going to stay.

public int GlowBrickID; public int GlowTorchID; public int ColouredGlassID; ... int GlowBrickID = config.getBlock("Glow Brick", 148).getInt(); int GlowTorchID = config.getBlock("Glow Torch", 149).getInt(); int ColouredGlassID = config.getBlock("Coloured Glass", 150).getInt(); .... *facepalm* http://bit.ly/W5opB8

Update to Forge 438 or above its fixed.

Im not seeing how this is a forge issue.. seems like a basic id conflict to me, go fix it.

I looked into it, it appears that pythons unzip function does not set execution flags. I'll have to write a case to run chmod on things post decompile.

Something is setting your system to use ascii, posibly a bad install of python? I've tested things and unicode characters in path names works fine. runt he command: locale And paste the results here please.

Sadly, We can't as that would break things quite a bit with multiple dimensions and the like. There is a reason why we have the sanity check when connecting to make sure that the client has Forge installed. However, its fairly simple on there end to add support for the differences {IIRC its only this one thing} I'm sure md_5 would be willing to do it We don't like breaking compatibility here, but we do it in a clean way that we hope eventually we wont have to do.

Nobody here is able to reproduce, nobody here has your setup, nobody here can really help you without being able to reproduce. This isn't a Forge issue. If it was a issue it obviously would of been fixed as chests are kinda important. Not sure how much we can help you track it down.

!! reformating disabled due to no astyle or config !! You MUST have astyle. I'll eventually get around to detecting it missing and throwing a major error

Sadly we can't outright crash the client because many modder are annoying and use this mechanic directly, meaning they replace there block items with real items directly without making sure they are free. However all item conflicts are logged in the log file for users to review if things explode.

Your configurations between the client and server are mismatched. FML now warns you when connecting so that you can fix them instead of having you crash with some cryptic NPE.

Update forge, it now ships with 32-bit, it was a oversight, i thought it generated 32-bit but aparently it didnt.

One or more of the blocks that are in your world do not match to a block. So, it seems you've messed up the configs somewhere, somehow. It's trying to generate a dungeon somewhere around that players location and trying to access a block that doesn't exist. Either some of your configs are messed up {you have terrain generation blocks >256} or your world is corrupt.

It cleans up a lot of issue that people have especially the people who like to hook there mods into auto building systems. Anyways all this shit is fixed, as its all FML issues. Just need to wait till the next time we sync things with FML, Which will have a lot more changes then just the workspace and downloads. Shit break while they are being re-written, deal with it. Nothing that has happened has been a show stopper, no more then 30 seconds for you, the modder, to work around on your end.