Adding Z Co-Ord to AIPlayer::getAIMove

#1 The getMoveDestination() returns Z-axis as well.

Do you mean you need your bots to fly ?

#2 I need them to fly without using any power. You know like a ballon.

Kim's programmer, Jim

#3 You are going to have to remove the physics from the Player class to get this to work properly me thinks. Other than that, setMovePosition() should work.

-s

#4 Looked into changing the Physics, and that causes even more problems. My research into the engine has led me to believe that the best place to make the changes I need is in the getAIMove method of AIPlayer.cc. The getAIMove () is called every tick to move all Bots along the path to the destination that was set by various Bot set position/destination/location script calls.

Currently getAIMove() does only a two dimensional calculation for moving, the X & Y axis. I need it to be three-dimensional; therefore I need to add the Z axis to the method. To do this correctly I need to understand how the method does the X & Y axis calculations and then add in the Z axis calculations.

Kim's programmer, Jim.

#5 Jim.

That's not an easy task. It took me over 1 month to figure this out. I had made some advance, my bots are flying, but they aren't still flying the way they should. If you want to help me with this I would be very gratefull too.

Here's what I know :

I would divide this in two categories. Easy Flying and Nice Flying. the first is just getting your bot up and down in the z-axis, the latter is having your bot fly like a plane, with physics applied and the plane will roll left and right while making curves.

For Easy Flying, your goal isn't the getAIMove on AIPlayer, but the onUpdateMove on Player. keep in mind that AIPlayer inherits from Player.
check : swimming resource and Air Control

the swimming resource will help setting a z direction based on the players aiming. The air control wil help controling the player in mid-air.
I made up my easy flight mixing both.

For Nice Flying : This requires your player to be mounted on a vehicle. BUT, and this is the catch. AIPlayers can't drive.
BadGuy have assembled a really nice AISteering but in only works on the 2D plane. I tried to make a 3D control but I gave up on the math.
This is Badguy's thread

Also you could check this

HTH

#6 Thanks for the suggestions Bruno.

I have looked at both swimming & Air control resources. The problem with both is that they modify the acceleration of a player in the Z co-ord. I don't what to do this. All I want to do is tell my Bots to move from Location x,y,z to location z', y', z' and have it do it.

I've also tried setting gravity to zero, no joy there either.

So now I'm looking for the algorithm used in the getAIMove() method.

Kim's programmer, Jim

#7 Jim,

Drop me a mail at grieco@matrix.com.br.

I'll send you back a copy of my playe.cc so you can try it out and tweak it to your use. If you succeed, please send it back to me cause I'm having similar problems.

#8 Maybe better to describe exactly how you want to use this vertical movement.

let me see,

Player uses getContact or something of the like to hold him on the ground.
that and gravity keep him there.
you want him to be able to leave the ground without jet force?

help me to understand why, and how you want to implement.

I dont really understand why you cant make the Air Control logic work for this.

Bruno:
still no luck on the 3d flight?
did I read correct that you gave up?

#9 Hi Badguy,

first findContact checks if the player is on the ground. if so, he implements a 2D move checking the surface normal to calculate the players acceleration. if not he increments the contact timer to calculate the damage on impact.

Air Control actuates as the 2D move while the player is falling. Swimming is the resource that calculates a 3D move based on the head angle and the aim point. If you implement just Air Control, you won't be able to leave the ground.

Yep, I gave up the 3D flight thing. I just can't understand the math behind it.I was hoping you could look at that getSteeringPitch function and go on working on "Nice Flight". Vehicles also calculate their steering only in 2D.

#10 All of you guys need to take a look at the various boids resources, not on GG but elsewhere.
http://www.red3d.com/cwr/boids/applet/
has some links w/ source, and there's also OpenSteer which has complete C++ source, although that is just for 2D I belive.

If you are talking about not adjusting for turning radius, flight physics, accelleration, etc then isnt it just a matter of of doing a VectorSub()? Maybe I'm not understanding the scale of your problems.

anyways, good luck guys!

-s

#11 OK people have you taken a look at getAIMove()? As I said earlier it only does move calcualtions in two dimensions, not three. Stop thinking about "flying" . Assume the Bot is in a zero-G environment so there is no gravity effect and don't worry about drag.

Now here are the questions that need to be answered.
1) What algorithum does getAIMove () use to calcualte the bots new move.
2) How do I add the third dimension cacluations to the method.

I can then use the following scipt to move a bot.

%Bot.setGravity(0);
%Bot.setMoveSpeed(0.5);
%Bot.setAimLocation(%Position);
%Bot.setMoveDestination (%Position);
%Bot.move();

Clear?

Kim's Programmer, Jim

#12 Jim,

As I said before, AIPlayer calls Player to handle it's movement. If you don't change Player.cc ( at least the air control resource ) you won't be able to move at all at 0 gravity.

