Jump to content

[1.14.4] Handful Of Config Questions


imacatlolol

Recommended Posts

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 by imacatlolol

I'm eager to learn and am prone to mistakes. Don't hesitate to tell me how I can improve.

Link to comment
Share on other sites

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).

  • Thanks 2

About Me

Spoiler

My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Link to comment
Share on other sites

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!

I'm eager to learn and am prone to mistakes. Don't hesitate to tell me how I can improve.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.