Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Tue Sep 30, 2014 3:50 pm

All times are UTC




Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Jan 04, 2012 8:45 pm 
Offline
Traffic Manager
Traffic Manager

Joined: Sat Jun 25, 2005 10:44 am
Posts: 166
Location: The Netherlands
So there's a few servers around that don't pause whenever players are connecting. Apparently these are modded servers. Is there any such code/plugin/patch available for others to use? It's really helpful when dealing with servers that run large maps.

Thanks

_________________
/r/OpenTTD
/r/tycoon


Top
 Profile  
 
PostPosted: Wed Jan 04, 2012 9:21 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Mon May 31, 2004 9:21 am
Posts: 1254
Pause_on_join? As that has been in stables for .. Years? Nothing modified about that I am afraid :(

_________________
The only thing necessary for the triumph of evil is for good men to do nothing.


Top
 Profile  
 
PostPosted: Wed Jan 04, 2012 9:22 pm 
Offline
Traffic Manager
Traffic Manager

Joined: Sat Jun 25, 2005 10:44 am
Posts: 166
Location: The Netherlands
TrueBrain wrote:
Pause_on_join? As that has been in stables for .. Years? Nothing modified about that I am afraid :(

Really? So why isn't this enabled by default?

_________________
/r/OpenTTD
/r/tycoon


Top
 Profile  
 
PostPosted: Wed Jan 04, 2012 9:39 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Wed Mar 30, 2005 9:43 am
Posts: 1477
It is on by default...

_________________
He's like, some kind of OpenTTD developer.


Top
 Profile  
 
PostPosted: Wed Jan 04, 2012 9:40 pm 
Offline
Traffic Manager
Traffic Manager

Joined: Sat Jun 25, 2005 10:44 am
Posts: 166
Location: The Netherlands
petern wrote:
It is on by default...

Well, I meant the other way around. Why is the game paused on join when it works just as well when the game doesn't pause?

_________________
/r/OpenTTD
/r/tycoon


Top
 Profile  
 
PostPosted: Wed Jan 04, 2012 9:48 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Thu Dec 20, 2007 12:49 pm
Posts: 3653
Because it doesn't "work just as well". As soon as a client would use say 90% CPU he can still join the game and play. If the game continues while he downloads the map, the client will have a lot of ticks to catch up on and might not have enough time to do that. As a result the client is kicked out of the server for lagging too much while it would otherwise be able to play.


Top
 Profile  
 
PostPosted: Wed Jan 04, 2012 9:49 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Wed Mar 30, 2005 9:43 am
Posts: 1477
Because it doesn't work very well... for large maps, maps with lots of vehicles, slow computers or slow connections, etc...

_________________
He's like, some kind of OpenTTD developer.


Top
 Profile  
 
PostPosted: Thu Jan 05, 2012 12:41 pm 
Offline
Traffic Manager
Traffic Manager

Joined: Sat Jun 25, 2005 10:44 am
Posts: 166
Location: The Netherlands
petern wrote:
Because it doesn't work very well... for large maps, maps with lots of vehicles, slow computers or slow connections, etc...

This is not what I am experiencing. Perhaps take a look at the n-ice long goal server. It doesn't pause on join yet there are many players and a LOT of vehicles. I don't get disconnected at all.

_________________
/r/OpenTTD
/r/tycoon


Top
 Profile  
 
PostPosted: Thu Jan 05, 2012 12:52 pm 
Offline
Tycoon
Tycoon

Joined: Wed Aug 26, 2009 6:33 am
Posts: 2435
Location: Poland
Maybe your computer/connection is fast?

_________________
Correct me If I am wrong - PM me if my English is bad
AIAI - AI for OpenTTD


Top
 Profile  
 
PostPosted: Thu Jan 05, 2012 1:02 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Mon May 31, 2004 9:21 am
Posts: 1254
It is a simple matter of facts. When you don't pause a server when a client is joining, the time it takes him to download the maps creates a queue of things the client has to catch up with when it finishes downloading. Not the least, he has to catch up with all the missed ticks.

So to put this in numbers: if it takes you 30 seconds to download a map (slow connection), you need to catch up with those 30 seconds after downloading. Say, because you have a crappy machine, you can in fast forward go only twice the speed of normal. So every second you catch up with 2 seconds. It will take you 15 seconds before you catches up with the 30 seconds. But 15 seconds has passed by. So it takes you another 7.5 seconds to catch up. But 7.5 has passed by. Well, you get the point. By the time you are in sync, you will be kicked for being out of sync too long.

As you can see, it is just a matter of numbers. The only people who don't really notice this problem, are people on connections fast enough to download the map in, say, 1 second.

So there is a huge difference between having this setting on and off. When it is on, there is no catching up to do, and when you finish downloading your map, you are good to go immediately. So it basically is a trade-of between 2 bad scenarios. Either pause everyone when a client joins, and ensure he can join, or have randomly people connecting who a bit later get dropped because it took them too long.

From our perspective, it is better to pause everyone, and make sure everyone can enjoy the game. That way we avoid a lot of questions, and make sure the gaming experience of our players is equal between everyone; not only for those with fast (connection or CPU wise) players.

Of course a server admin is free to have another opinion, and that is why it is a switch. Just realise the consequence of changing the value, and the impact it can have on the gaming experience of our slower (connection or CPU wise) clients.

_________________
The only thing necessary for the triumph of evil is for good men to do nothing.


Top
 Profile  
 
PostPosted: Thu Jan 05, 2012 1:38 pm 
Offline
Traffic Manager
Traffic Manager

Joined: Sat Jun 25, 2005 10:44 am
Posts: 166
Location: The Netherlands
TrueBrain wrote:
It is a simple matter of facts. When you don't pause a server when a client is joining, the time it takes him to download the maps creates a queue of things the client has to catch up with when it finishes downloading. Not the least, he has to catch up with all the missed ticks.

So to put this in numbers: if it takes you 30 seconds to download a map (slow connection), you need to catch up with those 30 seconds after downloading. Say, because you have a crappy machine, you can in fast forward go only twice the speed of normal. So every second you catch up with 2 seconds. It will take you 15 seconds before you catches up with the 30 seconds. But 15 seconds has passed by. So it takes you another 7.5 seconds to catch up. But 7.5 has passed by. Well, you get the point. By the time you are in sync, you will be kicked for being out of sync too long.

As you can see, it is just a matter of numbers. The only people who don't really notice this problem, are people on connections fast enough to download the map in, say, 1 second.

So there is a huge difference between having this setting on and off. When it is on, there is no catching up to do, and when you finish downloading your map, you are good to go immediately. So it basically is a trade-of between 2 bad scenarios. Either pause everyone when a client joins, and ensure he can join, or have randomly people connecting who a bit later get dropped because it took them too long.

From our perspective, it is better to pause everyone, and make sure everyone can enjoy the game. That way we avoid a lot of questions, and make sure the gaming experience of our players is equal between everyone; not only for those with fast (connection or CPU wise) players.

Of course a server admin is free to have another opinion, and that is why it is a switch. Just realise the consequence of changing the value, and the impact it can have on the gaming experience of our slower (connection or CPU wise) clients.

This makes sense. Thanks for the information.

_________________
/r/OpenTTD
/r/tycoon


Top
 Profile  
 
PostPosted: Fri Jan 06, 2012 12:25 pm 
Offline
Engineer
Engineer
User avatar

Joined: Sat May 22, 2010 12:03 am
Posts: 20
Being the admin of the n-ice servers I'd like to add that indeed a lot of players cannot connect anymore as soon as the game has been running a given time (~100 game years, depends on how much players are building). Players with fast computer and fast internet connections are not affected, but of course we want to allow "slower" players to be able to play too. Because of this we're currently discussing to change some parameters of that "Long run" server that should have an indirect impact on the connection process (e.g. less player structures and vehicles on the map).

Enabling pause-on-join, however, is not an option. Back when we had it enabled there was an admin call once or twice a day about the game not being unpaused anymore, even after 30 minutes, and then we had to unpause it manually or kick the "ghost" player who is causing it.
There seems to be several situations where a player who is losing connection at a specific point during the connection process will cause OpenTTD not to notice that he is gone but also not to treat him as a full player when it comes to applying timeouts. So he stays in the player list, the game stays paused, he is never removed - although you can see on operating system level that he doesn't even have a TCP connection to the server anymore. He is a "ghost", being there and being not there at the same time - clients that want to connect now will be stuck with the message that 0 players are waiting in front of them. Finding the player who is the ghost (not always easy when there are a lot of spectators) and kicking him cleans the situation and triggers the unpause.

At least the "no timeout" part is reproducible for the map download. You can easily simulate it: enable pause-on-join on a server, make the map 1024x1024 or bigger to make sure the download takes some time, then connect from a Windows client. During the map download do a right click on the title border of the window. This brings up the Windows context menu for the window and additionally "freezes" the OpenTTD client, so the download is never finished. Now lean back...10 minutes, 20 minutes...the game on the server is paused during the whole time, players will see you on the list as spectator. You are blocking the game for all other players but you are never thrown out.
Now imagine that a player loses connection during this process without OpenTTD noticing - then you have this effect forever, until an admin manually identifies and kicks the ghost player or at least manually unpauses the game. EDIT: filed as FS#4955

So to sum it up: the pause-on-join feature is simply not stable enough for us to be used. Also it is not configurable enough: independent from all the other things mentioned before it should be possible to configure a timeout for pausing.
Some players just take 10 minutes to download the map. Even if his connection stays stable and he eventually finishes the download and joins the game: a player who is this slow will never be able to keep in sync with the server afterwards - as the game unpauses he will start losing ground and be kicked out soon.
But why give him so much time anyway? There is a limit: if a player takes > X seconds for the map download you already know he won't be able to keep up with it anyway. So it should be possible to configure the pause-on-join to this behavior: "pause on join and unpause after successful connection OR connection loss OR if paused for X seconds". So it should "give up" after some time.
The premium feature would be a cooldown time - if pause-on-join was already granted to an IP address within the last X seconds, don't pause-on-join again if he starts a new connection attempt. Because I often see that such players keep on trying, blocking the server for another 10 minutes and so on...

We're using vanilla OpenTTD btw (installed from Debian package), no patches, our extra features come from an external software that is utilizing the admin interface.

I will add entries about the above mentioned problems on the bug tracker, linking them here when finished.


Last edited by xOR on Fri Jan 06, 2012 4:18 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Jan 06, 2012 1:12 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Mon May 31, 2004 9:21 am
Posts: 1254
xOR wrote:
(..)
At least the "no timeout" part is reproducible for the map download. You can easily simulate it: enable pause-on-join on a server, make the map 1024x1024 or bigger to make sure the download takes some time, then connect from a Windows client. During the map download do a right click on the title border of the window. This brings up the Windows context menu for the window and additionally "freezes" the OpenTTD client, so the download is never finished. Now lean back...10 minutes, 20 minutes...the game on the server is paused during the whole time, players will see you on the list as spectator. You are blocking the game for all other players but you are never thrown out.
Now imagine that a player loses connection during this process without OpenTTD noticing - then you have this effect forever, until an admin manually identifies and kicks the ghost player or at least manually unpauses the game.

Does this happen with 1.2.0-beta1 too? There has been some fixes in this area (long ago). If not, report to bug tracker. It is silly to change a setting to avoid a bug, instead of simply reporting the bug and letting us solve it. Software does not get better by avoiding bugs. It only gets better if such bugs get reported.

xOR wrote:
(..)
So to sum it up: the pause-on-join feature is simply not stable enough for us to be used. Also it is not configurable enough: independent from all the other things mentioned before it should be possible to configure a timeout for pausing.
Some players just take 10 minutes to download the map. Even if his connection stays stable and he eventually finishes the download and joins the game: a player who is this slow will never be able to keep in sync with the server afterwards - as the game unpauses he will start losing ground and be kicked out soon.
But why give him so much time anyway? There is a limit: if a player takes > X seconds for the map download you already know he won't be able to keep up with it anyway. So it should be possible to configure the pause-on-join to this behavior: "pause on join and unpause after successful connection OR connection loss OR if paused for X seconds". So it should "give up" after some time.
The premium feature would be a cooldown time - if pause-on-join was already granted to an IP address within the last X seconds, don't pause-on-join again if he starts a new connection attempt. Because I often see that such players keep on trying, blocking the server for another 10 minutes and so on...

Sorry, but that is total bulls***. Connection speed has NOTHING to do if you can keep up with a map or not. You can have the fastest machine in the world behind a very slow connection. You can keep up with the server just fine, but download a map (even more 2048x2048 maps) will take you for ever. Total unrelated facts. The other way around also holds: a user can download a map in seconds, and never be able to keep up. Simply said: what you said, is not true, false, invalid, and comparing apples with oranges. Sorry :)

xOR wrote:
(..)
We're using vanilla OpenTTD btw (installed from Debian package), no patches, our extra features come from an external software that is utilizing the admin interface.

I will add entries about the above mentioned problems on the bug tracker, linking them here when finished.

You should. And reading by your story you knew about this for a long time; you should have done so long ago. To make it clear why I try to say: we cannot improve OpenTTD if people don't report the problems they experience. It is very important that you report bugs, problems, issues and unusual things. Not meant at you specifically, but this is a nice case that shows the difference between what we experience on a day-to-day basis, and what you experience. Communication between those two is vital, and that happens over our bugtracker :)


That all said and done, this setting is a balance between worst. The default is the value that makes it most fair for every player, unrelated to his connection speed. And it is a setting so you can choose yourself which method you like best. Prefer fast connections over slow connections, or make everyone 'pay' for people with slow connections. Your choice.

Some other tips to get your map faster:

- Don't use NewGRFs (they slow down a lot, but also give a lot of extra benefits of course)
- Don't use AIs
- Use smaller maps
- Don't allow ships, or only a very limited amount

But I guess of most you were already aware :)

