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.
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]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[/code]
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.