KX_GameObject is dirty....

104 items actually. (blender 2.65)

why not there classes ? is more complicated to do than a method, or is just the “standard” ?

action can be much more complete inside a class

what is the sense of obj.state written in the actual way ?

what do attDict ? (can be used as another dictionary?)

Attachments


If I answer your questions In order, classes are only useful when you want to collect methods and data together that are responsible for similar tasks
The State of the object is used for the logic brick system, for changing the logic state.
Attrdict is used for direct access to the objects dictionary. This allows you to use setdefault and other dict methods that are useful.

I agree that there are rather too many attributes and methods. Having thought about it, it would be a good idea to isolate them with respect to their purpose in a component like design. After my work on a python driven gameloop for the engine is completed, further separating game objects using components might be a good idea.

Sent from my Nexus 5 using Tapatalk

in my opinion is to do
is not imaginable make anything more from -> obj.doSomething()
all doable in this way there already.
each name become ever more long for methods and without sense for attribute.
while a “class specialized” ,can have name obvious and short and with all methods/attribute that need.

using the state at the botton right (in my mind is 10)
print(own.state)#>>524288 O_O’

assign a new state should be also more funny .
if is in python should be usable from python otherwise can have a name a bit more specific (obj.state_brick or something)

States are very useful with python. You can easily go to the next state with:

own.state *= 2

Or go to the previous state with:

own.state /= 2

Or go to a specific state, for example state 10:

from mathutils import pow
state = 10
own.state = pow(2, state)

Just for your info. But I agree working with bits is a bit odd.

thanks Raco for the tips

anyway is not just odd

can have sense a thing like this 60/70 years ago with CPU made with wood
when draw some pixel on a monitor was already a miracle

so, write :
obj.state = 1024

can give visible advantage , but MUST be written directly the integer

otherwise “import math” can due the combustion of the wood’s cpu :smiley:

:wink:

Some methods I would agree are irrelevant. Namely, the setter and getter methods for position, velocity, orientation and angular. Removing these would remove eight unnecessary values.
Other methods could be made into attributes for ease of use (/aesthetics) such as enableRigidBody, suspendDynamics and so forth. I would also remove rayCastTo() as it could easily be reproduced with a Python method.

I’m going to remove them in my build and see what it looks like.

That doesn’t make a lot of sense. It’s faster to write an int anyway (you don’t have to use math.pow, it’s an alias for x ** power)

I’m pretty sure that using a binary mask for own.state has nothing to do with performance. It’s just a nice way to specify multiple states with a single variable, and avoid an additional structure in C++ (which would require an additional allocation, and subsequent management).

Although, in Python, a list of active states would be more intuitive (for most users).

Note: There are defined constants for each state, so you don’t have to do the math yourself.

I state the speed simply to deny the argument on behalf of a more “pythonic” data structure, such as a lit.

Some methods I would agree are irrelevant. Namely, the setter and getter methods for position, velocity, orientation and angular. Removing these would remove eight unnecessary values.
Other methods could be made into attributes for ease of use (/aesthetics) such as enableRigidBody, suspendDynamics and so forth. I would also remove rayCastTo() as it could easily be reproduced with a Python method.

The setter and getter methods are only inside because of backward compatibility.
May be we can remove them in Blender 2.7x.

Ton Blender roadmap – 2.7, 2.8 and beyond

For 2.7x projects we will allow forward and (minor) backward compatibility breakage. That means that by default, the 2.7x .blend files don’t have to read reliably in 2.6x or older. Backward compatibility stays crucial though, and should only be acceptable for big and important improvements. Changes can also be including a revision of UI layouts, naming of options, themes, and shortcut defaults.
However, for as long as we add breakage in Blender 2.7x versions, we could also try to keep the last 2.69 release updated with essential fixes.

I would love if they added more python handels for rigid body joints,

Like
own.rigidBodyJointTarget
own.sixDegreeOfFreedom= 4 vectors, travel xyz min, travel xyz max, angle xyz min, angle xyz max and a linked collision Flag.
own.rigidBodyJointOffestVectors

These would allow for percision control of mechanical systems, and physical controled motion state triggering, so we could make a euphoria type control for belender, controlled via external physics

I would love if they added more python handels for rigid body joints,

