Factorio Forums

Sorry for this but I just want to inform that the issue from 0.11.16 still isn't fixed. You (devs) may not know this, hence this post.
This time around I also have given it some though on how this issue may be adressed! idea 1 and 2 should be rather easy to implement (well it is NEVER easy, coding takes large amounts of time!).
So here we go:

Problem: Dropping player while downloading map because heartbeat check gets unstable due to overload on upload.

Solutions that might fix the problem:

1. Add an option in configs to decide the time before dropping a player due to instability.
2. manually set a cap in upload-speed for host, so sHe does not get bad heartbeats. Adding this as an option in the config file. exampel values: 0 = unlimited (default), 150 = 150KByte/S
   i.e
   a new line in config file:
   UploadLimit: 100
3. Not having to download the map at all - local saving! Games saved working like they did in Warcraft 3.
   When saving a game is triggered, it saves for all the players, meaning they don't will have to download the map next time they're joining.
   of course this means the map can't be changed between host has started the game until all the players have joined,
   so the save must be loaded paused waiting for players with the file to join before the host decide to un-pause.

Thanks for a reminder. We haven't really done much to solve the problem so far :/ We talked about it for a while with Cube and for 0.11.19 we will try to do the following:

1. When map download / upload is in progress the tolerance for player dropping will be automatically increased (2 or 3 times).

2. The algorithm that balances how many packets are send for map download / upload will be tweaked a little bit to keep some space on the line. This is not so easy and can't be done precisely because we don't really know what the speed of the line is. We are constantly adjusting the estimate for it. But we can make the comeback to the estimated maximum a little bit slower thus leaving some space for the heartbeat packets to go through.

As for 3 this is a nice optimisation. Definitely something we will look for in the future. However that is way more work and now we really want to stabilise the release.

Ok, so the two points mentioned have been implemented for the 0.11.19. On top of that cube did some improvement in the congestion detection logic. All in all this should help and solve this issue. However we couldn't test this under same circumstances you have. So if the issue is still there in 0.11.19 please speak up.

slpwnd wrote:Ok, so the two points mentioned have been implemented for the 0.11.19. On top of that cube did some improvement in the congestion detection logic. All in all this should help and solve this issue. However we couldn't test this under same circumstances you have. So if the issue is still there in 0.11.19 please speak up.

So after having someone downloading my 11Mbyte sized world over multiplayer I can happily announce that it is working!
(Uploaded at a speed of around 85kb/s, my limit is around 90kb/s so well done)


I have yet to test if the more-than-2-players-bug have been resolved as I need one more player for that. But I don't think I am as rare in that case so others would probably had mentioned that already.

Anyway thx for your work and fixing this!

Happy to hear it helped=)