Performance question about rapidly looping ACS scripts

[Matt]

Let's say one had a mod that had lots and lots of ACS calls to govern player movement, speed, etc.

Is it slower or faster to have multiple looping ENTER scripts, or do everything in one big script?

If I had a single ENTER script that called the other scripts, would that be effectively identical to doing it all as a single script?

Would the answer be different in multiplayer?

[edward850]

Neither, really. All you'd doing is changing the symptom. If they are individual scripts for each player, each script state will be run by the ACS thinker. If it's all the same script, you have each script loop being run by the script. It just comes down to code management (to which of course you would want to use unique instances).

I'm not sure what you expect to be different in multiplayer, other then needing O(n) instances/operations for each player?

[Matt]

I haven't the slightest clue what to expect, all I know is that something that seems to run just fine in single slows to a crawl in multi. Would something like that be because the script is being run once for every player every tic? (Though I don't seem to get the slowdown when I try to test it using 2 instances of ZDoom on the same machine)

[edward850]

There's likely far more to this story then you're explaining, because I can't make any sense of that scenario as is.
An ENTER script will run copies for each player that exists, if you have 2 players, that's 2 instances. Nothing special about that.

[Matt]

Basically, Hideous Destructor's performance instantly slows to a crawl when playing multiplayer online, and everyone thinks it's probably the ACS causing the problems. I really haven't been able to test this myself, so it's all secondhand.

That said, given what you've said about breaking things down into smaller scripts not making a difference, it's high time I turned that gigantic ACS loop into something manageable, so another question:

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?

[edward850]

Basically, Hideous Destructor's performance instantly slows to a crawl when playing multiplayer online, and everyone thinks it's probably the ACS causing the problems. I really haven't been able to test this myself, so it's all secondhand.

I question the validity of this, seeing as that's not how G/ZDoom works, unless the ACS itself is physically slowing down someone's machine. If it doesn't happen to you on a local machine test, then it's not the problem.
I'll try this out myself at some point, although it does sound like you already have your answer.
Edit: I theft Yholl and we did some testing. While there is indeed no performance issues, you have some major issues with trying to control player velocity with movement. Namely that you are. This is decidedly incompatible with network prediction, and it makes the player rather uncontrollable at times. I'll toss you a video of our experience once it's on the tubes.

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?

Correct. ACS keeps the state of each variable to the script instance that contains it, not globally.

[Nash]

Using ACS to alter player velocity or tackle "slippery movement" problems is definitely a no-no. Eventually an engine-side solution needs to happen if those are ever to be multiplayer-friendly. For this reason in my project, I just alter the deceleration in the source (it's very easy so why not haha).

[Matt]

Nash: Not having to package an entire new executable and pk3s seems to be a rather huge reason why not! D:

While there is indeed no performance issues, you have some major issues with trying to control player velocity with movement. Namely that you are. This is decidedly incompatible with network prediction...

Was there supposed to be something after the words "you are"? Or do you mean "Namely you are trying to control..."?

If so,just off the top of my head there are the main mechanics that I'm using:

1. using DECORATE (A_ChangeVelocity, A_ScaleVelocity) to thrust a player
2. using ACS (ThrustThing(Z)) to thrust a player
3. using ACS to change the player's speed property
4. setting the player's movement speed in the DECORATE playerpawn

Which of these are affected by the network prediction?

(Also, would changing player pitch/angle be affected by network prediction as well?)


EDIT: Saw the vid you PM'd me. Playing HD for that long on short notice without consulting the manual or the quickstart guide first... I am impressed. D:
(things you guys apparently had to play without: reloading, shotgun chambering (altfire), fire select on assault rifles, sprinting)

Maybe it's because I'm sneaking in peeks at the vid while at work, but it's a little hard to tell which movement problems are the prediction problems and which are you guys trying to get used to the movement changes. How much did disabling prediction help?

[edward850]

Which of these are affected by the network prediction?

None of them. Which is to say prediction isn't aware of them at all. They are all things not run by either P_PlayerThink or APlayerPawn::tick (during prediction, as player frames mustn't be run). The ACS isn't even part of the player and might as well exist on some alternative dimension, as far as the player thinkers are concerned.

What prediction does is run the players local input buffer in a loop on a detached player for the number of tics that they have created but not yet run. It does this in isolation of only the player, in a single iteration. So only doom's actual movement exists in this state.

How much did disabling prediction help?

Well the prediction stops arguing about where I'm supposedly suppose to be, however in doing so, one no longer has the luxury of instant feed back (you'd need to wait for the network to catchup to see your own inputs). This isn't a big problem with Yholl, because he only lives in Australia and that's a fledgling distance. If I was to grab someone in America, however, navigation would be close to impossible.

Take note when I have it on, the player mostly just lurches around. It's just not as noticeable because the prediction is only out by 3 tics (84ms), rather than 11tics (304ms). The greater the time span, the larger the disparity.

[NeuralStunner]

Take note when I have it on, the player mostly just lurches around.

780ms later... "You rang?"

I admit, that was possibly too obscure and likely too much of a stretch. :b

[Matt]

So how would prediction handle a mod that just happens to have a low player.forwardmove/sidemove setting?

Perhaps to rephrase my question: which one of those is accounted for by the prediction? Surely modified player speed would be, and wouldn't we be seeing problems when the player takes damage?

[edward850]

So how would prediction handle a mod that just happens to have a low player.forwardmove/sidemove setting?

Well of course, because that's part of the player movement code. Anything that is actually part of the player movement in engine is predicted, as that's what's being run. ACS has nothing to do with player movement, which is the key detail here.

[Matt]

So what about changing APROP_SPEED in ACS?

[edward850]

This feels like a broken record.

• Anything that is the player, sans their animation (animations run actions, and actions can edit the playsim, which is ultra bad), is handled by player prediction. The critical aspect here being that player prediction is just the player thinking routines running N tics at once. This is just an accelerated cycle, and is refreshed at the end of each gametic.
  (N is the local/net command difference.)
• Anything that is not the player, used in the most literal and explicit sense, is not.

So with that in mind, here's what'll happen:

• APROP_SPEED is accounted for by player prediction, because it's part of the player movement routine.
• The act of changing APROP_SPEED is not, as said act is not part of the player.
• Any change you make to APROP_SPEED will be part of the prediction at the end of the cycle. Because prediction is just accelerated thinking, the player will appear to lurch as the meaning of their inputs changed.

[Matt]

If this seems repetitive, it is because there tends to be a gap between what you actually say and what you seem to think you have said, into which falls some crucial information that can only be retrieved through renewed digging.

The critical aspect here being that player prediction is just the player thinking routines running N tics at once [based on nothing but the information available at the beginning of that set of tics]. ... Any change you make to APROP_SPEED will be part of the prediction at the end of the [prediction] cycle. Because prediction is just accelerated thinking [that does not factor in intervening changes coming from outside the playerpawn actor], the player will appear to lurch as the meaning of their inputs [has] changed [mid-cycle].

I think this answers my question. Thank you.

(That said, I should point out that this cannot be logically inferred from any prior statement on this thread by someone who does not already know how the prediction system works (in which case they could have figured out the answer on their own). I'm only belabouring this point in light of a recent little flare-up that seemed to have been triggered by something similar; your time helping me on this is appreciated nonetheless!)

It seems it should be possible to mitigate the problem by not recalculating the player speed property every single tic, but instead updating periodically only if a change has actually occurred. Would still get those lurches when the changes occur, but that should be acceptable.