kannonier8/blender
1
0
Fork 0
forked from bartvdbraak/blender
Code Pull Requests Activity
09e96f6b56
blender/source/gameengine/Converter/KX_ConvertActuators.cpp

1055 lines
30 KiB
C++
Raw Normal View History

doxygen: prevent GPL license block from being parsed as doxygen comment.
2011-02-23 10:52:22 +00:00
/*
Initial revision
2002-10-12 11:37:38 +00:00
* $Id$
*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* ***** BEGIN GPL LICENSE BLOCK *****
Initial revision
2002-10-12 11:37:38 +00:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* of the License, or (at your option) any later version.
Initial revision
2002-10-12 11:37:38 +00:00
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
correct fsf address
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Initial revision
2002-10-12 11:37:38 +00:00
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* ***** END GPL LICENSE BLOCK *****
Initial revision
2002-10-12 11:37:38 +00:00
* Convert Blender actuators for use in the GameEngine
*/
doxygen: gameengine/Converter tagged.
2011-02-25 13:30:41 +00:00
/** \file gameengine/Converter/KX_ConvertActuators.cpp
* \ingroup bgeconv
*/
update for MingW/CMake - ignore MSVC warnings when FREE_WINDOWS is defined to quiet warnings. - the CMake flags were not being set correctly making blender have weirdo colors (no -funsigned-char).
2010-09-15 16:13:32 +00:00
#if defined(WIN32) && !defined(FREE_WINDOWS)
Initial revision
2002-10-12 11:37:38 +00:00
#pragma warning (disable : 4786)
#endif //WIN32
quiet msvc/mingw compiler warnings.
2011-04-10 09:37:04 +00:00
#include <math.h>
2d Filters updated, now you can use custom filter and write your own GLSL shader program to filter rendering result.
2007-11-06 12:16:12 +00:00
#include "MEM_guardedalloc.h"
Initial revision
2002-10-12 11:37:38 +00:00
#include "KX_BlenderSceneConverter.h"
#include "KX_ConvertActuators.h"
2.5: Sound branch merge! See mailing list for additional information.
2009-08-09 21:16:39 +00:00
#include "AUD_C-API.h"
Initial revision
2002-10-12 11:37:38 +00:00
// Actuators
//SCA logiclibrary native logicbricks
#include "SCA_PropertyActuator.h"
#include "SCA_LogicManager.h"
#include "SCA_RandomActuator.h"
2d-Filters feature and actuators.
2007-10-22 20:24:26 +00:00
#include "SCA_2DFilterActuator.h"
Initial revision
2002-10-12 11:37:38 +00:00
// Ketsji specific logicbricks
#include "KX_SceneActuator.h"
#include "KX_IpoActuator.h"
#include "KX_SoundActuator.h"
#include "KX_ObjectActuator.h"
#include "KX_TrackToActuator.h"
#include "KX_ConstraintActuator.h"
#include "KX_CameraActuator.h"
#include "KX_GameActuator.h"
BGE patch: add state engine support in the logic bricks. This patch introduces a simple state engine system with the logic bricks. This system features full backward compatibility, multiple active states, multiple state transitions, automatic disabling of sensor and actuators, full GUI support and selective display of sensors and actuators. Note: Python API is available but not documented yet. It will be added asap. State internals =============== The state system is object based. The current state mask is stored in the object as a 32 bit value; each bit set in the mask is an active state. The controllers have a state mask too but only one bit can be set: a controller belongs to a single state. The game engine will only execute controllers that belong to active states. Sensors and actuators don't have a state mask but are effectively attached to states via their links to the controllers. Sensors and actuators can be connected to more than one state. When a controller becomes inactive because of a state change, its links to sensors and actuators are temporarily broken (until the state becomes active again). If an actuator gets isolated, i.e all the links to controllers are broken, it is automatically disabled. If a sensor gets isolated, the game engine will stop calling it to save CPU. It will also reset the sensor internal state so that it can react as if the game just started when it gets reconnected to an active controller. For example, an Always sensor in no pulse mode that is connected to a single state (i.e connected to one or more controllers of a single state) will generate a pulse each time the state becomes active. This feature is not available on all sensors, see the notes below. GUI === This system system is fully configurable through the GUI: the object state mask is visible under the object bar in the controller's colum as an array of buttons just like the 3D view layer mask. Click on a state bit to only display the controllers of that state. You can select more than one state with SHIFT-click. The All button sets all the bits so that you can see all the controllers of the object. The Ini button sets the state mask back to the object default state. You can change the default state of object by first selecting the desired state mask and storing using the menu under the State button. If you define a default state mask, it will be loaded into the object state make when you load the blend file or when you run the game under the blenderplayer. However, when you run the game under Blender, the current selected state mask will be used as the startup state for the object. This allows you to test specific state during the game design. The controller display the state they belong to with a new button in the controller header. When you add a new controller, it is added by default in the lowest enabled state. You can change the controller state by clicking on the button and selecting another state. If more than one state is enabled in the object state mask, controllers are grouped by state for more readibility. The new Sta button in the sensor and actuator column header allows you to display only the sensors and actuators that are linked to visible controllers. A new state actuator is available to modify the state during the game. It defines a bit mask and the operation to apply on the current object state mask: Cpy: the bit mask is copied to the object state mask. Add: the bits that set in the bit mask will be turned on in the object state mask. Sub: the bits that set in the bit mask will be turned off in the object state mask. Inv: the bits that set in the bit mask will be inverted in the objecyy state mask. Notes ===== - Although states have no name, a simply convention consists in using the name of the first controller of the state as the state name. The GUI will support that convention by displaying as a hint the name of the first controller of the state when you move the mouse over a state bit of the object state mask or of the state actuator bit mask. - Each object has a state mask and each object can have a state engine but if several objects are part of a logical group, it is recommended to put the state engine only in the main object and to link the controllers of that object to the sensors and actuators of the different objects. - When loading an old blend file, the state mask of all objects and controllers are initialized to 1 so that all the controllers belong to this single state. This ensures backward compatibility with existing game. - When the state actuator is activated at the same time as other actuators, these actuators are guaranteed to execute before being eventually disabled due to the state change. This is useful for example to send a message or update a property at the time of changing the state. - Sensors that depend on underlying resource won't reset fully when they are isolated. By the time they are acticated again, they will behave as follow: * keyboard sensor: keys already pressed won't be detected. The keyboard sensor is only sensitive to new key press. * collision sensor: objects already colliding won't be detected. Only new collisions are detected. * near and radar sensor: same as collision sensor.
2008-06-22 14:23:57 +00:00
#include "KX_StateActuator.h"
Initial revision
2002-10-12 11:37:38 +00:00
#include "KX_VisibilityActuator.h"
#include "KX_SCA_AddObjectActuator.h"
#include "KX_SCA_EndObjectActuator.h"
#include "KX_SCA_ReplaceMeshActuator.h"
Commit patch #8799: Realtime SetParent function in the BGE This patch consists in new KX_GameObject::SetParent() and KX_GameObject::RemoveParent() functions to create and destroy parent relation during game. These functions are accessible through python and through a new actuator KX_ParentActuator. Function documentation in PyDoc. The object keeps its orientation, position and scale when it is parented but will further rotate, move and scale with its parent from that point on. When the parent relation is broken, the object keeps the orientation, position and scale it had at that time. The function has no effect if any of the X/Y/Z scale of the object or its new parent are below Epsilon.
2008-04-06 18:30:52 +00:00
#include "KX_ParentActuator.h"
BGE patch 15044 approved: Edit Object Dynamics Actuator. Add enable/disable dynamics actuator under the "Edit Object" category. The Enable/disable rigid body option is also availale but not implemented.
2008-06-25 14:09:15 +00:00
#include "KX_SCA_DynamicActuator.h"
Initial revision
2002-10-12 11:37:38 +00:00
#include "KX_Scene.h"
#include "KX_KetsjiEngine.h"
#include "IntValue.h"
#include "KX_GameObject.h"
/* This little block needed for linking to Blender... */
2d Filters updated, now you can use custom filter and write your own GLSL shader program to filter rendering result.
2007-11-06 12:16:12 +00:00
#include "BKE_text.h"
Initial revision
2002-10-12 11:37:38 +00:00
#include "BLI_blenlib.h"
Bugfix: avoid crash with too long pathname.
2008-09-14 16:22:03 +00:00
#define FILE_MAX 240 // repeated here to avoid dependency from BKE_utildefines.h
Initial revision
2002-10-12 11:37:38 +00:00
#include "KX_NetworkMessageActuator.h"
#ifdef WIN32
#include "BLI_winstuff.h"
#endif
#include "DNA_object_types.h"
#include "DNA_sound_types.h"
#include "DNA_scene_types.h"
#include "DNA_actuator_types.h"
#include "DNA_packedFile_types.h"
#include "BL_ActionActuator.h"
BGE Patch: Add Shape Action support and update MSCV_7 project file for glew. Shape Action are now supported in the BGE. A new type of actuator "Shape Action" is available on mesh objects. It can be combined with Action actuator on parent armature. Only relative keys are supported. All the usual action options are available: type, blending, priority, Python API. Only actions with shape channels should be specified of course, otherwise the actuator has no effect. Shape action will still work after a mesh replacement provided that the new mesh has compatible shape keys.
2008-06-18 06:46:49 +00:00
#include "BL_ShapeActionActuator.h"
Merge of itasc branch. Project files, scons and cmake should be working. Makefile updated but not tested. Comes with Eigen2 2.0.6 C++ matrix library.
2009-09-24 21:22:24 +00:00
#include "BL_ArmatureActuator.h"
Initial revision
2002-10-12 11:37:38 +00:00
/* end of blender include block */
#include "BL_BlenderDataConversion.h"
/**
KX_BLENDERTRUNC needed to round 'almost' zero values to zero, else velocities etc. are incorrectly set
*/
#define KX_BLENDERTRUNC(x) (( x < 0.0001 && x > -0.0001 ) ? 0.0 : x)
void BL_ConvertActuators(char* maggiename,
struct Object* blenderobject,
KX_GameObject* gameobj,
SCA_LogicManager* logicmgr,
KX_Scene* scene,
KX_KetsjiEngine* ketsjiEngine,
int activeLayerBitInfo,
bool isInActiveLayer,
RAS_IRenderTools* rendertools,
KX_BlenderSceneConverter* converter
)
{
int uniqueint = 0;
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
int actcount = 0;
int executePriority = 0;
Initial revision
2002-10-12 11:37:38 +00:00
bActuator* bact = (bActuator*) blenderobject->actuators.first;
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
while (bact)
{
actcount++;
bact = bact->next;
}
gameobj->ReserveActuator(actcount);
bact = (bActuator*) blenderobject->actuators.first;
Initial revision
2002-10-12 11:37:38 +00:00
while(bact)
{
STR_String uniquename = bact->name;
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
STR_String& objectname = gameobj->GetName();
Initial revision
2002-10-12 11:37:38 +00:00
SCA_IActuator* baseact = NULL;
switch (bact->type)
{
case ACT_OBJECT:
{
bObjectActuator* obact = (bObjectActuator*) bact->data;
BGE #18665: Servo control and relative motion Servo control motion actuator did not work as expected when the object is moving on a moving platform. This patch introduces a new Ref field in the servo motion actuator to set a reference object for the velocity calculation. You can set the object during the game using the actuator "reference" attribute; use an object name or an object reference. The servo controller takes into account the angular velocity of the reference object to compute the relative local velocity.
2009-05-18 08:22:51 +00:00
KX_GameObject* obref = NULL;
Initial revision
2002-10-12 11:37:38 +00:00
MT_Vector3 forcevec(KX_BLENDERTRUNC(obact->forceloc[0]),
KX_BLENDERTRUNC(obact->forceloc[1]),
KX_BLENDERTRUNC(obact->forceloc[2]));
MT_Vector3 torquevec(obact->forcerot[0],obact->forcerot[1],obact->forcerot[2]);
MT_Vector3 dlocvec ( KX_BLENDERTRUNC(obact->dloc[0]),
KX_BLENDERTRUNC(obact->dloc[1]),
KX_BLENDERTRUNC(obact->dloc[2]));
MT_Vector3 drotvec ( KX_BLENDERTRUNC(obact->drot[0]),obact->drot[1],obact->drot[2]);
MT_Vector3 linvelvec ( KX_BLENDERTRUNC(obact->linearvelocity[0]),
KX_BLENDERTRUNC(obact->linearvelocity[1]),
KX_BLENDERTRUNC(obact->linearvelocity[2]));
MT_Vector3 angvelvec ( KX_BLENDERTRUNC(obact->angularvelocity[0]),
KX_BLENDERTRUNC(obact->angularvelocity[1]),
KX_BLENDERTRUNC(obact->angularvelocity[2]));
BGE patch: Add damping and clamping option to motion actuator. This patch introduces two options for the motion actuator: damping: number of frames to reach the target velocity. It takes into account the startup velocityin the target velocity direction and add 1/damping fraction of target velocity until the full velocity is reached. Works only with linear and angular velocity. It will be extended to delta and force motion method in a future release. clamping: apply the force and torque as long as the target velocity is not reached. If this option is set, the velocity specified in linV or angV are not applied to the object but used as target velocity. You should also specify a force in force or torque field: the force will be applied as long as the velocity along the axis of the vector set in linV or angV is not reached. Works best in low friction environment.
2008-06-24 19:37:43 +00:00
short damping = obact->damping;
Initial revision
2002-10-12 11:37:38 +00:00
/* Blender uses a bit vector internally for the local-flags. In */
/* KX, we have four bools. The compiler should be smart enough */
/* to do the right thing. We need to explicitly convert here! */
KX_LocalFlags bitLocalFlag;
bitLocalFlag.Force = bool((obact->flag & ACT_FORCE_LOCAL)!=0);
bitLocalFlag.Torque = bool((obact->flag & ACT_TORQUE_LOCAL) !=0);//rlocal;
bitLocalFlag.DLoc = bool((obact->flag & ACT_DLOC_LOCAL)!=0);
bitLocalFlag.DRot = bool((obact->flag & ACT_DROT_LOCAL)!=0);
bitLocalFlag.LinearVelocity = bool((obact->flag & ACT_LIN_VEL_LOCAL)!=0);
bitLocalFlag.AngularVelocity = bool((obact->flag & ACT_ANG_VEL_LOCAL)!=0);
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
bitLocalFlag.ServoControl = bool(obact->type == ACT_OBJECT_SERVO);
Initial revision
2002-10-12 11:37:38 +00:00
bitLocalFlag.AddOrSetLinV = bool((obact->flag & ACT_ADD_LIN_VEL)!=0);
BGE #18665: Servo control and relative motion Servo control motion actuator did not work as expected when the object is moving on a moving platform. This patch introduces a new Ref field in the servo motion actuator to set a reference object for the velocity calculation. You can set the object during the game using the actuator "reference" attribute; use an object name or an object reference. The servo controller takes into account the angular velocity of the reference object to compute the relative local velocity.
2009-05-18 08:22:51 +00:00
if (obact->reference && bitLocalFlag.ServoControl)
{
obref = converter->FindGameObject(obact->reference);
}
Initial revision
2002-10-12 11:37:38 +00:00
KX_ObjectActuator* tmpbaseact = new KX_ObjectActuator(gameobj,
BGE #18665: Servo control and relative motion Servo control motion actuator did not work as expected when the object is moving on a moving platform. This patch introduces a new Ref field in the servo motion actuator to set a reference object for the velocity calculation. You can set the object during the game using the actuator "reference" attribute; use an object name or an object reference. The servo controller takes into account the angular velocity of the reference object to compute the relative local velocity.
2009-05-18 08:22:51 +00:00
obref,
Initial revision
2002-10-12 11:37:38 +00:00
forcevec.getValue(),
torquevec.getValue(),
dlocvec.getValue(),
drotvec.getValue(),
linvelvec.getValue(),
angvelvec.getValue(),
BGE patch: Add damping and clamping option to motion actuator. This patch introduces two options for the motion actuator: damping: number of frames to reach the target velocity. It takes into account the startup velocityin the target velocity direction and add 1/damping fraction of target velocity until the full velocity is reached. Works only with linear and angular velocity. It will be extended to delta and force motion method in a future release. clamping: apply the force and torque as long as the target velocity is not reached. If this option is set, the velocity specified in linV or angV are not applied to the object but used as target velocity. You should also specify a force in force or torque field: the force will be applied as long as the velocity along the axis of the vector set in linV or angV is not reached. Works best in low friction environment.
2008-06-24 19:37:43 +00:00
damping,
Initial revision
2002-10-12 11:37:38 +00:00
bitLocalFlag
);
baseact = tmpbaseact;
break;
}
case ACT_ACTION:
{
if (blenderobject->type==OB_ARMATURE){
bActionActuator* actact = (bActionActuator*) bact->data;
STR_String propname = (actact->name ? actact->name : "");
BGE patch #14386: Action Actuator Current Frame Prop. This patch is very usefull for action feedback logic: a sensor on the property can be used to detect a certain moment in the action and trigger more stuff. The property must be on float type for best results
2008-06-23 15:32:44 +00:00
STR_String propframe = (actact->frameProp ? actact->frameProp : "");
Initial revision
2002-10-12 11:37:38 +00:00
BL_ActionActuator* tmpbaseact = new BL_ActionActuator(
gameobj,
propname,
BGE patch #14386: Action Actuator Current Frame Prop. This patch is very usefull for action feedback logic: a sensor on the property can be used to detect a certain moment in the action and trigger more stuff. The property must be on float type for best results
2008-06-23 15:32:44 +00:00
propframe,
Initial revision
2002-10-12 11:37:38 +00:00
actact->sta,
actact->end,
actact->act,
actact->type, // + 1, because Blender starts to count at zero,
actact->blendin,
actact->priority,
Adding an option for action actuator - "Continue" this means animations always play from where they left off. Continue was the 2.46 operation too, so new functionality is the option to disable. When using states, an action like kick or throw can often switch out before finishing playing the action, and there was no way to play from the start frame the second time round. (even setting the actions current frame through python doesn't work work)
2008-07-10 14:23:19 +00:00
actact->end_reset,
Initial revision
2002-10-12 11:37:38 +00:00
actact->stridelength
// Ketsji at 1, because zero is reserved for "NoDef"
);
baseact= tmpbaseact;
break;
}
else
printf ("Discarded action actuator from non-armature object [%s]\n", blenderobject->id.name+2);
}
BGE Patch: Add Shape Action support and update MSCV_7 project file for glew. Shape Action are now supported in the BGE. A new type of actuator "Shape Action" is available on mesh objects. It can be combined with Action actuator on parent armature. Only relative keys are supported. All the usual action options are available: type, blending, priority, Python API. Only actions with shape channels should be specified of course, otherwise the actuator has no effect. Shape action will still work after a mesh replacement provided that the new mesh has compatible shape keys.
2008-06-18 06:46:49 +00:00
case ACT_SHAPEACTION:
{
if (blenderobject->type==OB_MESH){
bActionActuator* actact = (bActionActuator*) bact->data;
STR_String propname = (actact->name ? actact->name : "");
BGE patch #17569 approved: Make FrameProp: work in Shape Action. PyDoc updated.
2008-09-22 21:49:48 +00:00
STR_String propframe = (actact->frameProp ? actact->frameProp : "");
BGE Patch: Add Shape Action support and update MSCV_7 project file for glew. Shape Action are now supported in the BGE. A new type of actuator "Shape Action" is available on mesh objects. It can be combined with Action actuator on parent armature. Only relative keys are supported. All the usual action options are available: type, blending, priority, Python API. Only actions with shape channels should be specified of course, otherwise the actuator has no effect. Shape action will still work after a mesh replacement provided that the new mesh has compatible shape keys.
2008-06-18 06:46:49 +00:00
BL_ShapeActionActuator* tmpbaseact = new BL_ShapeActionActuator(
gameobj,
propname,
BGE patch #17569 approved: Make FrameProp: work in Shape Action. PyDoc updated.
2008-09-22 21:49:48 +00:00
propframe,
BGE Patch: Add Shape Action support and update MSCV_7 project file for glew. Shape Action are now supported in the BGE. A new type of actuator "Shape Action" is available on mesh objects. It can be combined with Action actuator on parent armature. Only relative keys are supported. All the usual action options are available: type, blending, priority, Python API. Only actions with shape channels should be specified of course, otherwise the actuator has no effect. Shape action will still work after a mesh replacement provided that the new mesh has compatible shape keys.
2008-06-18 06:46:49 +00:00
actact->sta,
actact->end,
actact->act,
actact->type, // + 1, because Blender starts to count at zero,
actact->blendin,
actact->priority,
actact->stridelength
// Ketsji at 1, because zero is reserved for "NoDef"
);
baseact= tmpbaseact;
break;
}
else
printf ("Discarded shape action actuator from non-mesh object [%s]\n", blenderobject->id.name+2);
}
Initial revision
2002-10-12 11:37:38 +00:00
case ACT_IPO:
{
bIpoActuator* ipoact = (bIpoActuator*) bact->data;
bool ipochild = (ipoact->flag & ACT_IPOCHILD) !=0;
BGE patch: add frameProp to Ipo actuator (Carsten's request).
2008-10-01 21:17:00 +00:00
STR_String propname = ipoact->name;
STR_String frameProp = ipoact->frameProp;
Initial revision
2002-10-12 11:37:38 +00:00
// first bit?
bool ipo_as_force = (ipoact->flag & ACT_IPOFORCE);
BGE logic patch: new "Add" mode for Ipo actuator, several corrections in state system. New Add mode for Ipo actuator ============================= A new Add button, mutually exclusive with Force button, is available in the Ipo actuator. When selected, it activates the Add mode that consists in adding the Ipo curve to the current object situation in world coordinates, or parent coordinates if the object has a parent. Scale Ipo curves are multiplied instead of added to the object current scale. If the local flag is selected, the Ipo curve is added (multiplied) in the object's local coordinates. Delta Ipo curves are handled identically to normal Ipo curve and there is no need to work with Delta Ipo curves provided that you make sure that the Ipo curve starts from origin. Origin means location 0 for Location Ipo curve, rotation 0 for Rotation Ipo curve and scale 1 for Scale Ipo curve. The "current object situation" means the object's location, rotation and scale at the start of the Ipo curve. For Loop Stop and Loop End Ipo actuators, this means at the start of each loop. This initial state is used as a base during the execution of the Ipo Curve but when the Ipo curve is restarted (later or immediately in case of Loop mode), the object current situation at that time is used as the new base. For reference, here is the exact operation of the Add mode for each type of Ipo curve (oLoc, oRot, oScale, oMat: object's loc/rot/scale and orientation matrix at the start of the curve; iLoc, iRot, iScale, iMat: Ipo curve loc/rot/scale and orientation matrix resulting from the rotation). Location Local=false: newLoc = oLoc+iLoc Local=true : newLoc = oLoc+oScale*(oMat*iLoc) Rotation Local=false: newMat = iMat*oMat Local=true : newMat = oMat*iMat Scale Local=false: newScale = oScale*iScale Local=true : newScale = oScale*iScale Add+Local mode is very useful to have dynamic object executing complex movement relative to their current location/orientation. Of cource, dynamics should be disabled during the execution of the curve. Several corrections in state system =================================== - Object initial state is taken into account when adding object dynamically - Fix bug with link count when adding object dynamically - Fix false on-off detection for Actuator sensor when actuator is trigged on negative event. - Fix Parent actuator false activation on negative event - Loop Ipo curve not restarting at correct frame when start frame is different from one.
2008-07-08 12:18:43 +00:00
bool local = (ipoact->flag & ACT_IPOLOCAL);
bool ipo_add = (ipoact->flag & ACT_IPOADD);
Initial revision
2002-10-12 11:37:38 +00:00
KX_IpoActuator* tmpbaseact = new KX_IpoActuator(
gameobj,
propname ,
BGE patch: add frameProp to Ipo actuator (Carsten's request).
2008-10-01 21:17:00 +00:00
frameProp,
Initial revision
2002-10-12 11:37:38 +00:00
ipoact->sta,
ipoact->end,
ipochild,
ipoact->type + 1, // + 1, because Blender starts to count at zero,
// Ketsji at 1, because zero is reserved for "NoDef"
ipo_as_force,
BGE logic patch: new "Add" mode for Ipo actuator, several corrections in state system. New Add mode for Ipo actuator ============================= A new Add button, mutually exclusive with Force button, is available in the Ipo actuator. When selected, it activates the Add mode that consists in adding the Ipo curve to the current object situation in world coordinates, or parent coordinates if the object has a parent. Scale Ipo curves are multiplied instead of added to the object current scale. If the local flag is selected, the Ipo curve is added (multiplied) in the object's local coordinates. Delta Ipo curves are handled identically to normal Ipo curve and there is no need to work with Delta Ipo curves provided that you make sure that the Ipo curve starts from origin. Origin means location 0 for Location Ipo curve, rotation 0 for Rotation Ipo curve and scale 1 for Scale Ipo curve. The "current object situation" means the object's location, rotation and scale at the start of the Ipo curve. For Loop Stop and Loop End Ipo actuators, this means at the start of each loop. This initial state is used as a base during the execution of the Ipo Curve but when the Ipo curve is restarted (later or immediately in case of Loop mode), the object current situation at that time is used as the new base. For reference, here is the exact operation of the Add mode for each type of Ipo curve (oLoc, oRot, oScale, oMat: object's loc/rot/scale and orientation matrix at the start of the curve; iLoc, iRot, iScale, iMat: Ipo curve loc/rot/scale and orientation matrix resulting from the rotation). Location Local=false: newLoc = oLoc+iLoc Local=true : newLoc = oLoc+oScale*(oMat*iLoc) Rotation Local=false: newMat = iMat*oMat Local=true : newMat = oMat*iMat Scale Local=false: newScale = oScale*iScale Local=true : newScale = oScale*iScale Add+Local mode is very useful to have dynamic object executing complex movement relative to their current location/orientation. Of cource, dynamics should be disabled during the execution of the curve. Several corrections in state system =================================== - Object initial state is taken into account when adding object dynamically - Fix bug with link count when adding object dynamically - Fix false on-off detection for Actuator sensor when actuator is trigged on negative event. - Fix Parent actuator false activation on negative event - Loop Ipo curve not restarting at correct frame when start frame is different from one.
2008-07-08 12:18:43 +00:00
ipo_add,
local);
Initial revision
2002-10-12 11:37:38 +00:00
baseact = tmpbaseact;
break;
}
case ACT_LAMP:
{
break;
}
case ACT_CAMERA:
{
bCameraActuator *camact = (bCameraActuator *) bact->data;
if (camact->ob) {
KX_GameObject *tmpgob = converter->FindGameObject(camact->ob);
/* visifac, fac and axis are not copied from the struct... */
/* that's some internal state... */
KX_CameraActuator *tmpcamact
= new KX_CameraActuator(gameobj,
tmpgob,
camact->height,
camact->min,
camact->max,
camact->axis=='x');
baseact = tmpcamact;
}
break;
}
case ACT_MESSAGE:
{
bMessageActuator *msgAct = (bMessageActuator *) bact->data;
/**
* Get the name of the properties that objects must own that
* we're sending to, if present
*/
STR_String toPropName = (msgAct->toPropName
? (char*) msgAct->toPropName
: "");
interpreted request from Carsten - make message sensor work. object message actuators needed the prefix OB when sending a message to a specific object.--This line, and those below, will be ignored-- M source/gameengine/Converter/KX_ConvertActuators.cpp M source/blender/blenkernel/BKE_blender.h M source/blender/src/buttons_logic.c M source/blender/blenloader/intern/readfile.c
2008-10-03 09:51:43 +00:00
/**
* Get the Message Subject to send.
Initial revision
2002-10-12 11:37:38 +00:00
*/
STR_String subject = (msgAct->subject
? (char*) msgAct->subject
: "");
interpreted request from Carsten - make message sensor work. object message actuators needed the prefix OB when sending a message to a specific object.--This line, and those below, will be ignored-- M source/gameengine/Converter/KX_ConvertActuators.cpp M source/blender/blenkernel/BKE_blender.h M source/blender/src/buttons_logic.c M source/blender/blenloader/intern/readfile.c
2008-10-03 09:51:43 +00:00
/**
* Get the bodyType
Initial revision
2002-10-12 11:37:38 +00:00
*/
int bodyType = msgAct->bodyType;
/**
* Get the body (text message or property name whose value
* we'll be sending, might be empty
*/
STR_String body = (msgAct->body
? (char*) msgAct->body
: "");
KX_NetworkMessageActuator *tmpmsgact =
new KX_NetworkMessageActuator(
gameobj, // actuator controlling object
scene->GetNetworkScene(), // needed for replication
toPropName,
subject,
bodyType,
body);
baseact = tmpmsgact;
break;
}
case ACT_MATERIAL:
{
break;
}
case ACT_SOUND:
{
bSoundActuator* soundact = (bSoundActuator*) bact->data;
/* get type, and possibly a start and end frame */
2.5: Sound branch merge! See mailing list for additional information.
2009-08-09 21:16:39 +00:00
KX_SoundActuator::KX_SOUNDACT_TYPE
Initial revision
2002-10-12 11:37:38 +00:00
soundActuatorType = KX_SoundActuator::KX_SOUNDACT_NODEF;
switch(soundact->type) {
case ACT_SND_PLAY_STOP_SOUND:
soundActuatorType = KX_SoundActuator::KX_SOUNDACT_PLAYSTOP;
break;
case ACT_SND_PLAY_END_SOUND:
soundActuatorType = KX_SoundActuator::KX_SOUNDACT_PLAYEND;
break;
case ACT_SND_LOOP_STOP_SOUND:
soundActuatorType = KX_SoundActuator::KX_SOUNDACT_LOOPSTOP;
break;
case ACT_SND_LOOP_END_SOUND:
soundActuatorType = KX_SoundActuator::KX_SOUNDACT_LOOPEND;
break;
case ACT_SND_LOOP_BIDIRECTIONAL_SOUND:
soundActuatorType = KX_SoundActuator::KX_SOUNDACT_LOOPBIDIRECTIONAL;
break;
case ACT_SND_LOOP_BIDIRECTIONAL_STOP_SOUND:
soundActuatorType = KX_SoundActuator::KX_SOUNDACT_LOOPBIDIRECTIONAL_STOP;
break;
default:
/* This is an error!!! */
soundActuatorType = KX_SoundActuator::KX_SOUNDACT_NODEF;
}
if (soundActuatorType != KX_SoundActuator::KX_SOUNDACT_NODEF)
{
2.5: Sound branch merge! See mailing list for additional information.
2009-08-09 21:16:39 +00:00
bSound* sound = soundact->sound;
bool is3d = soundact->flag & ACT_SND_3D_SOUND ? true : false;
AUD_Sound* snd_sound = NULL;
KX_3DSoundSettings settings;
settings.cone_inner_angle = soundact->sound3D.cone_inner_angle;
settings.cone_outer_angle = soundact->sound3D.cone_outer_angle;
settings.cone_outer_gain = soundact->sound3D.cone_outer_gain;
settings.max_distance = soundact->sound3D.max_distance;
settings.max_gain = soundact->sound3D.max_gain;
settings.min_gain = soundact->sound3D.min_gain;
settings.reference_distance = soundact->sound3D.reference_distance;
settings.rolloff_factor = soundact->sound3D.rolloff_factor;
if(!sound)
{
BGE: allow sound actuators to be converted even when they have invalid samples without this, an incorrect sound path could cause scripts to to fail, making some functionality not work at all. This also fixes a problem where samples would be loaded multiple times.
2008-08-27 01:03:55 +00:00
std::cout << "WARNING: Sound actuator \"" << bact->name <<
"\" from object \"" << blenderobject->id.name+2 <<
"\" has no sound datablock." << std::endl;
}
2.5: Sound branch merge! See mailing list for additional information.
2009-08-09 21:16:39 +00:00
else
2.5 Audio: - recode of the whole sequencer audio handling - encode audio flag removed, instead you choose None as audio codec, added None for video codec too - ffmpeg formats/codecs: enabled: theora, ogg, vorbis; added: matroska, flac (not working, who can fix?), mp3, wav - sequencer wave drawing - volume animation (now also working when mixing down to a file!) - made sequencer strip position and length values unanimatable
2010-02-07 23:41:17 +00:00
snd_sound = sound->playback_handle;
2.5: Sound branch merge! See mailing list for additional information.
2009-08-09 21:16:39 +00:00
KX_SoundActuator* tmpsoundact =
new KX_SoundActuator(gameobj,
snd_sound,
soundact->volume,
quiet msvc/mingw compiler warnings.
2011-04-10 09:37:04 +00:00
(float)(exp((soundact->pitch / 12.0) * log(2.0))),
2.5: Sound branch merge! See mailing list for additional information.
2009-08-09 21:16:39 +00:00
is3d,
settings,
soundActuatorType);
BGE: allow sound actuators to be converted even when they have invalid samples without this, an incorrect sound path could cause scripts to to fail, making some functionality not work at all. This also fixes a problem where samples would be loaded multiple times.
2008-08-27 01:03:55 +00:00
tmpsoundact->SetName(bact->name);
baseact = tmpsoundact;
Initial revision
2002-10-12 11:37:38 +00:00
}
break;
}
case ACT_PROPERTY:
{
bPropertyActuator* propact = (bPropertyActuator*) bact->data;
BGE patch: Relink actuators with target within group when duplicating group; generalize protection against object deletion for all actuators that point to objects. Certain actuators hold a pointer to an objects: Property, SceneCamera, AddObject, Camera, Parent, TractTo. When a group is duplicated, the actuators that point to objects within the group will be relinked to point to the replicated objects and not to the original objects. This helps to setup self-contained group with a camera following a character for example. This feature also works when adding a single object (and all its children) with the AddObject actuator. The second part of the patch extends the protection against object deletion to all the actuators of the above list (previously, only the TrackTo, AddObject and Property actuators were protected). In case the target object of these actuators is deleted, the BGE won't crash.
2008-07-19 07:45:19 +00:00
SCA_IObject* destinationObj = NULL;
Initial revision
2002-10-12 11:37:38 +00:00
/*
here the destinationobject is searched. problem with multiple scenes: other scenes
have not been converted yet, so the destobj will not be found, so the prop will
not be copied.
possible solutions:
- convert everything when possible and not realtime only when needed.
- let the object-with-property report itself to the act when converted
*/
if (propact->ob)
Switch fixed time system. Logic updates should now happen at 30Hz, physics at 60Hz. (By default, use Python to set.) Some actuators still run at framerate (IPO, Action) for nice smooth animation, and an excuse to buy high end hardware. Keyboard sensors can now hook escape key. Ctrl-Break can be used from within blender if you've forgotten an end game actuator. Fixed a stupid bug preventing some actuators working (like TrackTo).
2004-10-16 11:41:50 +00:00
destinationObj = converter->FindGameObject(propact->ob);
Initial revision
2002-10-12 11:37:38 +00:00
SCA_PropertyActuator* tmppropact = new SCA_PropertyActuator(
gameobj,
destinationObj,
propact->name,
propact->value,
propact->type+1); // + 1 because Ketsji Logic starts
// with 0 for KX_ACT_PROP_NODEF
baseact = tmppropact;
break;
}
case ACT_EDIT_OBJECT:
{
bEditObjectActuator *editobact
= (bEditObjectActuator *) bact->data;
/* There are four different kinds of 'edit object' thingies */
/* The alternative to this lengthy conversion is packing */
/* several actuators in one, which is not very nice design.. */
switch (editobact->type) {
case ACT_EDOB_ADD_OBJECT:
{
// does the 'original' for replication exists, and
// is it in a non-active layer ?
BGE bug fix (good for 2.47): automatic detection that target object of AddObject actuator is being deleted to avoid crash (bad game design anyway)
2008-07-12 12:10:27 +00:00
SCA_IObject* originalval = NULL;
Python API get/setObject update for Actuators. (SetParent, AddObject, Camera and TrackTo) * bugfix for BGE python api - SetParent actuator getObject would segfault if the object was not set. * Added utility function ConvertPythonToGameObject() that can take a GameObject, string or None and set the game object from this since it was being done in a number of places. * allow setObject(None), since no object is valid for actuators, Python should be able to set this. * added optional argument for getObject() so it returns the KX_GameObject rather then its name, would prefer this be default but it could break existing games.
2008-08-14 08:58:25 +00:00
if (editobact->ob)
{
if (editobact->ob->lay & activeLayerBitInfo)
{
fprintf(stderr, "Warning, object \"%s\" from AddObject actuator \"%s\" is not in a hidden layer.\n", objectname.Ptr(), uniquename.Ptr());
}
else {
originalval = converter->FindGameObject(editobact->ob);
}
}
get/set Angular velocity for KX_GameObjects python api and for the AddObject actuator. Needed so objects created in an explosion could start spinning without having motion actuators and collision sensors on each item.
2008-08-27 03:34:53 +00:00
Convert and use actuators with no target object set. Certain actuators (Add Object/Replace Mesh/Scene/Track To) used to always require a target, or they would not influence the scene. If the actuator target is always set from Python, this could be annoying.
2004-09-19 01:33:08 +00:00
KX_SCA_AddObjectActuator* tmpaddact =
new KX_SCA_AddObjectActuator(
gameobj,
originalval,
editobact->time,
scene,
game engine compile fix for MSVC, game engine team might want to check.
2009-03-28 11:09:53 +00:00
editobact->linVelocity,
get/set Angular velocity for KX_GameObjects python api and for the AddObject actuator. Needed so objects created in an explosion could start spinning without having motion actuators and collision sensors on each item.
2008-08-27 03:34:53 +00:00
(editobact->localflag & ACT_EDOB_LOCAL_LINV)!=0,
game engine compile fix for MSVC, game engine team might want to check.
2009-03-28 11:09:53 +00:00
editobact->angVelocity,
get/set Angular velocity for KX_GameObjects python api and for the AddObject actuator. Needed so objects created in an explosion could start spinning without having motion actuators and collision sensors on each item.
2008-08-27 03:34:53 +00:00
(editobact->localflag & ACT_EDOB_LOCAL_ANGV)!=0
Convert and use actuators with no target object set. Certain actuators (Add Object/Replace Mesh/Scene/Track To) used to always require a target, or they would not influence the scene. If the actuator target is always set from Python, this could be annoying.
2004-09-19 01:33:08 +00:00
);
Initial revision
2002-10-12 11:37:38 +00:00
//editobact->ob to gameobj
baseact = tmpaddact;
}
break;
case ACT_EDOB_END_OBJECT:
{
KX_SCA_EndObjectActuator* tmpendact
= new KX_SCA_EndObjectActuator(gameobj,scene);
baseact = tmpendact;
}
break;
case ACT_EDOB_REPLACE_MESH:
{
Convert and use actuators with no target object set. Certain actuators (Add Object/Replace Mesh/Scene/Track To) used to always require a target, or they would not influence the scene. If the actuator target is always set from Python, this could be annoying.
2004-09-19 01:33:08 +00:00
RAS_MeshObject *tmpmesh = NULL;
Initial revision
2002-10-12 11:37:38 +00:00
if (editobact->me)
Switch fixed time system. Logic updates should now happen at 30Hz, physics at 60Hz. (By default, use Python to set.) Some actuators still run at framerate (IPO, Action) for nice smooth animation, and an excuse to buy high end hardware. Keyboard sensors can now hook escape key. Ctrl-Break can be used from within blender if you've forgotten an end game actuator. Fixed a stupid bug preventing some actuators working (like TrackTo).
2004-10-16 11:41:50 +00:00
tmpmesh = BL_ConvertMesh(
Initial revision
2002-10-12 11:37:38 +00:00
editobact->me,
blenderobject,
scene,
converter
);
Convert and use actuators with no target object set. Certain actuators (Add Object/Replace Mesh/Scene/Track To) used to always require a target, or they would not influence the scene. If the actuator target is always set from Python, this could be annoying.
2004-09-19 01:33:08 +00:00
KX_SCA_ReplaceMeshActuator* tmpreplaceact
= new KX_SCA_ReplaceMeshActuator(
Initial revision
2002-10-12 11:37:38 +00:00
gameobj,
tmpmesh,
ReplaceMesh Actuator option to replace the physics mesh and display mesh + python api options. When the mesh field is left blank and Physics option is enabled, it reinstances the physics mesh from the existing mesh. like calling gameOb.reinstancePhysicsMesh() from python.
2009-07-26 01:32:37 +00:00
scene,
(editobact->flag & ACT_EDOB_REPLACE_MESH_NOGFX)==0,
(editobact->flag & ACT_EDOB_REPLACE_MESH_PHYS)!=0
Initial revision
2002-10-12 11:37:38 +00:00
);
baseact = tmpreplaceact;
}
break;
case ACT_EDOB_TRACK_TO:
{
Convert and use actuators with no target object set. Certain actuators (Add Object/Replace Mesh/Scene/Track To) used to always require a target, or they would not influence the scene. If the actuator target is always set from Python, this could be annoying.
2004-09-19 01:33:08 +00:00
SCA_IObject* originalval = NULL;
Initial revision
2002-10-12 11:37:38 +00:00
if (editobact->ob)
Switch fixed time system. Logic updates should now happen at 30Hz, physics at 60Hz. (By default, use Python to set.) Some actuators still run at framerate (IPO, Action) for nice smooth animation, and an excuse to buy high end hardware. Keyboard sensors can now hook escape key. Ctrl-Break can be used from within blender if you've forgotten an end game actuator. Fixed a stupid bug preventing some actuators working (like TrackTo).
2004-10-16 11:41:50 +00:00
originalval = converter->FindGameObject(editobact->ob);
Initial revision
2002-10-12 11:37:38 +00:00
Convert and use actuators with no target object set. Certain actuators (Add Object/Replace Mesh/Scene/Track To) used to always require a target, or they would not influence the scene. If the actuator target is always set from Python, this could be annoying.
2004-09-19 01:33:08 +00:00
KX_TrackToActuator* tmptrackact
= new KX_TrackToActuator(gameobj,
Initial revision
2002-10-12 11:37:38 +00:00
originalval,
editobact->time,
editobact->flag,
blenderobject->trackflag,
blenderobject->upflag
);
baseact = tmptrackact;
BGE patch 15044 approved: Edit Object Dynamics Actuator. Add enable/disable dynamics actuator under the "Edit Object" category. The Enable/disable rigid body option is also availale but not implemented.
2008-06-25 14:09:15 +00:00
break;
}
case ACT_EDOB_DYNAMICS:
{
KX_SCA_DynamicActuator* tmpdynact
= new KX_SCA_DynamicActuator(gameobj,
BGE patch 18065: gameobj mass writeable + setmass actuator. This patch allows to change the mass of a dynamic or rigid body object during the game. Two methods are available: in a Python script by setting the mass attribute of the game object; by logic brick with the Edit Object->Dynamics->Set Mass actuator. The mass can only be set on dynamic objects and must be a positive floating point value.
2009-01-14 22:33:39 +00:00
editobact->dyn_operation,
editobact->mass
BGE patch 15044 approved: Edit Object Dynamics Actuator. Add enable/disable dynamics actuator under the "Edit Object" category. The Enable/disable rigid body option is also availale but not implemented.
2008-06-25 14:09:15 +00:00
);
baseact = tmpdynact;
Initial revision
2002-10-12 11:37:38 +00:00
}
}
break;
}
case ACT_CONSTRAINT:
{
float min = 0.0, max = 0.0;
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
char *prop = NULL;
[GameEngine] Commit all Kester's changes made to the gameengine to restore 2.25 like physics. [SCons] Build with Solid as default when enabling the gameengine in the build process [SCons] Build solid and qhull from the extern directory and link statically against them That was about it. There are a few things that needs double checking: * Makefiles * Projectfiles * All the other systems than Linux and Windows on which the build (with scons) has been successfully tested.
2004-03-22 22:02:18 +00:00
KX_ConstraintActuator::KX_CONSTRAINTTYPE locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_NODEF;
Initial revision
2002-10-12 11:37:38 +00:00
bConstraintActuator *conact
= (bConstraintActuator*) bact->data;
/* convert settings... degrees in the ui become radians */
/* internally */
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
if (conact->type == ACT_CONST_TYPE_ORI) {
quiet msvc/mingw compiler warnings.
2011-04-10 09:37:04 +00:00
min = (float)((MT_2_PI * conact->minloc[0])/360.0);
max = (float)((MT_2_PI * conact->maxloc[0])/360.0);
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
switch (conact->mode) {
case ACT_CONST_DIRPX:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_ORIX;
break;
case ACT_CONST_DIRPY:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_ORIY;
break;
case ACT_CONST_DIRPZ:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_ORIZ;
break;
}
} else if (conact->type == ACT_CONST_TYPE_DIST) {
switch (conact->mode) {
case ACT_CONST_DIRPX:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_DIRPX;
min = conact->minloc[0];
max = conact->maxloc[0];
break;
case ACT_CONST_DIRPY:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_DIRPY;
min = conact->minloc[1];
max = conact->maxloc[1];
break;
case ACT_CONST_DIRPZ:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_DIRPZ;
min = conact->minloc[2];
max = conact->maxloc[2];
break;
BGE patch: Add PyDoc for new logic bricks, set exception message on Py error, remove args on Py functions that don't take any to save CPU time
2008-07-23 21:37:37 +00:00
case ACT_CONST_DIRNX:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_DIRNX;
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
min = conact->minloc[0];
max = conact->maxloc[0];
break;
BGE patch: Add PyDoc for new logic bricks, set exception message on Py error, remove args on Py functions that don't take any to save CPU time
2008-07-23 21:37:37 +00:00
case ACT_CONST_DIRNY:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_DIRNY;
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
min = conact->minloc[1];
max = conact->maxloc[1];
break;
BGE patch: Add PyDoc for new logic bricks, set exception message on Py error, remove args on Py functions that don't take any to save CPU time
2008-07-23 21:37:37 +00:00
case ACT_CONST_DIRNZ:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_DIRNZ;
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
min = conact->minloc[2];
max = conact->maxloc[2];
break;
}
prop = conact->matprop;
BGE patch: new force field constraint actuator A new type of constraint actuator is available: Force field. It provides a very similar service to the Fh material feature but with some specificities: - It is defined at the object level: each object can have different settings and you don't need to use material. - It can be applied in all 6 directions and not just -Z. - It can be enabled/disabled easily (it's an actuator). - You can have multiple force fields active at the same time on the same object in different direction (think of a space ship in a tunnel with a repulsive force field on each wall). - You can have a different damping for the rotation. Besides that it provides the same dynamic behavior and the parameters are self explanatory. It works by adapting the linear and angular velocity: the dynamic is independent of the mass. It is compatible with all other motion actuators. Note: linear and anysotropic friction is not yet implemented, the only friction will come from the object damping parameters. Support for friction will be added in a future revision.
2008-10-01 19:16:13 +00:00
} else if (conact->type == ACT_CONST_TYPE_FH) {
switch (conact->mode) {
case ACT_CONST_DIRPX:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_FHPX;
min = conact->minloc[0];
max = conact->maxloc[0];
break;
case ACT_CONST_DIRPY:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_FHPY;
min = conact->minloc[1];
max = conact->maxloc[1];
break;
case ACT_CONST_DIRPZ:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_FHPZ;
min = conact->minloc[2];
max = conact->maxloc[2];
break;
case ACT_CONST_DIRNX:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_FHNX;
min = conact->minloc[0];
max = conact->maxloc[0];
break;
case ACT_CONST_DIRNY:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_FHNY;
min = conact->minloc[1];
max = conact->maxloc[1];
break;
case ACT_CONST_DIRNZ:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_FHNZ;
min = conact->minloc[2];
max = conact->maxloc[2];
break;
}
prop = conact->matprop;
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
} else {
switch (conact->flag) {
case ACT_CONST_LOCX:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_LOCX;
min = conact->minloc[0];
max = conact->maxloc[0];
break;
case ACT_CONST_LOCY:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_LOCY;
min = conact->minloc[1];
max = conact->maxloc[1];
break;
case ACT_CONST_LOCZ:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_LOCZ;
min = conact->minloc[2];
max = conact->maxloc[2];
break;
case ACT_CONST_ROTX:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_ROTX;
quiet msvc/mingw compiler warnings.
2011-04-10 09:37:04 +00:00
min = conact->minrot[0] * (float)MT_RADS_PER_DEG;
max = conact->maxrot[0] * (float)MT_RADS_PER_DEG;
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
break;
case ACT_CONST_ROTY:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_ROTY;
quiet msvc/mingw compiler warnings.
2011-04-10 09:37:04 +00:00
min = conact->minrot[1] * (float)MT_RADS_PER_DEG;
max = conact->maxrot[1] * (float)MT_RADS_PER_DEG;
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
break;
case ACT_CONST_ROTZ:
locrot = KX_ConstraintActuator::KX_ACT_CONSTRAINT_ROTZ;
quiet msvc/mingw compiler warnings.
2011-04-10 09:37:04 +00:00
min = conact->minrot[2] * (float)MT_RADS_PER_DEG;
max = conact->maxrot[2] * (float)MT_RADS_PER_DEG;
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
break;
default:
; /* error */
}
Initial revision
2002-10-12 11:37:38 +00:00
}
KX_ConstraintActuator *tmpconact
= new KX_ConstraintActuator(gameobj,
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
conact->damp,
conact->rotdamp,
min,
max,
conact->maxrot,
locrot,
conact->time,
conact->flag,
prop);
Initial revision
2002-10-12 11:37:38 +00:00
baseact = tmpconact;
break;
}
case ACT_GROUP:
{
// deprecated
}
break;
case ACT_SCENE:
{
bSceneActuator *sceneact = (bSceneActuator *) bact->data;
Convert and use actuators with no target object set. Certain actuators (Add Object/Replace Mesh/Scene/Track To) used to always require a target, or they would not influence the scene. If the actuator target is always set from Python, this could be annoying.
2004-09-19 01:33:08 +00:00
STR_String nextSceneName("");
Initial revision
2002-10-12 11:37:38 +00:00
KX_SceneActuator* tmpsceneact;
int mode = KX_SceneActuator::KX_SCENE_NODEF;
KX_Camera *cam = NULL;
//KX_Scene* scene = NULL;
switch (sceneact->type)
{
case ACT_SCENE_RESUME:
case ACT_SCENE_SUSPEND:
case ACT_SCENE_ADD_FRONT:
case ACT_SCENE_ADD_BACK:
case ACT_SCENE_REMOVE:
case ACT_SCENE_SET:
{
switch (sceneact->type)
{
case ACT_SCENE_RESUME:
mode = KX_SceneActuator::KX_SCENE_RESUME;
break;
case ACT_SCENE_SUSPEND:
mode = KX_SceneActuator::KX_SCENE_SUSPEND;
break;
case ACT_SCENE_ADD_FRONT:
mode = KX_SceneActuator::KX_SCENE_ADD_FRONT_SCENE;
break;
case ACT_SCENE_ADD_BACK:
mode = KX_SceneActuator::KX_SCENE_ADD_BACK_SCENE;
break;
case ACT_SCENE_REMOVE:
mode = KX_SceneActuator::KX_SCENE_REMOVE_SCENE;
break;
case ACT_SCENE_SET:
default:
mode = KX_SceneActuator::KX_SCENE_SET_SCENE;
break;
};
if (sceneact->scene)
{
nextSceneName = sceneact->scene->id.name + 2; // this '2' is necessary to remove prefix 'SC'
}
break;
}
case ACT_SCENE_CAMERA:
fix BGE bug #8309: After Parent Object added to the visual layer, Child Camera won't follow. This bug fix is made of two parts: 1) It's now possible to dynamically add a camera. 2) Empty camera name on a SetCamera actuator now points to the actuator's parent object if this object is a camera. This trick is useful to make current a dynamically created camera: just add a SetCamera actuator on the camera itself and leave the name empty. Later, when the camera is added in the scene with an AddObject actuator, either directly or via a parent object, you just need to activate the actuator to make the newly created camera current. If you set a name on a SetCamera actuator, it will always point to the original camera, even after replication.
2008-04-14 20:54:20 +00:00
mode = KX_SceneActuator::KX_SCENE_SET_CAMERA;
Initial revision
2002-10-12 11:37:38 +00:00
if (sceneact->camera)
{
cam = (KX_Camera*) converter->FindGameObject(sceneact->camera);
}
break;
case ACT_SCENE_RESTART:
{
mode = KX_SceneActuator::KX_SCENE_RESTART;
break;
}
default:
; /* flag error */
}
Convert and use actuators with no target object set. Certain actuators (Add Object/Replace Mesh/Scene/Track To) used to always require a target, or they would not influence the scene. If the actuator target is always set from Python, this could be annoying.
2004-09-19 01:33:08 +00:00
tmpsceneact = new KX_SceneActuator(gameobj,
Initial revision
2002-10-12 11:37:38 +00:00
mode,
scene,
ketsjiEngine,
nextSceneName,
cam);
baseact = tmpsceneact;
break;
}
case ACT_GAME:
{
bGameActuator *gameact = (bGameActuator *) bact->data;
KX_GameActuator* tmpgameact;
STR_String filename = maggiename;
STR_String loadinganimationname = "";
int mode = KX_GameActuator::KX_GAME_NODEF;
switch (gameact->type)
{
case ACT_GAME_LOAD:
{
mode = KX_GameActuator::KX_GAME_LOAD;
filename = gameact->filename;
loadinganimationname = gameact->loadaniname;
break;
}
case ACT_GAME_START:
{
mode = KX_GameActuator::KX_GAME_START;
filename = gameact->filename;
loadinganimationname = gameact->loadaniname;
break;
}
case ACT_GAME_RESTART:
{
mode = KX_GameActuator::KX_GAME_RESTART;
break;
}
case ACT_GAME_QUIT:
{
mode = KX_GameActuator::KX_GAME_QUIT;
break;
}
save and load configuration actuator, (option in game actuator menu) saves a marshal'd GameLogic.globalDict to the blendfile path with the blend extension replaced with bgeconf Use this in YoFrankie to save keyboard layout and graphics quality settings.
2008-09-12 02:15:16 +00:00
case ACT_GAME_SAVECFG:
{
mode = KX_GameActuator::KX_GAME_SAVECFG;
break;
}
case ACT_GAME_LOADCFG:
{
mode = KX_GameActuator::KX_GAME_LOADCFG;
break;
}
Initial revision
2002-10-12 11:37:38 +00:00
default:
; /* flag error */
}
tmpgameact = new KX_GameActuator(gameobj,
mode,
filename,
loadinganimationname,
scene,
ketsjiEngine);
baseact = tmpgameact;
break;
}
case ACT_RANDOM:
{
bRandomActuator *randAct
= (bRandomActuator *) bact->data;
unsigned long seedArg = randAct->seed;
BGE: memory leak in Random actuator + make actuator truly random when seed=0 in the UI. When running the game, seed 0 is replaced by a random seed accessible through Python in seed attribute of the actuator. Other seed value will be left unchanged and will generate fixed pseudo random series.
2009-06-01 18:41:58 +00:00
if (seedArg == 0)
{
seedArg = (int)(ketsjiEngine->GetRealTime()*100000.0);
seedArg ^= (intptr_t)randAct;
}
Initial revision
2002-10-12 11:37:38 +00:00
SCA_RandomActuator::KX_RANDOMACT_MODE modeArg
= SCA_RandomActuator::KX_RANDOMACT_NODEF;
SCA_RandomActuator *tmprandomact;
float paraArg1 = 0.0;
float paraArg2 = 0.0;
switch (randAct->distribution) {
case ACT_RANDOM_BOOL_CONST:
modeArg = SCA_RandomActuator::KX_RANDOMACT_BOOL_CONST;
paraArg1 = (float) randAct->int_arg_1;
break;
case ACT_RANDOM_BOOL_UNIFORM:
modeArg = SCA_RandomActuator::KX_RANDOMACT_BOOL_UNIFORM;
break;
case ACT_RANDOM_BOOL_BERNOUILLI:
paraArg1 = randAct->float_arg_1;
modeArg = SCA_RandomActuator::KX_RANDOMACT_BOOL_BERNOUILLI;
break;
case ACT_RANDOM_INT_CONST:
modeArg = SCA_RandomActuator::KX_RANDOMACT_INT_CONST;
paraArg1 = (float) randAct->int_arg_1;
break;
case ACT_RANDOM_INT_UNIFORM:
paraArg1 = (float) randAct->int_arg_1;
paraArg2 = (float) randAct->int_arg_2;
modeArg = SCA_RandomActuator::KX_RANDOMACT_INT_UNIFORM;
break;
case ACT_RANDOM_INT_POISSON:
paraArg1 = randAct->float_arg_1;
modeArg = SCA_RandomActuator::KX_RANDOMACT_INT_POISSON;
break;
case ACT_RANDOM_FLOAT_CONST:
paraArg1 = randAct->float_arg_1;
modeArg = SCA_RandomActuator::KX_RANDOMACT_FLOAT_CONST;
break;
case ACT_RANDOM_FLOAT_UNIFORM:
paraArg1 = randAct->float_arg_1;
paraArg2 = randAct->float_arg_2;
modeArg = SCA_RandomActuator::KX_RANDOMACT_FLOAT_UNIFORM;
break;
case ACT_RANDOM_FLOAT_NORMAL:
paraArg1 = randAct->float_arg_1;
paraArg2 = randAct->float_arg_2;
modeArg = SCA_RandomActuator::KX_RANDOMACT_FLOAT_NORMAL;
break;
case ACT_RANDOM_FLOAT_NEGATIVE_EXPONENTIAL:
paraArg1 = randAct->float_arg_1;
modeArg = SCA_RandomActuator::KX_RANDOMACT_FLOAT_NEGATIVE_EXPONENTIAL;
break;
default:
; /* error */
}
tmprandomact = new SCA_RandomActuator(gameobj,
seedArg,
modeArg,
paraArg1,
paraArg2,
randAct->propname);
baseact = tmprandomact;
}
break;
case ACT_VISIBILITY:
{
bVisibilityActuator *vis_act = (bVisibilityActuator *) bact->data;
KX_VisibilityActuator * tmp_vis_act = NULL;
bool v = ((vis_act->flag & ACT_VISIBILITY_INVISIBLE) != 0);
BGE: Occlusion culling and other performance improvements. Added occlusion culling capability in the BGE. More info: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.49/Game_Engine#BGE_Scenegraph_improvement MSVC, scons, cmake, Makefile updated. Other minor performance improvements: - The rasterizer was computing the openGL model matrix of the objects too many times - DBVT view frustrum culling was not properly culling behind the near plane: Large objects behind the camera were sent to the GPU - Remove all references to mesh split/join feature as it is not yet functional
2009-04-13 20:08:33 +00:00
bool o = ((vis_act->flag & ACT_VISIBILITY_OCCLUSION) != 0);
BGE set visible actuator, option to set visibility recursively to make managing visibility for collections of objects a lot easier. BGE Python api's ob.setVisible() also takes an optional recursive arg thats off by default
2008-09-05 16:22:14 +00:00
bool recursive = ((vis_act->flag & ACT_VISIBILITY_RECURSIVE) != 0);
Initial revision
2002-10-12 11:37:38 +00:00
BGE: Occlusion culling and other performance improvements. Added occlusion culling capability in the BGE. More info: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.49/Game_Engine#BGE_Scenegraph_improvement MSVC, scons, cmake, Makefile updated. Other minor performance improvements: - The rasterizer was computing the openGL model matrix of the objects too many times - DBVT view frustrum culling was not properly culling behind the near plane: Large objects behind the camera were sent to the GPU - Remove all references to mesh split/join feature as it is not yet functional
2009-04-13 20:08:33 +00:00
tmp_vis_act = new KX_VisibilityActuator(gameobj, !v, o, recursive);
Initial revision
2002-10-12 11:37:38 +00:00
baseact = tmp_vis_act;
}
break;
BGE patch: add state engine support in the logic bricks. This patch introduces a simple state engine system with the logic bricks. This system features full backward compatibility, multiple active states, multiple state transitions, automatic disabling of sensor and actuators, full GUI support and selective display of sensors and actuators. Note: Python API is available but not documented yet. It will be added asap. State internals =============== The state system is object based. The current state mask is stored in the object as a 32 bit value; each bit set in the mask is an active state. The controllers have a state mask too but only one bit can be set: a controller belongs to a single state. The game engine will only execute controllers that belong to active states. Sensors and actuators don't have a state mask but are effectively attached to states via their links to the controllers. Sensors and actuators can be connected to more than one state. When a controller becomes inactive because of a state change, its links to sensors and actuators are temporarily broken (until the state becomes active again). If an actuator gets isolated, i.e all the links to controllers are broken, it is automatically disabled. If a sensor gets isolated, the game engine will stop calling it to save CPU. It will also reset the sensor internal state so that it can react as if the game just started when it gets reconnected to an active controller. For example, an Always sensor in no pulse mode that is connected to a single state (i.e connected to one or more controllers of a single state) will generate a pulse each time the state becomes active. This feature is not available on all sensors, see the notes below. GUI === This system system is fully configurable through the GUI: the object state mask is visible under the object bar in the controller's colum as an array of buttons just like the 3D view layer mask. Click on a state bit to only display the controllers of that state. You can select more than one state with SHIFT-click. The All button sets all the bits so that you can see all the controllers of the object. The Ini button sets the state mask back to the object default state. You can change the default state of object by first selecting the desired state mask and storing using the menu under the State button. If you define a default state mask, it will be loaded into the object state make when you load the blend file or when you run the game under the blenderplayer. However, when you run the game under Blender, the current selected state mask will be used as the startup state for the object. This allows you to test specific state during the game design. The controller display the state they belong to with a new button in the controller header. When you add a new controller, it is added by default in the lowest enabled state. You can change the controller state by clicking on the button and selecting another state. If more than one state is enabled in the object state mask, controllers are grouped by state for more readibility. The new Sta button in the sensor and actuator column header allows you to display only the sensors and actuators that are linked to visible controllers. A new state actuator is available to modify the state during the game. It defines a bit mask and the operation to apply on the current object state mask: Cpy: the bit mask is copied to the object state mask. Add: the bits that set in the bit mask will be turned on in the object state mask. Sub: the bits that set in the bit mask will be turned off in the object state mask. Inv: the bits that set in the bit mask will be inverted in the objecyy state mask. Notes ===== - Although states have no name, a simply convention consists in using the name of the first controller of the state as the state name. The GUI will support that convention by displaying as a hint the name of the first controller of the state when you move the mouse over a state bit of the object state mask or of the state actuator bit mask. - Each object has a state mask and each object can have a state engine but if several objects are part of a logical group, it is recommended to put the state engine only in the main object and to link the controllers of that object to the sensors and actuators of the different objects. - When loading an old blend file, the state mask of all objects and controllers are initialized to 1 so that all the controllers belong to this single state. This ensures backward compatibility with existing game. - When the state actuator is activated at the same time as other actuators, these actuators are guaranteed to execute before being eventually disabled due to the state change. This is useful for example to send a message or update a property at the time of changing the state. - Sensors that depend on underlying resource won't reset fully when they are isolated. By the time they are acticated again, they will behave as follow: * keyboard sensor: keys already pressed won't be detected. The keyboard sensor is only sensitive to new key press. * collision sensor: objects already colliding won't be detected. Only new collisions are detected. * near and radar sensor: same as collision sensor.
2008-06-22 14:23:57 +00:00
case ACT_STATE:
{
bStateActuator *sta_act = (bStateActuator *) bact->data;
KX_StateActuator * tmp_sta_act = NULL;
tmp_sta_act =
new KX_StateActuator(gameobj, sta_act->type, sta_act->mask);
baseact = tmp_sta_act;
}
break;
2d-Filters feature and actuators.
2007-10-22 20:24:26 +00:00
case ACT_2DFILTER:
{
bTwoDFilterActuator *_2dfilter = (bTwoDFilterActuator*) bact->data;
SCA_2DFilterActuator *tmp = NULL;
Initial revision
2002-10-12 11:37:38 +00:00
2d-Filters feature and actuators.
2007-10-22 20:24:26 +00:00
RAS_2DFilterManager::RAS_2DFILTER_MODE filtermode;
switch(_2dfilter->type)
{
case ACT_2DFILTER_MOTIONBLUR:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_MOTIONBLUR;
break;
case ACT_2DFILTER_BLUR:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_BLUR;
break;
case ACT_2DFILTER_SHARPEN:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_SHARPEN;
break;
case ACT_2DFILTER_DILATION:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_DILATION;
break;
case ACT_2DFILTER_EROSION:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_EROSION;
break;
case ACT_2DFILTER_LAPLACIAN:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_LAPLACIAN;
break;
case ACT_2DFILTER_SOBEL:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_SOBEL;
break;
case ACT_2DFILTER_PREWITT:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_PREWITT;
break;
case ACT_2DFILTER_GRAYSCALE:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_GRAYSCALE;
break;
case ACT_2DFILTER_SEPIA:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_SEPIA;
break;
case ACT_2DFILTER_INVERT:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_INVERT;
break;
2d Filters updated, now you can use custom filter and write your own GLSL shader program to filter rendering result.
2007-11-06 12:16:12 +00:00
case ACT_2DFILTER_CUSTOMFILTER:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_CUSTOMFILTER;
break;
2d-Filters feature and actuators.
2007-10-22 20:24:26 +00:00
case ACT_2DFILTER_NOFILTER:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_NOFILTER;
break;
2d Filters updated, now you can use custom filter and write your own GLSL shader program to filter rendering result.
2007-11-06 12:16:12 +00:00
case ACT_2DFILTER_DISABLED:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_DISABLED;
break;
case ACT_2DFILTER_ENABLED:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_ENABLED;
break;
2d-Filters feature and actuators.
2007-10-22 20:24:26 +00:00
default:
filtermode = RAS_2DFilterManager::RAS_2DFILTER_NOFILTER;
break;
}
tmp = new SCA_2DFilterActuator(gameobj, filtermode, _2dfilter->flag,
BGE 2D Filters: filters run per scene now (fix for [#18152]) - it (slightly) breaks backward compatibility !!! Originally we had 2DFilters (m_filtermanager) stored in RenderTools. That way filters were stored globally and were being called once per each scene. This was producing two big problems: (1) performance and (2) flexibility of use. (1) Performance - To run the filters 2X == 2X slower (2) flexibility of use - Very often we want the filter in the scene but not in the UI for example. For those reasons I believe that 2DFilters with multiple scenes was very useless or unpredictable. I hope they work fine now. To make it work as before (2.4) you can simply recreate the 2dfilter actuators across the scenes. * * * * * Imagine that we have: (a) Main Scene (b) Overlay Scene in Main Scene the Z Buffer and RGB will be from the main scene. in Overlay Scene the Z Buffer will be from the Overlay Scene and the RBG buffer is from both [(a + 2D Filter) + b]. So in pseudo code if we have a,b,c,d,e scenes we have: (2DFilterE(2DFilterD(2DFilterC(2DFilterB(2DFilterA(a) + b) + c) + d) + e)
2010-03-03 06:38:47 +00:00
_2dfilter->float_arg,_2dfilter->int_arg,ketsjiEngine->GetRasterizer(),scene);
2d-Filters feature and actuators.
2007-10-22 20:24:26 +00:00
2d Filters updated, now you can use custom filter and write your own GLSL shader program to filter rendering result.
2007-11-06 12:16:12 +00:00
if (_2dfilter->text)
{
char *buf;
// this is some blender specific code
buf = txt_to_buf(_2dfilter->text);
if (buf)
{
Linux compilation problem, better fix
2009-05-10 21:30:30 +00:00
tmp->SetShaderText(buf);
2d Filters updated, now you can use custom filter and write your own GLSL shader program to filter rendering result.
2007-11-06 12:16:12 +00:00
MEM_freeN(buf);
}
}
2d-Filters feature and actuators.
2007-10-22 20:24:26 +00:00
baseact = tmp;
}
break;
Commit patch #8799: Realtime SetParent function in the BGE This patch consists in new KX_GameObject::SetParent() and KX_GameObject::RemoveParent() functions to create and destroy parent relation during game. These functions are accessible through python and through a new actuator KX_ParentActuator. Function documentation in PyDoc. The object keeps its orientation, position and scale when it is parented but will further rotate, move and scale with its parent from that point on. When the parent relation is broken, the object keeps the orientation, position and scale it had at that time. The function has no effect if any of the X/Y/Z scale of the object or its new parent are below Epsilon.
2008-04-06 18:30:52 +00:00
case ACT_PARENT:
{
bParentActuator *parAct = (bParentActuator *) bact->data;
int mode = KX_ParentActuator::KX_PARENT_NODEF;
BGE: user control to compound shape and setParent. Compound shape control ====================== 1) GUI control It is now possible to control which child shape is added to a parent compound shape in the Physics buttons. The "Compound" shape button becomes "Add to parent" on child objects and determines whether the child shape is to be added to the top parent compound shape when the game is stated. Notes: * "Compound" is only available to top parent objects (objects without parent). * Nesting of compound shape is not possible: a child object with "Add to parent" button set will be added to the top parent compound shape, regardless of its position in the parent-child hierarchy and even if its immediate parent doesn't have the "Add to parent" button set. 2) runtime control It is now possible to control the compound shape at runtime: The SetParent actuator has a new "Compound" button that indicates whether the object shape should be added to the compound shape of the parent object, provided the parent has a compound shape of course. If not, the object retain it's individual state while parented. Similarly, the KX_GameObject.setParent() python function has a new compound parameter. Notes: * When an object is dynamically added to a compound shape, it looses temporarily all its physics capability to the benefit of the parent: it cannot register collisions and the characteristics of its shape are lost (ghost, sensor, dynamic, etc.). * Nested compound shape is not supported: if the object being parented is already a compound shape, it is not added to the compound parent (as if the Compound option was not set in the actuator or the setParent function). * To ensure compatibility with old blend files, the Blender subversion is changed to 2.48.5 and the old blend files are automatically converted to match the old behavior: all children of a Compound object will have the "Add to parent" button set automatically. Child ghost control =================== It is now possible to control if an object should becomes ghost or solid when parented. This is only applicable if the object is not added to the parent compound shape (see above). A new "Ghost" button is available on the SetParent actuator to that effect. Similarly the KX_GameObject.setParent() python function has a new compound parameter. Notes: * This option is not applicable to sensor objects: they stay ghost all the time. * Make sure the child object does not enter in collision with the parent shape when the Ghost option if off and the parent is dynamic: the collision creates a reaction force but the parent cannot escape the child, so the force builds up and produces eratic movements. * The collision capability of an ordinary object (dynamic or static) is limited when it is parented: it becomes automatically static and can only detect dynamic and sensor objects. * A sensor object retain its full collision capability when parented: it can detect static and dynamic object. Python control ============== KX_GameObject.setParent(parent,compound,ghost): Sets this object's parent. Control the shape status with the optional compound and ghost parameters: compound=1: the object shape should be added to the parent compound shape (default) compound=0: the object should keep its individual shape. In that case you can control if it should be ghost or not: ghost=1 if the object should be made ghost while parented (default) ghost=0 if the object should be solid while parented Note: if the object type is sensor, it stays ghost regardless of ghost parameter parent: KX_GameObject reference or string (object name w/o OB prefix)
2009-05-21 13:32:15 +00:00
bool addToCompound = true;
bool ghost = true;
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
KX_GameObject *tmpgob = NULL;
Commit patch #8799: Realtime SetParent function in the BGE This patch consists in new KX_GameObject::SetParent() and KX_GameObject::RemoveParent() functions to create and destroy parent relation during game. These functions are accessible through python and through a new actuator KX_ParentActuator. Function documentation in PyDoc. The object keeps its orientation, position and scale when it is parented but will further rotate, move and scale with its parent from that point on. When the parent relation is broken, the object keeps the orientation, position and scale it had at that time. The function has no effect if any of the X/Y/Z scale of the object or its new parent are below Epsilon.
2008-04-06 18:30:52 +00:00
switch(parAct->type)
{
case ACT_PARENT_SET:
mode = KX_ParentActuator::KX_PARENT_SET;
tmpgob = converter->FindGameObject(parAct->ob);
BGE: user control to compound shape and setParent. Compound shape control ====================== 1) GUI control It is now possible to control which child shape is added to a parent compound shape in the Physics buttons. The "Compound" shape button becomes "Add to parent" on child objects and determines whether the child shape is to be added to the top parent compound shape when the game is stated. Notes: * "Compound" is only available to top parent objects (objects without parent). * Nesting of compound shape is not possible: a child object with "Add to parent" button set will be added to the top parent compound shape, regardless of its position in the parent-child hierarchy and even if its immediate parent doesn't have the "Add to parent" button set. 2) runtime control It is now possible to control the compound shape at runtime: The SetParent actuator has a new "Compound" button that indicates whether the object shape should be added to the compound shape of the parent object, provided the parent has a compound shape of course. If not, the object retain it's individual state while parented. Similarly, the KX_GameObject.setParent() python function has a new compound parameter. Notes: * When an object is dynamically added to a compound shape, it looses temporarily all its physics capability to the benefit of the parent: it cannot register collisions and the characteristics of its shape are lost (ghost, sensor, dynamic, etc.). * Nested compound shape is not supported: if the object being parented is already a compound shape, it is not added to the compound parent (as if the Compound option was not set in the actuator or the setParent function). * To ensure compatibility with old blend files, the Blender subversion is changed to 2.48.5 and the old blend files are automatically converted to match the old behavior: all children of a Compound object will have the "Add to parent" button set automatically. Child ghost control =================== It is now possible to control if an object should becomes ghost or solid when parented. This is only applicable if the object is not added to the parent compound shape (see above). A new "Ghost" button is available on the SetParent actuator to that effect. Similarly the KX_GameObject.setParent() python function has a new compound parameter. Notes: * This option is not applicable to sensor objects: they stay ghost all the time. * Make sure the child object does not enter in collision with the parent shape when the Ghost option if off and the parent is dynamic: the collision creates a reaction force but the parent cannot escape the child, so the force builds up and produces eratic movements. * The collision capability of an ordinary object (dynamic or static) is limited when it is parented: it becomes automatically static and can only detect dynamic and sensor objects. * A sensor object retain its full collision capability when parented: it can detect static and dynamic object. Python control ============== KX_GameObject.setParent(parent,compound,ghost): Sets this object's parent. Control the shape status with the optional compound and ghost parameters: compound=1: the object shape should be added to the parent compound shape (default) compound=0: the object should keep its individual shape. In that case you can control if it should be ghost or not: ghost=1 if the object should be made ghost while parented (default) ghost=0 if the object should be solid while parented Note: if the object type is sensor, it stays ghost regardless of ghost parameter parent: KX_GameObject reference or string (object name w/o OB prefix)
2009-05-21 13:32:15 +00:00
addToCompound = !(parAct->flag & ACT_PARENT_COMPOUND);
ghost = !(parAct->flag & ACT_PARENT_GHOST);
Commit patch #8799: Realtime SetParent function in the BGE This patch consists in new KX_GameObject::SetParent() and KX_GameObject::RemoveParent() functions to create and destroy parent relation during game. These functions are accessible through python and through a new actuator KX_ParentActuator. Function documentation in PyDoc. The object keeps its orientation, position and scale when it is parented but will further rotate, move and scale with its parent from that point on. When the parent relation is broken, the object keeps the orientation, position and scale it had at that time. The function has no effect if any of the X/Y/Z scale of the object or its new parent are below Epsilon.
2008-04-06 18:30:52 +00:00
break;
case ACT_PARENT_REMOVE:
mode = KX_ParentActuator::KX_PARENT_REMOVE;
tmpgob = NULL;
break;
}
KX_ParentActuator *tmpparact
= new KX_ParentActuator(gameobj,
mode,
BGE: user control to compound shape and setParent. Compound shape control ====================== 1) GUI control It is now possible to control which child shape is added to a parent compound shape in the Physics buttons. The "Compound" shape button becomes "Add to parent" on child objects and determines whether the child shape is to be added to the top parent compound shape when the game is stated. Notes: * "Compound" is only available to top parent objects (objects without parent). * Nesting of compound shape is not possible: a child object with "Add to parent" button set will be added to the top parent compound shape, regardless of its position in the parent-child hierarchy and even if its immediate parent doesn't have the "Add to parent" button set. 2) runtime control It is now possible to control the compound shape at runtime: The SetParent actuator has a new "Compound" button that indicates whether the object shape should be added to the compound shape of the parent object, provided the parent has a compound shape of course. If not, the object retain it's individual state while parented. Similarly, the KX_GameObject.setParent() python function has a new compound parameter. Notes: * When an object is dynamically added to a compound shape, it looses temporarily all its physics capability to the benefit of the parent: it cannot register collisions and the characteristics of its shape are lost (ghost, sensor, dynamic, etc.). * Nested compound shape is not supported: if the object being parented is already a compound shape, it is not added to the compound parent (as if the Compound option was not set in the actuator or the setParent function). * To ensure compatibility with old blend files, the Blender subversion is changed to 2.48.5 and the old blend files are automatically converted to match the old behavior: all children of a Compound object will have the "Add to parent" button set automatically. Child ghost control =================== It is now possible to control if an object should becomes ghost or solid when parented. This is only applicable if the object is not added to the parent compound shape (see above). A new "Ghost" button is available on the SetParent actuator to that effect. Similarly the KX_GameObject.setParent() python function has a new compound parameter. Notes: * This option is not applicable to sensor objects: they stay ghost all the time. * Make sure the child object does not enter in collision with the parent shape when the Ghost option if off and the parent is dynamic: the collision creates a reaction force but the parent cannot escape the child, so the force builds up and produces eratic movements. * The collision capability of an ordinary object (dynamic or static) is limited when it is parented: it becomes automatically static and can only detect dynamic and sensor objects. * A sensor object retain its full collision capability when parented: it can detect static and dynamic object. Python control ============== KX_GameObject.setParent(parent,compound,ghost): Sets this object's parent. Control the shape status with the optional compound and ghost parameters: compound=1: the object shape should be added to the parent compound shape (default) compound=0: the object should keep its individual shape. In that case you can control if it should be ghost or not: ghost=1 if the object should be made ghost while parented (default) ghost=0 if the object should be solid while parented Note: if the object type is sensor, it stays ghost regardless of ghost parameter parent: KX_GameObject reference or string (object name w/o OB prefix)
2009-05-21 13:32:15 +00:00
addToCompound,
ghost,
Commit patch #8799: Realtime SetParent function in the BGE This patch consists in new KX_GameObject::SetParent() and KX_GameObject::RemoveParent() functions to create and destroy parent relation during game. These functions are accessible through python and through a new actuator KX_ParentActuator. Function documentation in PyDoc. The object keeps its orientation, position and scale when it is parented but will further rotate, move and scale with its parent from that point on. When the parent relation is broken, the object keeps the orientation, position and scale it had at that time. The function has no effect if any of the X/Y/Z scale of the object or its new parent are below Epsilon.
2008-04-06 18:30:52 +00:00
tmpgob);
baseact = tmpparact;
break;
}
Merge of itasc branch. Project files, scons and cmake should be working. Makefile updated but not tested. Comes with Eigen2 2.0.6 C++ matrix library.
2009-09-24 21:22:24 +00:00
case ACT_ARMATURE:
{
bArmatureActuator* armAct = (bArmatureActuator*) bact->data;
KX_GameObject *tmpgob = converter->FindGameObject(armAct->target);
KX_GameObject *subgob = converter->FindGameObject(armAct->subtarget);
BL_ArmatureActuator* tmparmact = new BL_ArmatureActuator(gameobj, armAct->type, armAct->posechannel, armAct->constraint, tmpgob, subgob, armAct->weight);
baseact = tmparmact;
break;
}
Initial revision
2002-10-12 11:37:38 +00:00
default:
; /* generate some error */
}
if (baseact)
{
baseact->SetExecutePriority(executePriority++);
uniquename += "#ACT#";
uniqueint++;
CIntValue* uniqueval = new CIntValue(uniqueint);
uniquename += uniqueval->GetText();
uniqueval->Release();
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
baseact->SetName(bact->name);
Initial revision
2002-10-12 11:37:38 +00:00
//gameobj->SetProperty(uniquename,baseact);
gameobj->AddActuator(baseact);
converter->RegisterGameActuator(baseact, bact);
Various mem leaks related to CValue reference count fixed
2008-03-01 19:46:50 +00:00
// done with baseact, release it
baseact->Release();
Initial revision
2002-10-12 11:37:38 +00:00
}
bact = bact->next;
}
}
2d-Filters feature and actuators.
2007-10-22 20:24:26 +00:00
Copy Permalink