Behavior custom callbacks in 1.5 release, changed functionality?
by Glen C · in Torque Game Builder · 07/13/2007 (10:26 pm) · 9 replies
I've been testing a 1.5b3 project in 1.5 release, and it appears that custom callbacks no longer work with behaviors?
By 'custom callbacks', I mean the functionality where I could:
- take an object %object
- add to it behavior fooBehavior
- call %object.do_this_thing()
- handle the call in fooBehavior::do_this_thing()
I noticed in the beta that if there was no object::do_this_thing() defined, the behaviour would still handle the call, but after this happened a number of times, TGB'd crash. The solution was an empty object::do_this_thing() function and all was nifty.
In 1.5 release, there's a warning if object::do_this_thing() is not defined, but no sign of attached behaviors receiving the callbacks even if object::do_this_thing() is defined.
The Behavior examples seem to look for an attached behavior of a specific type and call things like health/damage calls directly against the behavior. I appreciated not having to check for a fixed behavior type, but rather letting any attached behaviors with appropriate functions defined react to a call to their owner.
Has this functionality been altered, and/or is there still a way to achieve the convenience of behaviors handling custom callbacks?
If this functionality has been removed without alternative, the best workaround I can think of just now is something awkward like:
function object::do_this_thing(%this) {
//Look for each possible behavior type I could want to attach with an interest in 'do_this_thing',
//and pass the call explicitly on to it...
}
By 'custom callbacks', I mean the functionality where I could:
- take an object %object
- add to it behavior fooBehavior
- call %object.do_this_thing()
- handle the call in fooBehavior::do_this_thing()
I noticed in the beta that if there was no object::do_this_thing() defined, the behaviour would still handle the call, but after this happened a number of times, TGB'd crash. The solution was an empty object::do_this_thing() function and all was nifty.
In 1.5 release, there's a warning if object::do_this_thing() is not defined, but no sign of attached behaviors receiving the callbacks even if object::do_this_thing() is defined.
The Behavior examples seem to look for an attached behavior of a specific type and call things like health/damage calls directly against the behavior. I appreciated not having to check for a fixed behavior type, but rather letting any attached behaviors with appropriate functions defined react to a call to their owner.
Has this functionality been altered, and/or is there still a way to achieve the convenience of behaviors handling custom callbacks?
If this functionality has been removed without alternative, the best workaround I can think of just now is something awkward like:
function object::do_this_thing(%this) {
//Look for each possible behavior type I could want to attach with an interest in 'do_this_thing',
//and pass the call explicitly on to it...
}
#2
07/16/2007 (3:39 pm)
Indeed, this appears to be the case in 1.5 release, distinct from what I've observed in the betas. It's also what I'm currently doing as per my alternative in order to keep moving forward. What I'm interested to know is whether the removal of that convenient functionality was intended and that there's no similarly functioning option - I found it was a very handy Behaviors aspect which made prototyping things smoother. If behaviors need to know what other behaviors they might possibly interact with to be able to do so, then the agility of Behavior mix & match & combination experiments is quite watered down.
#3
Maybe if I understood better what you were doing with these behaviors I could offer another alternative... Are there a lot of overlapping/similar methods in different behaviors?
(btw, the crash was probably because the console filled up with too many warning/errors from the method being undefined for the object)
07/16/2007 (4:00 pm)
It doesn't seem like a functionality that would be intended. Multiple behaviors can have methods with the same name (for example, onCollision), though, so I'm not sure being able to call do_this_thing() without first getting a specific behavior is the most robust/modular approach.Maybe if I understood better what you were doing with these behaviors I could offer another alternative... Are there a lot of overlapping/similar methods in different behaviors?
(btw, the crash was probably because the console filled up with too many warning/errors from the method being undefined for the object)
#4
Multiple behaviors can indeed have the same callbacks/methods; if I wanted to add more than one behavior to, say, a scene prop, and have them all respond to on_trigger() or on_destroy() to create a complex/multipart outcome, it was as easy as adding behaviors with the appropriate callback supported. Neat & efficient!
Replacing a healthBehavior which handles on_damage() in a basic way with healthAdvancedBehavior which handles on_damage() for more complex objects didn't require returning to the code to allow for another behavior to be accounted for, or knowing in advance what kind of health handling the object being hurt had.
Now, the indication seems to be that this agile utility wasn't a considered part of the brilliance of Behaviors, and while one can maybe add (ceiling) behaviors to an object, they can't then expect those to be able to interact freely with (ceiling) other behaviors, but rather need to be hardcoded for every possibility outside certain predefined and limited options.
I wonder at how it can be considered a more modular approach to have the modules unable to interact without hardcoded passthought channels having to be established for each and every custom callback?
The apparent removal of this functionality isn't a showstopper for me, I've already worked around it as described where needed to get my project mostly functional again in 1.5 release. It just seems a shame to lose what I found to be a positive prototyping/agility feature, and have to cut back/slow down toward more simplex/old fashioned options.
07/16/2007 (5:34 pm)
The crash I experienced was certainly not due to console spam, it was as I described in my first post. While it's possible some buffer somewhere was filling up and bombing, it was not via anything visible to the console.Multiple behaviors can indeed have the same callbacks/methods; if I wanted to add more than one behavior to, say, a scene prop, and have them all respond to on_trigger() or on_destroy() to create a complex/multipart outcome, it was as easy as adding behaviors with the appropriate callback supported. Neat & efficient!
Replacing a healthBehavior which handles on_damage() in a basic way with healthAdvancedBehavior which handles on_damage() for more complex objects didn't require returning to the code to allow for another behavior to be accounted for, or knowing in advance what kind of health handling the object being hurt had.
Now, the indication seems to be that this agile utility wasn't a considered part of the brilliance of Behaviors, and while one can maybe add (ceiling) behaviors to an object, they can't then expect those to be able to interact freely with (ceiling) other behaviors, but rather need to be hardcoded for every possibility outside certain predefined and limited options.
I wonder at how it can be considered a more modular approach to have the modules unable to interact without hardcoded passthought channels having to be established for each and every custom callback?
The apparent removal of this functionality isn't a showstopper for me, I've already worked around it as described where needed to get my project mostly functional again in 1.5 release. It just seems a shame to lose what I found to be a positive prototyping/agility feature, and have to cut back/slow down toward more simplex/old fashioned options.
#5
Now it looks like it would be necessary to derive all buttons from a particular class, and have basically a long switch statement including every type of button style, which would have to be modified every time a new one was added. This is a big step backward in modularity.
Was there a significant stability reason that behaviors were restricted this way, or was this the original design? And particularly, is there a way to re-enable the beta-style behaviors in the source code?
07/17/2007 (3:10 pm)
This certainly limits the utility of behaviors - for instance, I had previously set up a custom sceneobject-based button system using multiple behaviors, and because of the beta functionality, was able to set it up in a very modular way, so that a new type of button style could be created in a few minutes, without altering the core code.Now it looks like it would be necessary to derive all buttons from a particular class, and have basically a long switch statement including every type of button style, which would have to be modified every time a new one was added. This is a big step backward in modularity.
Was there a significant stability reason that behaviors were restricted this way, or was this the original design? And particularly, is there a way to re-enable the beta-style behaviors in the source code?
#6
www.garagegames.com/mg/forums/result.thread.php?qt=64862
07/17/2007 (3:15 pm)
For the sake of reporting, is this similar to what you are experiencing?www.garagegames.com/mg/forums/result.thread.php?qt=64862
#7
07/17/2007 (3:51 pm)
Yup, sounds like it. I'd have to run my own checks to confirm it still works from outside a behavior's code - since most of my functionality is in behaviors, I've not encountered that side.
#8
07/17/2007 (4:10 pm)
I just confirmed that you can call it on objects from outside the behavior without a problem, it's from within behaviors that is the issue. It's been reported and will hopefully be fixed soon. :)
Torque Owner Melissa Niiya