Re: A_SetDuration Code Pointer

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Re: A_SetDuration Code Pointer

Re: A_SetDuration Code Pointer

by DavidPH » Tue Jun 08, 2010 9:53 pm

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.

Re: A_SetDuration Code Pointer

by Graf Zahl » Sat Jul 04, 2009 3:22 pm

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.

Re: A_SetDuration Code Pointer

by HotWax » Sat Jul 04, 2009 3:13 pm

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.

Re: A_SetDuration Code Pointer

by Graf Zahl » Sat Jul 04, 2009 12:11 pm

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.

Re: A_SetDuration Code Pointer

by Graf Zahl » Fri Jul 03, 2009 2:54 pm

Enjay wrote: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.

Re: A_SetDuration Code Pointer

by HotWax » Thu Jul 02, 2009 2:59 pm

Enjay wrote: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".

Re: A_SetDuration Code Pointer

by Enjay » Thu Jul 02, 2009 2:58 pm

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.

Re: A_SetDuration Code Pointer

by Nash » Thu Jul 02, 2009 2:53 pm

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.

Re: A_SetDuration Code Pointer

by Rachael » Thu Jul 02, 2009 2:52 pm

Enjay wrote:Easier than:

TROO A (random (1,6)) A_Look

Or similar :?:
That's another thing - you're kinda screwing with the format of DECORATE. If that's already possible, then consider my last 2 statements null and void. If not, you'd have to add in a lot of spaces between durations and code pointers if you want to line up your code properly. And the more spacing you do with code, the more it goes off the edge of the editor, and the more of a pain in the butt it is to maintain.

Re: A_SetDuration Code Pointer

by The Slimeinator » Thu Jul 02, 2009 2:52 pm

@Enjay: That won't work. This feature request came from an old feature request that requested that method. Graf said that couldn't work. Thus, A_Delay instead.

Re: A_SetDuration Code Pointer

by Nash » Thu Jul 02, 2009 2:51 pm

As I've asked in my previous post, I think the advantage of this is that frames can have their durations altered dynamically in-game...

Here are some uses I can think of:

1) Monsters that move slower the less health it has.
2) Weapon attacks (mainly useful for melee-style weapons) that can be sped up or down depending on certain conditions.
3) Randomized durations for that extra randomness (useful for stuff like particle effects and explosions).

EDIT: Enjay, I don't think that piece of DECORATE snippet works... ?

Re: A_SetDuration Code Pointer

by Enjay » Thu Jul 02, 2009 2:50 pm

Easier than:

TROO A (random (1,6)) A_Look

Or similar :?:

Re: A_SetDuration Code Pointer

by Rachael » Thu Jul 02, 2009 2:49 pm

I think HotWax's solution is actually the simplest, without requiring any rewrites of code - it's also easy to use.

Re: A_SetDuration Code Pointer

by Enjay » Thu Jul 02, 2009 2:47 pm

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.

Re: A_SetDuration Code Pointer

by HotWax » Thu Jul 02, 2009 2:39 pm

Thanks for your testing on this. I'm not very practiced in Decorate and I suspected there were going to be some weird uses that could screw things up, but I couldn't think of any.

Do you think this needs to be resolved in code or is more something the author should need to be aware of? I'd rather put power into the modder's hands than to artifically take it away to avoid mis-use, but if needed I could probably have the function refuse to run on certain class types.

Also if you can find any other ways to screw things up with it, let me know. Crashes or game hangs would be the biggest issues, obviously. Right now the only thing I can think of is somebody unintentionally generating a 0-tic loop by misusing the expression evaluator. Don't think there's anything I can do about that, though.

Top