jabelar

Can't you just handle the RenderSpecificHandEvent and reset the swing progress to prevent it?

The biome has four lists: spawnableCreatureList, spawnableMonsterList, spawnableCaveCreatureList and spawnableWaterCreatureList. I think you could add them during the post-init phase of loading where you could use the BiomeManager and find the entries you're interested in and then use the getSpawnableList() method and edit it (it is public so I think you can directly edit it).

Well, the sign gui has a multi-line editor which is already "Minecrafty". If you wanted something more full featured I suppose maybe Swing components like JFormattedTextField.

DimensionManager.values() will return an array of DimensionType, including any registered by mods. You can use the getName() method on each element in the DimensionType array. You can also get ID, but you need to be careful with that as technically there is an ID in the DimensionManager and also an ID in the DimensionType and they are not guaranteed they are they same (although I recommend that modders do make them the same where possible). So probably the best way to get both ID and name is to use the DimensionManager.getIDs() method and then for each int element value use DimensionManager.getProviderType().getName() to get the name.

The original question is a bit ambiguous, but I read it as he wants to replace the loot globally for wither skeletons. In the event you get the name of the resource which would let you filter to only change the wither skeleton loot.

You can't just say "I wasn't able to find anything solid that I could use". You need to say what you looked at and why you had difficulty. I mean you want this to work like a horse, right? So I assume you looked at EntityHorse and its parent AbstractHorse? After looking at that, what did you try? Or what is your actual question?

Whenever your code doesn't do what you expect, you need to do standard debugging. That starts with observing the execution. You have a couple options, you can set a breakpoint on the onImpact() method and run Eclipse in debugger mode then step through and watch what is happening, or alternatively you can add System.out.println() or logger statements in your code to print out to console or log information that helps you understand what is happening. You need to first determine if your onImpact() method is even being called, and if it is being called trace through to understand why it isn't having effect. If you use one of the techniques above it should be quickly obvious what is wrong.

So yeah, so as you've found the WorldProvider class already does a celestial angle implementation and the WorldProviderSurface doesn't override it. So if you don't override it, then you'll get the same implementation. You should go through your other methods as well and confirm whether you really want to override them. The WorldProviderSurface really doesn't override much, so mostly you shouldn't override unless you specifically want it different than the overworld. The good thing is now you've learned how to find the source code, that is really the key to learning modding -- inspecting how vanilla does things. In addition to the Type Hierarchy, I strongly suggest you learn to use the Call Hierarchy which is really useful in Eclipse. The Call Hierarchy shows you everywhere a method, field or constructor is called and so it can give you great confidence in the proper use of methods.

Assuming you ran the full gradlew setupDecompWorkspace when you were setting up your workspace, then you should have all the source available as a Referenced Library in your project. So if you go to the Package Explorer pane you can navigate to the referenced libraries and find one (usually the first in the list) there should be one called forgeSrc and you can go into that to find all the net.minecraft and net.minecraftforge packages with code. That is for generally browsing the code. However, you can also find specific stuff. For example, your code extends WorldProvider. So if you want to see the code for that, you just click somewhere in the word or select it and then right-click and select Open Declaration. That will open up the source for that. Now the overworld probably extends WorldProvider so to find all the code that extends that, select the word and right-click and select Open Type Hierarchy. That will open up a pane that will show you all the classes derived from it, and also all the methods in it and inherited by it. You can then double-click on one of the derived classes to open up its source. So specifically for this case I would: 1) Open up your world provider class 2) Go to top of the class where you extend WorldProvider, right click on the world "WorldProvider" and select Open Type Hierarchy. 3) A pane will pop up that shows that there are derived classes and one of them is called WorldProviderSurface. You can guess that that is probably the overrworld. So double-click that in the hierarchy window, and that will open the source. 4) You'll find that the WorldProviderSurface doesn't override very many methods. You're interested in the celestial angle, which isn't overridden. So you will want to go up the hierarchy. So double-click the WorldProvider class in the hierarchy window. 5) Scroll through the code, or use Control-F, to find the calculateCelestialAngle() code. Basically using these techniques of selecting, using Type Hierarchy, you can quickly navigate through the parent and children classes. One other tip, when you bring up the Type Hierarchy it will also list all the fields and methods in the selected class. However, there is a toggle option (one of the small icons) where you can have it list all inherited methods. If that was on, you also can find the calculateCelestialAngle() method there and immediately see if it has overrides.

As Draco18s said, it is best to learn how block states and variants work. However, if you're really stuck trying to understand it it would actually work to make new block for each. Not elegant, but it is logically a legitimate way to implement it.

