Warning: Behavior Timers
by Craig Perko · in Torque Game Builder · 03/11/2008 (12:08 pm) · 8 replies
Since this is the first time I'm really using behaviors, I decided to make a game coded entirely in behaviors (and the level editor).
What I've discovered is that the "onBehaviorAdd" function can produce some REALLY WEIRD BUGS if you're not careful.
For example, the first time I created an attack behavior, I had it clone an existing object to use as an attack, send it off in a direction, and then schedule it to be destroyed after a set period of time. It also scheduled itself to attack again in a few seconds.
However, this ran IN THE LEVEL EDITOR. Meaning that the object in the level editor - the thing I click, resize, move around, delete - it was cloning objects while I was in level edit mode.
It didn't deign to run the rest of the script: the objects didn't move and - more importantly - they didn't delete themselves.
I quickly piled up hundreds of cloned objects before I could figure out what was happening. These are permanent objects that are added to the level file. I had to go in and delete two megabytes of definitions for the same objects, over and over.
Obviously, "onBehaviorAdd" isn't really where I wanted that call. I'm using "onAddToScene" now, which doesn't appear to have the same problems.
But, man, that's a weird, weird result.
It did get me to thinking, though: you could abuse this to create level creators. Behaviors that would build levels for you. Since they're building them in the level editor, you could save them and edit them...
It's an interesting idea, but a very confusing bug.
-Craig
What I've discovered is that the "onBehaviorAdd" function can produce some REALLY WEIRD BUGS if you're not careful.
For example, the first time I created an attack behavior, I had it clone an existing object to use as an attack, send it off in a direction, and then schedule it to be destroyed after a set period of time. It also scheduled itself to attack again in a few seconds.
However, this ran IN THE LEVEL EDITOR. Meaning that the object in the level editor - the thing I click, resize, move around, delete - it was cloning objects while I was in level edit mode.
It didn't deign to run the rest of the script: the objects didn't move and - more importantly - they didn't delete themselves.
I quickly piled up hundreds of cloned objects before I could figure out what was happening. These are permanent objects that are added to the level file. I had to go in and delete two megabytes of definitions for the same objects, over and over.
Obviously, "onBehaviorAdd" isn't really where I wanted that call. I'm using "onAddToScene" now, which doesn't appear to have the same problems.
But, man, that's a weird, weird result.
It did get me to thinking, though: you could abuse this to create level creators. Behaviors that would build levels for you. Since they're building them in the level editor, you could save them and edit them...
It's an interesting idea, but a very confusing bug.
-Craig
About the author
#2
Anyhow, the only reason I used it is because that's where people seem to do keybindings, so I just kind of lumped everything vaguely initialize-y into it.
-Craig
03/11/2008 (1:55 pm)
But what order are they added in? If I add fruitBehavior, and it automatically added pickupBehavior, then I added pickupBehavior (with a specific set of parameters, such as weight), would that cause a conflict? Rather, would it ignore the second pickupBehavior?Anyhow, the only reason I used it is because that's where people seem to do keybindings, so I just kind of lumped everything vaguely initialize-y into it.
-Craig
#3
03/11/2008 (2:29 pm)
Think of a behavior instance (I think thats what they are actually called) as a script object with X properties mounted to your object. They run and process independently of everything other than the object they are mounted to. So, since behaviors are treated as different objects, I don't see why you couldn't have two of the same behavior on an object.
#4
-Craig
03/11/2008 (2:52 pm)
That gets tangled... if a character has a "getsXP" behavior, you probably don't want two independent but otherwise very similar behaviors trying to track and spend the character's XP. At the very least, double XP would be an issue...-Craig
#5
In regards to the XP mentioned above, I would probably create an separate xpTracker behavior, but thats just me. If the attribute in the behavior operates as a separate system in itself I tend to split it out. On saying that, I'm new to TorqueScript so take my words with a grain of salt :)
03/12/2008 (7:34 am)
I've had similar timing issues. I've found that it seems safer to put my code in onBehaviorAdded instead of onBehaviorAdd.In regards to the XP mentioned above, I would probably create an separate xpTracker behavior, but thats just me. If the attribute in the behavior operates as a separate system in itself I tend to split it out. On saying that, I'm new to TorqueScript so take my words with a grain of salt :)
#6
03/12/2008 (8:00 am)
Why would it make a difference between Add and Added? Can you explain that to me?
#7
This is important, onSceneAdd/Remove aren't called in the editor, while onBehaviorAdd/Remove are. OnLevelLoaded/Ended aren't called in the editor either
03/17/2008 (12:35 pm)
Http://tdn.garagegames.com/wiki/TGB/Behaviors/CallbacksThis is important, onSceneAdd/Remove aren't called in the editor, while onBehaviorAdd/Remove are. OnLevelLoaded/Ended aren't called in the editor either
#8
03/17/2008 (12:39 pm)
But "onBehaviorRemove" isn't called unless you manually remove a behavior; it makes sense, although I don't like the fact that a timer-driven script can run in editor mode, let alone that it can create objects! 
Associate Phillip O'Shea
Violent Tulip
For example: If you have a collectable object (which can be picked up) you can specify it in a behavior, "PickupBehavior". You can also specify what "type" of object it is in another behavior, lets say "FruitBehavior". You can then do a check in the "FruitBehavior::onBehaviorAdd" function to see if it has the "PickupBehavior" attached to the object, if it doesn't attach it automatically.
Thats how I would use it anyway.