MultiCraft Small Changes To How The 1-click Install Options On The Jar List Work

Not open for further replies.


BeastNode Staff
Dec 18, 2015
The Realm of Obscurity.
Prior to this post the Forge installers wiped the contents of the mods, coremods and configs folders (and a few others) to avoid conflicts - mostly due to a high frequency in the past of having, as an example, a custom Forge 1.7.10 setup and then switching to Forge 1.10.2 without updating/changing the mods which just causes it to crash on loop.

However, this is starting to cause more issues than it is resolving so we have changed this.
When any option on the jar list for plain Forge is ran for the first time it will only remove the files for Forge itself and update to the new Forge version/build you have selected - any mods, configs, scripts etc.. will still be present in your files. Please make sure that you have updated any mods as required for the new build of Forge when updating, and/or keep an eye on the console during startup in case it errors (the errors should tell you the issue - ie if a mod is incompatible with that build and may need an update etc...).

The above applies to the plain Forge, Fabric and SpongeForge options as well as anything in the "Modded - Plugins/Bukkit" section of the jar list as these are all used for custom installations - these options will only remove their own data and update as needed, they will not wipe any mods/configs etc...
Note that this does not apply to the Custom Server JAR options on the jar list as they do not install anything themselves - when updating builds via these options you will need to remove the relevant older data first yourself, as always.

The SpongeForge options now also install the SpongeForge file with the name "spongeforge.jar" at all times so it does not need to be manually deleted each time it's updated unless you renamed the file yourself (in the same manner that we started doing with the Fabric-API.jar for the Fabric options). If you use the SpongeForge options and your SpongeForge file in the mods folder is not named this, delete the SpongeForge file you currently have and delete the jar folder before a restart on that SpongeForge option to reinstall on the latest version on the system with the new naming convention.

The Forge 1.17 and newer options on the jarlist prior to this post were also not removing the libraries folder correctly when installed for the first time, which is where these Forge builds run from - meaning, as an example, if you had Forge 1.18.2 build 40.1.47 installed and then changed to the Forge 1.18.2 build 40.1.51 option it would still be running .47 unless you had also deleted the libraries folder manually.
This is no longer required - when you run any Forge option for the first time it will wipe the libraries folder as well, meaning switching between Forge 1.17 and newer options will now work correctly without you needing to manually edit files first.

All modpack options will remove a number of modpack-specific files/folders on first install if they are present - these are all to help limit potential issues from configs, scripts etc.. that are still present in the files from previous modpacks you have used (as if a file already exists with the same name in the files when the installer unpacks the new modpacks files, it will not overwrite them).

All options that start with "Mod_" in their file names - basically everything mentioned above - will also completely wipe the jar folder contents on install from now on to limit further potential issues as well (such as libraries or Vanilla server jars from one installation causing issues on another if it's a different Forge version etc...).

Triggering a reinstall is still done in the same way as always when needed - delete the jar folder from the files before restarting on the jar list option you wish to reinstall.
Not open for further replies.