What about if I just replaced the vanilla grass and leaves? How do I currently replace vanilla blocks and leaves since their registry storage seems weird. I could extend the classes and change the colors to be biome specific?
How would I do this otherwise without new blocks. What you were telling me was to do stuff after canceling an event but, the grass and foliage would still return the same color values.
You can override an existing registry entry (e.g. a Block) by registering a new one with the same registry name. The new value should generally use or extend the old value's class.
If all you want to change is the colour, you can register your own IBlockColors for the vanilla Blocks instead of overriding them.
By "Replacing Biome Foliage", I thought you meant "replacing the tree generation"; I didn't realise you were talking about colours.
So your saying to make a new block leaves and a new block grass for the swamp then do this?
If you want to use your own leaves and grass, yes.
Note that cancelling the event under the conditions I described in my previous post only prevents the features generated by WorldGenSwamp from generating, i.e. trees with vines.
I remember, but I thought that a container is optional for a tile entity. I haven't seen the tag/packet sync anywhere, though.
The Container is used to sync data only needed in a GUI, e.g. inventory contents or crafting progress. Not every TileEntity has a Container.
The update tag/packet (TileEntity#getUpdateTag/getUpdatePacket) are used to sync data needed to render the block, e.g. banner colour/pattern or flower pot contents.
Subscribe to DecorateBiomeEvent.Decorate (fired on MinecraftForge.TERRAIN_GEN_BUS, not MinecraftForge.EVENT_BUS) and check if the Biome at the event's BlockPos plus 16 x and z is Biomes.SWAMPLAND or Biomes.MUTATED_SWAMPLAND and the event's EventType is EventType.TREE. If these conditions are met, cancel the event and generate your own features.
so how would i pass the uuid to the tileentitys nbt from the onBlockPlacedBy method? Then how would i dis allow the wrong player from opening the tile entity?
NBT is for serialisation, not runtime storage. Create a method in your TileEntity class that takes an EntityPlayer and assigns their UUID to the field. Read this field from NBT in your override of TileEntity#readFromNBT and write it to NBT in your override of TileEntity#writeToNBT.
Create another method in your TileEntity class that takes an EntityPlayer and returns a boolean indicating whether or not the player can open the TileEntity's GUI (i.e. whether or not their UUID is equal to the stored UUID). Call this method and check the result wherever you open your GUI, only opening the GUI if it returns true.
I've actually been discussing something similar on the forge forums recently.
It depends on where you want your UUID. If you're planning on using it on the server only then you can create a field in your tile entity class. If you need it on client/server and client then you'll need to use DataManager.
EntityDataManager is for Entities, not TileEntities. TileEntity data synchronisation is handled through the update tag/packet or the Container, depending on what you need the data for.
In this case, the UUID probably isn't required on the client at all.
currently, i have a string called playerName that i pass into the tile entity's constructor that is changed to the playerName playerUUID in onBlockPlacedBy. Is that the correct way of doing it?
You can't pass any non-constant data to the constructor of a TileEntity, since that data isn't available when the TileEntity is instantiated.
You need to create a field in the TileEntity to store the UUID and set it from your override of Block#onBlockPlacedBy, yes.
You didn't really, if I try using a TickHandler, none of my code works, if I use onUpdate, none of my code works. You said add @Override, it throws an error...
The purpose of @Override is to create a compilation error when the method doesn't actually override a super method. The solution is to fix your method's signature so it does override a super method, not to remove the annotation.
You should use your IDE to auto-generate override methods with the correct signature. Just start typing a method name in the main body of a class and it should bring up a list of methods you can override.
Avoid metadata values where possible. As Bright_Spark said, the correct way to do this is by calling IBlockState#withProperty to get an IBlockState with each property set to the specified value.
Forge's documentation has an introduction to block states here.
Potion implements IForgeRegistryEntry, so you need to register your Potion instances in RegistryEvent.Register<Potion>. You never set the registry names of your Potion instances or register them.
The Items.field_191525_da field wasn't renamed to Items.IRON_NUGGET until 2017-06-13, in the 1.12 MCP mappings. This is because it was added in 1.11.1 and the 1.11.x mappings were only ever for 1.11 rather than 1.11.2.
Since you're using 1.11.x, you need to use the SRG name: Items.field_191525_da.
0
You can override an existing registry entry (e.g. a Block) by registering a new one with the same registry name. The new value should generally use or extend the old value's class.
If all you want to change is the colour, you can register your own IBlockColors for the vanilla Blocks instead of overriding them.
By "Replacing Biome Foliage", I thought you meant "replacing the tree generation"; I didn't realise you were talking about colours.
0
If you want to use your own leaves and grass, yes.
Note that cancelling the event under the conditions I described in my previous post only prevents the features generated by WorldGenSwamp from generating, i.e. trees with vines.
0
The Container is used to sync data only needed in a GUI, e.g. inventory contents or crafting progress. Not every TileEntity has a Container.
The update tag/packet (TileEntity#getUpdateTag/getUpdatePacket) are used to sync data needed to render the block, e.g. banner colour/pattern or flower pot contents.
0
Subscribe to DecorateBiomeEvent.Decorate (fired on MinecraftForge.TERRAIN_GEN_BUS, not MinecraftForge.EVENT_BUS) and check if the Biome at the event's BlockPos plus 16 x and z is Biomes.SWAMPLAND or Biomes.MUTATED_SWAMPLAND and the event's EventType is EventType.TREE. If these conditions are met, cancel the event and generate your own features.
0
NBT is for serialisation, not runtime storage. Create a method in your TileEntity class that takes an EntityPlayer and assigns their UUID to the field. Read this field from NBT in your override of TileEntity#readFromNBT and write it to NBT in your override of TileEntity#writeToNBT.
Create another method in your TileEntity class that takes an EntityPlayer and returns a boolean indicating whether or not the player can open the TileEntity's GUI (i.e. whether or not their UUID is equal to the stored UUID). Call this method and check the result wherever you open your GUI, only opening the GUI if it returns true.
EntityDataManager is for Entities, not TileEntities. TileEntity data synchronisation is handled through the update tag/packet or the Container, depending on what you need the data for.
In this case, the UUID probably isn't required on the client at all.
0
You can't pass any non-constant data to the constructor of a TileEntity, since that data isn't available when the TileEntity is instantiated.
You need to create a field in the TileEntity to store the UUID and set it from your override of Block#onBlockPlacedBy, yes.
0
ICrafting was renamed to IContainerListener in 1.9.4.
0
Where do you need this? What do you need it for? Is it your own TileEntity?
Player names can change, you usually want to store the player's UUID instead.
If it's your own Block/TileEntity, override Block#onBlockPlacedBy to store the placer's UUID in the TileEntity.
0
The purpose of @Override is to create a compilation error when the method doesn't actually override a super method. The solution is to fix your method's signature so it does override a super method, not to remove the annotation.
You should use your IDE to auto-generate override methods with the correct signature. Just start typing a method name in the main body of a class and it should bring up a list of methods you can override.
0
Avoid metadata values where possible. As Bright_Spark said, the correct way to do this is by calling IBlockState#withProperty to get an IBlockState with each property set to the specified value.
Forge's documentation has an introduction to block states here.
0
Potion implements IForgeRegistryEntry, so you need to register your Potion instances in RegistryEvent.Register<Potion>. You never set the registry names of your Potion instances or register them.
0
That looks correct, but you should use your own names for the LootEntry/LootPool instead of the Biome Compass names.
0
Where and when? You need to do it before you create the PotionTypes, which you aren't doing.
Create a Git repository of your code, push it to a site like GitHub and link it here.
0
The Items.field_191525_da field wasn't renamed to Items.IRON_NUGGET until 2017-06-13, in the 1.12 MCP mappings. This is because it was added in 1.11.1 and the 1.11.x mappings were only ever for 1.11 rather than 1.11.2.
Since you're using 1.11.x, you need to use the SRG name: Items.field_191525_da.
0
Of your Potion instances.
PotionEffect doesn't implement IForgeRegistryEntry, so PotionEffects don't have registry names.