SetActorState:A question about future custom states support

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: SetActorState:A question about future custom states support

by Nash » Sat Mar 24, 2007 11:30 pm

Oh, that's too bad then. I was hoping that I could use this soon. ;(

by Graf Zahl » Sat Mar 24, 2007 4:17 pm

The code needs some reworking anyway. Limited to one sublabel only? Why? This would be the only place in the engine that doesn't allow more complex constructions of state label names.

by Nash » Sat Mar 24, 2007 12:40 pm

Can't use this because it hasn't been added to acc.exe. ;(

by Graf Zahl » Tue Mar 20, 2007 7:18 am

Some parts of the monster AI may be confused by forced state jumps. If you are careful you can do it, however. Just don't force a monster to jump directly into states which contain code pointers with monster AI, most importantly Spawn and See. That might cause strange behavior.

by skadoomer » Tue Mar 20, 2007 7:09 am

randy wrote:Note that you should refrain from using this function for any actors that use the monster AI, or unpredictable results could occur.
I'm a little confused by this. Does this mean monsters using any A_chase functions or any part of monster AI like A_facetarget or a_die? Furthermore, is this always going to be the case until say, doomscript or will this be fixed to work in future versions of zdoom?

by Nash » Mon Mar 19, 2007 7:06 pm

Holy shit, this is like the most awesome thing ever!

by Shadelight » Mon Mar 19, 2007 5:21 pm

Awesome, this will work for all kinds of stuff, I can't wait tell the next GZDoom comes out now. :D

by Cutmanmike » Mon Mar 19, 2007 5:07 pm

Sweet.
randy wrote:Note that you should refrain from using this function for any actors that use the monster AI, or unpredictable results could occur.
This the same for players I take it?

by randi » Mon Mar 19, 2007 5:02 pm

There you go:

Code: Select all

int SetActorState (int tid, str statename, optional bool exact);
If tid is 0, it affects the script activator, otherwise it affects all the matching actors. Statename is the name of the state you want to put the actor in. The final parameter, exact, specifies whether or not partial state name matches are accepted. If you don't specify it or set it to false, if you try to do something like:

Code: Select all

SetActorState (0, "Foo.Bar");
and the actor has a Foo state but no Foo.Bar state, it will enter the Foo state. If you set exact to true:

Code: Select all

SetActorState (0, "Foo.Bar", true);
then the actor must have a Foo.Bar state, or it will not change state at all, even if it has a Foo state.

The return value for this function is the number of actors that successfully changed state. Note that you should refrain from using this function for any actors that use the monster AI, or unpredictable results could occur.

by Zippy » Mon Mar 19, 2007 4:39 pm

randy, in reply to post #1, wrote:I don't see why not. I'm moving this to feature suggestions to make sure I don't forget about it.
randy, later on, wrote:No news, because I forgot about it.
The best laid plans...

by randi » Mon Mar 19, 2007 4:11 pm

No news, because I forgot about it. I was going to try to get a new release out today, but now I feel like I should include this too.

by Nash » Fri Mar 16, 2007 8:18 pm

Randy, any news or comments on this? Is it difficult to implement? Just wondering. I would use this feature to make my side scroller use less hacks.

by Graf Zahl » Sat Jan 13, 2007 12:31 pm

A_Jump can jump to labels. This feature is being used by some of the stuff in zdoom.pk3. It may still have a few bugs though.

by eliw00d » Sat Jan 13, 2007 11:41 am

is there any way to use A_Jump and the other jump actions to jump to a state and not a certain number of frames? i tried it with a weapon actor and it says the actor does not have that state or something like that.

by TheDarkArchon » Fri Jan 12, 2007 9:00 am

Which means yes: GZDoom's custom state implementation is ZDoom's future one so if your DECORATE is coughing up errors in GZDoom, it'll cough up the same errors (aside from GZDoom bugs) come 2.1.8.

Top