Debugging with other mods / Unit Testing / CI?

[BrainSlugs83]

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:

For reference this is version @MAJOR@.@MINOR@.@REV@.@BUILD@ of FML
for Minecraft version @MCVERSION@.

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?

[Eternaldoom]

The mods in the folder crash because they are obfuscated and you are in a deobfuscated environment. I think there is a tool called Bearded Octo Nemesis that can deobfuscate mods.

[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. :-)

 

 

[clienthax]

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. :-)

 

if you can't find a dev version of the mod, throw in codechickencore, it will runtime deob the mods for you.

[Eternaldoom]

BrainSlugs83, they aren't fully obfuscated, but they use srg names instead of MCP names.

[TheGreyGhost]

Hi

 

Some thoughts on point (2)

 

I've had a fair bit of trouble trying to perform automated testing with minecraft because a lot of the classes are difficult or impossible to stub especially the ones with static methods or even worse a static singleton.  Some things I've done that worked well:

1) Objenesis for instantiating vanilla classes without having to use one of the constructors - for stubbing, usually by extending the vanilla class with my own stub.

2) Junit for unit testing - this works great with my own classes which I can design to be testable

3) Mockito for mocks (haven't used much)

 

I generally try to keep interaction with forge code as separate as possible, putting all the functionality into my own testable classes, then have an adapter class which subscribes to events etc and does nothing except call the appropriate method in one of the testable classes.  This makes it a lot easier to test the classes independently.

 

For other things which need to be tested in game, I have used a 'test' item that activates my test code when used, for example placing blocks in a given order, spawning entities, or executing a defined series of player actions, then checking for the correct result.  A 'test world' saved game helps with this.

 

You might try looking at Jetbrains' IntelliJ as an alternative IDE to Eclipse.  It is really quite awesome.

 

-TGG