Perhaps the title of my thread is a bit confusing.
Let me try to explain what I mean.
I have a simple scene witch contains :
a)the hero object, the ground object and two empties in layer1 and
b) the enemy object in layer2
When the game starts each empty adds a copy of the enemy from layer 2 using the add object actuator.
These two copies of the enemy object are identical and have exactly the same properties.
When my hero hits the enemy, the enemy’s life decreases by an amount.
The problem is that when I hit one of the enemies,the other enemy’s life decreases too.
Is there a solution?
As life indicator I use a simple plane above the enemy with a shape actuator,
The plane copies the property life of the enemy object into its local property called lifeframe
The lifeframe property defines the frame of the shape action.
Eg for life 100 , lifeframe becomes 100 which applies to a full plane shape in the shape actuator plane
for life 50 lifeframe becomes 50 also which applies to a half plane (half life left) in the shape actuator of the plane.
The problem is that when I hit the first enemy, life indicator changes in both enemies,
when I hit the second enemy nothing happens to any of the life indicators.
How exactly is the life property modified? Are you using a collision sensor on the enemy itself to detect damage, or are you sending messages to the enemy with the message actuator?
Please note: when you’re creating multiple instances of the same object with the add object actuator, you’re creating objects that carry the same exact name, so all messages sent to “Enemy” will be received by every enemy that was spawned by the add object actuator.
Hero wields a sword(it has a property weapon) and when the sword collides with the enemy, life property of the enemy decreases. So for the enemy is:
Collision sensor (property weapon )—AND—Property (life,add -5)
For the life indicator is:
Always (true level triggering activated—AND—Property (Copy,Prop:lifeframe,OB:enemy,Prop Life)
As I said: The spawned objects have the same name, OB:enemy is referencing more than just one enemy object, and that could cause the kind of “information crosstalk” that you’re experiencing.
That could be done through python, by changing the name property of every game object spawned, right after creation.
Luckily for you, it’s not something that has to be done, as long as you make all your properties independent.
Don’t do the whole “Copy property” thing: You already have a life property that is specific to each and every enemy, so theres no need to create the lifeframe property, instead you should just use the one you already have -> which is the life property itself.
Layer1 consists of the hero mesh and two empties that act as spawn points.Hero has a hero property.
Enemy with life indicator is at Layer2.Enemy has a life property and life indicator has a lifeframe property.
Press P to play and move around with the arrow keys.
When hero collides with an enemy, the enemy’s life decreases by 10 until it reaches 0.At the same time life indicator’s length reduces according to enemy’s life.
When life reaches 0, enemy dies (end object).
Practically when hero collides with the left enemy both life indicators react and when hero collides with the right enemy no indicator reacts. If left enemy dies, the right enemy’s life indicator works normally.
Ok, I think I narrowed it down to the Shape Action actuator:
The code that’s using own.parent to copy the property works fine, and solves the problem that the property copy actuator was unable to solve (differentiate between two instances with the same name). I checked the memory address of each health bar, along with what happens with their lifeframe property when the enemy takes damage, and they’re both different when own.parent is used in a script to make the copy.
So, it’s not the underlying numbers (provided you’re using the script) that are going wrong here: the issue seems to be with the Action actuator, or the Action sequence itself.
This is something that you could explore further, in order to find exactly what that could be, but for now, you can use the example I made for you (attached); it uses regular IPO curves, along with the IPO actuator, and it seems to work fine.