Proposal: Modify KX_Scene.addObject to accept Vectors to describe position

Game Engine Game Engine Support and Discussion
1

Problem:
Currently, KX_Scene.addObject takes three arguments:

  • object (KX_GameObject or string) – The object to add
  • other (KX_GameObject or string) – The object’s center to use when adding the object
  • time (integer) – The lifetime of the added object, in frames. A time of 0 means the object will last forever.

Although other is only used as a positional argument (i.e., where the new object will be added) a Vector cannot be used.

Drawbacks:
The user must maintain a “spawn object” even if they intend to alter the new object’s location “manually” using Vectors.
Not allowing a Vector to be used as a positional argument seems rather counter-intuitive.

Proposal:
Allow Vectors to be passed in as the positional argument other.
Possibly, make other an optional argument. If no position is given, the new object will be added at the origin of the scene.

Benefits:
Eliminates the need to maintain a “spawn object” in your scenes.
Brings this method in line with the rest of the API, where KX_GameObjects and Vectors can occasionally be used interchangeably to describe positions (see KX_GameObject.rayCast)

2

I’m all for it.

3

I agree. Rarely do you want an added object to actually take the scale of other, so having the ability to simply add an object using a world position would be a good idea, I think.

4

Yes, in this sense this behavior doesn’t even fit the description in the API. It says: ‘object’s center’, which implies location inheritance only.

5

The addObject() method uses the whole transform matrix of the other object. I think there is a patch floating around that allows passing in a matrix instead of an object.

6

(side note) sens.hitPosition, and sens.hitNormal are lists, not vectors is there a reason they are not vectors?

7

Thy were simply not updated. This should be part of an API consolidation. This is a different topic.

Finally I do not care if addObject grabs the transformation from another object, uses the identity matrix, grabs the transformation from the original object, accepts an explicit transformation matrix and/or builds the matrix from given optional transformation parameters.

8

In the other thread it showed you should care at least a bit. With Python’s ‘addObject’ and the Add Object Actuator users should be able to add objects without having to rely on the transformation of other objects. The ‘other’ parameter should then be a Matrix, and by default an empty Matrix.

9

I agree, this should be added.

10

@gruntbatch: what would you prefer? Location (Vector) or transform (Matrix)? I personally would prefer a transform matrix.

11

I think that the easiest-to-use approach would be a method that does away with accepting an object for any type of transformational information, and instead accepts position, scale and rotation as individual, optional arguments. If any are left out, it defaults to the new object’s current position/scale/rotation.
However I think that a method that takes a pre-built transformation matrix would be much easier to implement.

12

There’s a patch of mine somewhere on the tracker with this implemented, though it doesn’t provide a default matrix as yet