Spring RTS Engine

Perhaps someone else noticed this also? There are minor jerks/freezes about every 5 seconds or so. Gameplay is not as smooth as it used to be. I will Mantis this if someone else confirms...

It may or may not be capable of that, but do you have the mex widget on?

No, and it only happens when I play online. Single player is fine.

Edit: I see now that these small lags occur several times per second. It is particularly easy to see if you look at the nano particle stream.

there are lags i wouldn't call minor in any way - had them when watching an ai vs ai replay (requires /cheat /godmode), on master. cpu profile view shows something going off scale, but i can't tell what it is, too much clutter.

Was it in CA? CA nano lups stuff is crashing

are you using bumpmapped water with shorewaves?
i had a similar problem with 0.78.2 until i disabled the shorewaves

It has something to do with the game server. The game jumps 1-2 sim frames back in time about every 1-2 seconds. In other words, exactly the same thing that happens with regular lags, but on a smaller scale. This could also explain why I think 0.79 runs slower than 0.78. 1-2 frames lost means a speed reduction of ~5%.

I'm going to begin a logarithmic search for the guilty commit

The lag is caused by the stream of NEWFRAME packets not being smooth enough, some packets get delayed, but some seem to have been sent too early as well. Not all hosts seem to have the problem. I have seen it on EXE and oxnull and some others. My guess is a gameserver bug that requires certain neworking conditions to appear.

N 14689: 36
N 14690: 35
N 14691: 70 <-- delayed packet
N 14692: 3
N 14693: 34
N 14694: 35
N 14695: 36
N 14696: 36
N 14697: 35
N 14698: 36
N 14699: 36
N 14700: 36
N 14701: 35
N 14702: 36
K 14703: 572
N 14703: 36
N 14704: 35
N 14705: 36
N 14706: 36
N 14707: 36
N 14708: 35
N 14709: 36
N 14710: 36
N 14711: 35
N 14712: 36
N 14713: 36
N 14714: 36
N 14715: 4 <-- this is strange, at a seemingly steady flow the next packet arrives too early
N 14716: 49
N 14717: 19
N 14718: 36
K 14719: 561
N 14719: 60
N 14720: 11
N 14721: 59
N 14722: 12
N 14723: 35
N 14724: 36
N 14725: 70 <-- delayed packet
N 14726: 2
N 14727: 35
N 14728: 36
N 14729: 44
N 14730: 28
N 14731: 35
N 14732: 67 <-- delayed packet
N 14733: 4
N 14734: 36
K 14735: 567
N 14735: 56
N 14736: 16
N 14737: 35
N 14738: 47
N 14739: 99
N 14740: 33
N 14741: 36
N 14742: 36
N 14743: 35
N 14744: 36
N 14745: 35
N 14746: 36
N 14747: 36

Yeah, a lag is a lag, and it causes packets to arrive later than usual.

Also, It does not undo simframes, thats impossible. Just the unit movements, which continue even if no packet is received, get reset.

Btw, whats those numbers stand for?

They look like frames and milliseconds to me.

Yes, but when do they get measured? Is it when simframes are executed? Or when their packet arrives?

It is milliseconds since last frame on the client side.
N=newframe
K=keyframe

I see now that someone broke EnforceGameSpeed during refactoring. This could be related, since EXE servers use it. Will check it out.

According to your description, enforcegamespeed has nothing todo with that, it only controls gamespeed.

But it controls the internalSpeed of the server. If the internalSpeed changes very quickly, something like this might happen. Packets may be sent earlier than they should.

On the other hand, I have seen this phenomenon on on many servers. I strongly doubt all of them use EnforceGameSpeed.

Edit: And the speed seems stable when I press "B" so it should not be possible.