187 Mod Authoring Issues
UI transparency set to nearly invisible in the game causes UI outside of the game to be unreadable (selecting mod categories when publishing). There is no need for transparency outside of a world.
Mod autoloading and dependency is causing multiple issues.
- Mod Dependency should be a button in the mod list that parses the added mods and then adds dependencies to the mod list for the world only when pressed. There are some problems with this implementation. It shouldn't have been a black box process.
- Required mods should be added to the mod list for the world instead of being loaded on the fly. It is impossible now to see if a conflicting mod is in use or disable it because they aren't added to the list. It is also not possible to see which mod is adding it so the parent can be removed unless you look at every mod on the workshop and it's required mods, and each of the required mods' required mods, and so on.
- If 2 mods have dependencies and the dependencies need to be in a particular order there is no way to set that. So, otherwise, perfectly working mods are broken because autoloading is completely unconfigurable.
- It is very possible to have colliding dependencies and there is no way to fix the loading order if multiple mods require the same mod or a forked copy that is incompatible with the other fork.
- Another situation when it is problematic is if you are mod testing in a world and the required mod is one you are trying to test as a local mod. The Local version gets processed before WS version when the game loads which overwrites new changes being tested with old versions from the WS. Yes, you could remove other mods, but that defeats the purpose of compatibility testing with other mods.