Kaworru

In the newer version there is no "OreDictionary" and it's replaced by tags instead. You can use the tags in your recipes or in your code, to cover all kind of variants from minecraft or your own mod. See: https://mcforge.readthedocs.io/en/1.18.x/resources/server/tags/#migration-from-oredictionary The mods normally extends these, by using the tags you automatically add the needed compatibility with other mods.

Thanks for the feedback. But first of all it's sound simple what you want to do, but technically it's the most complicated things as mod, because you need to adjust mostly everything related to display the player and it includes a lot of sub parts. My suggestion would be that you forget your current code and just start with a basic task like: "Hide the head of the player". Just create something which disables the default player renderer (over mixin, render event, ...) and use something like "head.visibile = false" to render the player without a head. Try this in single player mode, third party view and in multiplayer mod with another player. If this works you can try the same for the other body parts and later replace the default renderer with your own.

If you already able to perform the above steps without any problems then the next steps would be: Storing the selected race as server data and sync them with all connected players (in range or in general), there are several ways to do this but you will very likely need define your our network packages. Define your own Entity Renderer with a Render Manager which handles the different kind of models and assigned textures like: https://github.com/iChun/Morph/blob/1.16/src/main/java/me/ichun/mods/morph/client/render/RenderEntityAcquisition.java Enable / Disable the correct Renderer for the selected model based on the synced server data and disable the default one. This needs mostly to be done over a mixin like: https://github.com/iChun/Morph/blob/1.16/src/main/java/me/ichun/mods/morph/mixin/ModelRendererMixin.java and https://github.com/iChun/Morph/blob/1.16/src/main/java/me/ichun/mods/morph/mixin/PlayerRendererMixin.java In general the Morph mod is a good example and includes everything which is needed in your case. Keep in mind that the PlayerRenderer is only an instance of the LivingEntityRenderer, so everything which works with mobs models extending LivingEntityRenderer will also work with the player models to some extend. That's the reason why I recommend to try this first with pseudo mobs, because it's easier to test / learn and includes basically the same steps.

Thanks for the feedback. I fully agree that in an ideal world this should cause no issues. The reality is that most mod authors don't care and just add a comment that their mod is "client-side" only. I have an mod pack which has about 240 mods and about 35 of these causing issues on servers, I need to manually sort out these mods every time they get updated. I tried to contacted some of the mod authors, but in most cases they just pointed out it's a client side mod and don't want to fix it. 😔

That's not really a solution, it's still manual work to search for related mods and "not putting them on the server". A similar "solution" would be to not use any mod packs or mods at all. 🙃

It's sounds like a nice project, but also like a lot of work. If you want to replace the player model you need to replace all animation, textures and poses as well to make sure that they are matching for 1st and 3rd view. Maybe instead of replacing the player model, you can use additional render layer instead, like you already mentioned with the ears ? My recommendation would be to try to add your player models as simple mobs to the world, to get familiar with all of these steps. Basically the steps are similar for player models like: Defining the model / layer in java (e.g. https://github.com/MarkusBordihn/BOs-Player-Companions/blob/1.18.1/src/main/java/de/markusbordihn/playercompanions/client/model/DobutsuModel.java) Define a client renderer (e.g. https://github.com/MarkusBordihn/BOs-Player-Companions/blob/1.18.1/src/main/java/de/markusbordihn/playercompanions/client/renderer/companions/DobutsuRenderer.java) Register the client renderer for the model / layer (e.g. https://github.com/MarkusBordihn/BOs-Player-Companions/blob/1.18.1/src/main/java/de/markusbordihn/playercompanions/client/renderer/ClientRenderer.java) You can also give your pseudo mobs items and armors to see if they are rendered correctly.

Dear Forge Community, I wonder what is the best / compatible way to check the list of mods which are installed before they are actually get loaded? At the moment creating mod packs requires a lot of manually work, so I want to automate some of the tasks for myself. An basic example would be to automatically disable Opti-fine on dedicated servers before it crashes the server. Optifine is using the transformation service to get loaded before other mods, but not sure if this is the way. Thanks for any relevant feedback and/or references.