Okay, I understand what you're trying to do. But honestly you're really describing generating dungeons that are semi-custom depending on the mob spawner. In that case you're going to in some way need to have a list of the things you need to customize based on the entity, such as the floor, loot table, and any other things like height of the ceiling or other decorations. Once you get to that point, you might as well just create a list for each entity. There are not really that many vanilla entities -- maybe about 25 land-based ones. I would just make a "hard coded" Map collect with suitable blocks associated with each.

Do you really need to change your dungeon floor? I'd look at it the other way -- just force the entities to spawn on your floor. During world gen you can generate a mob or two as you want and after that you can handle the spawner generation with the event.

It is stuck because you're setting the celestial angle to always be the same value of 0.50F.

But since you're doing your own world gen why can't you just spawn your own entities?

Why not use the LivingSpawnEvent.CheckSpawn? Because in that case you could just force it to spawn on your blocks. Also, if you're concerned with world gen and if the event doesn't fire at that time at least during world gen you can generate any entities you want yourself.

I think you need the isSurfaceWorld() method to return true if you want the sky to render.

Yeah, that is a typo. I actually have it in two places in the article and in one place is it correct other it isn't thanks.

I think you need to make an advancement for each ingredient, as I think that is actually what happens in vanilla too. You don't need to make it a "visible" advancement in the advancement tree but it needs to exist. Look in the advancements.recipes assets folder in Minecraft to see examples of how the recipe advancements should be written.

This thread discussed how to get a window handle and might be useful to you: http://www.minecraftforge.net/forum/topic/63434-1122-hooking-into-lwjgl-minecraft-window-to-add-macos-touch-bar-features/ Also, I think there is a RenderTickEvent. That should probably tick no matter whether you're in a world or in main menu. Note that that event is called a couple times per tick so you should check the phase (like START).

It is 1.12.2. So you should have it. Make sure your build gradle file has a recent mapping indicated otherwise you won't get all the right method and field names. You can look at my build.gradle file in my repository to see what I am using.

It really depends on how nicely you want to play with the other vanilla biomes. The biome dictionary is intended to allow you to add biomes that are categorized such that they will generate naturally in a way that "makes sense" in terms of whether they are dry, cold, etc. That is the best way to hook into the vanilla generation without getting caught up in the intricate generation details. To add to the complication, I think there is some "abandoned" code. Like in the generateChunk() method near the end there is an local field for an array called abyte[] which seems to store all the biome IDs. however I don't see it ever being used. But since you also have the Z position requirement, I would guess there is no good way to fully integrate that into the vanilla generation which uses some randomness and some categorization to blend things together. So I think there is nothing wrong with forcing it in the chunk generator setBlocksInChunk() method, although maybe it would feel more logical to do it in your BiomeProvider's getBiomesForGeneration() and I think also the getBiomes() methods. You just need to make sure that the array that tracks actual biome is also properly updated. So in summary since you want your biome to generate semi-naturally, I would make sure it is tagged properly in the biome manager and biome dictionary type registrations and then to control the Z I would check and/or force that in the biome provider.

With modding you've only got a few alternatives to change vanilla behavior. Either Forge provides a hook, or they don't. If they don't if the vanilla fields/methods have public scope field available then you take advantage of them as you can. Lastly, you can use Java reflection to try to access fields/methods that are not public. Basically what you're experiencing is the immense value of the Forge hooks. Without them, most modding would require very invasive "sledgehammer" code replacement. I suggest you actually try making a Pull Request for MinecraftForge to add hooks you're interested in. It is a great way to give back to the community. I admit I only started doing it recently, and there are some tricks to it, but feels good.

I have a fair bit of tutorial information on custom dimensions, biomes and such. See: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-biome-quick-tips.html. There is a link to a fully custom dimension tutorial in there as well. You're right that the vanilla code is extremely convoluted -- it has redundant fields that point at each other, it uses terms that sound similar like generate, decorate, populate, and there are things called "world gen" that are actually just featues, but not full worlds. There are recursive structures, and so on. But the thing to remember is that after all the generation is simply placing blocks and actually as long as you get blocks where you want them it is all good. However, in your case you might be able to get by mostly by using the biome "type" both in the BiomeManager and BiomeDictionary. Those both have category tags for your biome like "COOL" to help the vanilla generators properly mix biomes. Regarding it only generating on certain Z values though that might be a bit trickier. One way might be to have the chunk generator's biome map replace your biome with another similar vanilla one whenever the Z doesn't match. Not sure how easy that would be exactly. The most control would come from making a custom dimension. You could basically copy the overworld but when it is selecting the biomes during generation you could check the Z and force your biome when desired.

I have a tutorial on custom dimension, along with a custom biome, here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-custom-dimension.html

The game is already looping, that is what a "tick" is. So you can handle the ClientTickEvent and check for mouse button press and then do ONE loop's worth of processing.