Platforms Players can Ride Version 1.1

#141 I'll definitely try it when I get some time this weekend. Will this also work in TGEA?

#142 I've been trying to make time to try it as well, but as an artist it takes a big chunk of time to work my way through. I am grateful for this though, and in fact have been watching the thread since the very first post a year ago.

#143 @Jaime - probably need to use windiff for TGEA.. i don't own TGEA, so i don't know what it'd take for it to work.

#144 Great work Ramen.
I too have been following this from the beginning.
It has helped me with some key aspects of my game and I will credit you fully for it.

#145 I havn't checked in on this for a bit - I ended up working on my own mover class (not locked to a path ) trying to solve that modelling problem I had a few posts up. Ha - after I got it moving, bamo still the same origin problem! That's HOURS trying to fix a model issue with programing ... but hey at least the new class is cool!

Anyhow, after reading about the "jitter" problem - I checked my own mover class which uses the same parent/child setup. I am not experiencing any jitter problems with the item/staticshape/AI player-animation/particle node. And I also don't need to do the "updateParentedRender" at the subclass (level).

This surprised me because I thought I'd copied the heirchial coordinate stuff mostly from this resource.

So I went through it to see what I'd done differently. The only thing I could find is that in my movingItem class, I call the "UpdateXformChange" / "updateParentedTransform" loop in two different places. Once in the process tick - like the pathshape. I do it again in my updatePos() function just before I change the parent object's transform. In retrospect - this did have something to do with jitter.

I'm working with the "ancient" version of the code. I don't have things set up to easily test the pathshape class at the moment, so this is only a suggestion for something to try. The equvelent to what I'm doing for the pathshape would be:

void PathShape::setPosition(F32 pos)
{
   mPosition = mClampF(pos,mNodeBase,mNodeBase + mNodeCount - 1);
   MatrixF mat;
   interpolateMat(mPosition,&mat);
   // KGB: Let everyone know that the change has happened
   UpdateXformChange(mat);
        for (U32 i=0; i < getNumChildren(); i++) {
            SceneObject *o = getChild(i);
	    o->updateParentedTransform(); //update the position of the child object
        }
   // End change
   Parent::setTransform(mat);
   setMaskBits(PositionMask);
}

Note: I had problems when I tried to do the loop in a secondary function - I'm not sure why. But try this with the code directly - not wrapped in the new "updateChildTransform" function.

I'm posting this untested because IF that works, you can eliminate the changes to static shape and item and avoid putting the updateRender code in the interpolateTick of the gamebase(and player) - which is way cleaner. If we can avoid having to update every subclass, that would be a bonus. One way or the other - I'll try it out middle of next week if nobody else (with a project set up and ready to go) gets to it first.

#146 @Ramen - Suggestion/Request: I noticed that you decided to change these function names.

SceneObject::updateParentedTransform() to SceneObject::updateChildTransform()
SceneObject::updateParentedRender() to SceneObjet::updateRenderChangesByParent()

Would you consider reverting back to the original names? It doesn't really matter what you decide to call something, but once you choose it and release it - it's best to stick with it. This makes it easier to keep the resource integrated with a larger codebase (that may use the function for additional things once integrated) - and easier to discuss code changes involving the underlying functions.

#147 Final Question: Has anyone played with wheeled vehicles and this?

#148 @Kent I changed the names of the functions to better explain it's purpose.
After not touching the code for awhile, i couldn't quite tell what the functions did by looking at the name.

Using the newer code requires far less changes then before. No changes are needed to shapebase.cc or item.cc or many others since it's mostly taken care of in sceneobject.cc

I did at one point in time attach a player to the torque buggy. worked somewhat but there was some issues with player collisions with the buggy, but it moved the player around. I haven't tried it using the newer code.

#149 Would this work to attach multiple flying vehicles to a larger flying vehicle?

#150 Hey there, guys. I got the new resource into a stock 1.5.2 build of the engine, and the player is moving smoothly. However, if I am not looking directly to the floor (camera angle-wise) the pathshape seems to be jerking quite violently. It only jerks on the screen when I am riding the pathshape. If I am looking at it from the ground, it looks like it is moving smoothly.

Any clues?

#151 Maybe you didn't do it right? I'm pretty certain i got all that jerking taken care of.

#152 I don't know if seeing a video would help, but in case it does, here it is.

doubleedgesoftware.com/problem_pics/jerking_platform.wmv

I am stumped on this one.

#153 Seeing that video, i gotta ask. are you using the most current files? i places a few other objects on the dock in that latest mission file for no reason, but i didn't see them in your video.

Also, does this happen in 3rd person view as well?

#154 Yes, it happens in third person view as well. I removed a lot of the extra items (except for the one dock and a few weapon/ammo items) so that I could see if the problem was being caused by anything else.

The only difference that I failed to mention is that I am using a different player model. Would that cause the issue?

#155 Well...... does this jitter happen with the default player model? i've not tested it with any other model.

#156 Good News, I've updated my local code to include dynamic attachement with relation to nodes!!!!!!


What this means is you can "Parent in Place" to a node.

Which means when the node moves, the child object moves with it. What can this be used for?

Well it could be used to put arrows into a player's body and have them animate along with the mesh.


I put two swords into kork here, one attached to "Bip01 Head" and another attached to "bip R Thigh"

I manually positioned them, then did the attachment code.

This is not the same as "mounting an object" because firstly, it's parented in place, not repositioned to the node's transform or anything, how it could be used like that as well.

IF there's interest, i'll post this updated code as well.

#157 That's pretty cool.

#158 Whoa! Very nice - that has a lot of potential uses!

Very nice to see you pushing the boundaries of this code, thanks for sharing all your hard work.

#159

Quote:I manually positioned them, then did the attachment code.

So... if you were to make throwing knives or something, and you threw them, then would you be able to have knives stick to the place where they hit the player? Or something along those lines?

I highly doubt that's possible, but I'm just trying to figure out what this could be used for.

#160 Yes.

I lost one of the functions i wrote called "GetClosestNode" which would search thru all the nodes of an object, and return the closest one.

But the way torque works, you'd need to add onto the collision scheme to detect a hit on the mesh itself.

It'd require some logics to get this to work the way "it should"

Collision isn't really my field of experience, so maybe someone out there could figure out how.