PS: tnx for your lengthy reply, it is nice to read how you experience things like this.

_________________
The only thing necessary for the triumph of evil is for good men to do nothing.


Top
 Profile  
 
PostPosted: Sat Jan 07, 2012 3:14 pm 
Offline
Engineer
Engineer
User avatar

Joined: Sat May 22, 2010 12:03 am
Posts: 20
TrueBrain wrote:
If not, report to bug tracker. It is silly to change a setting to avoid a bug, instead of simply reporting the bug and letting us solve it. Software does not get better by avoiding bugs. It only gets better if such bugs get reported.

Until my new aggressive approach to provoke this error (just wildly try to freeze OpenTTD during the different stages of joining the game) yesterday I didn't have a reproducible scenario. If I report that I am seeing ghosts and can't even tell how it happens you would have rather sent me to a mental clinic instead of trying to fix anything :P
Yesterday I then added it to the bug tracker and it was already fixed by Rubidium today.

However, I am still not sure whether this was the only section during the connection process that has such a problem. What I saw in the past is that a player having trouble to connect keeps on trying to get in, until suddenly you see a new join message from him without having seen a leave message before. This is when his old session has become a ghost session and is now starting trouble - but it isn't fitting the above scenario, because he doesn't have any old map download active, his client is already doing a new join attempt. A possible explanation would be if there are just some situations where OpenTTD doesn't notice a connection being lost when it's happening during a certain stage of the connection process, leading to having a ghost player.
After that map timeout problem has been fixed in a stable release (I don't run nightly servers) I will observe it and if such problems persist I will of course continue my attempts to reproduce it so I can create a bug tracker entry that a dev actually has a chance to fix. Being a developer myself (e.g. of the software that adds the extra features over the admin interface) I know that it will be impossible to find and fix such a problem without a good reproducible scenario as the problem is not obvious and it's not occurring every time. I checked the logs yesterday and we're having 520+ player joins within 24 hours and the problem isn't seen every day, so it's not happening very often. Things like this are really hard to catch, no chance to just fix it by code changes based on guesses...

TrueBrain wrote:
Sorry, but that is total bulls***. Connection speed has NOTHING to do if you can keep up with a map or not. You can have the fastest machine in the world behind a very slow connection. You can keep up with the server just fine, but download a map (even more 2048x2048 maps) will take you for ever. Total unrelated facts. The other way around also holds: a user can download a map in seconds, and never be able to keep up. Simply said: what you said, is not true, false, invalid, and comparing apples with oranges. Sorry :)

