Add mod selection mod.
Includes some contributions by rada and sanderd17.
Description
Description
Details
Details
- Auditors
wraitii - Committed
• leper Aug 25 2014, 6:02 PM - Parents
- rP15676: Add engine support to load mods from config and restart into mods.
- Branches
- Unknown
- Tags
Event Timeline
Comment Actions
See discussion in rP20552.
Mostly raising a concern for the missing documentation which should be fixed in a separate patch.
| /ps/trunk/binaries/data/mods/mod/gui/modmod/modmod.js | ||
|---|---|---|
| 1 | Misses defining documentation. | |
| 7 | example inside an example | |
| 11 | A minority of developers will comprehend this. | |
| 28 | Contains all mods that are available and not enabled, especially not the ones returned by GetAvailableMods. | |
| 63 | pointless | |
| 91 | Does not return all existing mods | |
| 118 | So write a ticket | |
| 156 | Only one copy of the ternary and sort call needed. | |
| 173 | Dark gray on dark gray background | |
| 175 | These properties are mandatory | |
| /ps/trunk/binaries/data/mods/mod/gui/modmod/modmod.js | ||
|---|---|---|
| 5 | Someone should have informed mod developers that they may not used version comparison operators in the name field. But this field may only be used with dependency checks if different mods may use the same identifier to denote the same set of implemented features. (That hypothetical use case might make more sense with a special field however, so that a mod can state that it implements different features that can be tested against). | |
Comment Actions
Thanks for giving the user an easy way to enable and disable mods!
Thanks for cleaning this up, breaking parts of it, not caring about invalidating possibly not obvious parts of the design instead of figuring out or even just asking to clarify that, then being smug about having done so. Have fun mainta^W breaking this more.
| /ps/trunk/binaries/data/mods/mod/gui/modmod/modmod.js | ||
|---|---|---|
| 118 | So we should open a ticket for every TODO in the whole codebase? Really? | |
| /ps/trunk/binaries/data/mods/mod/gui/modmod/modmod.js | ||
|---|---|---|
| 88 | This doesn't work as expected. Because neither this nor enableMod update the user config, the mod page after the restart only displays the list of mods enabled in the user.cfg, not the list of mods that are currently actually enabled. It should display the same list before and after the restart, just that the mods have been actually enabled after the restart. Reproduce:
Described in #4881. <Insert guilt flamewar here> (The restarting is done without restarting the process but just restarting the main loop in main.cpp which calls CONFIG_Init in source/ps/GameSetup/Config.cpp which reloads the user.cfg, so might not be a cakewalk to fix) | |
Comment Actions
Enabling a mod when a filter is active does not remove the mod from the list of unenabled mods, thus misleads the user into believing the mod is not activated. Then after some multiple clicks on enabling it will trigger a debug breakpoint in the engine complaining about OOB access.
Comment Actions
Sadly won't be able to "request verification" on this one. For the time being I'm removed elexis from the auditor list to take this out of the queue, feel free to raise again if there are outstanding issues.
Comment Actions
GetAvailableMods is too slow (see rP21823), but in a way that's rather subtle, and only on release copies.
We create a new Vfs, and populate it with mods. There are two major features of the Vfs that contribute to making this bad:
- It populates mods when a new folder is loaded to the same path
- if it finds an archive, it reads the whole thing immediately.
In this case, we'll load the mod mod, then the public mod to the same path, loading a bunch of mod stuff, but it's light enough to mostly not matter, then the user mod (from rP13472), which will populate the root of public, which finds the .zip (in Releases, which is why we missed A23's lag before the release), loads it up entirely, and takes too long.
I don't think we actually needed a VFS for this. We're trying to read a single json file. However, that .json file doesn't always exist physically, since it's sometimes in the .zip. _but_, because of an unrelated bug that I can't find a trace of (see #4027), we install a mod.json on windows. So we could just generalise that.
IMO the simplest solution would be to work VFS-less and open the mod.json that's on the side, since we need it on windows for an unknown bug. Then this should go back to always taking a relatively trivial amount of time.
There's no breakage since, as noted on #4027, modders would not use archives, so they'd create their own mod.json file. We control releases, so we can include the .json. The installer ifdef can just be removed to always run that code.