Right now, the updater tries to set up the run configuration just like thcrap, by identifying the .exe file it is launched with. However, just like thcrap, this identification fails with wrapper patches, so the updater is left with no specific game to update the patch files for.
As a result, patch file updates for such a game are delayed to the "Update other games and patches" phase, which either runs after the game was started, or not at all if that option is unchecked.
7e234f79adadcf84c972d9d6d0b67d3df9ee74aa works around this for the standard use case of thcrap_loader.exe being started with references to games.js IDs that are identical to those used in patches. A proper fix would involve thcrap communicating back EXE file names of subprocesses to the updater in its CreateProcess detour, and then blocking that function until the updater has signaled that the update either is complete, or was deferred to process exit via the update_at_exit option.
Right now, the updater tries to set up the run configuration just like thcrap, by identifying the .exe file it is launched with. However, just like thcrap, this identification fails with wrapper patches, so the updater is left with no specific game to update the patch files for.
As a result, patch file updates for such a game are delayed to the "Update other games and patches" phase, which either runs after the game was started, or not at all if that option is unchecked.
7e234f79adadcf84c972d9d6d0b67d3df9ee74aa works around this for the standard use case of
thcrap_loader.exebeing started with references togames.jsIDs that are identical to those used in patches. A proper fix would involve thcrap communicating back EXE file names of subprocesses to the updater in itsCreateProcessdetour, and then blocking that function until the updater has signaled that the update either is complete, or was deferred to process exit via theupdate_at_exitoption.