adding a behavior to a new sprite.

#1 ps. just of note. the only reason I know it was not working (as of yet, I am sure it is something very small) but there should be an onupdate I could read, oh and the object should be moving but it is not.

#2 I think "_behavior0" only works when inside the datablock of the object. try %this.enemy._behavioir0 = whatever.

Also, onUpdate is disbaled on behaviors due to the performance hit it causes. You can re-enable it (at your own risk) by calling enableUpdateCallback on the behavior (for example, inside the onAdd function, %this.enableUpdateCallback(), %this referencing the behavior).


I might be wrong though - hopefully someone else will be able to assist.

#3 sure thing. On update isn't that taxing if you do not make it taxing. I use it quite frequently on many objects and I have had no issues.



Thanks, will try that but I think to use addBehavior() would be the right call, it just getting it write. As I say I did try %this.addBehavior(genericBehavior.createInstance()); in the same function as the creation of the new object, but that did not work. As I believe I am sure it is something very small I am doing wrong.



Cheers.

#4 You can put %this.addBehavior(genericBehavior.createInstance());
in the onAdd() callback function of the enemy. I do this all of the time. Its true that you want to limit overhead in onUpdate() as much as possible.

#5 ok great, so should onAdd() be in the behavior I am adding? No worries will check. Thanks!

#6 I would put it in the enemyClass. I don't know how it would work in the behavior.

#7 well,
my ideas was, that I have an object to simply act like a trigger. when collided with by the player, the new enemySprite is created. It was in this fucntion, createEnemy() that I had placed the addBehavior. I am thinking that I need to put the addBehavior() in the onAdd() function?

#8 Ren, It should go like this:

Player hits trigger -> trigger callback creates a new object --> add behavior to new object in the new object's onAdd callback.

#9 and that onAdd exists with in the behavior itself, the one I want added to new object?

#10 No, it's at the object level. The onAdd for a behavior can't possibly be called before that behavior is added.

Let's say you have an object "Enemy" that you you want to add "EnemyBehavior" to.

trigger::onTriggerEnter
{
createEnemy()
}

Enemy::onAdd
{
Enemy.addBehavior(EnemyBehavior)
}

Note, that is not real code.

#11 so sorry but I am unsure where the

Enemy::onAdd
would be.

Is it in a class file.
So a simple file say enemyClass.cs that is called up in the game.cs?

#12 Here's some quick programming info:

Object::onCondition (for example) can be thought as a "callback." It's technically still just a method, but it's a method that (typically) gets called by other objects, not the object itself. Callbacks are when a certain condition is met and the engine (or other objects) call(s) all the objects that have that callback and tells them to do their method.

The engine, in this case, will automatically call "onAdd" for any t2dSceneObject that is added to the scene graph. If an object has no ::onAdd() method, then it's simply skipped.

It doesn't have to be defined anywhere, so you can simply create a Enemy::onAdd wherever you want (though, there are smart and dumb places to put it)

Inside that function you perform whatever functions you want to, keeping in mind that it will be called once per object at creation time. It's a great place to add behaviors, initialize variables, and set positions for objects. Behaviors themselves have "::onAdd" that you can access and manipulate. In the case of Behavioirs, onAdd is executed whenever the behavior is assigned, rather than when the object is created.

EDIT: IMPORTANT NOTE

onAdd() will always pass the %this variable, which references the object that was added. When you do myBehavior::onAdd(%this), the "this" will refer to the BEHAVIOR, not the ENEMY. To access the Enemy from a behavior method (onAdd, onRemove, onUpdate etc.), use %this.Owner.


Where it gets fun and tricky is when you overload the function with a new function. For example, you can define Enemy::onAdd(), but then you decide to derive your enemies from your Enemy Class into two categories: trolls and orcs. When you define Troll::onAdd(), it will perform THAT function instead of Enemy::onAdd().


In summary:

At any time you could re-define what Enemy::onAdd does, and if it never existed in the first place, it's easy to just put it where it's logical (in your Enemy.cs file, objects.cs file... whatever CS file you think it should go in.)

If you opt to organize everything "Enemy" related in an Enemy.cs file, make sure you exec("./Enemy.cs"); somewhere BEFORE you plan to access it (for example, in game.cs)

#13

Quote:
so sorry but I am unsure where the

Enemy::onAdd
would be.

Is it in a class file.
So a simple file say enemyClass.cs that is called up in the game.cs?

It's hard because you have your own terminology but ya, that seems like it should work. As long as enemyClass.cs is exec'd from game.cs (or somewhere) and the enemy you created had a class of "Enemy", you could put the following in enemyClass.cs:

function Enemy::onAdd(%this)
{
  //add your behavior here
}

#14 so essentially as long as the onAdd() is always in existence it will work. Right?

#15 Assuming that it's actually being executed and "found", then yes.

#16 great. thanks guys, that helps a ton.





cheers.