Leaderboard

They are not deprecated per sé, rather Mojang's devs stating "don't manually call these". They are just fine to override. This only applies to the @Deprecated methods in the Block class, AFAIK.

To code, to program, or to mod. Yes, I make a distinction between simply coding (writing technically valid code in some language) and programming (developing software to solve an actual problem). I learned the basics of Java from a teach yourself in 21 days book, about 15 years ago. Then, after being poor and without a computer for many years I re-learned Java from the official tutorials that Oracle has (https://docs.oracle.com/javase/tutorial/), though those might go a bit fast for someone who has never written code before. Before that I'd learned Atari Basic, Pascal, and beginning C++ (in that order). I was self-taught in all but Pascal (which I had a class on in high school), starting with Basic when I was in elementary school. Really learning to program was then a mater of practice -- the more you do it that better you get. Once you know the basics of a language, the thing to do is just start trying to do things with it. No matter what books you read or videos you watch you will never really know how to program unless you put time into programming -- like any skill it requires practice. As for modding, I watched some old videos by SweGoesMincraft (or something like that) which were for 1.6.4, to get the basics -- how to get Forge to recognize it as a mod, how to have Forge initialize it, etc. For there it was a mater looking through the code and figuring things out. This is also a skill; at first it can be hard -- Minecraft is most often not organized in the way I'd find most obvious. But a lot of it was trying things and see if they worked, looking at error reports to track down anything that actually crashed, struggling to figure what was going wrong if I didn't get the results I wanted. I remember the first time I got something to generate in game -- a quartz pillar though the middle of each chunk -- it seemed so cool that I'd made the game do *something*. I then went on to have it build scattered empty rooms, then rooms with content, then whole procedural dungeons (my real goal), and at each step I felt good that I'd made it work. That is how you learn to mod.

Many mods have been put up at github. If you Google this forum for github references, you can follow the links to see examples of what other modders have done (some are better to emulate than others).

This has worked.... Wow... Sry oO What a simple Solution and I do not come to this simple solution . Thanks a lot. Now it works.

I found the bug. It is because I adding the move through village AI task to the entities in the nether and that causes chunks to load. I will mark it as solved. DO NOT ADD MOVE THROUGH VILLAGE AI TASK TO NETHER ENTITIES.

Like Ugdhar says, the best thing is to learn to figure it out yourself. This is because that is what modding is based on. Other modders that write tutorials didn't learn it magically, rather they used their Java knowledge and inspected the vanilla code and then came up with ideas. Of course if you do find a tutorial then it is lucky, but just don't count on it. Also, unfortunately Minecraft has changed a lot over just a few years, and Forge continues to be revised as well, so tutorial information becomes outdated very quickly (I know because I try to write a lot of tutorial information). The other thing is that many modders post their code on places like github and allow public access to it. So you can simply take your favorite mods and check their code as well to get ideas. I'm honestly not much of an expert on world gen but I have a bit of information here you might want to think about: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-biome-quick-tips.html I should warn you though that from a code perspective, the world gen is some of the hardest to fully understand. There are a lot of classes and methods with similar names, and the random generation can make it hard to really picture the execution logic just by reading it. But it is obviously a fun thing to mod so worth learning. Note that in the end world gen is really just about placing blocks. So as long as you hook into the world gen process with a chunk generator, whether you follow the standard way of creating terrain, features and structures or just do your own is up to you.

Okay, except comparing your code to the vanilla Overworld chunk it seems you have some relevant changes. I expect that many of these are changes you've done while debugging but I just want to make sure. Some things that are different from vanilla: - in the generateChunk() method you have removed all the parts where it generates most features like caves, ravines, villages, monuments, mineshafts, etc. - in the populate() method you have removed the woodland mansion generation. - your code has a method called getScatteredFeatureSpawnList() which in my Forge Reference Library seems to now be getMonsters(). I guess they changed that between your version of 1.12.2 and mine. None of the above should be an issue and I assume you probably did the removing of features as part of the debug, right? Okay, looking further at your code, in your WPMedieval class you are associating a biome provider for a single biome that is your custom Generizer.MEDIEVAL. Since that isn't a copy of vanilla I wonder if your problem is actually with your biome stuff. I'm not that experienced in custom biomes, but I'd suggest greatly simplifying that as a debug step. Only register one biome and don't remove any vanilla, or maybe even just do nothing in terms of new biomes, and see if the problem still exists. Now one thing that I always run into trouble with regarding world gen is that the relationship between classes is very convoluted. It is possible you're running into such trouble. For example in your WPMedieval you specify that the DimensionType is OVERWORLD, but if you look at OVERWORLD it is defined to have a WorldProviderSurface. In other words your world provider is pointing to a dimension type that says it has a different world provider. I have no idea if that is an actual problem, but doesn't seem "healthy". Frankly the way that the world gen classes over-reference each other can cause some weird things like that. You might want to try creating a custom DimensionType that properly points to your world provider and clean up any other such things you might find. Similarly you might want to try making a custom WorldType instead of using the vanilla one because again it might have references to a different IChunkGenerator or other stuff that conflicts with your stuff. You also have two custom IWorldGenerator classes registered. Have you tried isolating to see if they are causing trouble? -- like don't register them and see if issue goes away. Also, in your IWorldGenerator classes you end up calling the CustomGenMinable class which extends the WorldGenerator class. So you're kind of mixing the Forge IWorldGenerator class with the vanilla WorldGenerator class. I don't know if that is a problem, but I think the idea is modders should use IWorldGenerator purely. Just some ideas. -

To help in future cases: When Obj::field stops working, it's usually because the field has been encapsulated and can only be accessed/changed with accessor/mutator(getter/setter) functions. That is, it typically becomes either Obj::getField/Obj::setField, or something similar if the field name changes(if you're using an IDE, you'll typically find it in the lookup). If you're still having trouble, you can usually find it by skimming the source files(some IDEs allow you to jump to a referenced class if you highlight it and right-click/use a keybind).

ItemStack::getCount