provide a way to check whether a client has a newer/older/identical build and assert their build date
After reading up on updater strategies, seems to be standard practice
Disadvantages:
Increases complexity by adding another step to the install process
Prevents even simpler alternative of 1. getdown.jar, 2. cadesim.jar by requiring 1. cadesim.jar, 2. getdown.jar, 3. cadesim.jar
Advantages seem to outweigh the disadvantages on this one - the update check just needs to be made simple, robust, and domain/install/system agnostic to avoid problems upgrading it in future.
Additional:
run the check before login when re-entering the lobby to catch. Maybe this means we should check before login rather than on startup.
Advantages:
Disadvantages:
. getdown.jar, 2. cadesim.jarby requiring1. cadesim.jar, 2. getdown.jar, 3. cadesim.jarAdvantages seem to outweigh the disadvantages on this one - the update check just needs to be made simple, robust, and domain/install/system agnostic to avoid problems upgrading it in future.
Additional:
run the check before login when re-entering the lobby to catch. Maybe this means we should check before login rather than on startup.