Game Development Community

movement code

by David Horn · in Torque X 3D · 05/24/2009 (9:37 pm) · 4 replies

I'm having difficulty moving a player directly. I want to simply move an object based on input, but all of the tutorials are dealing with physics and gravity (a 3rd person shooter person on a terrain). I tried to implement even this without the gravity, but I get horible results. In fact for some reason, it works better when I move the mouse???

What I'd like to do is simply move something around with the controller.
Is there something analogous to the TGE function setMoveDestination?

In TGE, I move an object, say on the X line, by (pseudo code)

if (the player moves the stick to the right){
currentX = playerObjectID.getXValue();
NewX = currentX + 20;
playerObjectID.setMoveDestination(NewX currentY currentZ);
}else{
playerObjectID.stop();
}

Then the player would move based on the property playerObjectID.setMoveSpeed(0.35);

Is there some way I can emulate this in TX3D?

#1
05/29/2009 (3:29 pm)
Sorry to bump, but since this might help others,

I've found that anytime I use the rigid physics, it doesn't work. I set velocity to an object and it barely moves. The only time that the velovity affects the object is if I move the mouse around.

What could be causing this?
#2
06/12/2009 (6:18 am)
David,

First, do you want to use physics to move an object? Typically you do if you are dealing with objects resting on terrain. Or, do you want to arbitrarily update the position of an object (as if it were in space)?

To accomplish the latter, try something like this:

1. Create a new component
2. On register, get a reference to the owner's scene component
3. On register, request tick processing
4. On ProcessTick, check the Move structure
5. If there's an X or Y change, then use it as a multiplier and add it to the scene component's X and Y position.

John K.
www.envygames.com
#3
06/12/2009 (1:36 pm)
I've tried both ways. Both give the same results.

Unfortunately, I've had to move on to 2D. From a documentation/features/tutorials perspective, it just couldn't be helped. I really feel that the 2D is the prize product that was very well though-out and the 3D was half-a$$ed. The fact that the 3D product was shipped with 2D documentation seems to support this.

I have had good luck in the 2D movement by changing the simulatefences setting, so I hope that when I return to 3D (when the above issues are addressed), changing that setting on the 3D side too will produce much better results.
#4
06/13/2009 (12:15 am)
I've found that SimulateFences makes a difference up close, but as an object goes into the distance it gets really jerky.