Elevators

#1 I would suggest searching the forums before using this approach.

Changing a Z coordinate of a shape doesn't actually highten or lower a shape. It teleports it to it's other location. If you have a player over a platform and it's teleported, the player will just fall.

#2 Well I was talking about incramenting the elevators z position over time not the player itself (The collision between the player and the floor of the elevator will handle that). I already checked with the forums and documentation that is where I saw the path approach.

#3 Moving shapes and similar will not push the player. Just FYI. Collisions are checked from player->objects and not objects->player afaik

Pathed interior resource is what you are looking for

#4 I vaguely remember reading about an approach to this where the area above the elevator was a trigger zone and when the trigger was crossed, the script changed the Z position of *both* the platform and the player (not relying on collision to push the player at all). I think a side effect was that the player seemed to hop a tiny bit each increment, because he was in reality teleporting to just above the elevator platform, then falling a tiny bit. But (assuming latency wouldn't cause problems) you might be able to minimize this effect by tweaking the distances and update periods.

To answer your original question, I don't see why a standard StaticShapeData datablock wouldn't give you all you need. You really only need the basics for this.

#5 A few off-the-cuff thoughts.....

1) if your world isn't too big, you could move the rest of the world down.....

2) close the elevator door, teleport him to a similar cubicle higher up, open the other door after a suitable pause.

3) mount the elevator platform on his feet or vice versa. (may not work, but it might be fun trying!)

4) make the elevator a flying vehicle. (overkill?)

#6 Yes, this is something I have been wrestling with. (I want moving platforms that will push the player around -- Not for lifts and elevators, but obstacles.)

But, as Thomas points out, collisions for these types of objects don't work because the player collision code is only checking for potential sets fo collisions from the player's viewpoint. (ie: If the player isn't moving, he's not marked as a collidable object.)

I've had pathed shapes working, a generic ShapeBase object glued to the PathedCamera code. But it just moves right through the player. It only collides with him if he happens to be moving at the time.

Robert on IRC helped me create a gutted Vehicle that simply acts as a generic collidable object, but unfortunately it's controlled by the Rigid dynamics system. Which means, you can't just setTransform() on it and have it work with the PathedCamera code, all movements have to be relative. Attempting to write a path-following code resulted in something that pretty much mirrors the AIFlyingVehicle resource someone posted on the forums -- it can follow waypoints. It works, and I am current using it for flying ships that are AI-controlled, but it's just not suited for the obstacles I'd like to implement in my game.

(Since it's rigid-controlled, it has to move up to speed, then deaccelerate as it nears the waypoint. This sort of movement is fine for spaceships or aircraft, but for fast-moving platforms it just doesn't work.)

Maybe someone who has a better understanding of the collision system can shed some light on this. I know the Pathed Interior stuff was patched not all that long ago, but I really don't know how it behaves. (ie: Will it push the player around?) I had some problems merging in the patch files and haven't revisited it since.

PS: When I say "player" in my case, I mean vehicle, but it seems it works the same for both actual player objects and vehicles.

#7 I am very surprised that the collision method would not work. How do the bullets collide with your character when you are not moving. Just doesn't make sense to me. I was working with other more simple engines and even they could do simple collision checks for things like elevators. I think it is just crazy to have to mess with something that may not work in the next HEAD like the path tutorial for something as simple as an elevator. That is just my opinion. seems like the more I learn about Torque the more limitations I find that I will need to find some long way around. Oh well I guess I will just have to mess around with it for a while and see what I can come up with.
Thank you for all of your responses.

#8 After thinking about it for a second my next question is: How in the world would you make a movable platform. Is this not supported either. lets say you jump on a platform that will take you accross a deep dark hole of some kind. when you activate the platform and it starts to move would your player just fall right through it. From what I am hearing you will because that would work on the same principle as the elevator.

#9 Matt, the collision method WORKS -- I've traced through some of it. When the player overlaps a moving ShapeBase, the proper bin collision methods are called. It's just not queuing the collision up. I worded my original message wrong.

I'm not sure if this means one needs to modify the player code to make it actively check for collisions even when non-moving, or if there is something much simpler I am overlooking. (And I suspect there is; After all, moving vehicles work just fine with the existing collision code in player.cc)

Pathed Interiors might indeed be the answer; I'm sure if someone were to clean up that code and submit it to HEAD, it'd become a permenant part of Torque.

As for projectiles, they do not use the convex hull checks -- They are ray based. Therefore, that's a whole seperate collision issue.

#10 I would try doing it as a child of Shapebase class, say a Platform class.

- It would have stuff from Player class so that it's movements are interpolated and it would follow a path;
- It would not be affect by gravity;
- It would also have a trigger that added whatever entered it to a list of objects to be updated on it's move. The trigger itself should be in that list so it moved with it.
- It's bounding box should be only relative to the platform. If the platform passes thru a slot in a wall the object over it should not trasverse it.
- It shouldn't have a mount point. a player should be able to walk over it.

I think it's enough to create a Platform develompent group :-)

#11 Thank you david for your response. I was thinking the same thing about the vehicles and was wondering how they move and can still hit you. I also think that bruno's Idea may be something that I may have to look into doing if I can't get it to work the way I want it. I am just happy that you guys respond so fast. TY :-)