It's a bit two-faced if you say at two places how you value our experience but then just tell me that my experience is bulls***. Apart from the fact that I have never been talking about connection speed (which is a horribly fuzzy term anyway, there is only "bandwidth", "latency" and "stability"/"packet loss") I was really only stating my experience:
- Player from country tries to join a very busy server several times, but he is always leaving with "connection lost" after some seconds
- I do "setting pause_on_join true"
- Player tries again, can join this time, game is unpaused
- Player stays for 2 minutes, then leaves with "connection lost", he couldn't keep in sync...
I have tried this several times, to get a feeling for it. And the longer a player takes to connect (so the longer the pause he causes is) the higher the chance that he cannot keep up afterwards. This can have various reasons, from a "bad" connection to an overloaded or too slow CPU of his computer - although from what I see this mostly affects players that are far away from the country my server is in (we got a GeoIP feature so when a player joins I always see his country), so it is rather related to the full mixture of connection stability, latency and rather the international peering (= throughput of data his ISP can have on its peers to other countries) than the bandwidth his local connection has.
Here's just one of many possible scenarios:
Imagine a connection that is overloaded or just "broken" and is lagging (heavy packet loss not getting anything sent/received) for 3 seconds, then working again for 3 seconds, then lagging again, and so on... The map download is tolerant enough to let him finish, so he might need twice the time of others to download the map, but he can finish it. However, 3 seconds of lag are too long for the actual game, at some point he will be thrown out because the 3 seconds let him get out of sync with the current frames too much.

