I was using the ZDoom Wiki and found this by accident: Classes:Behavior. The API is documented, but there isn't an actual explanation of the class and no examples are given for how we might use it. It sounds vaguely like the CatsToken class I used in a post some time back.
Please can the devs give us a brief introduction to this Behavior class and what it might be used for?
What is ZScript Behavior class used for?
Moderator: GZDoom Developers
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
-
MartinHowe
- Posts: 2089
- Joined: Mon Aug 11, 2003 1:50 pm
- Preferred Pronouns: He/Him
- Location: East Suffolk (UK)
Re: What is ZScript Behavior class used for?
You know in the past, people attached Inventory items to Actors to act as "actor plugins" that modify whatever Actor is carrying it? It's basically that, that but more elegant and proper (and also lighter on performance IIRC as you aren't instantiating full-on Inventory Actors multiplied by however many other Actors that are carrying them).
As the wiki states, think of it like an entity component system that's used in engines like Unreal or Unity.
That is to say, Behaviors are an Actor plugin system that's meant to supersede Inventory.
As the wiki states, think of it like an entity component system that's used in engines like Unreal or Unity.
That is to say, Behaviors are an Actor plugin system that's meant to supersede Inventory.
-
MartinHowe
- Posts: 2089
- Joined: Mon Aug 11, 2003 1:50 pm
- Preferred Pronouns: He/Him
- Location: East Suffolk (UK)
Re: What is ZScript Behavior class used for?
Thanks, @Nash. I did have a look at the source code and yes, they seem to be a generalisation of my CatsToken and similar things done by other people.
The issue I can foresee is the lack of virtuals for common events; in my case it is PreTravelled. I'm guessing you're meant to use the Tick() method and do everything by hand the hard way; that's fine up to a point, but the jump in difficulty level in coding may put some people off and it doesn't help when you need the engine to notify you before something happens.
In the case of the CatsToken, I could keep a check on the level locals to see if they change; that would be a substitute for Travelled(); but there's no obvious substitute for PreTravelled() which is essential for its functionality. On the other hand, we do not want this new class burdened down with lots of Actor style functionality, as it would defeat the entire point.
I can only hope the devs have given serious thought to making it possible for subclasses of Behavior to be able to detect critical things like map changes or the host actor about to take damage or whatever before they happen.
The only way I can see to do it is to make every actor virtual have a corresponding virtual in Behavior, with the same name and parameters and the addition of an Actor parameter for who called it; the Behavior's shadow copy virtual would do nothing by default but return control to the host actor's virtual; so the code generator could compile the vast majority of them out; in that way the Behavior can always know what is, or is about to, happen to the host actor and can do something in response.
This would require some sort of step in the compile process to duplicate the Actor virtual function calls in Behavior (with the added parameter though maybe we don't need it); and add code to each in Actor virtual to first call the corresponding virtual in each Behavior the actor owns (or rather, call some sort of dispatcher shim that handles the Behaviors). This isn't as crazy as it sounds, as most of the complexity can be automated; but it would rely heavily on the code generator to elide out the vast majority of both calls in Actor and definitions in Behavior, as most will (thankfully) not be used.
The issue I can foresee is the lack of virtuals for common events; in my case it is PreTravelled. I'm guessing you're meant to use the Tick() method and do everything by hand the hard way; that's fine up to a point, but the jump in difficulty level in coding may put some people off and it doesn't help when you need the engine to notify you before something happens.
In the case of the CatsToken, I could keep a check on the level locals to see if they change; that would be a substitute for Travelled(); but there's no obvious substitute for PreTravelled() which is essential for its functionality. On the other hand, we do not want this new class burdened down with lots of Actor style functionality, as it would defeat the entire point.
I can only hope the devs have given serious thought to making it possible for subclasses of Behavior to be able to detect critical things like map changes or the host actor about to take damage or whatever before they happen.
The only way I can see to do it is to make every actor virtual have a corresponding virtual in Behavior, with the same name and parameters and the addition of an Actor parameter for who called it; the Behavior's shadow copy virtual would do nothing by default but return control to the host actor's virtual; so the code generator could compile the vast majority of them out; in that way the Behavior can always know what is, or is about to, happen to the host actor and can do something in response.
This would require some sort of step in the compile process to duplicate the Actor virtual function calls in Behavior (with the added parameter though maybe we don't need it); and add code to each in Actor virtual to first call the corresponding virtual in each Behavior the actor owns (or rather, call some sort of dispatcher shim that handles the Behaviors). This isn't as crazy as it sounds, as most of the complexity can be automated; but it would rely heavily on the code generator to elide out the vast majority of both calls in Actor and definitions in Behavior, as most will (thankfully) not be used.