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.

This does not sound like a good way to handle totally separate mods. I do do that for different version of the same mod (Doomlike Dungeons has branches for different Minecraft versions, several of which may have the same mod version). But separate mods should be separate. IMO, if you really want to have some kind of starter base it should be a separate thing from any of the mods (while I do sometime move small bits of code around, I would never have thought to make mods as you are describing). But then. None of what I've copied was big enough to warrant a library IMO, and I try to avoid extra utility mods since when downloading other people mods I don't like having tons of extra dependencies, but that could be a solution. Draco's idea makes a certain amount of sense to me, but GitHub doesn't seem to offer forking for your own project (or they've hidden it) -- I don't think they intended it to be used that way. Perhaps you could do it locally on the command line though. I'd just keep that base separate for any kid of project -- but then, I'm just a self-taught programmer with no formal training on standard ways of doing things and probably a few weird habbits (the way I use branches is also a little different from the most common use).

I just need something clarified. I've always assumed that the running of load time events went something like this: 1. Run pre-init for all mods 2. Run init for all mods 3. Run post-init for all mods Where the operative part is "for all mods" -- that is, that regardless of load order or dependencies (or the absence of dependencies), init would not run until after all mods have run pre-init, and likewise with post-init running after all mods have run init. However, that was something of an assumption. So, was I right? Or would a mod set to load after another (or just after it in the directory) actually complete all its initializations before another is loaded? This could be useful to know for things like APIs. Whether or not it has any relevant to the poorly designed and apparently broken API I'm trying to fix is another thing, but this would be a useful thing to know and be sure of.

Well, the new version (1.12.2, and also 1.7.10) looks like this as a mob: But maybe I'm being too picky -- the in the classic 1.6.4 version the mob and block didn't actually look alike at all (though I'd still find it preferable): BTW, I didn't think any of those tool could convert Java class, and didn't really think they liked raw numeric input. I've looked at and down loaded Mr. Crayfishes a while back, but never really used except once as a test. Thanks.

Since there doesn't seem to be any software for changing Java model classes to JSON, is there a good does anyone know of a good tutorial on how to write JSON block models? Specifically, I'm needing to translate this: package com.gw.dm.model; import net.minecraft.client.model.ModelBase; import net.minecraft.client.model.ModelRenderer; import net.minecraft.entity.Entity; public class ModelBladeTrap extends ModelBase { ModelRenderer Base; ModelRenderer BotSpikeB; ModelRenderer BotSpikeC; ModelRenderer BotSpikeD; ModelRenderer BotSpikeA; ModelRenderer TopSpikeA; ModelRenderer TopSpikeC; ModelRenderer TopSpikeD; ModelRenderer TopSpikeB; ModelRenderer RerSpikeB; ModelRenderer RerSpikeC; ModelRenderer RerSpikeD; ModelRenderer RerSpikeA; ModelRenderer FrnSpikeA; ModelRenderer FrnSpikeC; ModelRenderer FrnSpikeD; ModelRenderer FrnSpikeB; ModelRenderer LftSpikeB; ModelRenderer LftSpikeC; ModelRenderer LftSpikeD; ModelRenderer LftSpikeA; ModelRenderer RitSpikeD; ModelRenderer RitSpikeC; ModelRenderer RitSpikeA; ModelRenderer RitSpikeB; public ModelBladeTrap() { textureWidth = 64; textureHeight = 32; Base = new ModelRenderer(this, 0, 0); Base.addBox(-2.5F, -2.5F, -2.5F, 5, 5, 5); Base.setRotationPoint(0F, 16.5F, 0F); Base.setTextureSize(64, 32); Base.mirror = true; setRotation(Base, 0F, 0F, 0F); BotSpikeB = new ModelRenderer(this, 2, 12); BotSpikeB.addBox(-0.5F, 0F, -0.5F, 1, 4, 1); BotSpikeB.setRotationPoint(1.5F, 19F, -1.5F); BotSpikeB.setTextureSize(64, 32); BotSpikeB.mirror = true; setRotation(BotSpikeB, 0F, 0F, 0F); BotSpikeC = new ModelRenderer(this, 2, 12); BotSpikeC.addBox(-0.5F, 0F, -0.5F, 1, 4, 1); BotSpikeC.setRotationPoint(-1.5F, 19F, 1.5F); BotSpikeC.setTextureSize(64, 32); BotSpikeC.mirror = true; setRotation(BotSpikeC, 0F, 0F, 0F); BotSpikeD = new ModelRenderer(this, 2, 12); BotSpikeD.addBox(-0.5F, 0F, -0.5F, 1, 4, 1); BotSpikeD.setRotationPoint(-1.5F, 19F, -1.5F); BotSpikeD.setTextureSize(64, 32); BotSpikeD.mirror = true; setRotation(BotSpikeD, 0F, 0F, 0F); BotSpikeA = new ModelRenderer(this, 2, 12); BotSpikeA.addBox(-0.5F, 0F, -0.5F, 1, 4, 1); BotSpikeA.setRotationPoint(1.5F, 19F, 1.5F); BotSpikeA.setTextureSize(64, 32); BotSpikeA.mirror = true; setRotation(BotSpikeA, 0F, 0F, 0F); TopSpikeA = new ModelRenderer(this, 0, 11); TopSpikeA.addBox(-0.5F, -4F, -0.5F, 1, 4, 1); TopSpikeA.setRotationPoint(1.5F, 14F, 1.5F); TopSpikeA.setTextureSize(64, 32); TopSpikeA.mirror = true; setRotation(TopSpikeA, 0F, 0F, 0F); TopSpikeC = new ModelRenderer(this, 0, 11); TopSpikeC.addBox(-0.5F, -4F, -0.5F, 1, 4, 1); TopSpikeC.setRotationPoint(-1.5F, 14F, 1.5F); TopSpikeC.setTextureSize(64, 32); TopSpikeC.mirror = true; setRotation(TopSpikeC, 0F, 0F, 0F); TopSpikeD = new ModelRenderer(this, 0, 11); TopSpikeD.addBox(-0.5F, -4F, -0.5F, 1, 4, 1); TopSpikeD.setRotationPoint(-1.5F, 14F, -1.5F); TopSpikeD.setTextureSize(64, 32); TopSpikeD.mirror = true; setRotation(TopSpikeD, 0F, 0F, 0F); TopSpikeB = new ModelRenderer(this, 0, 11); TopSpikeB.addBox(-0.5F, -4F, -0.5F, 1, 4, 1); TopSpikeB.setRotationPoint(1.5F, 14F, -1.5F); TopSpikeB.setTextureSize(64, 32); TopSpikeB.mirror = true; setRotation(TopSpikeB, 0F, 0F, 0F); RerSpikeB = new ModelRenderer(this, 2, 12); RerSpikeB.addBox(-4F, -0.5F, -0.5F, 4, 1, 1); RerSpikeB.setRotationPoint(-2F, 18F, 1.5F); RerSpikeB.setTextureSize(64, 32); RerSpikeB.mirror = true; setRotation(RerSpikeB, 0F, 0F, 0F); RerSpikeC = new ModelRenderer(this, 2, 12); RerSpikeC.addBox(-4F, -0.5F, -0.5F, 4, 1, 1); RerSpikeC.setRotationPoint(-2F, 15F, -1.5F); RerSpikeC.setTextureSize(64, 32); RerSpikeC.mirror = true; setRotation(RerSpikeC, 0F, 0F, 0F); RerSpikeD = new ModelRenderer(this, 2, 12); RerSpikeD.addBox(-4F, -0.5F, -0.5F, 4, 1, 1); RerSpikeD.setRotationPoint(-2F, 18F, -1.5F); RerSpikeD.setTextureSize(64, 32); RerSpikeD.mirror = true; setRotation(RerSpikeD, 0F, 0F, 0F); RerSpikeA = new ModelRenderer(this, 2, 12); RerSpikeA.addBox(-4F, -0.5F, -0.5F, 4, 1, 1); RerSpikeA.setRotationPoint(-2F, 15F, 1.5F); RerSpikeA.setTextureSize(64, 32); RerSpikeA.mirror = true; setRotation(RerSpikeA, 0F, 0F, 0F); FrnSpikeA = new ModelRenderer(this, 2, 12); FrnSpikeA.addBox(0F, -0.5F, -0.5F, 4, 1, 1); FrnSpikeA.setRotationPoint(2F, 15F, 1.5F); FrnSpikeA.setTextureSize(64, 32); FrnSpikeA.mirror = true; setRotation(FrnSpikeA, 0F, 0F, 0F); FrnSpikeC = new ModelRenderer(this, 2, 12); FrnSpikeC.addBox(0F, -0.5F, -0.5F, 4, 1, 1); FrnSpikeC.setRotationPoint(2F, 15F, -1.5F); FrnSpikeC.setTextureSize(64, 32); FrnSpikeC.mirror = true; setRotation(FrnSpikeC, 0F, 0F, 0F); FrnSpikeD = new ModelRenderer(this, 2, 12); FrnSpikeD.addBox(0F, -0.5F, -0.5F, 4, 1, 1); FrnSpikeD.setRotationPoint(2F, 18F, -1.5F); FrnSpikeD.setTextureSize(64, 32); FrnSpikeD.mirror = true; setRotation(FrnSpikeD, 0F, 0F, 0F); FrnSpikeB = new ModelRenderer(this, 2, 12); FrnSpikeB.addBox(0F, -0.5F, -0.5F, 4, 1, 1); FrnSpikeB.setRotationPoint(2F, 18F, 1.5F); FrnSpikeB.setTextureSize(64, 32); FrnSpikeB.mirror = true; setRotation(FrnSpikeB, 0F, 0F, 0F); LftSpikeB = new ModelRenderer(this, 2, 12); LftSpikeB.addBox(-0.5F, -0.5F, -4F, 1, 1, 4); LftSpikeB.setRotationPoint(1.5F, 15F, -2F); LftSpikeB.setTextureSize(64, 32); LftSpikeB.mirror = true; setRotation(LftSpikeB, 0F, 0F, 0F); LftSpikeC = new ModelRenderer(this, 2, 12); LftSpikeC.addBox(-0.5F, -0.5F, -4F, 1, 1, 4); LftSpikeC.setRotationPoint(-1.5F, 18F, -2F); LftSpikeC.setTextureSize(64, 32); LftSpikeC.mirror = true; setRotation(LftSpikeC, 0F, 0F, 0F); LftSpikeD = new ModelRenderer(this, 2, 12); LftSpikeD.addBox(-0.5F, -0.5F, -4F, 1, 1, 4); LftSpikeD.setRotationPoint(1.5F, 18F, -2F); LftSpikeD.setTextureSize(64, 32); LftSpikeD.mirror = true; setRotation(LftSpikeD, 0F, 0F, 0F); LftSpikeA = new ModelRenderer(this, 2, 12); LftSpikeA.addBox(-0.5F, -0.5F, -4F, 1, 1, 4); LftSpikeA.setRotationPoint(-1.5F, 15F, -2F); LftSpikeA.setTextureSize(64, 32); LftSpikeA.mirror = true; setRotation(LftSpikeA, 0F, 0F, 0F); RitSpikeD = new ModelRenderer(this, 2, 12); RitSpikeD.addBox(-0.5F, -0.5F, 0F, 1, 1, 4); RitSpikeD.setRotationPoint(1.5F, 18F, 2F); RitSpikeD.setTextureSize(64, 32); RitSpikeD.mirror = true; setRotation(RitSpikeD, 0F, 0F, 0F); RitSpikeC = new ModelRenderer(this, 2, 12); RitSpikeC.addBox(-0.5F, -0.5F, 0F, 1, 1, 4); RitSpikeC.setRotationPoint(-1.5F, 18F, 2F); RitSpikeC.setTextureSize(64, 32); RitSpikeC.mirror = true; setRotation(RitSpikeC, 0F, 0F, 0F); RitSpikeA = new ModelRenderer(this, 2, 12); RitSpikeA.addBox(-0.5F, -0.5F, 0F, 1, 1, 4); RitSpikeA.setRotationPoint(-1.5F, 15F, 2F); RitSpikeA.setTextureSize(64, 32); RitSpikeA.mirror = true; setRotation(RitSpikeA, 0F, 0F, 0F); RitSpikeB = new ModelRenderer(this, 2, 12); RitSpikeB.addBox(-0.5F, -0.5F, 0F, 1, 1, 4); RitSpikeB.setRotationPoint(1.5F, 15F, 2F); RitSpikeB.setTextureSize(64, 32); RitSpikeB.mirror = true; setRotation(RitSpikeB, 0F, 0F, 0F); } @Override public void render(Entity entity, float limbSwing, float limbSwingAmount, float ageInTicks, float netHeadYaw, float headPitch, float scale) { super.render(entity, limbSwing, limbSwingAmount, ageInTicks, netHeadYaw, headPitch, scale); setRotationAngles(limbSwing, limbSwingAmount, ageInTicks, netHeadYaw, headPitch, scale, entity); Base.render(scale); BotSpikeB.render(scale); BotSpikeC.render(scale); BotSpikeD.render(scale); BotSpikeA.render(scale); TopSpikeA.render(scale); TopSpikeC.render(scale); TopSpikeD.render(scale); TopSpikeB.render(scale); RerSpikeB.render(scale); RerSpikeC.render(scale); RerSpikeD.render(scale); RerSpikeA.render(scale); FrnSpikeA.render(scale); FrnSpikeC.render(scale); FrnSpikeD.render(scale); FrnSpikeB.render(scale); LftSpikeB.render(scale); LftSpikeC.render(scale); LftSpikeD.render(scale); LftSpikeA.render(scale); RitSpikeD.render(scale); RitSpikeC.render(scale); RitSpikeA.render(scale); RitSpikeB.render(scale); } private void setRotation(ModelRenderer model, float x, float y, float z) { model.rotateAngleX = x; model.rotateAngleY = y; model.rotateAngleZ = z; } @Override public void setRotationAngles(float f, float f1, float f2, float f3, float f4, float f5, Entity ent) { super.setRotationAngles(f, f1, f2, f3, f4, f5, ent); } public void renderAllTE(float scale) { Base.render(scale); BotSpikeB.render(scale); BotSpikeC.render(scale); BotSpikeD.render(scale); BotSpikeA.render(scale); TopSpikeA.render(scale); TopSpikeC.render(scale); TopSpikeD.render(scale); TopSpikeB.render(scale); RerSpikeB.render(scale); RerSpikeC.render(scale); RerSpikeD.render(scale); RerSpikeA.render(scale); FrnSpikeA.render(scale); FrnSpikeC.render(scale); FrnSpikeD.render(scale); FrnSpikeB.render(scale); LftSpikeB.render(scale); LftSpikeC.render(scale); LftSpikeD.render(scale); LftSpikeA.render(scale); RitSpikeD.render(scale); RitSpikeC.render(scale); RitSpikeA.render(scale); RitSpikeB.render(scale); } } Into something that can render as a block. I've tried using a TESR to render it through its tile entity, but haven't gotten anywhere with that -- also, its not really animated, so a basic block model is probably more appropriate. The catch is, the block needs to look just like the entity it spawns ("turns into" for the player), so maybe if I could just create a JSON file based on the same numbers that would be best. Only problem is I don't really know how, and otherwise I'll have to wait for someone else to (maybe) create a model of fix the TESR code. Any ideas where to start for learning this? (Or is this a silly idea?) Thanks!

Ah, so if I actually rendered the entity model directly as a block, it would be a TESR on some level, and the way would be found by researching ICustomModelLoader and its current implementations? (Though if I could duplicate it as JSON it would be preferable). Funny though, I thought all the rendering was ultimately base on OpenGL, just loaded / generated differently. I'll look into this when I have time (I've already spend half my vacation updating someone else's mod, so I may take a break once its in a playable state). Thanks.

Someone please answer this -- a lot of people would like to know -- I for example, have block that is the alternate state of a mob, so the two need to be identical. I know its been stated that block models don't have to be JSON, and this doesn't require TESR. So, is there a standard Forge way to do this, or are such statements a hint to hack in our own way. BUMP!

Trying to use the latest Forge development kit doesn't work with Eclipse Oxygen.3A, which is the latest recommended version of eclipse; it its shows none of the source files or libraries, and gives this error message: This is after running gradle setupDecompWorkspace and gradle eclipse successfully. It also doesn't work with eclipse 3.8 (though no message is given). Yes, it does work with some versions in between, though Eclipse pushes Oxygen.3A as the version to use.

I've started updating the old Dungeon Mobs mod by GnomeWorks to 1.12.2. https://github.com/BlackJar72/dungeon-mobs One thing I seem to have trouble with is rendering items / blocks / non-mob enities (notably throwables, which require and item). For some reason I have the most trouble with this -- I can't figure how to make most other things work one way or another, but rendering in Minecraft kills me everytime (except for mobs). If anyone who happens to be good with rendering would like to help with this I'd be glad, and many learn how its done by example. If not, oh well, please just no one lecture me on figuring it all out for myself.

Mob rendering code from 1.6 or 1.7 (or earlier?) will still work. Then there's the issue of block rendering, when has changed several times. This tutorial series doesn't contain any episodes purely about rendering, but I think it covers some of it when make mobs, items, etc. (linking first episode, not specific / relevant content) :

Look, there is no need to argue. Lets just drop it. I suppose I tend to focus on what seems the greater challenge to me. I like math, I fing algorithms and design patterns quite interesting, and love to workout a way to do something. I've always been good at math -- and according to most people programming -- never at foreign language. This all started with writing an original biome provider, completely unrelated to the vanilla system, from scratch, which I enjoyed. That was the fun, figuring out how to do that. That kind of thing is what go me into modding. I'm consider the issue solved, whether in the best way or not, fundamentally its been solved. But this has gone on enough. Its time to just let this conversation die. EDIT: I suppose I should find a new hobby, though. Not because I just don't have the ability to make another decent mod if I want to, but because, for me, Minecraft is fading -- the game as a whole doesn't hold my interest the way it once did, and modding it no longer helps. So, its time to find another interest. The "new" wore off a long time ago, and its not coming back.