JaredBGreat

You might want to look into the gson libraries that are packaged with Forge (and I think used by vanilla also). These allow you to store a key with a value (sound familiar?). Or you can just wait on the other idea.

Pretty much -- that's what I'm doing.

EDIT: Sorry to have bothered everyone, but I've solved the problem. If anyone else has this problem with IntelliJ one possible solution is to select the version of your mod that adds ".main" to the end in the module section. It main seems strange if the class has no members or methods called that, but it seems it can be a problem and that change can solve it. I never could get a test run to even try to start on Linux with 1.14.4. So I switched to IntelliJ, and it launched perfectly with "Example Mod." So, I refactored my package and mod class to "jaredbgreat.climaticbiomes" and ClimaticBiomes.java, and changed the mod name. That's it! That's all I've done so far, but a new test lauch results it this error (at least it tried to start): /usr/lib/jvm/java-8-oracle/bin/java -Dforge.logging.console.level=debug -Dforge.logging.markers=SCAN,REGISTRIES,REGISTRYDUMP -javaagent:/home/jared/bin/idea-IC-183.5912.21/lib/idea_rt.jar=45341:/home/jared/bin/idea-IC-183.5912.21/bin -Dfile.encoding=UTF-8 -classpath /usr/lib/jvm/java-8-oracle/jre/lib/charsets.jar:/usr/lib/jvm/java-8-oracle/jre/lib/deploy.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/cldrdata.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/dnsns.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/jaccess.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/jfxrt.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/localedata.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/nashorn.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/sunec.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/sunjce_provider.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/sunpkcs11.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/zipfs.jar:/usr/lib/jvm/java-8-oracle/jre/lib/javaws.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jce.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jfr.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jfxswt.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jsse.jar:/usr/lib/jvm/java-8-oracle/jre/lib/management-agent.jar:/usr/lib/jvm/java-8-oracle/jre/lib/plugin.jar:/usr/lib/jvm/java-8-oracle/jre/lib/resources.jar:/usr/lib/jvm/java-8-oracle/jre/lib/rt.jar net.minecraftforge.userdev.LaunchTesting Error: Could not find or load main class net.minecraftforge.userdev.LaunchTesting Process finished with exit code 1 Huh! I had no trouble finding "net.minecraftforge.userdec.LaunchTesting" before and ran just fine!?! (This was right after announcing I might be able to update after all.) What is going on? Frankly it looks like a bug to me, but since its about making mods I put it here. It doesn't seem to be able my code, since it doesn't even get that far. I have not changed any of the project setting since the successful launch, other than to set the "module" to the new mod class name and location. EDIT: Yes, I did Google the problem -- there are only 5 results and none of them useful (just a few other people saying they have the problem).

Well, one other little question then -- would it be best to use the latest 1.14 version, 1.14.4 at the moment, or are versions for 1.14.2 or 1.14.3 more stable and developed?

I see a lot of people skipping 1.13 because players have moved on, but I'm wondering, which is generally more stable and easier to work with: Forge for 1.13.x, because it's been out longer with more time to fix bugs, or Forge for 1.14.x, by building on bug fixes for 1.13. I'm not even sure if updating my mods is that feasible (especially the one the generate a huge procedurally generated structure with ten-of-thousands of blocks across dozens of chunks), and don't really like the idea of completely skippings version (I never have before) -- but which would be the better to shoot for? Is 1.13 worth it now?

OK, thanks. That is probably much more useful for what I'm doing.

Everything I see on @ObjectHolder seems to use it as an annotation for a specific class or field, attaching it to something specific and defined as static. Could I use it on a dynamic array wrapper, like an ArrayList or something similar? If I have to hard-code annotations on each block in advance ... what about when you don't what blocks you're using or how many there will be? But if I can use it to create data structures holding an arbitrary number of unknown blocks/items it might actually work. EDIT: If the field doesn't have to be static, I suppose I can use that on the field in my block wrapper class, DBlock, that same thing has allowed easy transitions from IDs to Blocks to BlockStates. (Otherwise, uh-oh.) Thanks.

I see that that old preInit(), init(), postInit() system seems to have bee replaced with a single setup() method in 1.13, and understand that mods are now loaded concurrently. Is there anything still around equivalent to the old postInit(), or some event for all mods have loaded (preferably before server start)? I used postInit extensively for compatibility and inter-mod interaction -- specifically to allow things like blocks, items, and biome from other mods to be used with my world-gen. This way I could load player configurable changes after all other mods should have their core content loaded. For example, Doomlike Dungeons loads its base config during preInit() but wait to postInit() to load its theme files, in order to allow dungeons to use blocks/loot from other mods without explicit dependence on any other mod (or even for me to know the mods in question exist). My new Climatic Biomes mod does something similar with biomes. I also generate lists of usable content by resource location at this time, as this is not always obvious from names that appear in-game. No, IMC is not likely to be useful and should not be necessary for my use case. Is there a still a good (preferably simple) way to do this? -- or are my theme systems dead and doomed?

This is for an older version, but I think the basic idea still works as an example: GenerateHerbs.java Note that I did not think to explicitly check dimensions, though the herbs would not have been prevented by other functions. Note the isLocationValid method at the end: This actually asks each herb if it should generate, and I think that is a good pattern -- vanilla basically does the same thing with mob spawns. So each of your crops would have some kind of "canGenHere" method(s) and you would then put tests for that specific crop there.

This is tricky -- I've always used NetBeans for everything but Minecraft, and have only used Eclipse with projects pre-made by Forge / Forge Gradle. Is there a guide or tutorial somewhere that could help me get started? My experience so far is that Gradle and / or Eclipse is finicky and projects can be strangely fragile (I'll skip examples, but the setup can be very weird and behave like no other software). For example, what is the root directory? Should it be the main project folder? The ./src folder? The ./src/main folder? I.e., is it for the project as a whole or source files? It's not really clear.

It never occurred to me to do this, so I ended up writing an elaborate (and fragile) system for loading NBT. Then someone called Hubry came along and added in this simpler system. It seems the meat of this system is in one line: out = new NBTFromJsonWrapper(tokens.getToken(0), s[2]);

I personally am glad this was brought up -- I'm not impatient to get the latest and greatest, but I've just really wanting to find out how and if my mods will be affected by the changes.

ASM? OK, I'm sure you aren't talking about assembly language (the first and only programming concept that comes to mind with that) -- so just what is ASM? I sorry to bump this again, but I just have to know!

I also use Linux. While I had a lot of trouble getting things going back in 1.5.2 days, I've never seen this problem. Then, I installed Oracle Java and don't use gradlew since I've actually installed Gradle as well. Perhaps installing Orcale Java and Gradle would help? Will get you Oracle Java, instead of the OpenJDK (which I find to be more buggy).

That's what I would do with some kind of base.