|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006083||Spring engine||General||public||2018-11-19 15:01||2018-11-21 18:19|
|Product Version||104.0 +git|
|Target Version||Fixed in Version|
|Summary||0006083: User cannot load "RandomMapGen 8x8 1.4" and other similar maps: timeout|
|Description||One of the BA players cannot play games on the map "RandomMapGen 8x8 1.4" : https://springfiles.com/spring/spring-maps/randommapgen8x8, on maintenance 886, BA 10.16|
He cannot join as a player, but can load the game and join as a spec once the game has already started.
Here is his infolog: https://pastebin.com/u6Ry5KPs
Here is mine: https://pastebin.com/5YNq6DVA
He tells me the map loads fine (infolog shows "hang detection" which is also present in my infolog and is caused by the huge load that the map generation represents) but no "critical" error.
I can also find some errors about graphic drivers, but here again it doesn't seem like anything that would cause the game to shut down.
He gets into the game (can see the map rendered) but sees the message user timeout and cannot reconnect, he can then exit the game.
When launching midgame, he gets into it fine and can spec the game.
My infolog shows that the timeout happens before he can send the BLK_SIZE = 32 PE costs checksum. Dunno if that's relevant.
I know map texturing happens on DrawGenesis, which seems to be "happening" around that time of loading, so i was thinking this might be a hint maybe.
It reproduces any time he tries to load RandomMapGen8x8, 12x12 or 24x24 in their 1.4 version and didn't happen on the RandomMapGen8x8 1.3 version, but did happen on the RandomMapGen12x12 1.3 version (same gadgetry but bigger map) so it also seems to be related to perfs aswell.
The changes between 1.3 and 1.4 can be found here: https://github.com/Fx-Doo/RandomMapGen
They mostly consist of rendering a minimap, rendering a splat distribution map and reviewing the way textures are applied to the map (texture by texture rather than cell by cell to minimize gl.Texture calls)
There was also minor changes to mapgen gadgets that haven't changed the way it generally works.
|Tags||No tags attached.|
|Checked infolog.txt for lua Errors|
Last edited: 2018-11-19 16:43
Yes, this is related to performance because the server automatically kills any clients that take too long to connect. Said kill message is however (somewhat cruelly) not processed by a client until it gets through the *entire* loading process, which can take minutes.
The timeout values used depend on whether the game has started or not, and can be configured in the host's springsettings via InitialNetworkTimeout (defaults to 30 seconds) and NetworkTimeout (defaults to 120 seconds), but are not really meant to be bumped for randomly generated maps. Not only will players pretty quickly give up when loading times become unbearable, but every other client would also have to wait if stragglers were not disconnected. Tread carefully here.
Hmm, what would be my options in this case?
While i can still find optimizations to do in the random map gen, i'm don't think e i can ensure anyone will be able to load under 30sec. Especially if we're talking about generating 24x24 maps.
I found out that i can generate the texture at 1/16th of its current resolution, apply less TestMoveOrder sampling (every 16x16 square instead of 8x8); while keeping a relatively similar quality (tks to detail mapping i guess).
But that only reduced loadtime by a mere 0000020:0000020%. Knowing the 24x24 took me up to 2 minutes in loadtime, we're still far from the 30s "goal".
Would it be possible for me to add some "checkpoints" during loading? Some kind of luarules messages or w/e that would keep players updated with others' loadprogress, and therefore allow to increase the InitialNeworkTimeout more safely maybe?
Last edited: 2018-11-21 18:19
You can certainly send LuaRules messages interspersed with your generation logic (which will also trick the server into thinking slow clients are still alive if you do this at the right frequency), but that doesn't quite address the "people never like long waiting periods" concern.
Larger maps may not be possible to generate on the fly without first exposing an API to do common higher-level parameterized operations like erosion in native code. This would allow removing Spring's builtin (very primitive, very unfinished) random map generator as a bonus, although hitting the right balance between general utility and generative power might be difficult.
|2018-11-19 15:01||Doo||New Issue|
|2018-11-19 16:37||Kloot||Note Added: 0019560|
|2018-11-19 16:43||Kloot||Note Edited: 0019560||View Revisions|
|2018-11-20 17:01||Doo||Note Added: 0019562|
|2018-11-21 18:18||Kloot||Note Added: 0019567|
|2018-11-21 18:18||Kloot||Note Edited: 0019567||View Revisions|
|2018-11-21 18:19||Kloot||Note Edited: 0019567||View Revisions|