ChampionAsh5357

Since I don't feel like typing out how entity attributes are handled again, read this:

Entity#func_230279_az_. Please specify the class next time.

net.minecraft.client.renderer.entity.model.* And yes, they do exist.

You need to learn some more Java. Forge does provide an easy access to reflection via ObfuscationReflectionHelper. Note: you will need to locate the unmapped names of all the fields you would like to modify.

Update your workspace to version 32.0.40 at least. It fixes the issue of FMLServerAboutToStartEvent being fired too late on an integrated server.

harvestLevel and harvestTool still need to be reevaluated. Until then, they will not work.

You would need to call Block$Properties#sound and pass in a SoundType. If you want to use custom sounds, you would need to create your own SoundType using the constructor.

Deprecation of randomTick and tick have nothing to do with overriding the methods. The deprecation is for usage. When calling those methods, you should call them through BlockState rather than through Block. As for why it won't work, you probably didn't add tickRandomly() to your block's properties. Deprecated methods will still work regardless.

You would need to modify fuseTime and explosionRadius within CreeperEntity using reflection.

harvestLevel and harvestTool still need to be re-evaluated. Until they are, implementations of these two methods will not work.

That's probably because that wouldn't be in TreeFeature as literally everything about the tree is customizable. You can even see that within the BaseTreeFeatureConfig. There you'll probably notice something called AbstractTrunkPlacer. From there, you'll find AbstractTrunkPlacer#func_236909_a_, a method that calls TreeFeature#func_236408_b_ with DIRT as a parameter. Looking into that method, you'll see that it sets the block state at the position to DIRT. So, you should probably create your own AbstractTrunkPlacer and implement the changes you want.

I am currently in the process of updating the docs's current information to 1.16.x as of version 32.0.38. There are a few quick fixes I have done already. I want to edit the Creating Registries section to include the static initialization done by DeferredRegister. The way, if I'm not mistaken to implement a custom registry using DeferredRegister is by using: public static final DeferredRegister<REGISTRY> REGISTRY_INSTANCE = DeferredRegister.create(REGISTRY.class, MODID); We can also create the registry rather than using the event by calling DeferredRegister#makeRegistry. My guess at an implementation would be: public ExampleMod() { REGISTRY_INSTANCE.makeRegistry("custom_registry", () -> new RegistryBuilder<>()); REGISTRY_INSTANCE.register(FMLJavaModLoadingContext.get().getModEventBus()); } DeferredRegister#makeRegistry returns a Supplier holding an IForgeRegistry. My question is what would the return value be used for and if this is the correct representation of the method. Thank you for your time.

MinecraftServer now uses a different system called DataPackRegistries to combine the reload and initialization of the listeners in one place. To access it, use: ((IReloadableResourceManager) event.getServer().getDataPackRegistries().func_240970_h_()).addReloadListener(listener); Note that the cast is necessary as the function returns an IResourceManager compared to its stored IReloadableResourceManager variable.

Sure, but if you want that, you might want to take a look at the EntitySheep code.

I would say read through the forge documentation and maybe look through some of Mcjty tutorials. If you don't have an intermediate understanding of Java, please go learn the language. To answer your question, FMLJavaModLoadingContext is basically a helper to get the current mod's event bus to register mod specific events. IEventBus#addListener basically takes in a Consumer that contains a parameter extending Event, the base for all forge events. Since Consumer is a functional interface, we can use Java 8 to reference specific functions within our class that has a parameter extending Event. This is why you see: modEventbus.addListener(this::function); This allows us to specify a specific event type to execute for. As for your hello world project, you can look within the forge source provided to find the correct event you might need to use (e.g. PlayerEvent$PlayerLoggedInEvent should work). If you looked at the reference calls it makes, you would see that the event is called on the forge event bus, so you would need to either add a listener to a non-static method or subscribe it to your mod's event bus using an annotation on a static method. From there, you will probably find the method PlayerEntity#sendStatusMessage. Note that this method only has relevance on the logical server. Hope this helps.

It would be good if you could show your code, that might help find the issue. My guess is you didn't register MobEntity#func_233666_p_ in your FMLCommonSetupEvent for your specific entity type as that does initialize the follow range attribute with a value of 16.

Did you damage the item without setting Item$Properties#defaultMaxDamage to a value?

DeferredRegister#create, check out the documentation in the source file next time.

Check if the held item in the hand (LivingEntity#getHeldItem) is holding either an instanceof your weapon class (if you want all weapons with that class to have the effect) or check explicitly if the item is your item.

Get the PlayerRenderer for the default and slim skin maps and then call addLayer for both of them.

You override the method? Even though if you're extending ArmorItem the only thing you need to do is specify the slot given in the constructor. As for the rendering, look at ElytraLayer for your base line and then apply for each skin map in the EntityRendererManager.

Rendering and the chestplate slot both are specified explicitly to the Elytra object and no other. If you want to get around that, you would need to register your own layer on the player and override IForgeItem#getEquipmentSlot with the slot you want the eltyra to go in.

I'm guessing you didn't look at the BeaconScreen code at all. Here's a tidbit: [removed code for BeaconScreen#drawGuiContainerBackgroundLayer - diesieben07] You would just need to adjust the x and y offsets from there.

Add a configurated feature in the biome (probably an OreFeature if generated in clusters) with your own FillerBlockType created using FillerBlockType#create. If you're generating clusters of one, use ReplaceBlockFeature where you only need to provide a blockstate of the target and new state. Remember to call these methods within a DeferredWorkQueue within your FMLCommonSetupEvent as they are not thread-safe.

FluidTags#makeWrapperTag or TagRegistry#func_232937_a_ for a more general case should work. And they are now ITag#INamedTag objects.