Client Update Concerns
Posted: Mon Jan 04, 2016 12:10 am
Given the recent amount of trouble experienced by users on the MOUL forum with the recent update, I think it would be relevant to share what I've learned about deploying client updates through 20+ Gehn builds. We've updated compiler versions twice quite successfully--it's very rare that we have any issues with an update aside from legit bugs that just weren't caught. The goal here is that an update should be an operation that requires one button press and causes little to no issue on the user's end. If your update methodology (or lack thereof) cause the player problems, especially on a mainstream shard such as MOULa, you are damaging your player retention.
Our Gehn process has changed significantly since the last time we livestreamed it. It now takes me approximately 5 clicks to update Gehn . Err... and there is a beta shard.
Problem: The first problem we tend to run into is that when the launcher detects an update, it will often die a terrible death and tell the user that their "harddisk is full" -- generally users are immediately frustrated because their hard drives are nowhere near full. This is, in fact, a permissions error. Most folks tend to install Uru in the Program Files directory, which is the default for the MOUL installer. The advice most give is to run the launcher as an administrator. This is an unnecessary hurdle to updating the game and is a barrier to player retention (to the user, this is like waving a magic wand--how would they know to do this without being told?). Running the launcher as an admin is also a security risk. There are currently an unknown amount of security issues in the client. The launcher is responsible for starting the client, therefore the client inherits administrator privileges. If I am a malicious user with a zero-day exploit, I know to pay attention for an update--people will be running the game as an administrator!
Solution: Invest in a good installer! The Gehn Shard installer, in my not so humble opinion, is quite amazing. It toggles the permissions of the Uru client's directory such that the patcher can do its thing without requiring user intervention. It also takes care of some non-Cyan Shard things like copying data from a MOULa install, if found. If not, it launches the patcher in a special "repair mode" that downloads the game from Cyan. It also takes care to install the latest redistributables.
Problem: The other major issue we encounter when shipping down an update are dealing with the issues of missing DLLs for dependencies such as DirectX and MSVC++. With the recent update, the problem here was users not having d3dx9_27.dll. Windows' suggestion in this case is to "reinstall the program". Unfortunately, Uru is a large program at ~3 gigs, so if you're me, asking me to reinstall that over my 1mbps connection is tantamount to saying "stick it where the sun don't shine!" For other users, reinstalling a program is just too difficult. Furthermore, if your installer doesn't include the correct dxwebsetup.exe (see above) that advice is about as useful as a skillet made of cheese (cows are my friends). More savy users will be able to google the DLL name and download that file from a DLL website, but this is a security risk--who knows what sort of hacks have been applied by these unknown individuals. Extremely savvy users will be able to find the DirectX installer on the web, but it appears that this requires an amount of work because Microsoft has hidden lots of downloads in favor of prompts to update to Windows 10.
Solution: This problem was a bit more difficult to solve, but we began with the end in mind. We would like for the patcher itself to be able to patch the user's computer--including installing updated versions of DirectX and MSVCRT! We rewrote from the ground up the everything related to UruLauncher. Here are the relevant pull requests on GitHub: #352, #353, and #385. This adds another flag for files in the game manifests that signifies, "I'm an installer!".
Here is the script I use to generate manifests. Dirtsand accepts the output of this script as-is, however, I think MOSS wants this to be compiled into the network format. I believe I remember hearing of a tool to do that. (I am contemplating submitting a DS pull request to change it to the MOSS way--I really like sendfile.)
Here's how it works: they run UruLauncher.exe, and UruLauncher then asks for the patcher manifest. Any file flagged as an installer is executed FIRST. UruLauncher then runs the client EXE, which might be an updated copy of the patcher itself (whee). The obvious downside to this approach is that the patcher on the user's machine must already have this functionality before you update anything like DirectX or MSVCRT... because it's the old patcher doing the update, after all.
This solution will be difficult for y'all to pick over because it's pretty tightly wound in with other H-uruisms like plString and plFileSystem. I however do recommend pulling it over as it greatly improves the launcher. This code is able to check the Uru install for updates and download them concurrently, which is nice for folks with fast connections where the hashing takes longer than the actual download.
Our Gehn process has changed significantly since the last time we livestreamed it. It now takes me approximately 5 clicks to update Gehn . Err... and there is a beta shard.
Problem: The first problem we tend to run into is that when the launcher detects an update, it will often die a terrible death and tell the user that their "harddisk is full" -- generally users are immediately frustrated because their hard drives are nowhere near full. This is, in fact, a permissions error. Most folks tend to install Uru in the Program Files directory, which is the default for the MOUL installer. The advice most give is to run the launcher as an administrator. This is an unnecessary hurdle to updating the game and is a barrier to player retention (to the user, this is like waving a magic wand--how would they know to do this without being told?). Running the launcher as an admin is also a security risk. There are currently an unknown amount of security issues in the client. The launcher is responsible for starting the client, therefore the client inherits administrator privileges. If I am a malicious user with a zero-day exploit, I know to pay attention for an update--people will be running the game as an administrator!
Solution: Invest in a good installer! The Gehn Shard installer, in my not so humble opinion, is quite amazing. It toggles the permissions of the Uru client's directory such that the patcher can do its thing without requiring user intervention. It also takes care of some non-Cyan Shard things like copying data from a MOULa install, if found. If not, it launches the patcher in a special "repair mode" that downloads the game from Cyan. It also takes care to install the latest redistributables.
Problem: The other major issue we encounter when shipping down an update are dealing with the issues of missing DLLs for dependencies such as DirectX and MSVC++. With the recent update, the problem here was users not having d3dx9_27.dll. Windows' suggestion in this case is to "reinstall the program". Unfortunately, Uru is a large program at ~3 gigs, so if you're me, asking me to reinstall that over my 1mbps connection is tantamount to saying "stick it where the sun don't shine!" For other users, reinstalling a program is just too difficult. Furthermore, if your installer doesn't include the correct dxwebsetup.exe (see above) that advice is about as useful as a skillet made of cheese (cows are my friends). More savy users will be able to google the DLL name and download that file from a DLL website, but this is a security risk--who knows what sort of hacks have been applied by these unknown individuals. Extremely savvy users will be able to find the DirectX installer on the web, but it appears that this requires an amount of work because Microsoft has hidden lots of downloads in favor of prompts to update to Windows 10.
Solution: This problem was a bit more difficult to solve, but we began with the end in mind. We would like for the patcher itself to be able to patch the user's computer--including installing updated versions of DirectX and MSVCRT! We rewrote from the ground up the everything related to UruLauncher. Here are the relevant pull requests on GitHub: #352, #353, and #385. This adds another flag for files in the game manifests that signifies, "I'm an installer!".
Here is the script I use to generate manifests. Dirtsand accepts the output of this script as-is, however, I think MOSS wants this to be compiled into the network format. I believe I remember hearing of a tool to do that. (I am contemplating submitting a DS pull request to change it to the MOSS way--I really like sendfile.)
Here's how it works: they run UruLauncher.exe, and UruLauncher then asks for the patcher manifest. Any file flagged as an installer is executed FIRST. UruLauncher then runs the client EXE, which might be an updated copy of the patcher itself (whee). The obvious downside to this approach is that the patcher on the user's machine must already have this functionality before you update anything like DirectX or MSVCRT... because it's the old patcher doing the update, after all.
This solution will be difficult for y'all to pick over because it's pretty tightly wound in with other H-uruisms like plString and plFileSystem. I however do recommend pulling it over as it greatly improves the launcher. This code is able to check the Uru install for updates and download them concurrently, which is nice for folks with fast connections where the hashing takes longer than the actual download.