ChampionAsh5357

Something that cannot be mentioned on the forums as coremodding isn't supported here.

I would try increasing the size of the model to around 0.005 compared to a flat plane.

Since this mod is uses a library that is present within Forge, yes it is possible. Although, you should prioritize handling these items in events if possible.

I would say don't do that and just register multiple dimensions. Each 'world' is a dimension, so having multiple 'world' with the same dimension qualifier will make it problematic to handle when saving or loading data. However, you can have two JSONs holding the same information under different dimension names.

Whenever trying to use RenderSystem, a good reference is the RenderState class as it shows you the startup and teardown methods needed to handle what you need. In this case, I would suggest looking at RenderState#TRANSLUCENT_TRANSPARENCY. As a side note, whenever possible, IRenderTypeBuffer should be used to handle drawing objects to the screen, although in this case it is not that applicable.

On the Forge discord, the following appears as a trick: Official documentation: https://docs.oracle.com/javase/tutorial/ Absolute basics with an interactive editor: https://www.codecademy.com/learn/learn-java Ongoing online course with assignments: https://java-programming.mooc.fi/ As a side note, the language on the forums should be English and that you will not receive support until you have a proper grasp of Java. Good luck, and I hope you come to ask more questions once you have spent a good amount of time learning and practicing the language.

Patience, you can't expect everyone to get back so fast. As for the issue, it probably is that your singleton reference to the configuration is not actually linked to the spec for updating the variables. I would suggest looking at how forge sets up their configuration. However, these are all guesses as they are snippets of code and not the entire repository context.

Nope, you're just registering the item twice. Your block calls this method which creates an item to which you then create another item under the same name.

Well, I wouldn't know, the entire class where the error is occurring is not shown. If you could provide a link to your repo, it would provide more detail. Also, you shouldn't use a vanilla block within a BlockItem placeholder. That will cause all instances of that block to believe that your item is its item representation.

All things model related should be done through data generation. As such, there happens to be a test that adds in an obj model loader. You can even look at the commit history to see how to currently implement it.

Well, yes. Names must be unique on a per registry basis. That's where your error is coming from.

Pickaxe model isn't json, your item model is still an 'item' not an 'armor'.

Probably not, it was exposed using access transformers most likely. I would say that TelepathicGrunt has a good explanation on how to do this. This should be lax enough so you don't have to copy anything directly but provide enough information on what certain methods do and how to properly use them.

It doesn't want an Effects object nor does it matter what class its passed from. It just wants an Effect of some kind. MCP names classes their object type appended with an s if its holding those specific objects (e.g. All vanilla Block are found in Blocks, Item in Items, etc.). There is no error that can occur with your code. Although, this will error anyways during registration if you ever decide to supply your own effect. This is because an Item is registered before an Effect. This parameter/argument should properly be wrapped in a supplier to avoid this issue.

A BlockItem is essentially an Item with a block's name. As such, they would be stored under Items.

And when are you trying to access the value?

That grabs the name from the NetworkPlayerInfo which is separate. You would need to set it from the ClientPlayerEntity in a sided-safe manner.

Supply the property used to determine if the push is grown via BlockState#with and set it to the max age most likely.

This seems very much like cheating...

They're on the class in the source itself. All javadocs are located there. Then the cast inside the method is even more unnecessary as you're passing in a ZombieEntity and can make the parameter a ZombieEntity.

When and how are you trying to access the values?

Yes, you should not even need to reference this at all.

Target selectors are a separate instance of GoalSelector. Also, read the documentation on ObfuscationReflectionHelper as you cannot provide a mapped name for a field. What you have currently will fail in production, not on userdev. I will assume your cast is hopefully checked as well, although why you do not supply a ZombieEntity for the parameter instead is questionable on if it is checked.

You can break down a model to its ModelRenderer and supply the IVertexBuffer with the UV wanted. You would probably need your own implementation of it as the TexturedQuad within ModelBox is private and wouldn't give you enough control to do what you want most likely.

Do not force load the configuration file. The client and common config will be available after registry and before common setup while the server isn't present until the associated server loads for the first time (these are on a per-save instance).