Leaderboard

Just because something works in the test environment doesn't mean it's good practice. I can declare all my objects as static final variables without deferring anything and it will still work. However, it would be a terrible fate to attest to since issues wouldn't be present except in broader scenarios. Everything feels disconnected when just starting out. This why we try things out until we understand how it works or ask questions for more specific topics. The objective of any programmer is to understand what they're doing, why they're doing it, and how they can complete it in a proper and/or efficient way. Following a tutorial just says here how's you do it without the what and why. We have to be able to problem solve in any situation presented to us. Whether that's through hard trial and error or asking others about the specific topic, it still allows the programmer to learn. I do admit when I started out in modding I didn't understand anything. I used bad practices from code I figured out at the time and never updated to new standards. Nowadays, I try to be on top of what I'm doing else I would fall behind. I'm not going to wait to figure out how to do something from a post. I'm going to keep testing and learning why certain things are how they are and how to use them properly. That's the reason why I am arguing this point. I'm not arguing for or against using a tutorial. I'm arguing against relying on the tutorial in any scenario since you as the programmer should be able to infer and predict how to make it yourself. That's not to say it'll work, but it at least shows you tried to solve the problem before relying on someone else's solution.

Have you try to look around the forum or see how vanilla does it? Use IWorldWriter/World (can't remember which) .playSound() and .add/spawnParticle().

Stuff like this can be easily found both in the vanilla Minecraft source code, and on the forge documentation (here is the documentation on sound for example). It will take forever for you to finish your mod if you have to ask a question here for every method you want to use. You should really take some time and learn the features of your IDE.

You can save the magnification value on the stack on serverside, and change the fov according to the magnification stored on the stack in the fov update event.

Ok I see how this could be achieved. You need to use 2 handlers though, what you suggested in the first post just would not work.

The isEmpty is unnecessary if you're going to compare the item to something. If it is empty, the item returned by getItem is AIR, which is definitely not ITEM_NAME

Exactly how do you think this would work? Are you expecting both events to fire at the same time?

This bug was fixed in a recent version, update

Instead of using multiple DeferredReigsters and iterating through your Blocks to register your BlockItems, it's probably simpler to just register the BlockItem at the same time as the Block (with DeferredRegister, so the actual registration still happens at the right time). This can be done helper methods like these; you could create a single method that takes the ItemGroup as a parameter, or separate methods for each ItemGroup.

This and this and this : All do the same thing. Pick one. (Ok, the last one registers another class, but all three are "I would like to register something with the event bus please")

No. I mean "don't use a list." public static void createBlockItems(final RegistryEvent.Register<Item> event) { final IForgeRegistry<Item> registry = event.getRegistry(); registry.register(new BlockItem(ModBlock.BlockA, new Item.Properties().group(ItemGroup.GROUP)).setRegistryName(ModBlock.BlockA.getRegistryName())); registry.register(new BlockItem(ModBlock.BlockB, new Item.Properties().group(ItemGroup.BLOCKS)).setRegistryName(ModBlock.BlockB.getRegistryName())); registry.register(new BlockItem(ModBlock.BlockC, new Item.Properties().group(ItemGroup.REDSTONE)).setRegistryName(ModBlock.BlockC.getRegistryName())); registry.register(new BlockItem(ModBlock.BlockD, new Item.Properties().group(ItemGroup.DECORATION)).setRegistryName(ModBlock.BlockD.getRegistryName())); } Also this line: IForgeRegistry blockRegistry = GameRegistry.findRegistry(Block.class).getRegistrySuperType(); Is useless, you never actually do anything with the blockRegistry. Objects.requireNonNull(block.getRegistryName()) RequireNonNull here is also useless. If it was null, the game would have already crashed. 12 blockItem.setRegistryName(Objects.requireNonNull(block.getRegistryName())); 13 registry.register(blockItem); setRegistryName returns the object, removing the need for a local variable.

You need also to chain the #build() method to #create, so it would be like this TileEntityType#Builder#create(your stuff)#build(null) since its #build() that actually returns the TileEntityType

Run gradlew --refresh-dependencies , after that run gradlew clean, and finally setup your project again with gradlew genIntellijRuns Have you already tried this process ^ ?

I recommend McJty's tutorial