Re: A_SetDuration Code Pointer

[Nash]

Yeah that's what I'm trying to say. You can't simply throw in an expression as a duration in the current system, it'll just return a syntax error.

[Enjay]

Yeah, I know that snippet doesn't work as things are at present, I was just wondering why that hadn't been used as the solution rather than the A_Delay option because it seemed, to me, simpler to put the randomisation directly on the line where it was going to be used rather than split the main frame and the duration onto two separate lines. However, now I know why it has to be this way.

[HotWax]

Can I ask what the advantage is for this pointer? Is it just that it makes random durations possible or is there something else? If it is just random durations, then would it not have been better to simply* have random durations.

*The author of this post has no idea how "simple" adding random durations would be nor, for that matter, if they are even possible.

It was stated in the thread this was split off from that the OP had already requested what you're suggesting, and Graf [No]'d (or [WFDS]'d) it because it wasn't that easy. (Right now the Decorate parser expects a constant in the duration field, and is not set up to evaluate variables or expressions there.) I do remember that he also stated in that thread that if it were to be done in Decorate, it'd have to be as an action function. Hence, A_Delay.

That said, I don't believe there's any real advantage to doing it either way, other than perhaps the formatting of actors looking "tidy".

[Graf Zahl]

Easier than:

TROO A (random (1,6)) A_Look

Or similar

Can't be done. Durations are evaluated at compile time and must be constant.

[Graf Zahl]

I'm afraid but this won't do. To do this properly a lot more work is needed than just to increase the calling actor's tics.

When the calling state has a 0-duration the code will run into a situation where the delay does not get applied properly and when called from weapons it doesn't work at all.

[HotWax]

Hm. I didn't test on weapons, but I think others in the thread did. What exactly doesn't work about them?

As for 0-duration states, AActor::SetState first grabs the new state's duration and puts it into tics, then fires off the code pointer (if any), and then checks to see if the tics are 0 to see whether it needs to continue advancing states. I guess that could be seen as a bit "dirty" but it does work.

I tested with this code and got what I expected:

Code: Select all

Pain:
    TROO H 2
    TROO H 0 A_Pain
    TROO H 0 A_Print("Before delay")
    TROO H 0 A_Delay (random(1, 3) * 10)
    TROO H 0 A_Print("After delay")
    goto See

This prints "Before delay" as the imp screams, delays 10, 20 or 30 tics and then prints "After delay" as the imp resumes its see state. If the 0-duration A_Delay frame were being treated as 0 duration, the two prints would hit at the same time and I would never see "Before delay" on the screen.

In any case I will concede relying on the order of operations conveniently falling in the correct sequence may be a bit hacky. So what would you suggest instead? I could add a check as the new state is being read to see if A_Delay is in use for that state, do the calculation then and adjust the tics before proceeding, but that seems even more hacky to me and if you're going to do that you might as well put the functionality directly into the duration parameter as Enjay suggested.

[Graf Zahl]

AActor::SetState assumes that the state's duration does not change. I haven't closely analyzed it yet but I won't rule out problems if a 0-duration gets changed.

For weapons the delays are stored elsewhere so A_Delay needs to do proper checks of what called it.

[DavidPH]

Been thinking about this lately, and I've come up with a possibility: A_JumpDelay(int tics[, state delaystate]).

I'm thinking it would set two AActor variables (JumpDelayTics and JumpDelayState, maybe) and count down each tic. When that count reaches 0, do the jump. delaystate would default to the next state, but I see no reason not to allow it to be fully configurable. The only problem I can think of would be pain/death/related, but that can be solved by making A_JumpDelay clear the delay when passes a negative tics. Basic usage would be like this:

Code: Select all

	POSS E -1 A_JumpDelay(30-health) // Takes longer as it loses health.
	POSS F 10 // Do something here.

	POSS E 10 A_JumpDelay(health) // Delay based on health...
	POSS E  0 A_JumpDelay(-1) // ...with a minimum of 10 tics.
	POSS F 10 // More stuff to do.

Note that the actor can continue executing states after the call to A_JumpDelay if so desired.

I'm willing to code this, but I figured I'd ask for opinions on the idea first in case there is some glaring logic error I'm not seeing.