vemerion

I don't think this is currently possible without using something like mixins. Might be worth it to add an event for it though.

If you want to change the hitbox size of the entity, you can change the arguments to the sized() method when creating the entity type. If you want to scale the model of the entity, you could use the scale() method on the matrix stack in the entity renderer (although I have never used GeckoLib so I don't know if that changes anything in regards to the rendering).

For those that might stumble upon this post with the same problem in the future: The solution in this case was to add this to the entity class: @Override public IPacket<?> getAddEntityPacket() { return NetworkHooks.getEntitySpawningPacket(this); } A rule of thumb: If you custom entity is not a LivingEntity, then you need to override getAddEntityPacket(). This is due to the fact that vanilla handles non-living entity spawn packets in a hard coded way.

I just tested and good news! You don't need to do anything special to have a semi-transparent item. Just make the texture transparent and you should be good to go!

The best tutorial is the vanilla source code! Advancements are data-driven, so you can add them via json files. To avoid having to manually create these json files, I would recommend using data generators! You can check out the AdvancementProvider class and for example the TheEndAdvancements class to see how to generate advancements json files. If you just want to know more about the advancement json format the Minecraft wiki has a good article on that.

I think the class was just renamed to ItemBlockRenderTypes when the switch to official mappings for class names was made.

The forge documentation about sounds explains which methods to use in different situations.

Yeah, either NBT or a capability should work.

You can't really have an instance field like extraArmor in item classes, since items are singleton and every stack will share the same item. This means that for example if one player uses the item and changes the extraArmor field, it will also change for all other players that also have that item.

No problem, I am glad I could be of assistance!

The problem is that you are adding a new layer every time RenderPlayerEvent is called. You should add the layer to the player renderer only once at startup.

The UUID is used to identify the attribute. This means that if two items have the same UUID for an attribute, the most recently equipped one will override the other if both are equipped at the same time. The Minecraft wiki has some info about it on the attribute page here. What I usually do is generate a random UUID once with UUID.randomUUID(), and then use that in UUID.fromString().

You are using the overload for ModelRenderer.render() that doesn't take rgb parameters and always renders the texture white. Change the call to body.render() in the renderToBuffer() method in your PoggModel class to actually use the supplied red, green, blue, alpha parameters.

Note that I am no expert on mappings, and I think generally it is best to use the same mappings as most other people use to make life easier for everybody. However, with that said, this should work: 1. Add this to your build.gradle to create a local maven repo on your computer: repositories { maven { url "file:///${project.projectDir}/mappings" } } 2. Change back the mappings channel (the mappings channel is hardcoded to use 'official', 'snapshot' and 'stable' so you have to use one of those): mappings channel: 'snapshot', version: 'vemerion-mappings' You can of course change 'vemerion-mappings' to something else but then you have to change it in the mappings repo as well in the next few steps 3. Create the file structure 'mappings/de/oceanlabs/mcp/mcp_snapshot/vemerion-mappings/' in your mod project folder 4. Inside the file structure you just created, create a zip file named 'mcp_snapshot-vemerion-mappings.zip', that should contain the fields.csv and methods.csv files etc 5. Run ./gradlew clean and ./gradlew cleanEclipse 6. Run ./gradlew genEclipseRuns and ./gradlew eclipse 7. If gradle complains about duplicate mappings then everything will probably fail and you have to update your mappings files and redo the process 8. Import the project into Eclipse 9. Your custom mappings should now work Hope this helps! As a last word of caution, I just want to reiterate that IMO it is probably best to stick with the normal MCP or Mojang mappings.

You can useFOVUpdateEvent.setNewfov() to set it to the old value to avoid the FOV change.