Read Physics type from KX_GameObject #35680

New Issue

Angus Hollands · 2013-06-09T01:38:11+02:00

Angus Hollands commented

2013-06-09 01:38:11 +02:00

%%%Adds a physics_type attribute to KX_GameObject
Adds Physics enums to bge.logic

KX_PHYSICS_STATIC
KX_PHYSICS_ACTOR
KX_PHYSICS_SENSOR
KX_PHYSICS_ACTOR_SENSOR
%%%

%%%Adds a physics_type attribute to KX_GameObject Adds Physics enums to bge.logic KX_PHYSICS_STATIC KX_PHYSICS_ACTOR KX_PHYSICS_SENSOR KX_PHYSICS_ACTOR_SENSOR %%%

Angus Hollands commented

2013-06-09 01:38:11 +02:00

Changed status to: 'Open'

blender-admin commented

2013-06-09 01:38:11 +02:00

#40341 was marked as duplicate of this issue

Mitchell Stokes commented

2013-06-11 04:18:41 +02:00

%%%You've documented the new constants, but didn't document the new KX_GameObject.physics_type attribute. Also, despite the existing inconsistencies, physics_type should probably be physicsType. Can a game object actually have a type of KX_PHYSICS_ACTOR_SENSOR? I'm also not entirely sold on the KX_PHYSICS_* prefix either (it would seem like we'd want to use this for something else), however, I cannot think of a better prefix off hand.%%%

Angus Hollands commented

2013-06-11 21:14:54 +02:00

%%%I've added a new patch with the documentation fixed. I've renamed it to physicsType (not sure why it wasn't before!).
Objects can be ACTOR_SENSOR - this denotes SENSOR objects which detect actors. It could be renamed to SENSOR_DETECT_ACTORS if needs be.%%%

%%%I've added a new patch with the documentation fixed. I've renamed it to physicsType (not sure why it wasn't before!). Objects can be ACTOR_SENSOR - this denotes SENSOR objects which detect actors. It could be renamed to SENSOR_DETECT_ACTORS if needs be.%%%

Mitchell Stokes commented

2013-06-20 05:31:56 +02:00

%%%Can we determine if an object is set to No Collision? It would be nice if this property returned similar results to that of bpy: http://www.blender.org/documentation/blender_python_api_2_67_1/bpy.types.GameObjectSettings.html#bpy.types.GameObjectSettings.physics_type%%%

Angus Hollands commented

2013-06-21 00:35:11 +02:00

%%%Made modifications as requested. Now we don't use the ClientObjectInfo struct, but instead handle the mapping in scene conversion.%%%

Mitchell Stokes commented

2013-07-17 09:07:08 +02:00

%%%I'm starting to wonder if this is something we want to actually have go through the physics module instead of KX_GameObject. Something like:

constraint.getPhysicsType(gameobj)

It's more round-about, but it also keeps physics settings out of KX_GameObject.%%%

%%%I'm starting to wonder if this is something we want to actually have go through the physics module instead of KX_GameObject. Something like: constraint.getPhysicsType(gameobj) It's more round-about, but it also keeps physics settings out of KX_GameObject.%%%

Angus Hollands commented

2013-07-17 21:33:05 +02:00

%%%If that was the case, I'd be much happier if we renamed constraints to physics, because it really is much more than just constraints. I've just had a thought (I'm away from home) in how would LibLoaded objects interact with scene conversion (I presume rarely)?%%%

Angus Hollands commented

2014-04-28 02:37:28 +02:00

New file fixes ugly code from before (we can just make use of blenderobject->body_type), and ensures all objects (not just physics objects) are considered.
Also includes isActor and isGhost.
Renames record_animation to recordAnimation to keep style conventions.

Yes, ideally we wouldn't deal with a convoluted KX_GameObject namespace, but that is a more fundamental engine design issue, in my opinion. Per your suggestion, we might as well move all physics information, which would not be convenient. Instead, the best solution would be to group this data on the object, but then we're looking and components, aren't we! :)

New file fixes ugly code from before (we can just make use of blenderobject->body_type), and ensures all objects (not just physics objects) are considered. Also includes isActor and isGhost. Renames record_animation to recordAnimation to keep style conventions. Yes, ideally we wouldn't deal with a convoluted KX_GameObject namespace, but that is a more fundamental engine design issue, in my opinion. Per your suggestion, we might as well move all physics information, which would not be convenient. Instead, the best solution would be to group this data on the object, but then we're looking and components, aren't we! :)

Raf Colson commented

2014-05-13 16:54:47 +02:00

Added subscriber: @raco

Raf Colson commented

2014-05-13 16:54:47 +02:00

Just a suggestion. I know you guys put a lot attention to this already, but I would prefer a different design/approach.

KX_GameObject.ghost (Type: boolean) instead of isGhost.
KX_GameObject.actor (Type: boolean) instead of isActor.
KX_GameObject.physics_type (Type: string) which can be 'NO_COLLISION', 'SENSOR', 'STATIC', 'DYNAMIC', 'RIGID', 'SOFT_BODY', (...), like it is with the bpy.

Of course, these attributes shouldn't be limited to read-only. So, for example, it's possible to set KX_GameObject.physics_type to 'NO_COLLISION' instead of replacing the mesh.

Just a suggestion. I know you guys put a lot attention to this already, but I would prefer a different design/approach. - KX_GameObject.ghost (Type: boolean) instead of isGhost. - KX_GameObject.actor (Type: boolean) instead of isActor. - KX_GameObject.physics_type (Type: string) which can be 'NO_COLLISION', 'SENSOR', 'STATIC', 'DYNAMIC', 'RIGID', 'SOFT_BODY', (...), like it is with the bpy. Of course, these attributes shouldn't be limited to read-only. So, for example, it's possible to set KX_GameObject.physics_type to 'NO_COLLISION' instead of replacing the mesh.

Raf Colson commented

2014-05-21 08:27:46 +02:00

I wish to add: