Can it work in post init since My mods do alot of stuff there and will have to do stuff in post init.
It's strongly recommended to use the registry events, but it should still be possible to register things in postInit since the registries are frozen after that. This may or may not be true in future versions.
Can you not move the things currently done in postInit to be done earlier?
Can you describe this in further details? I am trying to just physically make my own armor items and make vanilla's unaccessible would I still need to do this? Describe where this is called at if I still need to do this. 1.7.10 had it rendering based on the item armor class getcolor stack and get color
All armour rendering (even armour with custom models) is handled by LayerArmorBase and its subclasses.
You need to create a class that extends LayerArmorBase and delegates to another LayerArmorBase instance.
Override LayerArmorBase#doRenderLayer to call a copy of LayerArmorBase#renderArmorLayer for each slot. In your copy of LayerArmorBase#renderArmorLayer, use a custom colour for the second layer (the block with the // Non-colored comment in the vanilla code) instead of the default colour when the item being rendered is one of your armour items.
Override all other public/protected methods to call the corresponding methods on the other LayerArmorBase instance.
In init, find the RenderLivingBase instances you want to replace the LayerArmorBase instances of, iterate through RenderLivingBase#layerRenderers until you find the LayerArmorBase instance, create a new instance of your class using it and then replace the original instance with the new one.
You can either perform this replacement for individual vanilla RenderLivingBase instances and leave mods to opt-in to the replacement manually or perform the replacement for every RenderLivingBase in RenderManager#entityRenderMap and RenderManager#skinMap (which you'll need to access via reflection as the getter method returns a read-only view).
The former preserves any custom armour rendering for other mods' entities but may render your armour without the extra colour, the latter guarantees that your armour will be rendered with the extra colour but may break any custom armour rendering.
It sounds like you want a Map<String, Double> field, which will be converted to a category with a property for each key. If you want the order to be maintained, you should be able to use a LinkedHashMap.
How do I know what layer the render index is on a different color for it rendering based on the index. I want pads to be a different color as well.
Only a single layer of the armour model is coloured by ItemArmor#getColor, the other layer uses the default colour (defined in LayerArmorBase).
If you want to change the default colour for your armour, you'd need to replace the LayerBipedArmor instances for the vanilla Render instances with your own implementation. You'd also need to replace the vanilla overlay textures with greyscale ones for the colouring to work properly.
What is going on with 1.12 it won't let me register anything and it wants me to fire an event. I want to be able to register things in init/post init as my mod is a core utility mod that will be able to remove items/blocks with override ones.
Are you talking about registry events? You don't fire them, you subscribe to them.
You can control the order your handlers are called in using the @SubscribeEvent#priority property.
Completely override it since mc 1.2.5 and newer versions use separate colors. As well as make them configurable
So you want it to always be a single colour, determined by a config file?
You'll need to create your own class that extends ItemArmor and overrides ItemArmor#getColor to return this colour, overrides ItemArmor#hasColor to return false, and overrides ItemArmor#setColor/removeColor to do nothing.
To override the vanilla leather amour in 1.10.2 you can try using substitution aliases, but I'm not sure if they ever worked properly. You can also just register your items normally and replace the recipes for the vanilla armour with recipes for your own armour.
Caused by: java.lang.NullPointerException
at net.minecraftforge.items.SlotItemHandler.getStack(SlotItemHandler.java:79) ~[SlotItemHandler.class:?]
at net.minecraft.inventory.Container.getInventory(Container.java:75) ~[Container.class:?]
at net.minecraft.inventory.Container.addListener(Container.java:61) ~[Container.class:?]
at net.minecraftforge.fml.common.network.internal.FMLNetworkHandler.openGui(FMLNetworkHandler.java:100) ~[FMLNetworkHandler.class:?]
at net.minecraft.entity.player.EntityPlayer.openGui(EntityPlayer.java:2776) ~[EntityPlayer.class:?]
at sommanker.biochemicalengineering.block.EnergyProducer.onBlockActivated(EnergyProducer.java:132) ~[EnergyProducer.class:?]
SlotItemHandler#getStack can only throw a NullPointerException when SlotItemHandler#getItemHandler returns null (i.e. the SlotItemHandler was created with a nullIItemHandler). You create the SlotEnergyProducerFuel using the ContainerGenerator#handler field, but this is null because you never assign it a value.
For Blocks, you should be able to register an IStateMapper that returns an empty Map from IStateMapper#putStateModelLocations using ModelLoader.setCustomStateMapper. This should tell Forge not to load any models for the Block.
For Items, you should be able to register a variant with ModelBakery.registerItemVariants that points to an existing model. This will tell Forge to load this model instead of loading the default model (the one corresponding to the Item's registry name).
Both of these should be done in ModelRegistryEvent.
Okay, so I have made and saved two structures, how do I read the NBT and convert it to using code since there are a few functions that need to be in it?
You don't convert the NBT to code, you load the structure from NBT in your world generator.
You can use Structure Blocks in Data Mode to run custom logic for specific positions (e.g. generate a chest with a specific loot table or spawn a mob). Either override StructureComponentTemplate#handleDataMarker or use Template#getDataBlocks to implement this custom logic.
For a short-lived entity like a projectile, you can get away with storing the shooting Entity in a field directly and not writing it to NBT. If you implement IThrowableEntity, FML will automatically sync the shooting Entity to the client when the projectile spawns.
If you need the shooting Entity to persist, write its UUID to NBT. If the projectile isn't short-lived, store the shooter's UUID in a field instead of the Entity.
If you need to access the shooting Entity on the client, synchronise it using its ID.
Each JSON file can only contain a single recipe. You can have any number of recipes that produce the same item, they just need to have different names.
You have a World instance as an argument, which implements IBlockAccess. It looks like you're already passing this as the IBlockAccess argument when calling Block#isAir and Block#isLeaves.
What's the issue here?
So they are saying to publicly release it extract the jar of the coremod and compile them separately that's a pain.
Compile the coremod and the regular mod into separate JARs and optionally package the coremod JAR inside the mod JAR, yes.
How are my posts hard to understand?
Sometimes it's your grammar and spelling, sometimes it's vagueness and lack of detail.
When talking about something (especially code-related), try to use its exact name. In your thread on the Forge forums you asked about an "index", but nobody knew what that meant since there's nothing called an "index" in the registry system.
Earlier in this thread you asked "how to get IBlockAccess from an object", but I had no idea what "object" you meant, why you needed an IBlockAccess or where you needed it.
Also he kept saying it wasn't a license agreement so what does that mean it's just a suggestion? I mean if it's not an agreement are they making it only forge forums specific?
diesieben07 said that it wasn't an EULA, which is a specific type of contract/legal document. To my understanding, the coremod policy is a set of recommended best practices rather than a legally-binding agreement. Failure to comply with the policy won't get you in legal trouble, but some sites like Curse may eventually reject mods that don't comply with it.
0
It's strongly recommended to use the registry events, but it should still be possible to register things in postInit since the registries are frozen after that. This may or may not be true in future versions.
Can you not move the things currently done in postInit to be done earlier?
All armour rendering (even armour with custom models) is handled by LayerArmorBase and its subclasses.
You need to create a class that extends LayerArmorBase and delegates to another LayerArmorBase instance.
Override LayerArmorBase#doRenderLayer to call a copy of LayerArmorBase#renderArmorLayer for each slot. In your copy of LayerArmorBase#renderArmorLayer, use a custom colour for the second layer (the block with the // Non-colored comment in the vanilla code) instead of the default colour when the item being rendered is one of your armour items.
Override all other public/protected methods to call the corresponding methods on the other LayerArmorBase instance.
In init, find the RenderLivingBase instances you want to replace the LayerArmorBase instances of, iterate through RenderLivingBase#layerRenderers until you find the LayerArmorBase instance, create a new instance of your class using it and then replace the original instance with the new one.
You can either perform this replacement for individual vanilla RenderLivingBase instances and leave mods to opt-in to the replacement manually or perform the replacement for every RenderLivingBase in RenderManager#entityRenderMap and RenderManager#skinMap (which you'll need to access via reflection as the getter method returns a read-only view).
The former preserves any custom armour rendering for other mods' entities but may render your armour without the extra colour, the latter guarantees that your armour will be rendered with the extra colour but may break any custom armour rendering.
0
It sounds like you want a Map<String, Double> field, which will be converted to a category with a property for each key. If you want the order to be maintained, you should be able to use a LinkedHashMap.
0
Only a single layer of the armour model is coloured by ItemArmor#getColor, the other layer uses the default colour (defined in LayerArmorBase).
If you want to change the default colour for your armour, you'd need to replace the LayerBipedArmor instances for the vanilla Render instances with your own implementation. You'd also need to replace the vanilla overlay textures with greyscale ones for the colouring to work properly.
Are you talking about registry events? You don't fire them, you subscribe to them.
You can control the order your handlers are called in using the @SubscribeEvent#priority property.
See my mod's init classes for examples of how to use registry events.
0
So you want it to always be a single colour, determined by a config file?
You'll need to create your own class that extends ItemArmor and overrides ItemArmor#getColor to return this colour, overrides ItemArmor#hasColor to return false, and overrides ItemArmor#setColor/removeColor to do nothing.
To override the vanilla leather amour in 1.10.2 you can try using substitution aliases, but I'm not sure if they ever worked properly. You can also just register your items normally and replace the recipes for the vanilla armour with recipes for your own armour.
0
SlotItemHandler#getStack can only throw a NullPointerException when SlotItemHandler#getItemHandler returns null (i.e. the SlotItemHandler was created with a null IItemHandler). You create the SlotEnergyProducerFuel using the ContainerGenerator#handler field, but this is null because you never assign it a value.
0
For Blocks, you should be able to register an IStateMapper that returns an empty Map from IStateMapper#putStateModelLocations using ModelLoader.setCustomStateMapper. This should tell Forge not to load any models for the Block.
For Items, you should be able to register a variant with ModelBakery.registerItemVariants that points to an existing model. This will tell Forge to load this model instead of loading the default model (the one corresponding to the Item's registry name).
Both of these should be done in ModelRegistryEvent.
0
Armour models don't use IItemColor, they use ItemArmor#getColor. You can use ItemArmor#setColor to set the colour of a Leather Armour ItemStack.
What exactly are you trying to do?
1
You can probably achieve that with a custom ITemplateProcessor.
0
You don't convert the NBT to code, you load the structure from NBT in your world generator.
You can use Structure Blocks in Data Mode to run custom logic for specific positions (e.g. generate a chest with a specific loot table or spawn a mob). Either override StructureComponentTemplate#handleDataMarker or use Template#getDataBlocks to implement this custom logic.
0
For a short-lived entity like a projectile, you can get away with storing the shooting Entity in a field directly and not writing it to NBT. If you implement IThrowableEntity, FML will automatically sync the shooting Entity to the client when the projectile spawns.
If you need the shooting Entity to persist, write its UUID to NBT. If the projectile isn't short-lived, store the shooter's UUID in a field instead of the Entity.
If you need to access the shooting Entity on the client, synchronise it using its ID.
1
The registry system and registry events are documented here. Events in general are documented here.
The main change in 1.12 is that registry events are fired after preInit instead of before preInit.
You can see how I register my mod's Blocks and ItemBlocks here. You can see how I register my mod's models here.
0
Use World#getSeed to get the seed, then use this as the seed of a Random instance.
0
You can use Structure Blocks to save a structure to NBT and then generate it later.
For examples, look at ComponentScatteredFeaturePieces.Igloo, WorldGenFossils, StructureEndCityPieces and WoodlandMansionPieces.
2
Each JSON file can only contain a single recipe. You can have any number of recipes that produce the same item, they just need to have different names.
0
You have a World instance as an argument, which implements IBlockAccess. It looks like you're already passing this as the IBlockAccess argument when calling Block#isAir and Block#isLeaves.
What's the issue here?
Compile the coremod and the regular mod into separate JARs and optionally package the coremod JAR inside the mod JAR, yes.
Sometimes it's your grammar and spelling, sometimes it's vagueness and lack of detail.
When talking about something (especially code-related), try to use its exact name. In your thread on the Forge forums you asked about an "index", but nobody knew what that meant since there's nothing called an "index" in the registry system.
Earlier in this thread you asked "how to get IBlockAccess from an object", but I had no idea what "object" you meant, why you needed an IBlockAccess or where you needed it.
diesieben07 said that it wasn't an EULA, which is a specific type of contract/legal document. To my understanding, the coremod policy is a set of recommended best practices rather than a legally-binding agreement. Failure to comply with the policy won't get you in legal trouble, but some sites like Curse may eventually reject mods that don't comply with it.