The H'uru patcher was redesigned primarily due to issues encountered by users when the client was built with a new version of Visual C++. I believe the specific update that caused issues was going from VC++2010 to VC++2012. In Cyan's patcher, when plUruLauncher detects a new version of itself is available, 1) it downloads that as a temporary file and 2) executes the new temporary file patcher. The new patcher 3) deletes the old one, 4) moves itself to the old patcher's location, and 5) starts the newly renamed patcher. On a high level, the H'uru patcher operates on the same general pattern, however, an additional step is inserted between steps 1 and 2. While Cyan's ExternalPatcher seems to be hard-wired to expect only a single file in the patcher manifest (the patcher itself), this is not the case in the H'uru patcher. In the H'uru patcher, we include all of the client's redistributable dependencies (dxwebsetup.exe, oalinst.exe, PhysX_Setup.exe, and vcredist_x86.exe) flagged 0x10 in the ExternalPatcher manifest. If the patcher downloads any new file or downloads an update to any file flagged 0x10, it starts a worker thread that executes those files silently in the background and waits for their completion. This is done on the old patcher, before launching the new patcher. This way the environment is sane when it's time to launch both the new patcher and the game itself, which may depend on the new redistributables.
This approach was designed to be friendly to the parameters we have to work in, however, I do see some sticking points that may require more effort on the Cyan side of things than we would potentially like. The first problem I see is that the files are actually flagged in the manifest. I am uncertain as to how easy it would be for Chogon to flag files in the manifest. I note that his GatherBuild json format is really "dumb" in that it's just a list of files and where they should go. Also, the Cyan patcher requires that the patcher be the first (and assumes it is the only) file in the ExternalPatcher manifest, meaning that accidental misordering of the files in the manifest can trigger problems for old clients. Additionally, in looking at the H'uru patcher, the Cyan patcher, and the C++ feature level of VC++2003, I think the approach needs to be changed somewhat. While the H'uru codebase only relies on C++14, the dependencies on features added after C++03 have become widespead, and VC++2003 is not exactly grounbreaking in that regard. Further, there are much more H'uru-isms than I expected.
With all that in mind, I would like to tweak my initial proposal. The goal is still to produce a patcher that can be built with the OU/Cyan codebase and VC++2003 that will silently prepare a player's computer for the new H'uru-based client. To do this, I plan to port over only the updater feature to the OU codebase within the framework of the existing patcher. This will make life much easier for me, and I won't have to spend loads of time playing the "will this work on an old, quirky compiler I have little experience with" game. Further, I would like to handle the redistributable files slightly differently. While I think flagging the files ultimately makes the most sense design-wise, we still have to operate within the parameters of the old patcher. Therefore, I propose that all redistributables be listed in a new manifest with a working name of "DependencyPatcher". There will be no need to set any special magic flag on this manifest. This manifest will be the place for dxwebsetup.exe, et al. If I understand Chogon's gather-build system correctly, we can provide our own artifacts in that system. I am operating on the assumption that any artifacts listed in a bundle's json file can be placed in its own manifest.
Under the above proposal, the update scenario would look like this:
- UruLauncher.exe (current MOULa) would request the "ExternalPatcher" manifest and download the above proposed patcher as a temp file.
- The new UruLauncher.tmp executable would begin and realize it is in the middle of a self-patch. It moves itself to UruLauncher.exe and launches itself in its new location.
*** NEW FUNCTIONALITY*** - The newly renamed UruLauncher.exe would request the "DependencyPatcher"
- If any files are downloaded here, a background thread is launched to run those applications. The patcher waits for this process to finish before proceeding.
*** END NEW FUNCTIONALITY *** - UruLauncher.exe would request the "ExternalPatcher" manifest (again) and realize it's up-to-date.
- UruLauncher.exe updates the game client from the "ThinExternal" manifest.
- UruLauncher.exe launches UruExplorer.exe
TL;DR: I need to know from Chogon if
- Can we apply an arbitrary flag to a filesrv manifest...
- ... if not, can we put arbitrary EXE files into an arbitrary manifest?
) may fail login - keep 'em vanilla