Choonster

I decided to report this on GitHub.

This is a known issue.

Minecraft Version: 1.14.4 Forge Version: 28.0.19 Code: https://github.com/Choonster-Minecraft-Mods/TestMod3/tree/ba1306dd180514cc7dd135b21262f8eb72cdd305 Log: https://gist.github.com/Choonster/2ee4d06856ca409f85b89728e9ddd47e After updating to 1.14.4 and attempting to run the client (the first time since updating to 1.14), I encountered a crash due to LastUseTimeModelItem#initCapabilities being called when LastUseTimeCapability.LAST_USE_TIME_CAPABILITY was still null. It appears that an ItemStack of this Item is being created in Minecraft#populateSearchTreeManager, which is called towards the end of Minecraft#init. ClientModLoader.begin is called earlier in Minecraft#init to start loading mods, but this doesn't actually fire FMLCommonSetupEvent (the event that Capabilities are registered in) directly; instead it registers a resource reload listener that fires the event (and the other setup events). The initial reload that calls this listener doesn't happen until the very end of Minecraft#init (after Minecraft#populateSearchTreeManager). It feels counter-intuitive that IForgeItem#initCapabilities can be called before Capabilities have actually been registered, but is this a bug or is it intended behaviour?

You need to use the registry name of the Biome, not the numeric ID or the display name. This will be whatever you name you've specified in the setRegistryName call for the Biome.

It looks like the possible trades for each level of each profession are stored in VillagerTrades.field_221239_a (may have a deobfuscated name in newer mappings). The trades for each level are stored in an array, so you can probably create a new array with the both existing trades and your new trades and then replace the existing array in the profession's Int2ObjectMap.

This was fixed by this pull request for 1.14.3. Update to the latest 1.14.3 version of Forge.

I suggest looking at how Block#rotateBlock finds the property to change and doing something similar.

Recipes don't have to have the same name as their output item, you can call your recipes whatever you want.

All of the sound-playing methods in the documentation are methods of the class mentioned in the header. e.g. The first three are methods of World, which means you need to call them on an instance of World.

You could probably use ForgeConfigSpec.Builder#define(String, T, Predicate<Object>) with a Predicate that checks if every integer in the array is within the appropriate range. The only downside I can see is that Forge will correct single number properties outside the defined range to the minimum or maximum of the range; but if any number in your array is outside the defined range, Forge will correct the entire property to the default array value.

Metadata doesn't exist in 1.13+. To copy damage (or any other value) from an ingredient to the output, you'll need a custom recipe type that overrides IRecipe#getCraftingResult. You can see an example of this here, with a JSON recipe that uses it here.

I ended up initialising my SoundEvents in a method called from RegistryEvent.Register<Item> and storing them in a temporary Map until they're registered in RegistryEvent.Register<SoundEvent>. You can see this here.

The parameters of that overload of defineInRange are (path, defaultValue, min, max). You're passing 1.0 as the default value and -3.0 as both the minimum and maximum values.

1.13 flattened spawn eggs into a separate item for each entity type instead of being a single item with the entity type in the NBT. See the wiki for the new item registry names.

In TestMod3, I have a series of packets for updating item capability data in Containers. Because they all operate in similar ways, they all extend a generic base class and their static encode/decode/handle methods all call corresponding generic static methods in the base class. I've run into a strange issue with the decode methods where IDEA can infer the type arguments and doesn't want me to explicitly specify them, but the compiler can't infer the type arguments and generates a compilation error. You can see an example of a decode method without explicit type arguments here, which generates this compilation error: TestMod3_1.13.2\src\main\java\choonster\testmod3\network\capability\fluidhandler\MessageBulkUpdateContainerFluidTanks.java:49: error: incompatible types: cannot infer type-variable(s) HANDLER,DATA,MESSAGE return MessageBulkUpdateContainerCapability.decode( ^ (argument mismatch; cannot infer functional interface descriptor for MessageFactory<HANDLER,FluidTankInfo,MESSAGE>) where HANDLER,DATA,MESSAGE are type-variables: HANDLER extends Object declared in method <HANDLER,DATA,MESSAGE>decode(PacketBuffer,CapabilityDataDecoder<DATA>,MessageFactory<HANDLER,DATA,MESSAGE>) DATA extends Object declared in method <HANDLER,DATA,MESSAGE>decode(PacketBuffer,CapabilityDataDecoder<DATA>,MessageFactory<HANDLER,DATA,MESSAGE>) MESSAGE extends MessageBulkUpdateContainerCapability<HANDLER,DATA> declared in method <HANDLER,DATA,MESSAGE>decode(PacketBuffer,CapabilityDataDecoder<DATA>,MessageFactory<HANDLER,DATA,MESSAGE>) However, adding the explicit type arguments (like this) causes IDEA to recommend removing them, as shown in this screenshot: Does anyone know what would cause this mismatch, or if there's a way to avoid the explicit type arguments here?

They've been replaced by the Vanilla EntityType class and its builder.

The implementation of the create method is generated at runtime for enums that implement IExtensibleEnum. See the doc comment on IExtensibleEnum for more information.

If you mean a network message (SimpleNetworkWrapper/SimpleChannel), use PacketDistributor.ALL and PacketDistributor#noArg to get the PacketTarget argument for SimpleChannel#send. PacketDistributor.ALL sends the packet to all players on the server.

I have a system to sync ItemStack capabilities here and here, the packet classes can be found here. You can see the implementation for IPigSpawner (IPigSpawnerFinite) here and the corresponding packets here.

Generally you should use LazyOptional#ifPresent to run a function (usually a lambda expression) if the value is present. The function receives the interface instance as an argument. If you need the interface instance itself, you can use LazyOptional#orElse or LazyOptional#orElseGet.

The 1.13.2 update of TestMod3 is still very much a work in progress, there are lots of parts that haven't been fully updated to the new version and the mod as a whole doesn't compile yet. @V0idWa1k3r is correct that the ItemPigSpawner class is still referencing the 1.12.2 version of CapabilityPigSpawner.getPigSpawner. The CapabilityX and command classes are probably the best place to look for updated examples of capability use. LazyOptional#ifPresent is probably the most common method you'll be using to interact with capabilities, but there are other methods in LazyOptional depending on what you're trying to achieve.

PlayerInteractEvent is a base class for the more specific interaction events, so it doesn't have all of the information itself. PlayerInteractEvent.EntityInteract is fired when a player right clicks an entity (including another player). getEntityPlayer() will return the player that did the clicking, getTarget() will return the entity that was clicked.

I believe that Cadiboo was suggesting you look at the implementations of those GUIs (i.e. GuiModList and GuiConfig) for examples. It looks like GuiModList uses GuiScrollingList and some of the children of GuiConfig extend GuiListExtended, so these are probably the places to start looking.

If you're extending an Entity class without an EntityType constructor parameter, you need to override Entity#getType to return your EntityType. The same applies to TileEntity classes with TileEntityType.

You need to sync the capability values to all players watching the player entity, not just the player themselves. You can use SimpleNetworkWrapper#sendToAllTracking(IMessage, Entity) to send an IMessage to all players tracking an entity.