BrainSlugs83

Hmmm... I'm not sure that's right. Forge Mods aren't obfuscated anymore I'd thought -- FML handles this when it loads them by dynamically mapping the correct types etc. -- If I decompile my own mod (the one I created via gradlew build) or one of the crashing mods (using jd-gui) all the types are in plain english, and not obfuscated (i.e. Block is "Block" and "World" is "World", etc. etc.). -- It's my understanding that this is how cross-version mods work. (My mod works in 1.7.2 and 1.7.10 now that I manually handle the weirdness with Blocks.sand in 1.7.2 for example). Still though, I'll take a look and see if it helps. EDIT: This did not work for me. The mods crash at the same spot even after being pushed through the BON tool. Very cool tool though. Thank you for mentioning it to me. :-)

Hey guys, [*]I'm working on a mod at the moment, and have been made aware that there are some compatibility issues with other mods. I'd like to know, is there a way within the Eclipse dev. environment to load other mods as well as my own mod that I'm dev'ing? -- It seems if I put mods that otherwise work into the Eclipse\Mods folder that I just get crashes. -- I suspect this is normal, but I just want to confirm -- If this works for other users, I'll post my logs and we can see if we can walk through it. [*]Secondly, professionally, I strongly embrace TDD/coded unit tests -- but I come from a strong .NET background -- so I'm still picking up some of the Java stuff like Gradle, etc. -- and I'm wondering: what's a good place to get started on the Java/Eclipse side of TDD/unit testing? -- and Has anyone done any work along the lines of coded unit tests in Minecraft with Eclipse? -- I can't be the first to think of this right? (I get that some things are hard to test -- esp. games -- but I do gamedev as a hobby, and there's always something that can be unit tested, etc. -- and I find that knowing that you accidentally broke something [that you might not otherwise have noticed] is fucking awesome -- esp. in gamedev.) [*]Thirdly, I'd like to target multiple versions of Minecraft (and ideally run my unit tests against all those versions and super ideally publish via a CI process) -- right now I'm having trouble just compiling against multiple versions -- I setup a 1.7.2 Forge Gradle environment in a different folder than my 1.7.10 ( -- but even if I move my source code over there and do a gradlew build from that location -- I think the .jar that comes out is still linked against 1.7.10 -- I believe this to be true because accessing Blocks.sand in the 1.7.2 environment throws the same Exception as if I'd compiled against 1.7.10 (that the field is missing). -- It seems to link against 1.7.2 properly for Eclipse (no exception) but from a gradlew build from that location, I get immediate crashes about missing fields (which happens if you run the 1.7.10 version on 1.7.2). [*]Finally, is it just me? But the readme.txt that comes packaged with every version of Forge I've tried contains a line that reads as follows: Is this a bug? Or am I downloading it wrong? -- it seems those @values@ should be replaced at the time the source is packaged up so that the file reflects the version of the source code we have, correct?