Platforms Players can Ride Version 1.1
by Cinder Games · in Torque Game Engine · 01/27/2007 (4:34 pm) · 268 replies
Platforms Players can Ride Version 1.2!!!!!!
with Dynamic object Attachment
###################################
##This post has been edited and updated 2/13/07 ##
##################################

Here's the new and improved files you'd need.
Version 1.2
subvoicestudios.com/~ramensama/torque1.5.2.zip
1.7.2008
What's new? There are several new features and improvements.
1) Removed or reduced jitter caused by multiple players on a platform
2) Support for new items on platforms. Now Items, Shapes, lights, particle emitters, and possibly others!
3) Object to object Attachment. Players can now attach Items, shapes, etc to them. Even the attached objects can attach more objects to themselves!
4) Reduced the number of code changes.... a little.
This must be extracted in the base torque directory where it's installed...
c:/torque
or whatever. it's designed to simply overwrite a stock install of torque.
Afterwards you must add pathshape.cc and pathshape.h to your project in visual studio or whatever.

To attach an object, you must use this syntax:
ParentObject.attachChild(ChildObject);
So if you want to attach an item to the player, move the player towards the object, press F11 to get the object ID. Press ~ and type in $player.attachchild(ObjectID);
The item is now attached to the player.
$player.detachchild(ObjectID); is how to remove the object.
Ancient Versions of the code can be found here.
These are version 1.1, not the newest version and probably have bugs that the newer code does not.
Here's a link to the new updated code. It's for torque 1.4...
subvoicestudios.com/~ramensama/torque.zip
And for Torque 1.5
subvoicestudios.com/~ramensama/torque1.5.zip
with Dynamic object Attachment
###################################
##This post has been edited and updated 2/13/07 ##
##################################

Here's the new and improved files you'd need.
Version 1.2
subvoicestudios.com/~ramensama/torque1.5.2.zip
1.7.2008
What's new? There are several new features and improvements.
1) Removed or reduced jitter caused by multiple players on a platform
2) Support for new items on platforms. Now Items, Shapes, lights, particle emitters, and possibly others!
3) Object to object Attachment. Players can now attach Items, shapes, etc to them. Even the attached objects can attach more objects to themselves!
4) Reduced the number of code changes.... a little.
This must be extracted in the base torque directory where it's installed...
c:/torque
or whatever. it's designed to simply overwrite a stock install of torque.
Afterwards you must add pathshape.cc and pathshape.h to your project in visual studio or whatever.

