[changed] delay(0)

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.

Share this post


Link to post

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

Share this post


Link to post

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.

 

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

 

Share this post


Link to post

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

Share this post


Link to post

Confirmed: this commit fixed this issue.

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now