#13 Indeed Like Bruno has stated.
getAIMove only calculates and prepares the move structure.
which is then used by the Player code.

it is the Player code that will null your z movement.
So..
Basically the place to start is getAIMove and simply add the plane you want doing it just like they do for the x,y

now that you have prepared the move struct.
you can then goto the player.cc file

1.) the player cannot "Pitch" will this need to change?
2.) if findContact is unable to find a contact. the player will fall this will need to be changed.
once that is changed it should work.

i'm sure if im wrong someone will comment.

Edit:
after a quick review..
I see you will be adding the z coord usage from the move struct to the player.cc before it will work.
updateMove(Move*) ignores the move->z value.

#14 Badguy;

Your right of course about the relationship between getAIMove() and updateMove(). Where I'm having my problem is in the following section of code

if (isZero(xDiff))
            movePtr->y = (location.y > mMoveDestination.y)? -1 : 1;
         else
            if (isZero(yDiff))
               movePtr->x = (location.x > mMoveDestination.x)? -1 : 1;
            else
               if (mFabs(xDiff) > mFabs(yDiff)) {
                  F32 value = mFabs(yDiff / xDiff);
                  movePtr->y = (location.y > mMoveDestination.y)? -value : value;
                  movePtr->x = (location.x > mMoveDestination.x)? -1 : 1;
               }
               else {
                  F32 value = mFabs(xDiff / yDiff);
                  movePtr->x = (location.x > mMoveDestination.x)? -value : value;
                  movePtr->y = (location.y > mMoveDestination.y)? -1 : 1;
               }

As you can see the calculations for the X and Y changes are interrelated and I'm still not sure of the reasoning behind the code logic. I could just try things and see what works, but I perfer understand what I doing and why.

Kim's programmer, Jim

#15 Jim,

xDiff and yDiff are the distance between the location and destination.

if you are at the desired x location
    then you only need to move in the y axis, move-Ptr will be assigned to -1 or +1 depending on each side of the x axis you are
else
   if you are at the desired y location
        do the same you made before with the x-axis instead
  else 
       Figure out if you are nearer the x location or the y location
      if( nearer y-location )
          set value to yDiff/xDiff this will yield a value smaller than 1.
         set this value or -value to movePtr-y depending on which side you are
         set movePtr-x to -1 or 1 depending on which side you are
    else
         do the exact opositte of the above

HTH

BTW, are you sure you don't want a complete Player.cc that already handles this ?

#16 Edit:
Oops wrong response.
indeed Bruno is correct.

Edit :
Oops again ..
I should read the code before I try to correct people.

#17 Bruno,

Thanks for the hand.

I'm not sure I don't want to Player.cc, I just want to be sure that getAIPlayer is dealing with all three co-ords.

As you can tell, I'm a newbie with 3D work. Why is getAIMove() just changing one of the co-ords at a time? Wouldn't changing both (if needed) be more efficent?

Kim's programmer, Jim

P.S. I'm not a newbie programmer, I just spent most of my time with networking & communications. ;)

#18 In that codeSnipplet you posted, AiPlayer deals with both x and y coordinates.

It's no use getting AIPlayer to deal with the 3 axis. because when it gets back to Player, it will igonre the Z coord anyway.

The "simple flight" solution is to get this Z coord from the aiming part of the code. and use setAimObject() to set you in it's direction.

P.S.
What happens is not that we are newbies programmers. We know how to use the language but it's not about languages anymore, everything is API driven nowadays. So you must learn how to use the API MORE than how to use the language itself.

#19 Bruno;
I'm not sure I can say this any clearer, the "simple flight' solution doesn't work for my needs. Therefore I need to add in full three dimensional movement controls. I'm taking things one step at a time and changing things from the start of the AIPlayer movement thru to the end of the Player movement.

So onto some questions:
When near the y dest co-ord; why use the ratio of yDiff/xDiff for the y co-ord change and a full one for the x co-ord (the need for a sign change is assumed). I'm sure that the rule I'm looking for is fairly obvious I just can't get my head in the right mode.

Kim's programmer, Jim

#20 Jim,

I can't post the complete "simple flight" solution here cause the onUpdateMove function is too big.

I'm still not sure of what your needs are and why "simple flight" won't do for you. So my suggestion is stil :
Send me an email
I'll reply back with the file.
Compile it and test.
If it still doesn't do than persuade in a more difficult task of tweaking the bots to fly ( it took me over 1 month ).

The division thing you are asking me about was there before me so I just don't know exactly why it does that. But I beleive it's because you should work with normalized vectors ( vectors that have each coordinate maximum as 1 ). And you need to slow down when reaching your destination, otherwise you will behave as a yoyo trying to reach them.