SetDuration might be a bad name for it. I would do something like A_Delay, or maybe A_FrameDelay. What it would do is freeze the monster at the current frame (as if the duration had been set there) and not allow it to proceed until the delay is up. I would treat the specified frame duration as being in addition to anything passed in from the code pointer.
For example, take this code snippet:
Code: Select all
MONS A 4
MONS B 0 A_Delay (random (5, 10))
MONS C 5 A_Delay (random (0, 2))
MONS D 0
MONS E 7
Here's how I would envision this would work:
1) Frame A is reached, no code pointer, so the actor is just set to the A frame for 4 tics.
2) Frame B is reached, at which point A_Delay is run and the monster is set at frame B for 5 - 10 tics depending on the result.
3) Since there's no duration on frame B, frame C is reached next and A_Delay is run again, holding the actor at frame C for 0 - 2 tics.
4) Frame C's normal 5-frame delay would then be waited out, so the end result is the actor is held at C for 5 - 7 tics.
5) Frame D is reached, no code pointer to run and no delay, so the monster immediately gets set to frame E as normal.
The way Decorate is currently set up, the delay would more accurately hold the actor at the
previous frame, but that might be more confusing to authors.
SetDuration might be a bad name for it. I would do something like A_Delay, or maybe A_FrameDelay. What it would do is freeze the monster at the current frame (as if the duration had been set there) and not allow it to proceed until the delay is up. I would treat the specified frame duration as being in addition to anything passed in from the code pointer.
For example, take this code snippet:
[code]MONS A 4
MONS B 0 A_Delay (random (5, 10))
MONS C 5 A_Delay (random (0, 2))
MONS D 0
MONS E 7[/code]
Here's how I would envision this would work:
1) Frame A is reached, no code pointer, so the actor is just set to the A frame for 4 tics.
2) Frame B is reached, at which point A_Delay is run and the monster is set at frame B for 5 - 10 tics depending on the result.
3) Since there's no duration on frame B, frame C is reached next and A_Delay is run again, holding the actor at frame C for 0 - 2 tics.
4) Frame C's normal 5-frame delay would then be waited out, so the end result is the actor is held at C for 5 - 7 tics.
5) Frame D is reached, no code pointer to run and no delay, so the monster immediately gets set to frame E as normal.
The way Decorate is currently set up, the delay would more accurately hold the actor at the [i]previous[/i] frame, but that might be more confusing to authors.