FPS & Ping settings..?

[danger89]

I will try that.

EDIT:
Note: the lagg problem occurs faster at start of the round/match (which everyone is still "alive" & everyone approach each other in the middle of the map).

I just make a record of the game, you please be patient, I will upload it soon.

2 Video's ADDED!
http://www.youtube.com/watch?v=3MGDCTqYIL8
http://www.youtube.com/watch?v=G1Vxx5zuSrk


Ps.
The worst thing is that people no longer like the game because of lag. And also I get many complaints about it. Thereby I get less players in my server. Besides that, I am forced to set max_clients at 6 or 7, otherwise it will be even worse!


Kind regards,
Melroy van den Berg

[Phytotron]

I've had an issue since 0.2.8.x* where there's like this "built up lag waiting to pop" at the beginning of each round. I describe it like that because it clears once everyone has made their first turn. If I engage at or near someone who hasn't turned yet, they invariably jump all over the damn place. So, my solution is that at the start of each round I make a L-R turn, and then wait until others have made their first turn (and the lagometer appears) to engage them. Sadly, this often deprives me of the fun of that early confrontation in the middle of the arena.

* I suppose it's possible it has always been there, but due to the Mac framerate issues prior to 0.2.8.x I just didn't notice it.

[danger89]

Thx for your reaction, to bad to ear the issue. However I got it (sometimes) also after everybody made there first turns..

[danger89]

Lagg bug still not fixed.

[inVacua]

I noticed that the ping charity on the old armgetron server changed more than only on the connect of a new player and was lower than on your server. I always did that to reduce lag, go spec and back to game without leaving than the ping charity changed, and the lag was gone. Didnt know what the old server had what you didnt have ?
I also noticed that a ping charity of 27 is the best for me to play, didnt know if it helps you ? And I also have ping problems with your server, did you relocate it ? I think it started two weeks ago.

And I have a request, could you change the ai players to only one with the real wildcat config. I mean with finite walls not infinite.

[danger89]

I noticed that the ping charity on the old armgetron server changed more than only on the connect of a new player and was lower than on your server. I always did that to reduce lag, go spec and back to game without leaving than the ping charity changed, and the lag was gone. Didnt know what the old server had what you didnt have ?
I also noticed that a ping charity of 27 is the best for me to play, didnt know if it helps you ? And I also have ping problems with your server, did you relocate it ? I think it started two weeks ago.

Ok yes if there are more players especially if there ping is higher the ping charity on the server become above the 100. Normally it is around the 30, which is much better indeed. Should this be THE issue? There is standing that I don't need to change the charity because the game will auto recognize the ping charity, should I ignore that? If so, which settings should I change and to what value?

I changed this:

PING_CHARITY 40
PING_CHARITY_MAX 50

But still the ping charity become much higher then 50 ?

And I have a request, could you change the ai players to only one with the real wildcat config. I mean with finite walls not infinite.

Sure I will do that..

[inVacua]

The ping charity only grows so high if you let it be. You can change it in the network setup of Armagetron:
Game->Network Game->Network Setup->Ping Charity

Wich settings you should use, I dont know anything about arma servers Maybe 0 ?

[compguygene]

The ping charity only grows so high if you let it be. You can change it in the network setup of Armagetron:
Game->Network Game->Network Setup->Ping Charity

Wich settings you should use, I dont know anything about arma servers Maybe 0 ?

You can change the ping charity settings on your client, but the server will pretty much ignore them and make it's own decisions. If you are using the current .2.8.3.1 client and have a basic broadband connection, the default network settings should be sufficient.

[Phytotron]

Yeah, there are a few different things you guys are talking about, both client-side and server-side. I'm not going to break it down as I'm not as familiar enough with the technicalities (I'll leave that to Z-Man or someone who does actually know; that is, not speculators). But I do know that, generally speaking, you should leave all those settings at default—that goes for both client and the dedicated server. Just leave it alone.

[compguygene]

There are 2 network settings on the server side that I have found really help to minimize lag.

MAX_IN_RATE
and
MAX_OUT_RATE

When I first started hosting Ladle servers Epsy pointed out that Fortress Cafe used:
MAX_IN_RATE 100
MAX_OUT_RATE 100
DEDICATED_FPS 100

I have seen servers that use lower settings than these that are hosted in Data Centers, and suffer lag because of it.

Personally, via some experimentation, and watching servers eat resources, I have set most of my servers to

MAX_IN_RATE 200
MAX_IN_RATE 200
DEDICATED_FPS 100

And I have seen servers with scripting with rates as high as 300-400, to minimize lag.

Also, at a bare minimum you should set DEDICATED_IDLE 24 so your server automatically restarts once daily.

[Z-Man]

Pythotron is right about the ping charity settings: leave them alone. They're not responsible for this. Also, there are two algorithms for ping charity, one clientside, one serverside, and only if all clients are 0.2.8.3, the serverside version is used which respects serverside configuration. Yeah, some problems can be avoided with zero charity (instakills, mostly), but not lag.

I browsed a bit through the source code and found an odd bit that *may* cause turns to not get processed properly if CYCLE_DELAY*DEDICATED_FPS is smaller than one. Since the default DEDICATED_FPS is 40 and you have a very low CYCLE_DELAY, increasing DEDICATED_FPS may help.

compy: on the server, MAX_IN_RATE is ignored, and MAX_OUT_RATE is capped by the value the clients set. They can't go over 64, so there should not be a difference between 100 and 200, apart from the placebo effect.

[compguygene]

Well, thank you for clarifying! Anybody can be fooled by what seems right!

[Phytotron]

Pythotron

<--- Not a T. cerrejonensis

[sinewav]

very clever.

[Z-Man]

Oh, get easier to memorize names I suggest "Tom".

Anyway, yeah, there were quite ugly bits of code that didn't work properly that, in quite general situations, caused cycle turn processing to be delayed. To reproduce, all you need to do is run a dedicated server with low, but not too low, DEDICATED_FPS (6 is best) and low CYCLE_DELAY. One spectator and one player is enough to see the delayed processing; if the player goes left-right-right quickly, only the first two turns will be sent to the spectator right away, the third is delayed. And independently of CYCLE_DELAY, some turn commands with unfortunate timing would be delayed one frame as well. Both is now fixed in bzr. A workaround for the first problem is to increase DEDICATED_FPS, and for the second to increase MAX_SIMULATE_AHEAD. Values up to 0.2 should be safe, higher values enable scare-cheats where a player lets his cycle jump ahead. The wall would not be dangerous to other players and in fact insta-kill the cheater, but that fact would be non-obvious.