You'll need to specify your own IGuiFactory class using the @Mod#guiFactory property. DefaultGuiFactory uses the GuiConfig(GuiScreen, String, String) constructor, which uses GuiConfig#collectConfigElements to create and sort the config elements, you'll need to create a similar method and use a GuiConfig constructor with a List<IConfigElement> parameter.
EntityThrowable#onImpact is called when the entity hits either a block or another entity. When it hits an entity, RayTraceResult#getBlockPos will return null.
EntityPotion#applySplash (called by EntityPotion#onImpact) uses the entity's bounding box as the basis for the effect area.
They say no apis and libs if not all is necessary to run the coremod. No it's not all but, I need the apis and util/lib for the rest of my mods and some of them will be using asm helpers if possible like block properties and bnb gaming lib did. I also think it's unnecessary to split up the main common mod as it's function as the mod is suppose to be helping out just no asm like bonemeal events.... He was also completely ignoring anything I had to say maybe you could reason with them?
So I don't think I could ever be 1.12+
diesieben07 and LexManos (to an extent) tried to explain how you can change your mod to comply with the policy. Your posts are often quite hard to understand and Lex doesn't have a lot of patience.
Your coremod can depend on any libraries it requires to function, but the actual coremod JAR should only contain the loading plugin and class transformers. The coremod JAR can be packaged inside the mod JAR (to be automatically extracted by Forge), and the mod can depend on the coremod.
If you have questions about this, you can try asking them on the Forge forums; but try to write your posts clearly and avoid complaining about things being impossible.
If you're overriding them, you have an IBlockAccess argument.
If you're calling them, where are you calling them from?
I already had this in my constructor and it wasn't even mildly green even when I set the swamp foliage config to it's default noise generator foliage. There is another value hard coded somehwere else like either in the water class or minecraft just like pine and birch leaves?
0xe0ffae is the only water colour used by swamps. This is used as a multiplier of water's default blue colour, it's not displayed directly.
So when vanilla's method called chunk primer it's still going to = "block array byte[]" ? Since It's an overridden method. I am confused as to what you are trying to say and how to convert it?
To set the Block and metadata at a specific position in 1.7.10, you'd calculate an array index based on the coordinates (the i2 local variable in the BiomeGenBase#genBiomeTerrain method) and then set that index of the Block and byte arrays to the desired Block and metadata.
To set the IBlockState (which is essentially a wrapper around a Block and metadata) at a specific position in 1.8+, you'd simply call ChunkPrimer#setBlockState with the coordinates and the IBlockState. You don't need to calculate any indexes or deal with any arrays, the ChunkPrimer handles all of that for you.
Compare 1.10.2's Biome#generateBiomeTerrain method to 1.7.10's BiomeGenBase#genBiomeTerrain method to see the difference between using the arrays and using the ChunkPrimer. The method also has a nice doc comment in 1.8.9+ explaining what it does.
Forge's documentation has an introduction to block states here, which you may find helpful.
BlockColors#blockColorMap is a non-static field (though I previously mistook it for a static field), so you need to pass the BlockColors instance to the Field#get method.
I need to know how to convert generate terrain method since it uses chunk primers,
I also need to know how to get IBlockAccess from an object since I need to know if the block is air.
If you don't have an explicit IBlockAccess argument, you'll usually have a World argument/field. World implements IBlockAccess.
Where do you need this?
I also need to know where the swamp hard coded water color is because the 1.7.10 multiplier value once I overrode it with the same value was no longer the same color
Biome#getWaterColor uses the Biome#waterColor field, which is set in the constructor from the Biome.BiomeProperties argument. Looking at the Biome.registerBiomes method, Biomes.SWAMPLAND uses 14745518 (0xe0ffae) for the water colour.
public final RegistryDelegate<T> delegate = PersistentRegistryManager.makeDelegate((T)this, (Class<T>)token.getRawType());
if this is how I get the key then do I need another key to get this key?
Block extends IForgeRegistryEntry.Impl, so the IForgeRegistryEntry.Impl#delegate field can be accessed directly on any Block value (like BlockColors does).
You need to get the Map<RegistryDelegate<Block>, IBlockColor> from the BlockColors.blockColorMap field via reflection, then look up the Block's RegistryDelegate in the Map to get its IBlockColor.
Maybe I'm just stupid but I can't understand these files or how they are loaded, I looked at the forge bucket but I couldn't see where the code was saying to use this new custom model, or find the code that actually changes the texture based on the contained liquid.
I have an explanation of the model loading process (including custom model loaders) here.
ModelDynBucket.BakedDynBucketOverrideHandler is responsible for generating and returning a new model based on the ItemStack's contained Fluid.
This is an ItemOverrideList, Minecraft calls ItemOverrideList#handleItemState whenever it's rendering an item model to allow another model to be rendered instead.
Your code is infinitely recursing (the method is calling itself), so it crashes with a stack overflow.
There's no public method to get an existing IBlockColor instance, so you'll need to use reflection to access BlockColors.blockColorMap and get the IBlockColor from there. The IForgeRegistryEntry.Impl#delegate field contains the RegistryDelegate of a registry entry (e.g. a Block), which is used as a key in this Map.
You should store the existing IBlockColor instance in a field of your GrasColor/FoliageColor classes.
and also would have to do 0-5 tint indexes as well since it's faces?
Multiple faces can (and do) have the same tint indexes. None of Vanilla's block models use multiple tint indexes, only its item models do.
I can't call super this?
There's no super method to call, you're implementing IBlockColor directly rather than extending a Vanilla implementation (which isn't possible to do because they're anonymous classes).
In 1.7.10, each index of the Block and byte arrays is used to store the Block and metadata at a specific position.
In 1.8+, these arrays have been replaced by a ChunkPrimer, which stores the IBlockState at each position instead. Use ChunkPrimer#setBlockState to set the IBlockState at a position.
Seems to work in 1.10.2 for IBlockColor thing. Would this be compatible if other mods registered the same block maybe I should be using an event?
The IBlockColor will only be used for the Blocks you register it for. If another mod registers an IBlockColor for the same Block after you register yours, it will overwrite yours.
I recommend storing the vanilla IBlockColor before overwriting and delegating to it (i.e. calling IBlockColor#colorMultiplier and returning the result) when the Biome isn't an instance of BiomeSwamp (or the World/BlockPos are null). This will allow you to use the vanilla colours for the inventory or other biomes and preserve the changes made by any other mod's IBlockColor.
For fun I decided to try blocks.STONE and it only effected the particle effects. I can see why you say this is bugged. The particle effects were green but, the block wasn't.
The IBlockColor is only used to colour a model when the tint index of a face is specified. Vanilla only specified this for models that it dynamically colours, e.g. leaves and grass.
It's also used by the digging particles, regardless of whether or not a tint index is specified.
I just need to know what color it's suppose to be in the inventory?
When the World/BlockPos are null (e.g. in the inventory), Vanilla uses ColorizerGrass.getGrassColor(0.5, 1.0) for grass and ColorizerFoliage.getFoliageColorBasic() for leaves
So yeah do you have a way to get it working for the inventory?
Do you have a way to get it working the resource packs or does the code above already do that?
The IItemColor for grass/leaves uses the Block's IBlockColor, so it should use your replacement IBlockColor for the item model automatically.
The IBlockColor/IItemColor are independent of the resource pack, though a resource pack could replace the grass/leaves models with ones that don't specify a tint index.
Each face of each model element can set a tint index that allows the IBlockColor/IItemColor to know which element is being coloured. This allows models to have multiple dynamic colours.
How do I find out what biome color was returning for beta 1.8.1 swamp grass and foliage color?
You'd have to see if it's been documented anywhere (e.g. on the wiki) or decompile that version and find the numbers yourself.
Does this work in the same way vanilla does overlaying the green per biome?
The vanilla grass/foliage colours are handled by the IBlockColor/IItemColor implementations, yes.
I've just realised that the IBlockColor instances for grass and leaves use the Biome#getGrassColorAtPos and Biome#getFoliageColorAtPos methods (through BiomeColorHelper), which fire the BiomeEvent.GetGrassColor and BiomeEvent.GetFoliageColor events. These events can be used to change the grass/foliage colours at specific positions without replacing the IBlockColor instances.
Unfortunately BiomeSwamp overrides these methods and doesn't fire the events, so they can't actually be used for swamps. I'll open a Forge issue for this, but it's very unlikely that any fix for it gets backported to 1.10.2.
BlockColors.init creates and returns a new instance of BlockColors. The instance you create by calling it is never used by Minecraft, so your IBlockColor is never used either.
You need to get the existing BlockColors instance that Minecraft knows about with the Minecraft#getBlockColors method and register your IBlockColor with it. The same applies to ItemColors: Minecraft already has an instance that you can get with the Minecraft#getItemColors method.
IBlockColor/IItemColor use the colour format 0xRRGGBB, where RR is the red component, GG is the green component and BB is the blue component.
"colorMultiplier" is the only method there I can only change multipliers not the actual color?
It's a multiplier of whatever the texture's colour is. Since the vanilla leaf and grass textures are greyscale, the multiplier is essentially the same as the resulting colour.
Call BlockColors#registerBlockColorHandler in init from your client proxy, just like you would if you were registering an IBlockColor for your own Block.
This part of the model system hasn't really changed since it was introduced in 1.9, so it should work in 1.10.2 (though I haven't tested it in any version).
0
You'll need to specify your own IGuiFactory class using the @Mod#guiFactory property. DefaultGuiFactory uses the GuiConfig(GuiScreen, String, String) constructor, which uses GuiConfig#collectConfigElements to create and sort the config elements, you'll need to create a similar method and use a GuiConfig constructor with a List<IConfigElement> parameter.
1
EntityThrowable#onImpact is called when the entity hits either a block or another entity. When it hits an entity, RayTraceResult#getBlockPos will return null.
EntityPotion#applySplash (called by EntityPotion#onImpact) uses the entity's bounding box as the basis for the effect area.
0
Where are you calling them from?
diesieben07 and LexManos (to an extent) tried to explain how you can change your mod to comply with the policy. Your posts are often quite hard to understand and Lex doesn't have a lot of patience.
Your coremod can depend on any libraries it requires to function, but the actual coremod JAR should only contain the loading plugin and class transformers. The coremod JAR can be packaged inside the mod JAR (to be automatically extracted by Forge), and the mod can depend on the coremod.
If you have questions about this, you can try asking them on the Forge forums; but try to write your posts clearly and avoid complaining about things being impossible.
0
Are you overriding or calling these?
If you're overriding them, you have an IBlockAccess argument.
If you're calling them, where are you calling them from?
0xe0ffae is the only water colour used by swamps. This is used as a multiplier of water's default blue colour, it's not displayed directly.
0
To set the Block and metadata at a specific position in 1.7.10, you'd calculate an array index based on the coordinates (the i2 local variable in the BiomeGenBase#genBiomeTerrain method) and then set that index of the Block and byte arrays to the desired Block and metadata.
To set the IBlockState (which is essentially a wrapper around a Block and metadata) at a specific position in 1.8+, you'd simply call ChunkPrimer#setBlockState with the coordinates and the IBlockState. You don't need to calculate any indexes or deal with any arrays, the ChunkPrimer handles all of that for you.
Compare 1.10.2's Biome#generateBiomeTerrain method to 1.7.10's BiomeGenBase#genBiomeTerrain method to see the difference between using the arrays and using the ChunkPrimer. The method also has a nice doc comment in 1.8.9+ explaining what it does.
Forge's documentation has an introduction to block states here, which you may find helpful.
0
BlockColors#blockColorMap is a non-static field (though I previously mistook it for a static field), so you need to pass the BlockColors instance to the Field#get method.
I explained this to someone else here.
If you don't have an explicit IBlockAccess argument, you'll usually have a World argument/field. World implements IBlockAccess.
Where do you need this?
Biome#getWaterColor uses the Biome#waterColor field, which is set in the constructor from the Biome.BiomeProperties argument. Looking at the Biome.registerBiomes method, Biomes.SWAMPLAND uses 14745518 (0xe0ffae) for the water colour.
0
Block extends IForgeRegistryEntry.Impl, so the IForgeRegistryEntry.Impl#delegate field can be accessed directly on any Block value (like BlockColors does).
You need to get the Map<RegistryDelegate<Block>, IBlockColor> from the BlockColors.blockColorMap field via reflection, then look up the Block's RegistryDelegate in the Map to get its IBlockColor.
0
I have an explanation of the model loading process (including custom model loaders) here.
ModelDynBucket.BakedDynBucketOverrideHandler is responsible for generating and returning a new model based on the ItemStack's contained Fluid.
This is an ItemOverrideList, Minecraft calls ItemOverrideList#handleItemState whenever it's rendering an item model to allow another model to be rendered instead.
0
Your code is infinitely recursing (the method is calling itself), so it crashes with a stack overflow.
There's no public method to get an existing IBlockColor instance, so you'll need to use reflection to access BlockColors.blockColorMap and get the IBlockColor from there. The IForgeRegistryEntry.Impl#delegate field contains the RegistryDelegate of a registry entry (e.g. a Block), which is used as a key in this Map.
You should store the existing IBlockColor instance in a field of your GrasColor/FoliageColor classes.
Multiple faces can (and do) have the same tint indexes. None of Vanilla's block models use multiple tint indexes, only its item models do.
There's no super method to call, you're implementing IBlockColor directly rather than extending a Vanilla implementation (which isn't possible to do because they're anonymous classes).
0
In 1.7.10, each index of the Block and byte arrays is used to store the Block and metadata at a specific position.
In 1.8+, these arrays have been replaced by a ChunkPrimer, which stores the IBlockState at each position instead. Use ChunkPrimer#setBlockState to set the IBlockState at a position.
0
The IBlockColor will only be used for the Blocks you register it for. If another mod registers an IBlockColor for the same Block after you register yours, it will overwrite yours.
I recommend storing the vanilla IBlockColor before overwriting and delegating to it (i.e. calling IBlockColor#colorMultiplier and returning the result) when the Biome isn't an instance of BiomeSwamp (or the World/BlockPos are null). This will allow you to use the vanilla colours for the inventory or other biomes and preserve the changes made by any other mod's IBlockColor.
The IBlockColor is only used to colour a model when the tint index of a face is specified. Vanilla only specified this for models that it dynamically colours, e.g. leaves and grass.
It's also used by the digging particles, regardless of whether or not a tint index is specified.
When the World/BlockPos are null (e.g. in the inventory), Vanilla uses ColorizerGrass.getGrassColor(0.5, 1.0) for grass and ColorizerFoliage.getFoliageColorBasic() for leaves
The IItemColor for grass/leaves uses the Block's IBlockColor, so it should use your replacement IBlockColor for the item model automatically.
The IBlockColor/IItemColor are independent of the resource pack, though a resource pack could replace the grass/leaves models with ones that don't specify a tint index.
0
Each face of each model element can set a tint index that allows the IBlockColor/IItemColor to know which element is being coloured. This allows models to have multiple dynamic colours.
You'd have to see if it's been documented anywhere (e.g. on the wiki) or decompile that version and find the numbers yourself.
The vanilla grass/foliage colours are handled by the IBlockColor/IItemColor implementations, yes.
I've just realised that the IBlockColor instances for grass and leaves use the Biome#getGrassColorAtPos and Biome#getFoliageColorAtPos methods (through BiomeColorHelper), which fire the BiomeEvent.GetGrassColor and BiomeEvent.GetFoliageColor events. These events can be used to change the grass/foliage colours at specific positions without replacing the IBlockColor instances.
Unfortunately BiomeSwamp overrides these methods and doesn't fire the events, so they can't actually be used for swamps. I'll open a Forge issue for this, but it's very unlikely that any fix for it gets backported to 1.10.2.
Edit: I've opened an issue here.
0
BlockColors.init creates and returns a new instance of BlockColors. The instance you create by calling it is never used by Minecraft, so your IBlockColor is never used either.
You need to get the existing BlockColors instance that Minecraft knows about with the Minecraft#getBlockColors method and register your IBlockColor with it. The same applies to ItemColors: Minecraft already has an instance that you can get with the Minecraft#getItemColors method.
IBlockColor/IItemColor use the colour format 0xRRGGBB, where RR is the red component, GG is the green component and BB is the blue component.
0
It's a multiplier of whatever the texture's colour is. Since the vanilla leaf and grass textures are greyscale, the multiplier is essentially the same as the resulting colour.
0
Call BlockColors#registerBlockColorHandler in init from your client proxy, just like you would if you were registering an IBlockColor for your own Block.
This part of the model system hasn't really changed since it was introduced in 1.9, so it should work in 1.10.2 (though I haven't tested it in any version).