A_SetDuration Code Pointer

[The Slimeinator]

I saw this in an old Feature Suggestion topic.

How about a code pointer that sets the duration of the calling frame? This could be useful for objects and monsters that need chaotic and unpredictable behavior.

[XutaWoo]

Code: Select all

BAL1 A 2
       ^
There you go

[InsanityBringer]

Allowing random at the usual duration spot (if it isn't already) would be better than this. If this goes in as said here to do random states it would require this:

Code: Select all

POSS A 0 A_PosAttack
POSS A 0 A_SetDuration(random(1,10)

For something complex it would be even worse. If it was put into the usual duration spot, it would be this

Code: Select all

POSS A random(1,10) A_PosAttack

I'm not sure if this will be implemented though. It deplends on how the state system works, which currently, if I am right, creates a fixed table of all the states needed at run-time. I could be horribly wrong though.

[The Slimeinator]

Allowing random at the usual duration spot (if it isn't already) would be better than this. If this goes in as said here to do random states it would require this:

Code: Select all

POSS A 0 A_PosAttack
POSS A 0 A_SetDuration(random(1,10)

For something complex it would be even worse. If it was put into the usual duration spot, it would be this

Code: Select all

POSS A random(1,10) A_PosAttack

I'm not sure if this will be implemented though. It deplends on how the state system works, which currently, if I am right, creates a fixed table of all the states needed at run-time. I could be horribly wrong though.

The second version you posted was what the original feature suggestion was about and the reason it got no'd. Graf suggested suggesting a code pointer to change state duration instead.

[Ryan Cordell]

Trouble is, how would A_SetDuration know which frame to modify? If it's in a zero duration frame, does it modify the "previous" frame (the one above with any duration)? Does it modify itself? What about the frame which has a duration and calls the function?

I dunno, this just isn't clicking with me.

[HotWax]

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.

[The Slimeinator]

With A_Delay, there could be a problem with calling another function at the same time with a zero duration frame prior to the A_Delay frame.

[Ghastly]

With A_Delay, there could be a problem with calling another function at the same time with a zero duration frame prior to the A_Delay frame.

Not really. Wouldn't it already execute that function, and move on? Granted, it would probably use the sprite as the previous frame, but it would have already activated the previous frame's function?

[The Slimeinator]

Perhaps you're right.

[HotWax]

In looking at the way ZDoom does things, I think the easiest solution would be to make A_Delay do what it says on the tin -- Simply wait X tics before continuing on to its own frame. A special before it on a 0-duration frame will be executed, followed immediately by the A_Delay, which will then create a delay at the previous frame (that does mean TNT1 A 0 A_SomeFunc -> MONS E 0 A_Delay (5) would cause the enemy to render invisible for 5 tics). This is in line with how ZDoom processes specials attached to frames, but I can almost guarantee it will cause some author confusion at some point.

[Ghastly]

I can almost guarantee it will cause some author confusion at some point.

All the more reason for a note in the wiki about it.

[printz]

Can't you do a loop that can be randomly exited?

[Rachael]

Can't you do a loop that can be randomly exited?

[wiki]A_Jump[/wiki]

[HotWax]

Can't you do a loop that can be randomly exited?

You could, yes. But you can do more with A_Delay than simply have random delays...

Also, this is now a code submission: http://forum.zdoom.org/viewtopic.php?f=34&t=22639

[printz]

Can't you do a loop that can be randomly exited?

[wiki]A_Jump[/wiki]

Yes. I knew and I said that as a solution to have random duration events.