addobject problem for an emitter object

I’m having an issue in the addobject function where it expects an object(not a vector as I am attempting)…
you can see below in the last line of code before the function is called…I already wrote this from scratch about 5 times this week…and keep having issues…(sad face)

import bge
import random

cont = bge.logic.getCurrentController()
own = cont.owner
scene = bge.logic.getCurrentScene()
obj = scene.objectsInactive
part_fire = obj['part_fire']

def get_vert_pos(vert):
    mesh = own.meshes[0]
    verts = mesh.getVertexArrayLength(0)
    if vert in range(0, verts):
        temp = mesh.getVertex(0,vert)
        vert_pos = own.worldOrientation * temp.getXYZ()

def spawn_random():
    vert_vec = get_vert_pos(1)#test...later can increment or cast a random int in range
    #here is a timing system for spacing before adding the particle
    scene.addObject(part_fire, vert_vec, 50)# 'vert_vec' field expects and can I get around this?

I also noted that an emitter must have at least one face before it takes any vertex into account…I assume verts that do not make up a face get culled…

I assume verts that do not make up a face get culled…

Correct, lone vertices and edges are ignored

How to position it? Just create it, then move it:

new_obj = scene.addObject(part_fire, any_obj, 50)
new_obj.worldPosition = vert_vec

I’ll also point out that you’re missing the translation part of the transform from the get_vert_pos function. Try moving the object away from the world origin…

Thanks again sdfgeoff(der am besten schokolada komt aus AMERICA! :P)…sorry I assume germany?

Ah yes. just using the worldOrientation ATM…this is my basis to build upon…I am just trying to get it barebones working…not that I noticed that… :slight_smile:

you can just:

newobj = scene.addObject(“myname”,None,456)
newobj.position = …

the problem (i believe, not sure though) with scene.addObject(“myname”,“randomObj”,456) is that the new object has the scaling of the “randomObj”

Be aware that the .position attribute has been deprecated for a long time. Use .worldPosition or .localPosition instead. It will be removed shortly.

Very close - next country over (well, under actually - other side of the Bodensee to Germany). Despite being in a German speaking area, mein deutch ist kaput…

Greetings to the both sides of the Bodensee ;).

Another option (just in case you get conflicts with physics):

Have one inactive object to emit (particle).
Have one object that has the mesh (mesh provider).
Have one object that emits objects (emitter).
Have one object that runs the logic (adder) - can be one of the above or a separate object.


  • analyse the mesh of the mesh provider to get the vertex positions.
  • translate the vertex positions into scene scene space (world coordinates)
  • move the emitter to one of the positions
  • add the particle inheriting the emitter’s transformation

This let the particle spawn at the target location rather than somewhere in space where other objects might collide with.

Remarks: I strongly advice to be more careful with variable names. Cryptic abbreviations do not support understanding the intention of the code.

For example “obj = scene.objectsInactive” is pretty irritating.

I suggest to write “templates = scene.objectsInactive”.

That means the the following code reads like this: “particle = templates[‘part_fire’]” and “scene.addObject(particle, emitter, 50)”.

Glad to be among neighbors :slight_smile:

I never use ‘.position’, and am aware it is depreciated :slight_smile:

I am honestly just trying to get even the basics working at this point…I am not a strong coder…and just picked up python recently…most of my old tricks just don’t work :frowning:

I am also not too keen on having a lot of helper objects. I really just want to set this up as a template that I can attach to any object and use specific verticies to emit the particles…the particles themselves will have their own attributes and methods to handle their movement and animation…
I am still fighting with this…I have been working on this off and on and thought I had it working at one point…but let me fight with it a day or so and I will come back if I need more help…or if I get good results…

this is something I would like to release to other users once I get it working…fingers crossed :slight_smile:

ok, so I have it working and working fine…mostly…there is always something :slight_smile:

I have been brainstorming, trying to figure out a way to stop the particles to not stay with the vertex…e.g. be spawned at the vertex, but not follow the vertex…
it mostly stems from two parts of the code…


particle = scene.addObject(part_fire,own,120)#needed since I cannot add and object to the scene at a vector location
#only an objects location   :P
particle.worldPosition = vec_for_vertex(1)# here is the second clearly sets the position to the vertex every call

I want to set it to that location at it’s spawn time(addObject) by using a variable in it’s properties(bool) and if it is false
set it to that location…then switch it to true…
I was just wondering if there was a better way…or if someone has a better idea…I’m thinking it may be messy…

EDIT: I just tried it before posting this…and it seems to retain whatever value across all particles(they all maintained a ‘False’ value)…so I scratched that idea…any ideas?


I was thinking about this for a few more minutes and decided maybe just using a random int would be fine…

if own['interval'] > own['stepping']:
        for i in range(0, verts):
            particle = scene.addObject(part_fire,own,120)
            particle.worldPosition = vec_for_vertex(random.randint(0,i))#test...later can increment or cast a random int in range
     own['interval'] = 0

*don’t know why when I paste code the formatting gets crazy sometimes…

works ok…I would still prefer them to not follow the object though…in the case if a fireball for instance…it would look better to have them trail behind and fade…

Unless you parent the particles to another object, they are independent from any other object. This means since creation time, they will stay where they are and just do there own motion (e.g. from physics engine, or logic).


This let the particle spawn at the target location rather than somewhere in space where other objects might collide with.

So long as you move them before the logic part of the gameloop ends, the physics engine will never know where they were during the logic tick I have abused this a couple times to make various operations easier: move the whole caboodle to the origin, do your magic, move it all back, and the physics engine (and the user) never knows what happened…

This is good to hear. I never tried to find out what happens when an object gets created inside of a physics face (before ending the frame).

you are correct…I made a simple mistake…they do not seem to care for vertex animation though…I tan/ping pong scaled an object (up and down) and the verts still emitted from the same places…

also adding the object inside the loop was a silly mistake…I now add them before and just set the position in the loop.