Abastro

Don't bump an over-half-year-old thread. Just make your own issue thread with what you've tried.

Oh, you meant zooming in/out from the player. IDK about this issue, setting the render view entity should work well.

A bit unrelated note, you don't need a coremod for zoom. There's FOVUpdateEvent for that.

As Draco said, you can use %s for that. (I didn't know whether '{}' works or not - I always use %s) In my experience, anything beyond %s doesn't work. And as far as I know it's hard to change lang file on the fly(during runtime). You'll need reflection hackery. Why do you need it?

Ah, I didn't read your code carefully. As Choonster said, you don't have to make every fields static. Just the field holding the whole configuration need to be static. You can create a new class containing all the configuration fields. You can do as what Choonster said. You can store the client configuration fields in any class/instance you want if you use it properly. I prefer to put it in either the mod instance or the network instance which can be accessed from the mod instance.

No, the only way you can use will be using server resourcepacks(the one which is only applied when the user allows it). Languages are considered as resources, so you can't modify it with the server-only mod. Also you can't get the server locale. You need to specify details like {} on lang file. For the translation component "key", you set something like 'key=the string is {}'.

Well, why can't you get and set the fields when it's not final? Also you can create instance of RPConfiguration since it's not final. You need separate instance than the static one anyway, considering the combined client. Just send sync packet based on the static configuration and setup separate client config with the packet. Anyway, forge does not have any tool for this. You have to do it yourself.

You mean the tooltip? Because there's no way to translate comments... Then config.modid.common.enabled.name.tooltip will work. Just put the appropriate tooltip for the key in the lang file.

How to implement it is just a matter of choice. You can make a new instance of the RPConfiguration class on client and manually sync the fields. Forge won't do any server-client syncing for you. Or, you could just wait till 1.13 like me, it introduces synchronized data packs.

Minecraft Forge uses it internally, if I recall correctly. It's recommended to use register events: https://mcforge.readthedocs.io/en/latest/concepts/registries/

It's prohibited due to performance, so... Why do you need thousands of wireframe cubes in the first place? I guess that's the part where many optimizations can take in place. Also it's better not to update thousands of vertices every frame. Store them in a VBO and only update it when it's needed. (AFAIK this is also done with chunk rendering. There should be tools for that) Don't call draw many times, it should be one main source of lag. Speedup of 2x is really a BIG improvement, actually. Instead, varying width lines can be done better with quads. Just play with some trigs and coordinates to find the orientation.

Well. @ObjectHolder requires Entity ID, not class. If you took a glance on EntityEntry, you must've found that it holds the class you need... So check for entity with the class.

If you are on the latest version, afaik it's better to check with EntityEntry registry. Use @ObjectHolder to get the entry and check if the class is the same with the class from the entry.

AFAIK notifyBlockUpdate is sufficient. It works both on TEs and Blocks, GiantNuker.

Yes, you should notify it every time something client-related changes. Call World::notifyBlockUpdate with the current blockstate for both old and new for that.