Even if my interpretation was wrong that wouldn't change the observations that players who can download the map within a 10 second pause will most probably be able to stay in the game afterwards, while someone who took a full minute already for the map download will lose connection again after a few minutes in the game.


TrueBrain wrote:
That all said and done, this setting is a balance between worst. The default is the value that makes it most fair for every player, unrelated to his connection speed. And it is a setting so you can choose yourself which method you like best. Prefer fast connections over slow connections, or make everyone 'pay' for people with slow connections. Your choice.

I know that and it's a good thing that we got this setting - but what I suggested was giving us a bit more fine granulation of choices for it, which a "pause timeout" would do (e.g. don't pause longer than max_pause_time, where 0 is the default and means "infinite" and any higher number is the timeout in seconds).

TrueBrain wrote:
Some other tips to get your map faster:

- Don't use NewGRFs (they slow down a lot, but also give a lot of extra benefits of course)
- Don't use AIs
- Use smaller maps
- Don't allow ships, or only a very limited amount

But I guess of most you were already aware :)

I am aware of all of them and have set the servers up accordingly (no AIs, no NewGRFs, low ship limit), but maybe others reading this aren't , so it for sure didn't hurt to list them here :wink:


Top
 Profile  
 
PostPosted: Sat Jan 07, 2012 3:38 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Thu Feb 09, 2006 7:15 pm
Posts: 3794
All but one state now have a configurable timeout associated with them. The only state that doesn't have a timeout is the "waiting for other player to finish download" state as this state does not depend on the client. Once the other download is finished a download for this client will start and it'll eventually timeout there.

