exposing an internal field like this isn't the best practice, but it seemed like the best and simplest solution to me to a problem of not being able to do anything to unknown setting keys (such as removing them or migrating their data if that key used to be a valid setting)
The actual reason lies in the loader implementation, which for some reason can sometimes count up the `m_refreshedModCount` twice for some mods which are disabled.
This small change checks the actual loaded mod count instead of relying on an incorrect `LoaderImpl` member and fixes issue #687.
* add level: links and mod: links
* fix errors
* fix errors 2
* fix errors 3 (hopefully)
* fix errors 4 (i think fixed?)
* fix 5 PLEASE
* fix mod links and make level links actually work
* PLEASE JUST WORK!!!!!!!!!!!!!
* change it to this
* oops forgot a )
* PLEASE HORRIBLE CODE JUST WORK!
* AHHHHHHHHHHHHHHH fix
* just work
* I DO HORRIBLE CODE
* Update ModInfoPopup.cpp
---------
Co-authored-by: alk <45172705+altalk23@users.noreply.github.com>
* size_t is unsigned
`i` is always >= 0 because it is unsigned. This causes crashes if no children are found before reaching 0.
* oops
`node->getChildrenCount() - 1` in the 2nd part of the for loop underflows as well if the children count is 0
I think CMake is trying to link zlib from the host system? This prevents it from doing that.
This also causes a fun new CMake warning when configuring for whatever reason.
Currently, "Report an Issue" button, which can be found in the `ModInfoPopup` if `mod.json` contains `issues` property, doesn't do anything useful except opening crashlog directory.
This changes it to actually open the specified URL in browser / crashlogs directory, instead of both buttons having the same action.
