Performance question about rapidly looping ACS scripts

[edward850]

Hmm. I have this odd feeling that we aren't quite on the same page, actually. You started talking about things changing mid-cycle, but there's nothing to change. Once the prediction starts, there is only prediction, as it has to be entirely visual only for player input. The playsim cannot/should not be running anymore.

I think what this needs is flowcharts.

[Matt]

No, I think I get what you mean now.

It's like, to be totally abstract:

Input:
---+

Predictor's inference (and what is shown to the player):
---+---+---+

Not handled by predictor:
ACS is making you lose one "-" after every "+"

Actual happening:
---+--+-+

At the end of the prediction cycle, the player's view realigns with the actual happening and player lurches by "---" backwards. No change is being registered by the predictor, just the game world.

[edward850]

Ah good, so we aren't on the same page, and I now know why. The predictor isn't extrapolation, it's literally "the player has all of this as of yet processed input; Detach the player object from the game and run all of it at once, render the scene, reset". It does not occur during anything, only once the present gametic has finished does it run , and is reset before the playsim is run again (otherwise the player state would desynchronise horribly).

Remember, Doom runs when the network tells it to, and the network is built out of player input. What happens with latency is the local player ends up having more input then all other players, so the playsim cannot proceed with those tics until they arrive. So, this means your live input wouldn't otherwise be instantly be represented by what gametic is presently running, even though the input already exists. However, because it does exist, the predictor loops though all the input in the local buffer, and runs the player for each tic of local input that is yet to run. It is physically running the player the same way a gametic would run them, just in a contained loop. The last iteration is ultimately what you see.
It's prediction in the sense that it can only be assumed the result is correct based off no other external factors that it otherwise can't run during the loop. Not because ZDoom is predicting information (which would be extrapolation). The input does already exist, and you already have it (which is why it's running it), it's just not "real".

It also never occurs during a gametic (if it did, the playsim would be ruined). ACS doesn't change its result. It occurs inbetween the gametic and the renderer, not inside the gametic. If you keep setting the result of APROP_SPEED, it doesn't matter as that's not the problem. Changing the actual conditions at all is the problem (so changing it at all). Only changing it if the speed would change doesn't mean anything, as that's what the issue already is in the first place.

[Matt]

If you keep setting the result of APROP_SPEED, it doesn't matter as that's not the problem. Changing the actual conditions at all is the problem (so changing it at all). Only changing it if the speed would change doesn't mean anything, as that's what the issue already is in the first place.

What do "the actual conditons" and "it" refer to in these sentences, if not changing the player speed?

[edward850]

Anything. Any change at all. Player prediction is a cut down version of the game ticker where only the player moves and functions. ACS especially does not exist, so changing anything about the player with it will change the outcome when prediction is next run.
The issue is not that you use setplayerproperty every tic, even though you apply the same speed. Rather, the issue is the speed changes at all, outside of the player's understanding of it.
If you created a loop, setting the player speed to 2.0 constantly every tic, well of course that doesn't matter because the result is already correct. It's changing that 2.0 to something else that changes the outcome.

Think of playing back a demo, once with player-speed-altering ACS, and once without. The prediction is the latter, constantly every tic, as an instantaneous loop of the number of tics the gametic has yet to catchup to the network. The former is reality, trailing behind.

[Matt]

So:
1. we start with a player that starts off defined with speed 2.0
2. a single ACS script is called to change this to 2.5
3. everything after that script is lurch city?

[edward850]

Well that depends. Are you constantly swapping between 2.0 and 2.5? Then yes. If it's constant, only the change will lurch, once.

[Matt]

One lurch per substantive change, got it.

...which does make it a bit puzzling, though, given it really shouldn't change that often in the existing code...

...it only changes with ::checks code:: every change of direction, change of weapon, change in floor height, jump, pain, press of fire or altfire, change of inventory if playing in carrylimit mode,...

...yeah this might need a bit of simplification.

[edward850]

Yholl suggested it would be vastly better off if you didn't change it at all in multiplayer. It's just not really a latency friendly thing to be changing constantly. Perhaps make it a cvar.
There really is no point in the player having to fight their own movement. It could become a huge problem where precision movement is vital. Imagine having your movement suddenly change in The Chasm, with a 300ms latency.

[randi]

If I have a looping ENTER script that defines a static variable, that is static relative to each player (i.e., within each player's own instance of the script), right? It's not like player 1's variable is going to contaminate player 2's?

No, static variables are literally map variables that you can only use in the script that contains them. Regular non-static variables are per-instance.

[Matt]

Thanks Randi! Hadn't tested my code and you've just prevented committing to a rather embarrassing mistake.