Hi, this is more a theoretical question, so I have no code to show. I'm working on a new project where I need to create some animated entities. It looks like in the vanilla code all of the entity models (e.g. ParrotModel) are directly implemented in the .java file to get access to their different parts like head, arms, legs and so on. I wonder if it is possible to load the entity block model or parts over a .json file instead and access the different parts over their defined name / groups instead? I have no issues to convert a .json model to the corresponding .java code, but want to make it easier for others to adjust the models without touching the code.

Unfortunately that's not the case. I tried to write a function for this, but the VoxelShape is based on 3D points (x, y, z). The problem is you need to define a 3D rotation point and need to move all other points related to this rotation point. In the end it was easier for me to draw (or rotate) a box in Blockbench and just write down the needed points. 😅

Thanks. Works like a charm. Example for the record: ItemProperties.register(ModItems.STEEL_LIGHTER.get(), new ResourceLocation(Constants.MOD_ID, "open"), (itemStack, clientLevel, livingEntity, id) -> { return (livingEntity == null || !itemStack.is(ModItems.STEEL_LIGHTER.get()) || livingEntity.getMainHandItem().isEmpty() || itemStack != livingEntity.getMainHandItem()) ? 0.0F : 1.0F; });

Hi, I created a simple steel lighter item, which has a item property "open" with "1.0" or "0.0" to display two different models, see: https://github.com/MarkusBordihn/BOs-Steel-Armor-Tools-Weapons/blob/main/src/main/resources/assets/steel_armor_tools_weapons/models/item/steel_lighter.json This works fine, but I want to change the state in the case the steel lighter is currently selected in the hotbar or not. I tried the LivingEquipmentChangeEvent which offers exactly the needed functionality, see: https://github.com/MarkusBordihn/BOs-Steel-Armor-Tools-Weapons/blob/main/src/main/java/de/markusbordihn/steelarmortoolsweapons/client/equipment/EquipmentChange.java But it seems that the ItemStack from this event is different from the ItemStack which is used for the ItemProperties.register(...), even both should be client side only. What I tried so far: Using itemStack.getOrCreateTag().putBoolean(...) and itemStack.getOrCreateTag().getBoolean(...) Using a hashmap with <itemStack, boolean> Using a local variable (current version) A debug of the hashmap with <itemStack, boolean> shows that the itemStack within the ItemProperties.register(...) is different from the itemStack in LivingEquipmentChangeEvent. So I wonder if there is a alternative event / approach I could use in this case or any other client only item state which I could share between these two events.

Yeah this is exactly the thing I want to avoid. I got so many false positive error reports with other mods which using mixin/core modifications. But no worries, I got a working version and learned more about the render events.

Thanks for the feedback. But it seems there is not really an easy way for this, most of the code is hard-coded and could not be accessed directly. 😞 I worked around this by using the "RenderHandEvent" and "RenderPlayerEvent" to create a dedicated render for my crossbow item.

Sorry, but this is not correct. If you search for "Items.CROSSBOW" in the vanilla source code you will see some references in the ItemInHandRenderer.java and PlayerRenderer.java for the animation for e.g. which hand should be visible at which state. The models works fine in the 3rd person view and the inventory slot, but not in the first person view which use the custom render mentioned above.

Hi, I'm not new to forge modding, but new to client render with 1.17 and working on a mod which adds steel tools and weapons. Currently I'm stuck with the crossbow item by using the default CrossbowItem with a different registration name and texture for a steel version, see: https://github.com/MarkusBordihn/BOs-Steel-Armor-Tools-Weapons/blob/main/src/main/java/de/markusbordihn/steelarmortoolsweapons/item/ModItems.java#L56 My currently problem is that it seems that the ItemInHandRender and PlayerRender has a hard reference to Items.CROSSBOW, which mean that the render is not working for my steel crossbow version. Normally I would somehow register a listener for the render event and replace it with a custom one as soon I detect my item in the hand. But have not really an idea how to do this correct with the version 1.17.1. I took a look at the original code but was not able to see how these render a register or how I could intercept the existing ones. Would be thankful for any pointers in the right direction (e.g. registration / listener methods) or maybe a basic example how this works in general. Thanks a lot.