To attach an object, you must use this syntax:
ParentObject.attachChild(ChildObject);
So if you want to attach an item to the player, move the player towards the object, press F11 to get the object ID. Press ~ and type in $player.attachchild(ObjectID);
The item is now attached to the player.
$player.detachchild(ObjectID); is how to remove the object.
Ancient Versions of the code can be found here.
These are version 1.1, not the newest version and probably have bugs that the newer code does not.
Here's a link to the new updated code. It's for torque 1.4...
subvoicestudios.com/~ramensama/torque.zip
And for Torque 1.5
subvoicestudios.com/~ramensama/torque1.5.zip
#102
You're right, shapeBase does appear to include those collision functions. I don't know why that doesn't make collision detection work when the pathshape is in motion.
I haven't been working on this recently. But FWIW here's what my experience was.
I want my pathshapes to push the player out of the way, like you but maybe a little simpler. My initial goal was just to get the pathshape to report collision on its own. I wasn't getting a freakin response from script such as
I managed to get this working by adding the following code to pathShape.cc -- actually to my own hacked version called joeShape.cc:
With this, I actually get my onCollision function to fire off when the shape hits the player.
My next step is, I think, to apply an impulse or whatever to get the player out of the damn way when collision is detected. In your case, to smoothly push the player around, I wonder if you might need to "attach" the player to the side of your moving shape ... argh my brain hurts already :)
CAVEAT: I haven't shared this code before because I DON'T KNOW WTF I'M DOING. It's a mess. I just kept hacking till it worked. It may be a really foolish "solution". I'm posting it anyway because I hope it helps - I'll be VERY interested if you can solve your problems - and, maybe someone who really groks this stuff will step in and light the way.
09/07/2007 (7:08 pm)
@TerenceYou're right, shapeBase does appear to include those collision functions. I don't know why that doesn't make collision detection work when the pathshape is in motion.
I haven't been working on this recently. But FWIW here's what my experience was.
I want my pathshapes to push the player out of the way, like you but maybe a little simpler. My initial goal was just to get the pathshape to report collision on its own. I wasn't getting a freakin response from script such as
function TestJoeShape::onCollision(%this,%obj,%col){
error("A collision with a testjoeshape has occurred");
}I managed to get this working by adding the following code to pathShape.cc -- actually to my own hacked version called joeShape.cc:
//------trying to get collision working ... below is from player.cc ...
static MatrixF IMat(1); // need for collision shite
bool JoeShape::buildPolyList(AbstractPolyList* polyList, const Box3F&, const SphereF&)
{
// Collision with the player is always against the player's object
// space bounding box axis aligned in world space.
Point3F pos;
getTransform().getColumn(3,&pos);
IMat.setColumn(3,pos);
polyList->setTransform(&IMat, Point3F(1.0f,1.0f,1.0f));
polyList->setObject(this);
polyList->addBox(mObjBox);
return true;
}
void JoeShape::buildConvex(const Box3F& box, Convex* convex)
{
if (mShapeInstance == NULL)
return;
// These should really come out of a pool
mConvexList->collectGarbage();
Box3F realBox = box;
mWorldToObj.mul(realBox);
realBox.min.convolveInverse(mObjScale);
realBox.max.convolveInverse(mObjScale);
if (realBox.isOverlapped(getObjBox()) == false)
return;
Convex* cc = 0;
CollisionWorkingList& wl = convex->getWorkingList();
for (CollisionWorkingList* itr = wl.wLink.mNext; itr != &wl; itr = itr->wLink.mNext) {
if (itr->mConvex->getType() == BoxConvexType &&
itr->mConvex->getObject() == this) {
cc = itr->mConvex;
break;
}
}
if (cc)
return;
// Create a new convex.
BoxConvex* cp = new OrthoBoxConvex;
mConvexList->registerObject(cp);
convex->addToWorkingList(cp);
cp->init(this);
mObjBox.getCenter(&cp->mCenter);
cp->mSize.x = mObjBox.len_x() / 2.0f;
cp->mSize.y = mObjBox.len_y() / 2.0f;
cp->mSize.z = mObjBox.len_z() / 2.0f;
}
void JoeShape::updateWorkingCollisionSet() // a horrible frankenstein of the funcs from player.cc & item.cc
{
bool updateSet = false;
Box3F convexBox = mConvex.getBoundingBox(getTransform(), getScale());
// F32 l = (newLen * 1.1f) + 0.1f; // from Convex::updateWorkingList
F32 l = 0.1f; // joe changed - not doing velocity
const Point3F lPoint( l, l, l );
convexBox.min -= lPoint;
convexBox.max += lPoint;
// Check containment
if (mWorkingQueryBox.min.x != -1e9f)
{
if (mWorkingQueryBox.isContained(convexBox) == false)
{
// Needed region is outside the cached region. Update it.
updateSet = true;
}
else
{
// We can leave it alone, we're still inside the cached region
}
}
else
{
// Must update
updateSet = true;
}
// Actually perform the query, if necessary
if (updateSet == true)
{
const Point3F twolPoint( 2.0f * l, 2.0f * l, 2.0f * l );
mWorkingQueryBox = convexBox;
mWorkingQueryBox.min -= twolPoint;
mWorkingQueryBox.max += twolPoint;
disableCollision();
mConvex.updateWorkingList( mWorkingQueryBox, sCollisionMask );
enableCollision();
}
}
void JoeShape::checkCollision()
// This is a clusterhack of stuff from player.cc & item.cc updatePos() funcs.
// Trying to check collision, basically. It works, but, dude ...
{
Point3F pos;
mObjToWorld.getColumn(3,&pos);
CollisionList collisionList;
static Polyhedron sBoxPolyhedron;
static ExtrudedPolyList sExtrudedPolyList;
static EarlyOutPolyList sEarlyOutPolyList;
MatrixF collisionMatrix(true);
U32 mask = sCollisionMask;
bool doToughCollision = true;
if (doToughCollision)
{
// Build list from convex states here...
collisionMatrix.setColumn(3, pos);
Box3F wBox = getObjBox();
collisionMatrix.mul(wBox);
Box3F testBox = wBox;
Point3F oldMin = testBox.min;
Point3F oldMax = testBox.max;
testBox.min.setMin(oldMin);
testBox.max.setMin(oldMax);
sEarlyOutPolyList.clear();
sEarlyOutPolyList.mNormal.set(0,0,0);
sEarlyOutPolyList.mPlaneList.setSize(6);
sEarlyOutPolyList.mPlaneList[0].set(wBox.min,VectorF(-1,0,0));
sEarlyOutPolyList.mPlaneList[1].set(wBox.max,VectorF(0,1,0));
sEarlyOutPolyList.mPlaneList[2].set(wBox.max,VectorF(1,0,0));
sEarlyOutPolyList.mPlaneList[3].set(wBox.min,VectorF(0,-1,0));
sEarlyOutPolyList.mPlaneList[4].set(wBox.min,VectorF(0,0,-1));
sEarlyOutPolyList.mPlaneList[5].set(wBox.max,VectorF(0,0,1));
CollisionWorkingList& eorList = mConvex.getWorkingList();
CollisionWorkingList* eopList = eorList.wLink.mNext;
while (eopList != &eorList)
{
if ((eopList->mConvex->getObject()->getType() & mask) != 0)
{
Box3F convexBox = eopList->mConvex->getBoundingBox();
if (testBox.isOverlapped(convexBox))
{
eopList->mConvex->getPolyList(&sEarlyOutPolyList);
if (sEarlyOutPolyList.isEmpty() == false)
break;
}
}
eopList = eopList->wLink.mNext;
}
if (!(sEarlyOutPolyList.isEmpty()))
{
collisionMatrix.setColumn(3, pos);
sBoxPolyhedron.buildBox(collisionMatrix, mObjBox);
// Build extruded polyList...
VectorF vector(0,0,0);
sExtrudedPolyList.extrude(sBoxPolyhedron, vector);
sExtrudedPolyList.setVelocity(vector);
sExtrudedPolyList.setCollisionList(&collisionList);
CollisionWorkingList& rList = mConvex.getWorkingList();
CollisionWorkingList* pList = rList.wLink.mNext;
while (pList != &rList)
{
if ((pList->mConvex->getObject()->getType() & mask) != 0)
{
Box3F convexBox = pList->mConvex->getBoundingBox();
if (testBox.isOverlapped(convexBox))
{
pList->mConvex->getPolyList(&sExtrudedPolyList);
}
}
pList = pList->wLink.mNext;
}
if (collisionList.t < 1.0)
{
// Set to collision point
F32 dt = 1.0f * collisionList.t;
// Pick the most resistant surface
F32 bd = 0;
Collision* collision = 0;
for (int c = 0; c < collisionList.count; c++)
{
Collision &cp = collisionList.collision[c];
F32 dot = -mDot(vector,cp.normal);
if (dot > bd)
{
bd = dot;
collision = &cp;
}
}
if (collision)
{
Con::printf("joeshape ENGINE collision triggered");
}
}
else
{
Con::printf("joeshape ENGINE collisionList.t > 1.0f");
if (!isGhost()) {
// Joe - here's where SHAPE hits PLAYER. I don't know why it's here.
// In any case, this is the spot to trigger whatever.
Con::executef(mDataBlock,2,"onCollision",scriptThis());
}
}
}
}
}With this, I actually get my onCollision function to fire off when the shape hits the player.
My next step is, I think, to apply an impulse or whatever to get the player out of the damn way when collision is detected. In your case, to smoothly push the player around, I wonder if you might need to "attach" the player to the side of your moving shape ... argh my brain hurts already :)
CAVEAT: I haven't shared this code before because I DON'T KNOW WTF I'M DOING. It's a mess. I just kept hacking till it worked. It may be a really foolish "solution". I'm posting it anyway because I hope it helps - I'll be VERY interested if you can solve your problems - and, maybe someone who really groks this stuff will step in and light the way.
#103
I'm trying for a different solution to a similar problem and was wondering if anyone has any thoughts:
I have a "hold player" feature working great - if the pathShape's "holdChild" flag is set, it drags the player(s?) along no matter where they go. There is a script callback "onLostSurface" where the actual detachment occurs. In my case, the script casts a ray to see if the player is above the pathshape ... if so it does not release from the shape(if the flag is set), otherwise it does. This lets me jump while on the platform without being left behind but still allows the player to simply walk off and detach. It also allows script to respond to a player leaving the shape when they are not locked.
This is great, but it's only half of what I want to accomplish. You can refuse to detach a player, but they can still run as far from the shape as they want (they just drag along with the shape from whatever distance). I can force the player back to the platform by setting it's position, but this isn't what I want (it's a warp effect).
I really want to limit relative movement of the player on the platform. In other words: define a radius and/or bounding area and use a flag to determine if the player is "locked" to the area, then cancel any player moves that would take them outside the limits (probably along with another script callback). The needed information seems to be in an "attachInfo" structure (defined in sceneObject.h) .... I'm running into a conceptual problem about where the actual movement of the player relative to the pathshape occurs (not to mention vectors and matrixes confuse the poop out of me).
I was looking at the movement override used for mounted players in the player::updatePos() function, but it looks like maybe what I want is in player::updateMove(). Before I spend HOURS on this --- am I even in the right place?!? Any thoughts??
09/08/2007 (11:50 am)
@joe: Thanks for the code ... this'll really help me!I'm trying for a different solution to a similar problem and was wondering if anyone has any thoughts:
I have a "hold player" feature working great - if the pathShape's "holdChild" flag is set, it drags the player(s?) along no matter where they go. There is a script callback "onLostSurface" where the actual detachment occurs. In my case, the script casts a ray to see if the player is above the pathshape ... if so it does not release from the shape(if the flag is set), otherwise it does. This lets me jump while on the platform without being left behind but still allows the player to simply walk off and detach. It also allows script to respond to a player leaving the shape when they are not locked.
This is great, but it's only half of what I want to accomplish. You can refuse to detach a player, but they can still run as far from the shape as they want (they just drag along with the shape from whatever distance). I can force the player back to the platform by setting it's position, but this isn't what I want (it's a warp effect).
I really want to limit relative movement of the player on the platform. In other words: define a radius and/or bounding area and use a flag to determine if the player is "locked" to the area, then cancel any player moves that would take them outside the limits (probably along with another script callback). The needed information seems to be in an "attachInfo" structure (defined in sceneObject.h) .... I'm running into a conceptual problem about where the actual movement of the player relative to the pathshape occurs (not to mention vectors and matrixes confuse the poop out of me).
I was looking at the movement override used for mounted players in the player::updatePos() function, but it looks like maybe what I want is in player::updateMove(). Before I spend HOURS on this --- am I even in the right place?!? Any thoughts??
#104
A smarter way is to go through the collision mesh and pick out collision information to re-create the bounds but unfortunately I think the code is too much of a beast to tackle right now, I still need to level design out 2 more levels by this month as well as be the programmer...so...gotta keep things going.
In pathshape.h add some fields for the datablock
in pathshape.h add a function in PathShape
In pathshape.cc
@Joe - thanks for the code..Yep...looks quite scary..i'm not that brave yet;P
09/09/2007 (6:46 pm)
I looked at the collision code for several days but instead fell back to implementing a user definable bounds box over the platform. I will probably look this over in the future as the code causes quite a bit of jitter (caused by me detecting the player past the bounds and resetting him inside of the bound area) but it works well enough for now. What I do is detect if the box is in motion and apply my predefined bounds.A smarter way is to go through the collision mesh and pick out collision information to re-create the bounds but unfortunately I think the code is too much of a beast to tackle right now, I still need to level design out 2 more levels by this month as well as be the programmer...so...gotta keep things going.
In pathshape.h add some fields for the datablock
struct PathShapeData: public StaticShapeData {
...
public:
PathShapeData();
F32 boundWidth;
F32 boundHalfWidth; // Half the width (x)
F32 boundHeight;
F32 boundHalfHeight; // Half the height (y)
};in pathshape.h add a function in PathShape
class PathShape: public StaticShape
{
....
void adjustChild();
};In pathshape.cc
PathShapeData::PathShapeData()
{
boundHalfWidth = 0.0f;
boundHalfHeight = 0.0f;
}
void PathShapeData::initPersistFields()
{
Parent::initPersistFields();
addField("boundWidth",TypeF32,Offset(boundWidth,PathShapeData));
addField("boundHeight",TypeF32,Offset(boundHeight,PathShapeData));
}
void PathShapeData::packData(BitStream* stream)
{
Parent::packData(stream);
stream->write(boundWidth);
stream->write(boundHeight);
}
void PathShapeData::unpackData(BitStream* stream)
{
Parent::unpackData(stream);
stream->read(&boundWidth);
if (boundWidth != 0.0f)
boundHalfWidth = boundWidth/2.0f;
stream->read(&boundHeight);
if (boundHeight != 0.0f)
boundHalfHeight = boundHeight/2.0f;
}
void PathShape::processTick(const Move* move)
{
// client and server
Parent::processTick(move);
if (gEditingMission)
return;
// Move to new time
advancePosition(TickMs);
MatrixF mat;
interpolateMat(mPosition,&mat);
UpdateXformChange(mat);
for (U32 i=0; i < getNumChildren(); i++) {
SceneObject *o = getChild(i);
o->updateParentedTransform(); //update the position of the child object
}
Parent::setTransform(mat);
// Adjust child position based on bounds if pathshape is moving
if (mState != PathShape::Stop)
adjustChild();
}
void PathShape::adjustChild()
{
if (mDataBlock->boundHalfHeight == 0.0f ||
mDataBlock->boundHalfWidth == 0.0f)
return;
Point3F pos = getPosition();
for (U32 i=0; i < getNumChildren(); i++)
{
SceneObject *o = getChild(i);
Point3F childPos;
childPos = o->getPosition();
// Check Width
F32 distance = mFabs(childPos.x - pos.x);
if (distance >= mDataBlock->boundHalfWidth)
{
distance = distance - mDataBlock->boundHalfWidth;
if (childPos.x > pos.x)
childPos.x -= distance;
else
childPos.x += distance;
o->setPosition(childPos);
}
// Check Height
distance = mFabs(childPos.y - pos.y);
if (distance >= mDataBlock->boundHalfHeight)
{
distance = distance - mDataBlock->boundHalfHeight;
if (childPos.y > pos.y)
childPos.y -= distance;
else
childPos.y += distance;
o->setPosition(childPos);
}
}
}@Joe - thanks for the code..Yep...looks quite scary..i'm not that brave yet;P
#105
@Joe: I think that the collision in Terrence's issue is failing with the blocker shapes, not the pathshape itself. I *think* that the collision is failing because the shape without collision checking is moving past the player before the player does it's collision check. I think collision code needs to be in the shapebase (or something) in order to work for terrence's problem. Pathshape collisions are also important!
09/11/2007 (10:54 am)
@Terrence: That's a nice quick-fixer (way less warpy than my current fix). I'm still trying to figure out how to override the move in the player object's move methods to avoid going out of bounds at all, if I get a less jumpy situation - I'll post it.@Joe: I think that the collision in Terrence's issue is failing with the blocker shapes, not the pathshape itself. I *think* that the collision is failing because the shape without collision checking is moving past the player before the player does it's collision check. I think collision code needs to be in the shapebase (or something) in order to work for terrence's problem. Pathshape collisions are also important!
#106
Here's an odd situation that I've noticed before - but never became an issue until now: what does the pathshape use as the "center" for it's position?
Removed Image
Marker Object 1565, player object 1615, and pathshape object 1644 all have the exact same position and rotation. The pathshape appears to be roughly centered on the Y axis and at the extreme positive extent of the X axis.
This is throwing off all of my relative math (player position 1 0 0 != pathshape position 1 0 0). I've had to tweak my methods to make the solution above work. Has anyone else noticed this? It has been consistent for me since I first added the resource - did I miss (or add?) something in my merge?
09/11/2007 (11:15 am)
@Terrence: is your platform centering correctly?Here's an odd situation that I've noticed before - but never became an issue until now: what does the pathshape use as the "center" for it's position?
Removed Image
Marker Object 1565, player object 1615, and pathshape object 1644 all have the exact same position and rotation. The pathshape appears to be roughly centered on the Y axis and at the extreme positive extent of the X axis.
This is throwing off all of my relative math (player position 1 0 0 != pathshape position 1 0 0). I've had to tweak my methods to make the solution above work. Has anyone else noticed this? It has been consistent for me since I first added the resource - did I miss (or add?) something in my merge?
#107
I'm guessing i'll have time for torque again in a couple weeks. At that point i'll continue my work on this code. Maybe by then you guys will have come up with some great solutions to some of the problems it has.
To answer a quick question on how some of this works...
Everytime the pathshape moves, it instanly moves the player object the exact same amount. I could imagine this could cause some issues with collisions.
@Kent
I believe torque uses the Origin of the Shape to determine it's position. not it's world box center.
I'll try to keep more active with this thread.
09/11/2007 (3:42 pm)
Wow, Alot of people seem to be using my code these days. unfortunately, i've been preoccupied with real life stuff to the point where i've had to neglect torque.I'm guessing i'll have time for torque again in a couple weeks. At that point i'll continue my work on this code. Maybe by then you guys will have come up with some great solutions to some of the problems it has.
To answer a quick question on how some of this works...
Everytime the pathshape moves, it instanly moves the player object the exact same amount. I could imagine this could cause some issues with collisions.
@Kent
I believe torque uses the Origin of the Shape to determine it's position. not it's world box center.
I'll try to keep more active with this thread.
#108
It seems to me that every other object (Shapebase, TSStatic, Player, Vehicle, etc.) uses the center point when determining their position. If the pathshape has a different way of determining it's "position" than the player (and all other objects) - how do you ever figure out their precise relative positions to each other in the world?
09/13/2007 (8:34 am)
Ok now for a dumb question: So what command is it to get the "world box center" for the pathshape?It seems to me that every other object (Shapebase, TSStatic, Player, Vehicle, etc.) uses the center point when determining their position. If the pathshape has a different way of determining it's "position" than the player (and all other objects) - how do you ever figure out their precise relative positions to each other in the world?
#109
10/18/2007 (5:01 pm)
Well, this is a question that goes back a long ways, but the common solution isn't working. Using 1.5.2...I keep getting the console error: Unable to instantiate a non-conobject PathShapeData (also same error for PathShape). I included the files into the project on a clean version and compiled. It compiled without a problem, yet it still won't work. What are the possible causes aside from not including the files in the project ('cause I did)?
#110
I was having some jittering issues but I *think*a full clean & rebuild fixed the issue. Don't ask me how that caused jittering though...
Edit again..
Okay, so I found another jitter bug (lol!) and this one wasn't fixed by a clean rebuild.
I wanted to be able to attach StaticShapes to PathShapes so I added updateParentedRender() to StaticShape's interpolateTick method. I'm using cubes as my test model. The cubes attach just fine but they jitter as if there was no update call.
My player is riding smoothly. The un/packUpdate calls in staticShape transfer the entire obj to world matrix. Could this be screwing things up?
10/24/2007 (9:45 pm)
This is a great resource. Though I'd love an update.I was having some jittering issues but I *think*a full clean & rebuild fixed the issue. Don't ask me how that caused jittering though...
Edit again..
Okay, so I found another jitter bug (lol!) and this one wasn't fixed by a clean rebuild.
I wanted to be able to attach StaticShapes to PathShapes so I added updateParentedRender() to StaticShape's interpolateTick method. I'm using cubes as my test model. The cubes attach just fine but they jitter as if there was no update call.
My player is riding smoothly. The un/packUpdate calls in staticShape transfer the entire obj to world matrix. Could this be screwing things up?
#111
Yourself=smooth ride
someone else= jitters.
It seems the camera isn't jittering, just the player model. It is a great resource tho. :)
10/25/2007 (4:19 am)
The only real problem I've noticed with this resource is the players jittering. Yourself=smooth ride
someone else= jitters.
It seems the camera isn't jittering, just the player model. It is a great resource tho. :)
#112
10/25/2007 (4:40 am)
I'll look into that later. I think alot of our problems stem from the player class. It's movement logic is terribly bloated but for the most part necessary. For one, the player's velocity doesn't take into account the velocity of the object it is attached to. This screws up jumping on moving objects. Something I'd like to fix.
#113
10/25/2007 (7:27 am)
I modify this resource to support movement without path and use the velocity to move the shape. But the movement is not that smooth, so anyone is familiar with the interpolation can help explain how it was done? Thanks.
#114
In SceneObject.cc line 2327 change:
to
This fixed the issues with my attached StaticShape objects jittering.
Somehow the player was correcting itself (probably because it is the control object). I think this might correct your issues as well Mike.
10/26/2007 (6:05 am)
I found and fixed a bug!In SceneObject.cc line 2327 change:
mat.mul(four,getRenderTransform());
to
mat.mul(four,getTransform());
This fixed the issues with my attached StaticShape objects jittering.
Somehow the player was correcting itself (probably because it is the control object). I think this might correct your issues as well Mike.
#115
Anyone can have a quick look in my code and see if something pop up in their head "hey that's wrong"!? http://rafb.net/p/9e3R4c36.html
Help greatly appreciated.
oh, I integerated Brian "bugfix", hadn't seen any difference.
10/29/2007 (3:08 pm)
Hi, dunno if i'm in the good thread for this but i'm using the ressource. I'm trying just like Steven Chiu to modify the ressource to get another movement than a path to follow. Attachement seem to work fine I changed pathShape to FloatingPlatform everywhere but thing is my platform motion is not smooth, and player don't follow smoothly it's position. Still, I though I used packUpdate unpackUpdate processTick and interpolateTick correctly so I don't know what's wrong. The platform move is based on 2 variables, mAmplitude and mTime which I update in processTick and set the mask bit every time I change it.Anyone can have a quick look in my code and see if something pop up in their head "hey that's wrong"!? http://rafb.net/p/9e3R4c36.html
Help greatly appreciated.
oh, I integerated Brian "bugfix", hadn't seen any difference.
#116
I've completely revamped this whole system so I'm not gonna promise anything but when I get home tonight I'll give your platform a go and see if I can get it to work.
There are some serious issues with the way this resource operates. I've worked out most of them but there is still work to be done.
10/29/2007 (3:29 pm)
@Laval Student:I've completely revamped this whole system so I'm not gonna promise anything but when I get home tonight I'll give your platform a go and see if I can get it to work.
There are some serious issues with the way this resource operates. I've worked out most of them but there is still work to be done.
#117
11/07/2007 (6:46 am)
I replace the platform DTS with my own one, but player slide away when jump on it. Anyone had the same problem before?
#118
11/07/2007 (11:46 am)
Steven, Ive had this problem before aswell and it has to do with the collision mesh. Im not entirely sure what the problem is but it does have to do with the collision mesh. Make sure its convex and not concave.
#119
It doesnt have any effect. What can I do to make them move automaticaly without needing a collision?
11/07/2007 (2:28 pm)
I am trying to get the pathshape to move as soon as the mission starts. If I place this in the onadd function:%state = %obj.getstate();
if (%state == 2) // 2 == stopped.
{
schedule(1000, 0, %obj.setState("forward"));
//%obj.setState("forward");
%obj.followpath(%obj.Path);
}It doesnt have any effect. What can I do to make them move automaticaly without needing a collision?
#120
11/07/2007 (3:13 pm)
Adam, I'll check the collision mesh again today. Thanks for sharing this.
Torque 3D Owner Caylo Gypsyblood
I fixed this problem by making the player move much slower when ON a pathshape (I also removed the ability to JUMP unless the pathshape is at a landing zone).