Fixed on native client to show actual length again by querying X-Dropbox-Content-Length header instead, no such luck for webclient though unfortunately
Fixes on Windows where if cursor grabbing was enabled and the game window was closed via taskbar preview, the cursor would still be trapped/confined in the region the game window was in before the game was closed
Should mostly fix situation where after server is closed, game will should still take up to 30 seconds to actually disconnect, especially for LAN/localhost servers
I tested unplugging ethernet and disconnecting from wifi, then reconnecting a couple of seconds later, and in both cases the game was able to survive connection dropout without being disconnected from the server.
So hopefully this doesn't cause any issues
This was because 'nameLen' was always set as sizeof(SOCKADDR_STORAGE) instead of sizeof(SOCKADDR) for ipv4 and sizeof(SOCKADDR_STORAGE) for ipv6
While that worked fine on later Windows operating system versions, it did not work on windows 98
The Direct3D11 backend still won't work pre-windows 7, but at least now the launcher part of ClassiCube will still run (instead of .exe not running at all due to requiring d3d11.dll) so the user can update to Direct3D9/OpenGL build instead
Browsers may rarely randomly close the IndexedDB connection, which would prevent the game from being able to save options or maps anymore until the user restarted the game.
With this commit, the game now listens for the 'onclose' event on the IDBConnection for when the connection is unexpectedly closed - and when the 'onclose' event is raised, clears the cached IndexedDB connection global so that the next call to getDB opens a fresh IndexedDB connection.
I tested this by deleting the IndexedDB database in developer tools (which triggered 'onclose' event) and seemed to work fine
Previously, only the Central Diretory Records for files had their modification dates set to the current date, while the Local File Records for files had their modification dates left as 0.
Hence when extracting default.zip using windows' built-in zip decompressor, the resulting files would have a modification and creation date of '0'. (aka 10th March 1601)
Unfortunately, attempting to later put these files back into a .zip using windows' built-in zip compressor would fail with an obscure 'File not found or no read permission' error, which was actually due to the modification/creation date of these files being '0'.
This commit changes Local File Records for files to also have their modification set to the current date, which results in files extracted using windows' built-in zip decompressor now having valid modifcation and creation dates, thus bypassing the 'File not found or no read permission' error
This means that e.g. time isn't wasted with drawing default background, then completely drawing over the top of it with checkresourcescreen's custom background
