Open Alystrasz opened 1 month ago
Relevant code can be found here: https://github.com/R2NorthstarCN/NorthstarLauncher/commit/e01944fdcdc13c3aa06ce878da3d7cd1edb770d9 https://github.com/R2NorthstarCN/NorthstarMods/commit/dd23739de94e4c4022ab1e6b0b4b0953969db9d0 note: we are using a custom masterserver which doesn't have connectionless auth from atlas. this means we are still running very ancient server browser nut files and I decided to just change MAD related code instead of implementing the same server browser changes in masterserver.cpp
(Initially posted by @wolf109909 in Discord)
I think I've found some issues that might occur when mad failed to finish any of the install states in current main branches. Heres the walkthrough: I've done a few temporary fixes to these problems while debugging myself, here is the first part:
1
again, instead of retrying the download, user got sent into the server and disconnected with out of sync with server.Debugging
In
moddownloader.cpp
atvoid ModDownloader::DownloadMod(std::string modName, std::string modVersion)
, theScopeGuard cleanup
will get called even when you early return in any of the failing conditions which sets themodState.state
. this will cause modState.state to always be set toDONE
, which makes the UI think the mod is downloaded (detailed info on the second part). I just removed the scope guard and moved to the old code reusing style for temoporary fix.After that, I tried again. I get these instead:
1
again, but this time got to3
immediately.2
but the download progress bar glitches.From my debugging, I found
3
is caused by line 39 and line 41 inmenu_ns_moddownload.nut
where theNSGetModInstallState()
call is right next toNSDownloadMod( mod.name, mod.version )
, when in CPP thevoid ModDownloader::DownloadMod(std::string modName, std::string modVersion)
creates arequestThread
and making theNSDownloadMod
in squirrel operation not blocking, givingNSGetModInstallState()
with the oldg_pModDownloader->modState.state
. Immediately the UI will freak out and send user aDownload Failed
warning BUT in the mean timeModDownloader::DownloadMod
is still running and didn't get canceled. Once the user triggers1
again, theNSGetModInstallState()
will give the correct state but its set from the previousNSDownloadMod
call. there we got some kind of race condition between two downloader threads that does filesystem opertaions and computer not very happy(its not that bad tbh just glitchy).Another tempfix
I added simple thread block like the ones used in masterserver.cpp to limit only one concurrent threads at the same time. then I added a new state on top of
modState.state
, naming itIDLE
. I set the state toIDLE
before spawningrequestThread
, making the script able to wait for the firstmodState.state
and not just returning. At this stage, I think the whole process is more stable and user-friendly. ps: I do this in discord instead of a github issue cause I'm not entirely sure if I'm doing this correctly. there are environmental differences between my testing branch and main branch. I will push the fixed code to my branch, but they are not very clean and are just temp fixes.