A third server listing status: "Busy"

[freddyhayward]

Servers could announce "Busy" when they start saving/loading the game, then announce "Online" when running again. The colour could be orange or yellow. That way, people understand why the server isn't responding even when it appears to be online, and can wait a little instead of become frustrated.
Does anyone have the ability to update the listing server code? The only thing I could find was https://github.com/ashleybaldock/simlist and I couldn't test anything because it requires setting up your own database or something. On the simutrans side of things, I was implement a proof-of-concept hack by changing the server name instead of status:

[prissi]

Since the typical announcement intervall for servers is every 15 minutes, I fail to see how this improves stuff. Also a save load cycle is a few seconds so it would not matter. And finally, the ingame network windows is not constantly updating, it updates only if something has been changed. So even if there is a busy state, the server would display busy unless the window is forced to update again.

I wanted to say my simlist code at https://github.com/prissi/simlist is more recent, however, it misses the last error corrections. I will try to upload again tonight.

[freddyhayward]

Since the typical announcement intervall for servers is every 15 minutes, I fail to see how this improves stuff.

This would obviously not use the 15-minute interval. It would announce at the start and end of each cycle.

Also a save load cycle is a few seconds so it would not matter.

It can take any amount of time depending on the size of the map and hardware. Bridgewater-brunel can take over 10-15 minutes.

And finally, the ingame network windows is not constantly updating, it updates only if something has been changed. So even if there is a busy state, the server would display busy unless the window is forced to update again.

That's precisely what a player would do if they wanted to play on a server that was busy, instead of repeatedly trying to connect and timing out.

[prissi]

I think 15 minutes per joining is almost denial of service. It there are 8 players connecting, it needs already two hours to get everyone on it. This is broken by design. But, the extended code of the serverlist is slightly different, as far as I know. Abyhow, I updated https://github.com/prissi/simlist with the current state of the code.

[freddyhayward]

I think 15 minutes per joining is almost denial of service. It there are 8 players connecting, it needs already two hours to get everyone on it. This is broken by design.

It takes even longer than that due to long transfer times for those of us without fast broadband. Yet we continue to do it because the large world and realistic simulation are so attractive.

[RESTRICTED ACCOUNT]

It takes even longer than that due to long transfer times for those of us without fast broadband.

I think it will take a very long time regardless of whether it is high-speed broadband or not. (´・ω・｀) I use optic fiber internet.
I think there is another reason for the difference between people who connect fast and people who connect slowly..

[freddyhayward]

I think it will take a very long time regardless of whether it is high-speed broadband or not. (´・ω・｀) I use optic fiber internet.
I think there is another reason for the difference between people who connect fast and people who connect slowly..

Of course there are many other factors. If you did not have optic fiber internet, it would take even longer.

[Andarix]

code serverlist is here for extended

https://github.com/An-dz/simlist

[Vladki]

code serverlist is here for extended

https://github.com/An-dz/simlist

yeah, that's the one running at http://list.extended.simutrans.org:8080/list

[prissi]

If there is "just" the demand for a large map, why does not somebody host a big standard map. That probably would perform much better ... Actually a BB sized map runs on standard even in 32 bit version, consuming (without convois) about 1.2 GB. Since the original routing of Knightly was not that wasteful, there must be something in very urgent need of improvement (or remove to tilt the balance to playability).

About download speed: I myself (in Japan) have 5 GB/s broadband (although only GB ethernet) at home, but since the Chinese "accidently" destroyed one important sea cable last year, all internet traffic is routed via the US. So typical ping is 326ms to Europe. Maintaining my servers on commandline feels like early 90ies again and modem speed. This will certainly affect download speed from Japan.

[Mariculous]

Yet we continue to do it because the large world and realistic simulation are so attractive.

Imho schedules, shortest (here fastest) path routing and the pax generation are much more important than a huge map by itself.
Stephenson-Siemens was quite a lot of fun too, although I must admit, it's too small for more than 3, maybe 4 players.

Anyways, this is moving offtopic.

[prissi]

Imho schedules, shortest (here fastest) path routing and the pax generation are much more important than a huge map by itself.

That are not the most memory or computation intensive parts though or have been highly optimised in the past. Maybe it is time for another branch then ... But you are right, this becomes hugely offtopic.