[changed] delay(0)

[Mordeth]

A little heads-up.

 

After reporting the PolyWait bug on irc and the subsequent fix, I gave the latest DRDteam build a spin. The good news is that the PolyWait bug seems solved. The bad news is that this specific ACS script has different outcomes in older versus this version of EE.

 

    while ( 1 ) {
        n0 = maxVessel - 1;
        while ( n0 >= 0 ) {

            //current and next node for this vessel
            cur = vessel[n0][1];
            nxt = cur + 1;
            if ( nxt == maxNodes ) nxt = 0;

            //wait if this vessel is still moving
            PolyWait( vessel[n0][0] );

            //move current vessel to this next node
            Polyobj_Move( vessel[n0][0], nodes[cur][0], nodes[cur][1], nodes[cur][2] );
            vessel[n0][1] = nxt;

            n0--;
        }

        //check head-tail distance
        if ( vessel[0][1] == 4 ) {
            pos0 = GetPolyobjy( vessel[maxVessel-1][0] ) >> 16;
            pos1 = GetPolyobjy( vessel[0][0] ) >> 16;
            diff = pos0 - pos1;

            if ( diff != 516 ) PolyWait( vessel[0][0] );
        }
        delay(0);
    }

 

Basically, a bunch of polyobjects are chained head to tail and move in a circular fashion. The "head-tail" section in the script serves to correct any bumps to the polyobjects that the player causes, because, hey, apparently players can still hinder damaging polyobjects.

 

The problem is the "delay(0)"  bit. In older EE versions, the movement of the polyobjects in their never-ending circle was smooth. In the latest build, the delay(0) bit causes a momentarily halt in the movement, which goes away if you comment out this line. Which is very weird, because the polyobjects are sure still moving at that point and would only halt for the polywait line in order to be synchronized.

 

So, not a big deal here... but something has changed in ACSVM and I bet it was unintentional.

[Gez]

Delay(0) conceptually doesn't make much sense to me.

[Graf Zahl]

Correct, but in Hexen 'delay' really meant, "wait for n+1 tics", if I remember correctly. Maybe something was changed here for some backwards compatibility reason.

 

[Altazimuth]

Graf's on the money. We were discussing this earlier in IRC, and @DavidPH noted that the prior behaviour was inconsistent with Hexen behaviour (though we're not sure about ZDoom's behaviour in this regard), which is what he goes by for this sort of thing. We all forgot to post here clarifying, so apologies for that.

[Mordeth]

I actually got more or less the same info from @DavidPH. It had to do (and I'm paraphrasing here) with the fact that scripts are not executed in the exact same order or moment as in the previous tic, plus the fact that a tic does not actually represent an exact  or same time period from one iteration to the next. Delay(0) basically means "wait for the next iteration" while delay(1) means "postpone 1 tic". So with delay(1) you're not actually getting a continuation of your loop each and every tic, as you would expect. You get "slippage".

 

The easiest way to see this in-game is to make script to transfer a light level from sector A with some kind of light flicker to a different normal sector B. Basically, in pseudo code:

while ( 1 ) {
    n= GetSectorLightLevel( A );
    Light_ChangeToValue( B, n );
    delay(1);
}

 

You would think this would continuously update sector B's light level to that of A as B's level changes since this is executed every tic, but that is not the case. Choose a "blinking light" effect, and you'll occasionally get sequences of very fast changing light level changes... and they will not propagate to B on time but lag or skip altogether.  Choose a delay(0) instead, and B will always match A (with a sharp decrease in performance).

 

Also, I do not think this is the cause of the altered behaviour reported in the original post. I guess the combination of a delay() with polywait() is having some unexpected effect.

[Graf Zahl]

6 hours ago, Altazimuth said:

(though we're not sure about ZDoom's behaviour in this regard)

 

ZDoom had it initially so that it waits x tics, i.e. 0 doesn't wait, but later had to implement a fallback for old Hexen maps. But due to the large amount of material already present when this was noticed it was not possible to do it unconditionally anymore.

 

It only waits the additional tic if the map comes with an original Hexen MAPINFO.

 

[Altazimuth]

Should be fixed, though @Mordeth will need to confirm for the next build.

[Mordeth]

Confirmed: this commit fixed this issue.

[esselfortium]

On 3/29/2017 at 3:27 PM, Graf Zahl said:

 

ZDoom had it initially so that it waits x tics, i.e. 0 doesn't wait, but later had to implement a fallback for old Hexen maps. But due to the large amount of material already present when this was noticed it was not possible to do it unconditionally anymore.

 

It only waits the additional tic if the map comes with an original Hexen MAPINFO.

 

That seems like a sensible way to handle it.