Choonster

ItemBlock uses the Block's creative tab, so calling Item#setCreativeTab on an ItemBlock won't do anything.

I have a DataFixer designed to flatten blocks in preparation for 1.13 here (the flattening definitions are initialised here). You should be able to use it to achieve this remapping. If you decide to use it, make sure you understand how it works first.

setupDecompWorkspace doesn't exist any more. Import build.gradle into your IDE as a Gradle project, then run the genIntellijRuns or genEclipseRuns task as appropriate.

It's the thread stickied at the top of this forum called "Rules and EAQ - READ FIRST OR YOU WILL GET BANNED!!!".

The BlockFlattening.create method creates an instance and initialises it with the blocks to be flattened. The instance is registered with the mod's ModFixes instance here, this is called in init.

I've written a block flattening DataFixer in 1.12.2 for my mod's variant blocks here. If you use this code, make sure you understand what it's doing.

Use Entity#getType to get its EntityType, which is an IForgeRegistryEntry.

Instead of constructing the PacketBuffer, writing to it and then calling openGui, simply call openGui with a lambda function that writes to the supplied PacketBuffer. Forge constructs the PacketBuffer for you.

Your most recent few posts with these pre-written snippets of advice have been poorly formatted on the dark theme: To fix it, you should be able to use the Tx (Remove Format) button and then re-apply the code formatting to the necessary parts. Normally I'd PM you this, but unfortunately the forum wants me to delete a whole lot of PMs in my inbox before I can send another one.

You'll need to create your own IRecipe implementation (optionally extending an existing one like ShapelessRecipes) that implements IRecipe#getRemainingItems to return the appropriate remaining items. You'll also need an IRecipeFactory to parse your recipe from JSON, this needs to be registered in _factories.json. You can see some examples of custom recipes and factories here and the _factories.json file here.

It looks like TagCollection#getOwningTags does this, but it's a client-only method so you'll need to copy its logic rather than call it directly. This iterates through all registered tags of the TagCollection's type, so you may need to cache the results if you call this frequently.

Thanks, that makes sense. I'm wondering how this approach would work in 1.13 with its removal of the current lifecycle events such as preInit. The closet equivalent would be the mod construction event (don't have the exact name at the moment), but I think that the documentation only suggests initialising registry entries in the appropriate registry events.

I'd be curious to know what the proper way to handle records is. I've just realised that my record item hasn't worked since I switched to instantiating registry entries in registry events; because the SoundEvent passed to the constructor doesn't yet exist when RegistryEvent.Register<Item> is fired. It's possible to override ItemRecord#getSound to return the SoundEvent directly (ignoring the ItemRecord#sound field), but this requires adding the record to the ItemRecord.RECORDS map manually so that Minecraft will display the record name above the hotbar when it's played. Is there a better way to do this?

You may want to look at Forge's FancyMissingModel, which uses SimpleModelFontRenderer to render the location of the missing model.

They edited the OP with a link to their GitHub repository.

You'll need to explain exactly what you mean by "couldn't get access to the jar file". What are you doing and what exactly what error are you getting?

I think I know what's going on now. The missing recipe IDs warning isn't from Forge loading the IDs saved with the world, it's from Forge loading the server's IDs into the client's registries. This means that the server has several recipes that the client doesn't know about, which is probably due to the client and server having different versions of Thermal Foundation installed.

It looks like Forge is complaining because there are recipe IDs saved in your world that no longer exist in Thermal Foundation. The strange thing is, the recipe registry is explicitly configured to not be saved to the disk; so there shouldn't be any saved recipe IDs in the first place (and there aren't in any of my worlds). Are you using any mods apart from Thermal Foundation/OTG? Could you please post your world's level.dat file?

Looking at the event and the code around it more closely, I'm not sure you can remove the mapping. I haven't confirmed this, but it looks like the old name and ID remain in the registry even if you choose remap the missing entry. Remapping adds an alias from the old name to the new one that the modder-facing IForgeRegistry methods appear to respect; but the internal ForgeRegistry#getID methods don't appear to. You may want to confirm this yourself.

I've actually just implemented a DataFixer for this myself, see this commit of TestMod3. It uses a list of flattening definitions that specify the old registry name and metadata to look for, a function to get the replacement state and a function to modify or remove the saved TileEntity. It then iterates through each block in the chunk NBT looking for ones that match a flattening definition before running the state/TileEntity functions and updating the block. I also have a separate class (Remapper) that handles the MissingMappings event and tells FML to leave the missing IDs in the save, allowing them to be accessed in the DataFixer. There might be better ways to do this, but I'm fairly confident that it works.

EntityPlayerMP is used for all players on the server side. EntityPlayerSP is used for the controlling player on the client side. EntityOtherPlayerMP is used for all other players on the client side.

This field has been named hasCrashed in the latest MCP mappings, so you should update your mappings to stable_39 (the final mappings version for 1.12). The MCPBot website you linked earlier explains what you need to change in your build.gradle to do this (click on the stable_39 dropdown button and then click "Use in ForgeGradle"). There's no wiki that explains what each field/method does, the closest thing would be the Javadocs of Vanilla fields/methods provided by MCP. These are included in the source code attached to the forgeSrc dependency when you run setupDecompWorkspace. Like field/method names, Javadocs are contributed by the community using MCPBot; so they may not always be 100% accurate or up-to-date.

The server maintains a network connection for each connected client along with a reference to the server-side player entity. When a packet is received on this connection, the server knows which player sent it and you can access the player through the NetworkContext.

Yes, that should work.

The entity ID should work for players, but it's not actually needed here. The player who sent the packet is available on the server side through the MessageContext, see this example in the documentation for more details.