Jump to content

Choonster

Moderators
  • Posts

    5117
  • Joined

  • Last visited

  • Days Won

    75

Everything posted by Choonster

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. It looks like the RightClickItem docs are incorrect, since the RightClickBlock docs explicitly mention that the client will try RightClickItem unless the result is SUCCESS: /** * This event is fired on both sides whenever the player right clicks while targeting a block. * This event controls which of {@link net.minecraft.block.Block#onBlockActivated} and/or {@link net.minecraft.item.Item#onItemUse} * will be called after {@link net.minecraft.item.Item#onItemUseFirst} is called. * Canceling the event will cause none of the above three to be called * * Let result be a return value of the above three methods, or {@link #cancellationResult} if the event is cancelled. * If we are on the client and result is not {@link EnumActionResult#SUCCESS}, the client will then try {@link RightClickItem}. * * There are various results to this event, see the getters below. * Note that handling things differently on the client vs server may cause desynchronizations! */ If you perform some action, you should set the event's cancellation result to EnumActionResult.SUCCESS and then cancel the event. This will stop the Vanilla methods from being called and the other event from being fired. That said, there's no need to use events to handle the right click behaviour of your own Item; just override the appropriate methods in the Item class instead.
  8. No. As I said, those ByteBufs aren't PacketBuffers; so that code will never send the unique IDs. When I say "create a new instance", I mean "use the new operator".
  9. The ByteBuf passed to those methods isn't an instance of PacketBuffer, you need to create a new instance of PacketBuffer and pass the ByteBuf to the constructor.
  10. Minecraft normally uses the entity ID (Entity#getEntityId) rather than the unique ID in networking situations (and this is its main purpose). This reduces unnecessary network traffic as the entity ID is a single 32-bit integer (that's actually compressed further) rather than a UUID that's sent as a pair of 64-bit integers. If you absolutely need to send a UUID, you can wrap the ByteBuf in a PacketBuffer and use PacketBuffer#readUniqueId/PacketBuffer#writeUniqueId to read/write UUIDs.
  11. There isn't one by default, you need to create it. This hasn't changed since 1.8.9.
  12. Are your RGB values actually being synced to the client? I suspect that they're always 0 on the client, so the block is being rendered black. There's no need for a TESR here at all. If you register a standard JSON model with a tint index (see the wiki), you can then register an IBlockColor that reads the RGB value from the TileEntity and returns it.
  13. HarvestDropsEvent can be called for any block in the game, 99% of which won't have the BlockOldLeaf.VARIANT property in their block state. As you've seen, calling IBlockState#getValue with an invalid property throws an exception. You need to check the Block itself first, use IBlockState#getBlock to get it and then check that it's equal to Blocks.LEAVES/Blocks.LEAVES2. IBlockState#getBlock returns a Block, which will never be equal to an IBlockState. You need to check the Block and the properties in two separate expressions within the if condition. Edit: It looks like @diesieben07 already explained most of this in your previous threads. Please stop creating new threads for the same topic.
  14. ItemBlock itself isn't suitable for blocks with variants, you need to use a subclass that overrides Item#getMetadata(int) to convert the item metadata to block metadata and calls Item#setHasSubtypes to mark the item as having variants/subtypes. ItemCloth does these and also overrides Item#getTranslationKey(ItemStack) to add the stack's colour as a suffix to the translation key (unlocalised name) so that each colour can have its own translation.
  15. This sounds like an issue with the ItemBlock and/or the model registration for the ItemBlock. Please post the code where you instantiate and register the ItemBlock and the code where you register the models for the ItemBlock(or create a repository so that we can see all of your code).
  16. To reduce the number of files you need to create, you can use Forge's blockstates format to specify a base model (e.g. minecraft:cube_all) and the textures for it without needing to create a model for each block.
  17. What exactly is your current issue? Please post your latest code (or a link to your repository). If it's a model issue, please post your blockstates/model files and your debug.log.
  18. If an item has subtypes like Stone and Dirt do, you need to specify the metadata using the data property when using it in a JSON recipe's ingredient. Look at some of the recipes that use Planks or Stone (e.g. minecraft:acacia_boat) to see examples of this.
  19. If you're following my example, the COLOR property is stored in the metadata and as such is already set when Block#getActualState is called. The FACING property is stored in the TileEntity and is the only property that needs to be set in your override of Block#getActualState.
  20. No. Each version of Forge only supports a single version of Minecraft and won't work on any other version.
  21. Unlisted properties aren't used to determine which model to render for a block, they're used by custom block models to determine how they should render. The correct solution here (while keeping a single block) would be to store the extra data in a TileEntity and use regular properties that have their values set in Block#getActualState. Though Mojang is moving away from having a single block for all colours with The Flattening in 1.13, so it may be best to split the colours into separate blocks now (as Cadiboo suggested). I have an example of a block with a colour and a facing here: Block, TileEntity, blockstates file
  22. There are still some Vanilla methods like Entity#getName that perform translation but aren't client-only. These use the deprecated net.minecraft.util.text.translation.I18n and I don't think there's any real alternative.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.