Updater: Patches for games started through wrapper patches (vpatch, etc.) aren't updated correctly #69
Labels
Comments
nmlgc
added a commit
that referenced
this issue
Jun 10, 2018
…ugh wrapper patches. [V] See #69 for more details.
nmlgc
added a commit
that referenced
this issue
Jun 10, 2018
…ugh wrapper patches. [V] See #69 for more details.
nmlgc
changed the title
32th-System
added a commit
that referenced
this issue
May 26, 2023
* thcrap_update: handle games started through wrapper patches This fixes issue #69 * thcrap_update: update throgh wrapper patches: handle multiple loaders * thcrap_update: fix race condition * thcrap_update: fix deadlock and properly handle background_updates=false update_at_exit seems to still be broken * wrapper update: exchange data in a nicer format * wrapper update: fix background_updates * wrapper update: fix race condition * wrapper update: fix todo * wrapper update: experimental update at exit fix * wrapper update: better update_at_exit mechanism * wrapper update: communicate back game_id with update_at_exit * wrapper update: fix update_at_exit behaviour with wrapper patches to mimic last version * wrapper update: consider some of zero318's suggestions * thcrap: move PID removal code to ExitDll * thcrap: loader_pid should be a 32-bit integer specifically
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
7e234f7 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.The text was updated successfully, but these errors were encountered: