Several objects sharing the same script

Good day, ladies and gentlemen!

I am working on a simple space game in which the player navigates an asteroid field while avoiding and shooting down mines that are chasing the player’s ship.

I have come upon a problem where the mines all simultaneously explode the moment one of them does so. I am using a Near sensor that runs my Python script when the player’s ship gets close enough.

Another problem I am having is with the ship’s bullets. When fired I also parent a lamp to the bullet (via Python, I came across the same problem when parenting the lamp ordinarily) that then follows the bullet and nicely lights up asteroids and other objects that it passes by. My problem here is that whenever I fire another bullet the lamp from the previous bullet disappears so the only bullet that actually illuminates anything is the one fired last.

How would one be able to fix these problems? Any suggestions are much appreciated.

Have a nice day.

EDIT: My problem turned out to be that my explosion mesh was too big when it spawned and as such triggered other mines if they were too close to each other. Big thanks goes to Monster for his help!

Be aware each lamp need processing power to process shading and you have limited number of lamps (8 at each layer).

The problems with your mines sound like a design issue in your logic. You should provide more details on this. Most-likely it is something really simple.

I had no idea Blender was limited to eight lamps per layer, thanks!

It would appear that both my mines are assigned to the same “missile”-variable (I was intending to make a homing missile at first and haven’t renamed the variable yet) in the same instance of the script. When I printed the name of the owner of the controller when the object got hit it printed the name for both of my mines, even though I only hit one.

My code for the mines are below.

import bge

def main():
    cont = bge.logic.getCurrentController()
    missile = cont.owner
    scene = bge.logic.getCurrentScene()
    target = scene.objects["PlayerShip"]
    touch = cont.sensors['Touch']
    hit = touch.positive
    movSpeed = 50.0
    damage = 1.0
    if 'hp' not in missile:

    targetVector = missile.getVectTo(target)[2]
    if targetVector[0] < 0:
        missile.applyForce((-movSpeed, 0, 0), True)
    if targetVector[0] > 0:
        missile.applyForce((movSpeed, 0, 0), True)
    if targetVector[1] < 0:
        missile.applyForce((0, -movSpeed, 0), True)
    if targetVector[1] > 0:
        missile.applyForce((0, movSpeed, 0), True)
    if targetVector[2] < 0:
        missile.applyForce((0, 0, -movSpeed), True)
    if targetVector[2] > 0:
        missile.applyForce((0, 0, movSpeed), True)
    if hit:     #hits object
        if 'hp' in touch.hitObject:
            touch.hitObject['hp'] -= damage
        explosion = scene.addObject("MineExplosion", missile)
def start(missile):
    missile['hp'] = 1.0
    missile['hostile'] = True

EDIT: I made my first mine (model, physics, logic bricks and wrote the code for it) and then simply made a copy of that. Would this link the two sets of logic brick in such a way that it could cause my problems?

From what I see at the above code it defines an individual behavior of the “missiles”. I can’t see any interconnection between several objects using the same code.

The trigger to end the “missile” depends on the sensor called “Touch”. This is an individual sensor at each object.
Your variables are function local and will not survive the return from the function. They can’t be the reason either.

Could it be that something activates the “Touch”-sensors of all “missiles”?

Remarks (outside from the request:

  • the property “hostile” is not used.
  • the property “hp” (of the missile" is not used)
  • movSpeed is hardcoded (better read a property with missile.get(“movSpeed”, 50.0) )
  • damage is hardcoded (better read a property with missile.get("damage ", 1.0) )
  • “hit” is used exactly once. So you can simply write touch.positive.

The code mixes several independent tasks:

  • target identification
  • target tracking
  • hit processing
  • damage calculation

You will not have a problem to do it that way. But it might become an issue when adding more and more complex behavior.
I suggest to switch to Module mode and create at least one entry point for each single task.

It allows you much more freedom in your design and you can reuse it for other similar objects:

  • individual target detection (e.g. at missile start)
  • individual target tracking (e.g. no tracking at all as you would expect from mines :wink: )
  • individual hit-handling.
  • separate damage processing. Your code keeps the damage processing at the rocket. I suggest to inform a central damage dealer about the damage of the exploding missile and other damage maker. The damage dealer calculates and applies the real damage by looking at all involved objects and attributes (damage, protection, armory, shields etc.). This makes it much easier to manage rather than on several individual objects.

I managed to find the problem. After checking which object triggered the touch-sensor for the mine I didn’t shoot I found that it reacted to the explosion from the first mine, but only when they weren’t too far apart from each other. It turned out that the problem was that my explosion-mesh (which I scale up and then down using another script) was too large at first so the very frame that it spawned it touched the other mine. The reason I scaled the explosion instead of simply using an animation is that the game has been meant as a programming exercise so I have been trying to use as much programming as possible. I’m thinking that it’s time I sit down and take a proper look at animation in Blender.

Thank you very much for your help as well as the remarks on my code. I appreciate it greatly and will definitely do my best to learn from it and improve my code.

Once again, thank you very much and have a lovely day!

This side effect could become quite handy if you want to process the chain reaction of a mine field ;).

Indeed, that could be quite interesting.