As the download and sync-up phase now have a timeout, you effectively have a maximum pause time as well (sum of both timeouts).


Top
 Profile  
 
PostPosted: Sat Jan 07, 2012 4:34 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Mon May 31, 2004 9:21 am
Posts: 1254
xOR wrote:
(..)
Until my new aggressive approach to provoke this error (just wildly try to freeze OpenTTD during the different stages of joining the game) yesterday I didn't have a reproducible scenario. If I report that I am seeing ghosts and can't even tell how it happens you would have rather sent me to a mental clinic instead of trying to fix anything :P
Yesterday I then added it to the bug tracker and it was already fixed by Rubidium today.

We are mostly very fast with critical denial of service attacks :D

xOR wrote:
(..)
However, I am still not sure whether this was the only section during the connection process that has such a problem. (..)

Connections will no longer 'hang' (TCP has a default timeout of 5+ minutes, so it is quite possible it takes that long before a connection drops. Plenty of time for him to reconnect). We now timeout on every stage in the connection process, and kick you if you take too long :) So this issue should be resolved with upcoming stable.

xOR wrote:
(..)
I know that and it's a good thing that we got this setting - but what I suggested was giving us a bit more fine granulation of choices for it, which a "pause timeout" would do (e.g. don't pause longer than max_pause_time, where 0 is the default and means "infinite" and any higher number is the timeout in seconds).

Which is what is implemented now ;)

xOR wrote:
(..)
It's a bit two-faced if you say at two places how you value our experience but then just tell me that my experience is bulls***.

Your experience was fine :) Your conclusion out of those facts was not. That was what I called bulls*** on :) Nothing can be wrong with experience :)

Let me try to explain it a bit more, mostly as I feel it will be valuable for you to diagnose these issues in the future.

Your claim:
xOR wrote:
(..)
a player who is this slow will never be able to keep in sync with the server afterwards - as the game unpauses he will start losing ground and be kicked out soon.
(..)

relates 2 events that don't have to be related. For a client to keep up with a server, all he needs to do is have a powerful enough CPU, and grind the map as often as requested. For a client to download a map, he needs bandwidth.

There are typical a few ways a client can be dropped.

- (1) Connection lost, happens when the other side terminates the TCP connection. This happens after 5+ minutes if the line goes dead, or when a client sends a clean TCP termination. The first happens when your DSL modem for example just terminates (power-loss, etc), the second happens when you close down windows / OpenTTD.
- Client timeout. This in fact includes a group of failures:
- (2) Client in unable to process the map, and can no longer keep up (can't keep in sync).
- (3) Client is very late with sending that he is in sync, and times out as such.

From the second post, what I read from you, is that you mostly notice the last group. People with a poor connection which stalls for what-ever reason for a period of time, like the scenario you describe (but I can think up a few others too), can be late with telling they are in sync, and be dropped as such.

The important difference is here. He might be able to keep up just fine, and from the clients point of view, he is doing nothing wrong. From a server point of view, the client is slacking, and will be dropped.

But as you might understand, these events are unrelated, in the way that: a slow download in no way implies that his connection is bad, and that he will be dropped later on. You can't put all people with a slow download in this group. You seem to experience only the last group, and I think that is because the second group goes unnoticed. Even if they take a long time to download, they don't bother you afterwards, so they are not apparent. The last group is the most annoying group. But there is also nothing you can do against this group. In fact, it can be they download the map in seconds, and drop a bit later, every single time. The first group is a problem on its own, which sadly also happens.

So what I try to say, is that the conclusion you made out of the facts, are in fact not related, and they should not be confused as related. You can't predict that a user will be dropped when his download of the map is slow.

I hope this makes it a bit more clear. At least I hope it explains the difference between not being able to keep up, and having a s*** connection. The bigger your map is, the more you notice the first group. The latter is always there.

PS:
xOR wrote:
(..)
The premium feature would be a cooldown time - if pause-on-join was already granted to an IP address within the last X seconds, don't pause-on-join again if he starts a new connection attempt.
Because I often see that such players keep on trying, blocking the server for another 10 minutes and so on...

This would typical be something for someone to make for the AdminPort. To me it feels like that would be perfect for there :)

_________________
The only thing necessary for the triumph of evil is for good men to do nothing.


Top
 Profile  
 
PostPosted: Sat Jan 07, 2012 7:34 pm 
Offline
Engineer
Engineer
User avatar

Joined: Sat May 22, 2010 12:03 am
Posts: 20
Rubidium wrote:
All but one state now have a configurable timeout associated with them. The only state that doesn't have a timeout is the "waiting for other player to finish download" state as this state does not depend on the client. Once the other download is finished a download for this client will start and it'll eventually timeout there.

As the download and sync-up phase now have a timeout, you effectively have a maximum pause time as well (sum of both timeouts).

Great, as you say that implicitly forms the pause timeout that I wanted and should also cover all other possible error sources, including those that haven't been found so far. Thanks!

TrueBrain wrote:
You seem to experience only the last group, and I think that is because the second group goes unnoticed. Even if they take a long time to download, they don't bother you afterwards, so they are not apparent.