Like
own.rigidBodyJointTarget
own.sixDegreeOfFreedom= 4 vectors, travel xyz min, travel xyz max, angle xyz min, angle xyz max and a linked collision Flag.
own.rigidBodyJointOffestVectors

These would allow for percision control of mechanical systems, and physical controled motion state triggering, so we could make a euphoria type control for belender, controlled via external physics

The KX_GameObject currently does way to much things on its own. It looks like a cluttered facade for several different things.

I think it can be split into several other objects as part of a composition.

E.g.
Not all KX_GameObject have a mesh. No need to always have a mesh-attribute.
Not all objects are physics objects no need to have all this physics related attributes all the time.

How about this?
KX_GameObject is a container with:

  • KX_GameObject.logic (e.g. controllers, sensors, actuators, state, propertyNames)
  • KX_GameObject.world (e.g. worldPosition, worldOrientation, scene, getVectTo, parent, groupMembers)
  • KX_GameObject.mesh (if it has a mesh, visible)
  • KX_GameObject.font (e.g. text)
  • KX_GameObject.physic (e.g. applyForce, linearVelocity, restoreDynamics, mass)
  • KX_GameObject.animation (e.g. playAction )
  • KX_GameObject.render (e.g. occlusion)

If the sub-object does not exist the requested behavior is not supported (e.g. applying velocity to a static object).

To be honest: rayCastTo and getVectTo do not really belong to a single KX_GameObject. The KX_GameObject can be an argument to a function (see mathutils).
SendMessage at KX_GameObject is pretty strange (it belongs to bge.logic) as the controller sends the message with an optional object as argument.

Hi Monster, do I understand correctly that you’re suggesting this kind of structure? For example:

own = cont.owner
own_position = own.world.worldPosition

If we discuss this with authenticity, then I would recommend that world is not the home to transform information.
A GameObject is essentially an entity which occupies a point in the game world, with a transformation associated with it.
This belongs fundamentally to the GameObject.

I would agree with that. And wouldn’t like all attributes to be separated like that. All mentioned are unique in relation to the owner, except ‘scene’ maybe.

EDIT: Don’t know why I quote replied…

All these attributes do belong to the GameObject, however not all of them are actually useful attributes of certain objects. If an object were used only as a sensor, it wouldn’t need majority of that dictionary, nor would changing a lot of it actually do anything… right?
I am not sure if this would show a performance change, as it would not need to calculate all of those (does it calculate everything in the dictionary every frame?), but if it doesn’t it would still be nice to categorise these.
If there is no performance gain, then I think the different classes would just create a mess for peoples’ code (having to change all of their game object scripts would discourage people from using new versions of Blender, which is why many people still use 2.49)… maybe it could be accessible in the new method AND the old (current) method. For example:


own.physics.setLinearVeloctiy(...)
would be the same as
own.setLinearVelocity(...)

Redundant, however I think it is much more user-friendly.

Or maybe it is a bad idea altogether

I wouldn’t agree with this. A GameObject (which should constitute the base class for all KX_ types that are involved in the scene if we are using inheritance) has only its transformation. All an “object” needs to exist in the scene is its transformation.

A Physical object requires a Physical mesh to interact with collisions. A rendered object requires a Render mesh to interact with lighting/shading. In modern engines, entities support composition (giving the entity a RenderComponent for rendering rather than subclassing IRenderableEntity for example) to allow for more flexible combinations of objects.

I don’t believe that the BGE will go as far as implementing component/composition under the hood. There’s too much code to change. But It can maintain the Python interfaces in this manner with little difficulty (which is what most users will ever see).

If these changes were made, they would be done for 2.70 which will break many things anyway.

The names where just some very rough suggestions to express what I mean. I do not like them that much. I think you already got the idea of an option to separate the “concerns” of the KX_GameObject.

Indeed it does not need to be changed under the hood (but would provide some benefits too). It is a suggestion to move away from the cluttered class by refactoring. Even a new class would be fine. This way we could keep the old KX_GameObject for a while.

Just ideas :wink:

I like these ideas.

For example, worldPosition -> KX_GameObject.worldPosition, rather than KX_GameObject.world.worldPosition. Position, orientation, scaling should be top level attributes since they are the most fundamental properties of a KX_GameObject, assuming as agoose stated, KX_GameObject is an entity occuping space (kinda like the real world :p).