Launching modloader hangs

[bitterbutt]

Noticed this morning that when attempting to launch the modloader that the process hangs and the GUI doesn't load. This resulted in several processes sitting in the background before I realized something was wrong.

Reviewing the logs, the modloader is timing out making requests to the site API for my existing mods. Here is an excerpt:

reqwest-0.11.17\src\blocking\client.rs:978] signaled close for runtime thread (ThreadId(35))
[WARN  C:\Users\Kate\Desktop\astro\unrealmodding\unreal_mod_manager\src\mod_processing\index_file.rs:111] Failed to download index file for "StickyBeacons.Android995", error sending request for url (https://astroneermods.space/api/mods/indexFile?modId=StickyBeacons.Android995): operation timed out
[TRACE reqwest-0.11.17\src\blocking\client.rs:976] closing runtime thread (ThreadId(15))
[TRACE reqwest-0.11.17\src\blocking\client.rs:978] signaled close for runtime thread (ThreadId(15))

I am not too familiar with rust but for some reason removing the log and then launching the loader works. So here is a quick batch script to operate as a workaround. launch.bat

@echo off
setlocal

:: Get the current timestamp in YYYYMMDD_HHMMSS format
set timestamp=%date:~-4%%date:~4,2%%date:~7,2%_%time:~0,2%%time:~3,2%%time:~6,2%

:: Rename the log file with timestamp
ren "modloader_log.txt" "modloader_log_%timestamp%.txt"

:: Check if logs directory exists, if not, create it
if not exist "logs\" mkdir logs

:: Move the renamed file to the logs directory
move "modloader_log_%timestamp%.txt" "logs\"

:: Launch the executable
start "" "astro_modloader.exe"

endlocal

Attached are an "old" log and a "fresh" log for review. modloader_log20231208 94434.txt modloader_log.txt

[konsti219]

Does this always happen if a log file is already present?

It could be that Windows Defender is slowing down the program massively for scanning causing timeouts.

If this does not always happen it could have just been an internet thing.

[bitterbutt]

So far in my testing, it happens nearly anytime a log file already exists. I have only had it sucessfully load once today without removing/renaming the log.

Network connectivity does not appear to be implicitly causing issues.

I am not too familiar with rust, could the concurrent threads during the modloader startup be causing issues with writing the log? Using a mutex may prevent similiar behavior. Though, of course, if I'm the only one experiencing the issue then I'm fine with my hacky log rotation script. Haha.

[konsti219]

The underlying runtime for making network requests is multi threaded and does logging but that should not be an issue. Basically all OSs allow multiple threads to write to the same file at the same time, it might just result in weird files.

Our architecture is however specifically designed to not hold up the UI with network ( https://github.com/AstroTechies/unrealmodding/blob/84e60cc856cf6b918c924a43f0d34df7a96b1636/unreal_mod_manager/src/mod_processing/mod.rs#L51 ). I think the timeouts that can be seen in the log file are just another effect of some underlying problem that also results in the UI failing to render. How the log file could possibly cause this I have no idea. You are first in hundreds of users to experience this and my guess is just that something about your Windows install is weird.

Maybe a different way of dealing with the log file could help, but I don't have the time to implement that.

[NeatWolf]

I believe I have the same issue. It happens whenever there's an existing mod+config file. every time I relaunch it, it stays in memory, dormant, never actually showing the UI.

The only way to make it work is by deleting everything from the \AppData\Local\Astro\Saved\Mods and reinstalling every mod+recreating all profiles. That is: every time I launch it it works until I close it modloader_log.txt

Note: it never actually shuts down properly:

EDIT: I suspect it has something to do with folder permissions. Most of the issues disappear by running the loader as Admin. Besides, if you run it as admin, you can't drag&drop mods from non-admin windows. That wouldn't be an issue if you could add mods in other ways (maybe via file open dialogue?). By running the loader as Admin (I'd suggest adding this info to the correct usage - if it's not already there), it correctly closes itself when, well, closing it.