LexManos

https://bbs.archlinux.org/viewtopic.php?id=126112

You didn't register a name to your tile entity....

Try build #638, Its caused by your command having a quote in it which fubars things. Hopefully this build fixes.

Seems that it doesn't like your natives, try getting a fresh copy. Your os doesnt like loading the 32-bit version it seems...

https://github.com/MinecraftForge/FML/blob/master/common/cpw/mods/fml/common/registry/IEntityAdditionalSpawnData.java

Humm aside from the fact that you're doing things horribly wrong! jesus christ! We have facilities in place for extra spawn data for a reason! Lookin at those changesets, it doesn't seem like we do anything that would effect your mod this way. However, I did test on 611 and 624, and do see the issue happening. Will do a little more testing with versions and see if I can track down to a specific build. Taking a wild guess i'm gunna say it has something to do with runtime deobfusication based on the horribly method you're using for serializing your data... Seriously dude, thats bad, you should just send enough to get the information you need across not THE ENTIRE OBJECT, it is nothing but massive network churn. Alright, I was correct, you are trying to serialize the entire object. Which does not work as to maintain ModLoader compatibility we need to make all fields/methods public in all remapped classes. So you need to look into actually determining what data you need and not relying on ObjectOutputStream, that was designed for small data objects, not large great grandchild objects.

This change does not effect runtime at all this is purely a development time deal. As it's the eclipse compiler that doesn't compile it to standard names.

This is telling us that you can't compile MCPMerger, go check if you have a MCPMerger class file...

Yes there are classes named the same as ModLoader classes as thats required to make java work... But they are not Risugami's classes.

No we are not a mod distribution network.

https://github.com/MinecraftForge/MinecraftForge/issues/502#issuecomment-15915024

In fml.py, line 383 should look like: forklist = cmdsplit(command) process = subprocess.Popen(forklist, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, bufsize=-1) Make it this: forklist = cmdsplit(command) print(command) pprint(forklist) process = subprocess.Popen(forklist, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, bufsize=-1) And post what it prints out there. Something is causing a %1 or some BS. Though it shouldnt

Interesting this is caused by Risugami having a srg name function in his class that is the same as a obfed name in his class... Namely fun_94042_c()Z This is most likely dead code from something he screwed up. I'll point this at cpw and see if we can think of a way do deal with this particular modder stupidity.

Update, you're 18 versions out of date.

http://www.minecraftforge.net/forum/index.php/topic,7085.msg37495.html#msg37495

Try out build #629 I was able to reproduce and track it down to this commit, reverting seems to of worked, however may result in concurrency issues that the original commit attempted to fix. If those do arise, I will look into a better solution to both issues.

Post a copy of your pre-reobfusicate'd class files and your post-rebfusicated class files. Meaning your mod files from src/ and reobf/

The file scala-library.jar was found in your lib directory and has an invalid checksum a7a5289d3acd69ef1c399082c83c217d1b613a61 (expecting 458d046151ad179c85429ed7420ffb1eaf6ddf85) - it is unlikely to be the correct download, please move it out of the way and try again.

Yes, we now deobfusicate minecraft at runtime to a more stable environment so that modders can now start working on mods that can survive multiple minecraft versions. We also deobfusicate every standard ModLoader mod or anything else that is loaded at runtime to srg names so everything should work fine. However there will be edge cases, usually when someone is using dirty name based reflection without support for srg names. For those edge cases we typically say its up to the modder to update as it's about a 2 second job which in all honesty they should already have as they need multiple names to test there mod in the dev environment... Anyways, there is nothing 'magical' about your logs. Its doing exactly what it was intended to do. Provide a stable codebase at runtime for modders. There needs to be a little cooperation with modders but for the most part its super super easy for them to do.

2013-04-01 15:04:54 [iNFO] [sTDERR] Caused by: java.lang.RuntimeException: Method not found: [apa.canBeReplacedByLeaves(Laab;III)Z] 2013-04-01 15:04:54 [iNFO] [sTDERR] at codechicken.core.asm.ASMHelper.alterMethods(ASMHelper.java:225) 2013-04-01 15:04:54 [iNFO] [sTDERR] at codechicken.core.asm.TweakTransformer.transform(TweakTransformer.java:185) Something is breaking in the CCC's transformer, speak with them.

You're doing it wrong. As you're probably adding the real minecraft.jar and not the minecraft.jar that is the launcher {IE: the one that you download manually from minecraft.net} They REALLY need to change that name to minecraft_launcher.jar but whatever. Anyways as long as the 'minecraft.jar' it finds is the launcher the first will work.

This is all vanilla mechanics. And here is the kicker, how exactly, without the block existing, are we supposed to know that the block has an associated tile entity. And how that tile entitie's data should be read/written to disc? Basically if you're loading a world with corrupt/changed mods/whatever you're assuming the responsibility for what will happen. Hell FML now even warns you and you have to click yes before entering a world if it detects that you don't have the same id mapings as you did last time. Its not a forge issue and its really not something we should/will fix. Welcome to vanilla mechanics?

https://github.com/MinecraftForge/MinecraftForge/commit/5b03eb9792c6d09155569800d5555510864bd4aa update

http://www.minecraftforge.net/forum/index.php/topic,7142.msg37366.html#msg37366

open your level.dat in a nbt editor and delete the forge section