You definitely have a point there, there might be players that I simply don't notice.

TrueBrain wrote:
So what I try to say, is that the conclusion you made out of the facts, are in fact not related, and they should not be confused as related. You can't predict that a user will be dropped when his download of the map is slow.


I didn't want to say that you could predict a laggy connection/slow CPU by a slow map download in all cases or that a fast map download is a guarantee for the player to not lose connection afterwards. Also while I understand that there is no direct relation between these things on the low technical level I still think there is an indirect relation. The chance that a player is an "unstable candidate" is just higher if he takes 30 seconds to download the map, than of someone who downloads the same map in just 1 second. Because for some of them the reason for the slow map download is their laggy connection.

And now don't forget that I am not talking about kicking players out that download the map for too long. I just don't grant them a pause for the full length. This
- has no effect on players with good connections/CPU, they could do without pausing anyway
- gives players with slower connections/CPU at least some pausing time, so still increases their chance of getting in (it gives players who just needed a little extra 10 seconds pause a chance to connect that they didn't have before)
- limits the pause time for players that wouldn't have gotten in anyway

With the current trade-off you have to choose between "fully please players with bad connections and annoy players with good connections with long pauses" and "completely annoy all players with bad connections and please players with good connections".
When my assumptions were completely wrong and there is a relation of 0% between map download and connection/CPU stability the pause timeout will just be an option that is a trade-off in the middle of the other two extreme trade-offs: you leave more players in (those that just needed a few extra seconds pause time during the more critical join process) while not annoying the other players for too long. So it is a good thing by itself.

But every additional % of relation more is one % more players you are not pausing the game for that wouldn't have been able to play anyway. So the improvement scales with the relation, and I know it is not 0% from the cases I have seen.

Anyway, that timeout is now in and I am sure I will get more experience with the impact of it as soon as my servers are running it.

TrueBrain wrote:
PS:
xOR wrote:
(..)
The premium feature would be a cooldown time - if pause-on-join was already granted to an IP address within the last X seconds, don't pause-on-join again if he starts a new connection attempt.
Because I often see that such players keep on trying, blocking the server for another 10 minutes and so on...

This would typical be something for someone to make for the AdminPort. To me it feels like that would be perfect for there :)


If you by that mean implementing it in an external application using the admin port: I tried that. I wrote a plug-in for my software and the first idea was that it pauses the game as soon as it gets the information that a player connected and unpauses it when he finally joined the game. Unfortunately I noticed that the first time admin port clients learn about a new player (ADMIN_PACKET_SERVER_CLIENT_JOIN) is already too late to do the pausing - it is received after the map download.

So my next attempt was to have my plug-in activate the internal pause-on-join feature and just do the unpause after a given time if it detected a pause. It already started to become ugly as the admin port doesn't inform me of pauses/unpauses with a specific packet, I had to parse the text from the console messages I get through the admin interface. Ugly, but it worked and my plug-in sent an unpause after 10 seconds if the game wasn't unpaused. Too bad that now OpenTTD simply ignored this unpause command. Apparently manual unpauses cannot override pauses done by the pause-on-join feature.

Maybe I am missing something there? Otherwise I'd say right now it's not possible to implement it from an admin port client. The only thing I could do is a rather rough solution: if a pause-on-join was performed let my plug-in do "setting pause_on_join false" and after X seconds again do "setting pause_on_join true" so that join-pauses simply aren't being done that often. But in my opinion it would be more clean to do it on a per IP basis and that doesn't seem to be possible right now.

I guess I should file two feature requests for the admin port now: one requesting that the admin port is informed of pauses/unpauses by the protocol and one that admin port clients get informed about connecting clients already when they are downloading the map :wink:


Top
 Profile  
 
PostPosted: Sat Jan 07, 2012 7:53 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Mon May 31, 2004 9:21 am
Posts: 1254
xOR wrote:
TrueBrain wrote:
PS:
xOR wrote:
(..)
The premium feature would be a cooldown time - if pause-on-join was already granted to an IP address within the last X seconds, don't pause-on-join again if he starts a new connection attempt.
Because I often see that such players keep on trying, blocking the server for another 10 minutes and so on...

