Leaderboard

My recommendation would be to use World#isRaining in conjunction with Biome#getTemperature (with the biome obtained via World#getBiome). Though, it sounds like you're already doing that; why won't getBiome work for you? Edit: My bad, I was a little too hasty; I've edited my answer.

ClickEvent.Action.OPEN_URL

Using the Forge method would indeed be preferred. My thought on the matter is: Vanilla methods that are marked deprecated means they should not be called by outside methods. Due to this, the method can be removed at any time by Mojang or Forge without undergoing the "oh look I'm deprecated, that means I will get removed in the next version; your IDE should be shouting at you to use the newly introduced approach instead!" Therefore the Forge provided method is often considered a better approach and often more future-proof.

This one is outdated, but the explanation of the concept is still the same:

It seems like I'm learning, since I did think to try this, and it worked! Thank you so much, you're a champ

Hmm, I don't use Eclipse myself so I'm not entirely sure if it's a problem with that or if it's something else... All I usually have to do is press a button which re-imports the Gradle project (I use IntelliJ IDEA). Not sure if Eclipse has a similar function somewhere. You could also try deleting your Gradle cache to force it to refresh. There should be a .gradle folder in your computer's user directory, all you should have to do is delete the caches folder. Not sure if it'll work as I expect, but it may be worth a shot if you can't figure out anything else (unless someone who knows Eclipse better than me can provide some tips).

Makes sense, considering I used the methods.csv of the latest snapshot to find World#func_226691_t_ in the first place

Sounds like an issue of using outdated MCP mappings. Make sure you're using the latest snapshot version (20200513-1.15.1 at the time of writing this).

You need to create your own IRecipe implementation.

BabyEntitySpawnEvent only fires on breeding, so it wouldn't cause the recursion you mentioned as long as you configure the additional babies manually. Analyze the BreedGoal#spawnBaby method to see how you should configure the additional babies. Also, don't forget to use a lower event priority and check if the event is canceled before doing anything in case another mod wants to cancel the spawning.

Sure! I hadn't really looked into the generateNoiseOctaves function properly, it takes arguments: (double[] noiseArray, int xOffset, int yOffset, int zOffset, int xSize, int ySize, int zSize, double xScale, double yScale, double zScale) The return value shape is determined by the x-y-zSize parameters. These are the size of the region you want to sample. Changing the size will not change the scaling or the density of the noise, it sort of just expands the area generating new noise in those new parts. The x-y-zScale parameters will of course change the scale. The x-y-zOffset will move the noise around inside the area. I then sampled points around this area with some interpolation to create the final world shape.

Ran a quick test, both registries seem to return the same IDs, which makes sense all things considered. So, both the vanilla and forge registries would work for this purpose, unless I'm missing something. In the end I believe it would just be personal preference; most modders seem to use the vanilla registry, but using the forge registry may be preferred by the forge team.

Not really. I've done a little searching, and about the best I've come up with is: https://wiki.mcjty.eu/modding/index.php?title=Tut14_Ep12 https://gist.github.com/Commoble/ac7d7b57c9cbbfcae310c4ab110c3cc0 and small bits and pieces here and there from random googling. Really more than likely, after getting the hang of how things are put together, chunk generators/biome providers/etc. looking at the vanilla code, and probably reading up on noise algorithms are going to be the best bet. I usually make it an hour-2 digging through the vanilla code for world stuff before I start going in circles and my eyes cross lol.

If you keep stepping through it, do you get to an endless loop or something? I mean, doing that should show you exactly where in the code it's getting stuck. I'm guessing something is null, or there's a loop that never meets its exist condition or something. And I figured you weren't getting a crash since you mentioned that it got stuck. You should push this to a github so that people can see updated code as you change things, and see the big picture. For instance, we have no dimension code, and can't see the resource location of the dimension. Sometimes something that appears unrelated might have something to do with the problem, that's why when I have an issue I always share all my code, I figure since I'm asking for help, what do I know what code is relevant or not?

Unfortunately it sounds like you were blindly following from one of the (rather terrible) tutorials on YouTube, and therefore do not understand how registering stuff actually works. A class per registry entry is not necessary. All you need is an instance of Block to register a type of block. In this case, you should instantiate an instance of SlabBlock per slab you want, and register these instances. I would also suggest reading the registry page on Forge's Documentation: https://mcforge.readthedocs.io/en/1.15.x/concepts/registries/

Why don't you just use forge setdimension ingame?

Yes, that's all you need to do. It won't affect any of the game's normal behaviors, aside from what you change (i.e. the stack size). I recommend adding an option in your mod's config to disable this feature if desired by users, but that's up to you. You may also want to use a different event priority for registering your replaced item to make it harder/easier for other mods to override your replacement by default.

Keep in mind that a lot of the concepts from previous versions can still apply. In the case of extra utilities, it save the item's creation time to NBT, compares it to the world time, then uses PlayerTickEvent to blow up players who have expired ingots in their inventory.

Use a deferred registry, it's designed to get rid of these sorts of headaches.

Then you're gonna have a lot of problems. The workbench is programmed so simply that if you copied the workbench exactly (provided you updated the way of handling containers), you would only need to change a single line of code within the container.

Apparently it is fixed by running gradlew build and after that, refreshing build.gradle.

"There are mappings in MCP bot but not in my workspace" "I'm using 4 month old mappings!" See the problem here? Update your mappings. Nothing to do with us.

And remember to both initialize and reset pressTime to zero somewhere so you can do your magic first time and every time