Jump to content

sciwhiz12

Members
  • Posts

    391
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by sciwhiz12

  1. What file named "config"? Where was this file before you deleted it?

    Also, there's two places where configs are stored: the ".minecraft/configs" stores the client and common configs, while the "serverconfigs" folder within each world stores the server-specific (in this case, world-specific) configs: ".minecraft/saves/<Name of World here>/serverconfigs". Please backup, then delete the second folder. (Yes, the folders still exist in single-player worlds.)

    And please post an updated and complete debug.log. I cannot see the mentioned ParsingException in any of the logs you've shown, which leaves me to believe that you are posting incomplete logs.

  2. Please specify which Forge version, 'latest' does not help. Please upload your debug.log.

    Also, describe the issue in-depth. What did you do, from the moment you started the server, for the issue to happen?

  3. I believe that 1.14.4 Forge is incompatible with Java 9+. Try installing Java 8 (from AdoptOpenJDK) and using that for running Forge.

    Vanilla Minecraft, thought it is not officially supported, does run on Java 9+.  However, Forge 1.14 uses a complicated system that isn't compatible with Java 9+, because of the things needed to allow Forge to run.

  4. The 32.0.66 build removed a method from the FMLServerStartingEvent, which was used by mods to register their commands, and a new event added in its place, (namely, the RegisterCommandsEvent), so mods adding commands needs to be updated for 32.0.67+.

    However, it seems your version Immersive Engineering has not been updated, so it will not work with your Forge version.

    Your options are either to downgrade to 32.0.66 or wait until IE releases an update.

  5. Extend `WorldSavedData` and override `read()` and `write()`. You can also create a empty constructor calling the super constructor with the name of your WorldSavedData.

     

    If you have a `ServerWorld`, `ServerWorld#getSavedData` returns a `DimensionSavedDataManager`.

    Call `DimensionSavedDataManager#getOrCreate` (or `#get`), passing in a Supplier that gives new instances of your WorldSavedData, and a string data identifier.

    I'm not very sure if this is cross-dimensional.

    • Like 1
    • Thanks 1
  6. 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?"

  7. First, this post should be in the Modder Support forums, as this sub-forum is for user bug reports and support requests.

    Second, 1.16 rewrote many of the internals regarding dimensions, to make way for data-driven dimensions (JSON files defining dimensions). I may not have first-hand experience, but it might've been removed because it serves no purpose anymore, due to dimensions being defined by JSONs and all that.

    • Like 1
×
×
  • Create New...

Important Information

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