This would typical be something for someone to make for the AdminPort. To me it feels like that would be perfect for there :)


If you by that mean implementing it in an external application using the admin port: I tried that. I wrote a plug-in for my software and the first idea was that it pauses the game as soon as it gets the information that a player connected and unpauses it when he finally joined the game. Unfortunately I noticed that the first time admin port clients learn about a new player (ADMIN_PACKET_SERVER_CLIENT_JOIN) is already too late to do the pausing - it is received after the map download.

(..)

Lol; I more meant banning IPs that constantly drop ;)

Regarding admin port: please make a feature request about the "before map download", with a clear example how you want to use it. I don't really know if it has a chance of being added, as I haven't looked (at all) which signals the admin port in fact gets ;)

Regarding pause: pause is not a boolean. If you manually pause the game, the flag: manual pause, is set to true. If pause_on_join pauses the game, the flag: pause_on_join pause is set to true. And we have more of those flags. Only if all flags are false, the game is unpaused. So yeah, you cannot unpause a game that is paused by pause_on_join.

That all said etc, I now understand why you would want a timeout value on pause_on_join. Please do make a feature request about it, and I will see if we can implement that. To me it sounds sane, to only allow, say, 10 seconds to download the map, and then the game continues. Try to catch up afterwards, but stop nagging out current users :P

_________________
The only thing necessary for the triumph of evil is for good men to do nothing.


Top
 Profile  
 
PostPosted: Sat Jan 07, 2012 10:12 pm 
Offline
Engineer
Engineer
User avatar

Joined: Sat May 22, 2010 12:03 am
Posts: 20
As Rubidum said I think the pause timeout is now already implicitly included in the timeouts he has added. I will look at it later and then decide. I can still add an automatic ban of IP addresses dropping too often (my framework already supports detection of repeated actions and certain reactions for it, so adding that would be like 2 lines of code).

Thanks for the explanation about the pause flags - I already assumed it would be something like that, now I know for sure and can understand why it's behaving like I saw it is.

About the feature requests...I am making quite heavy use of the admin interface, I doubt that there is anyone using it as much as me. I have written a C# library for it which makes it easy to work with it and that interface should already cover 99% of what the admin port is providing. But it actually isn't enough, for my plug-ins to be able to judge certain situations they would need to see the map (so: make map download over admin port possible), need to get a list of all vehicles and their settings, stations etc etc.
I am afraid that it is probably out of scope for an admin port though, using it to add extra game features is far beyond administration, which is why I am not requesting this stuff. I am just happy with what it is already capable of right now. And I wanted to hug you when I saw your SVN checkin about bidirectional communication between GameScripts and the admin port! So I could use game scripts that probably have access to more game specific information as "spies within OpenTTD" to give my program information it otherwise couldn't get and maybe even have influence on the game using them. At least that is what I will try to do. And also utilize the advanced goal features those scripts can provide and connect it with our highscore system! It's on my ToDo list to check this stuff and its possibilities, already anxious about starting to play with it! :D


Well, and as hugs aren't possible to do over the Internet let me just say: Thank you! :bow:


Top
 Profile  
 
PostPosted: Sat Jan 07, 2012 10:15 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Thu Dec 20, 2007 12:49 pm
Posts: 3653
xOR wrote:
I am afraid that it is probably out of scope for an admin port though, using it to add extra game features is far beyond administration, which is why I am not requesting this stuff. I am just happy with what it is already capable of right now. And I wanted to hug you when I saw your SVN checkin about bidirectional communication between GameScripts and the admin port! So I could use game scripts that probably have access to more game specific information as "spies within OpenTTD" to give my program information it otherwise couldn't get and maybe even have influence on the game using them. At least that is what I will try to do. And also utilize the advanced goal features those scripts can provide and connect it with our highscore system! It's on my ToDo list to check this stuff and its possibilities, already anxious about starting to play with it! :D
Using a GameScript (not in 1.1, only 1.2) you can get information about the map. As far as I know a GameScript can communicate with the Admin port, so that should solve that nicely.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Powered by phpBB © 2000-2013 phpBB Group

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2013.
Hosted by Zernebok Hosting.