[1.14.4] Handful Of Config Questions

[imacatlolol]

I've been learning about the new NightConfig-based system that Forge uses now, but I've still got a few questions to clear things up:

• For the config type, the javadocs says that the SERVER type is synced to the client. How would I use this, exactly? If I had to take a guess, the client registers the config like normal but a local file is never made by the client (unless it's a local world); the server simply fills in the object values upon connection, and from that point they should be treated as immutable on the client side. The takeaway being the the client still needs to register the server config during initialization. Is that right?
• How performant is it to get values from the config? What I mean is, if I need to check a config value every frame for rendering code, is it okay to just grab the value from the config like normal? Or, should I store a "proxy" value that only gets updated when the config changes? I'm assuming it doesn't query the file every single time so it wouldn't be an issue, but I'm not confident.
• For client configs, should I place its registration in the client's proxy, or can I leave it in the mod's constructor like other configs? I would assume that client configs would simply be skipped on the server side and wouldn't create a file, but again, I'm not confident.

Edited December 31, 2019 by imacatlolol

[imacatlolol]

Bumping since I'd still appreciate some clarification.

[Cadiboo]

On 1/1/2020 at 6:59 AM, imacatlolol said:

For the config type, the javadocs says that the SERVER type is synced to the client. How would I use this, exactly? If I had to take a guess, the client registers the config like normal but a local file is never made by the client (unless it's a local world); the server simply fills in the object values upon connection, and from that point they should be treated as immutable on the client side. The takeaway being the the client still needs to register the server config during initialization. Is that right?

Its logical server side (per-world) and syncs to the client on connection. You register it on all distributions.

On 1/1/2020 at 6:59 AM, imacatlolol said:

How performant is it to get values from the config? What I mean is, if I need to check a config value every frame for rendering code, is it okay to just grab the value from the config like normal? Or, should I store a "proxy" value that only gets updated when the config changes? I'm assuming it doesn't query the file every single time so it wouldn't be an issue, but I'm not confident.

Using a "proxy" or "baked" value is much better. You can see and/or profile the performance of the get method yourself. It's (possibly nested) Map#get calls so isn't extremely slow but is a lot slower than direct field access.

On 1/1/2020 at 6:59 AM, imacatlolol said:

For client configs, should I place its registration in the client's proxy, or can I leave it in the mod's constructor like other configs? I would assume that client configs would simply be skipped on the server side and wouldn't create a file, but again, I'm not confident.

Forge registers its client & server configs on all distributions, however they only use simple config values like booleans and numbers. If you're using a class that only exists on a specific distribution (for example an enum) you might want to look into only registering that config on that distribution.

 

The config types contain some documentation. I've got a tutorial on configs here if you'd like some info. It's not very in-depth though (yet).

[imacatlolol]

52 minutes ago, Cadiboo said:

Its logical server side (per-world) and syncs to the client on connection. You register it on all distributions.

Using a "proxy" or "baked" value is much better. You can see and/or profile the performance of the get method yourself. It's (possibly nested) Map#get calls so isn't extremely slow but is a lot slower than direct field access.

Forge registers its client & server configs on all distributions, however they only use simple config values like booleans and numbers. If you're using a class that only exists on a specific distribution (for example an enum) you might want to look into only registering that config on that distribution.

 

The config types contain some documentation. I've got a tutorial on configs here if you'd like some info. It's not very in-depth though (yet).

Great, thanks for the details!