Jump to content
View in the app

A better way to browse. Learn more.

Forge Forums

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Featured Replies

Posted

Currently, there are three paths where a config is loaded and parsed: the FMLConfig class for fml.toml, the ConfigTracker class for the initial config load at startup, and the ConfigWatcher class for reloading the config when the file is changed on disk.

 

When a config fails to be parsed by Night Config, a ParsingException is thrown. Both FMLConfig and ConfigTracker propagate the exception and crash the game, while ConfigWatcher logs then silently discards the exception. The problem is that the ParsingException message is not user-readable. Parsing errors from invalid syntax give a syntax message ("[client]s" -> "Invalid character 's' after a table declaration."), but corrupted configs will result in "Not enough data available", which is not understandable at first glance to a user.

 

I first made a PR that overwrote any config that failed to load with their default values. LexManos then raised valid points: maybe it is caused by user error? Is something screwing with saving? Never overwrite user data, so they can fix it. I thought about it for a while, thinking of a few solutions (moving the non-parsable config before defaulting to new config) before closing the PR for a new idea.

 

My idea for the PR is this:

  • A new exception in `net.minecraftforge.fml.config`, `ConfigLoadingException`, that wraps around a given `ModConfig` and exception cause and gives a human-readable message:
    Failed loading config file " + config.getFileName() + " for modid " + config.getModId()
  • Having try-catch blocks in ConfigTracker and ConfigWatcher to wrap the ParsingException with a ConfigLoadingException, and re-throws it.
  • Having a try-catch block in FMLConfig to wrap any ParsingException with a RuntimeException with a more understandable message, like "FML config file {fml.toml} failed to load"

I'm thinking of putting something at the end of the messages as a suggestion to the user; something like "...; maybe it's corrupt?" or to that effect.

 

This way, it is immediately obvious with a look at the exception message that a particular config is erroring, and support advice can be tailored: "It seems that ____ config file is corrupted/invalid syntax. Could you delete/open the file?"

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

Important Information

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

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.