Recast / Detour

[The Storm]

When a human that already had played the map wants to go somewhere, he knows exactly how to go there without the need to always directly see the target path.

I often even walk with aiming at some direction but moving to a completely different one that often is complicated - corners with stairs.

[Neoptolemus]

Sorry, I think I didn't explain my last post properly The bot already can look in any direction and still move towards the waypoint, but it is limited only to the 8 cardinal directions (i.e. forwards, backwards, left, right or diagonally). That means that if the destination point is orientated on a narrow angle, it may end up moving to a position where the intended destination is no longer reachable, like so:



The yellow line is the exact direction the bot needs to move in, and the dotted line is the route the bot will take since in CS 1.6 you can't move in that direction unless you're rotated in the right way.

To combat this problem, the bot can insert a new waypoint next to the intended one which IS still reachable to compensate for this occurrence.

Hope this clears it up!

In other news, I've started working on off-mesh connections, which will allow for ladder movement, running off ledges and jumping. Funnily enough, the ladders will probably be the easier part since it's trivial to retrieve the ladder position and size and place connections at the top and bottom. Jumping and running off ledges is harder as it will require modifying the recast and detour library.

[The Storm]

Okay, now I got your point correctly.

However isn't it possible when the bot wants to move at target waypoint you to do the best path calculations in advance and insert additional waypoits between if needed? This way the bot will not even consider getting close to the wall.

[atomen]

I must say, awesome reading! Really impressive work.
Keep us updated

[Neoptolemus]

Thanks atomen!

I've started implementing ladders. My code now extracts the func_ladder brush and uses it to place waypoints at the top and bottom and hook it up to the navmesh.

In principle this works, the bot tries to climb the ladder, but despite looking upwards at the top and trying to move forwards, the bot just stays frozen at the foot of the ladder.

Am I missing something? I've confirmed that the bot is trying to move forwards, and they're looking upwards, but they just stay stuck on the ladder. My LookAt function looks like this:

void LookAt(bot_t* pBot, Vector target) {
	edict_t *pEdict = pBot->pEdict;

	Vector viewPos = pBot->pEdict->v.origin + pBot->pEdict->v.view_ofs;
	Vector dir = target - viewPos;
	Vector bot_angles = UTIL_VecToAngles(dir) - pEdict->v.punchangle;

	pEdict->v.idealpitch = bot_angles.x;
	pEdict->v.ideal_yaw = bot_angles.y;
	ClampAngle(pEdict->v.idealpitch);
	ClampAngle(pEdict->v.ideal_yaw);

	pEdict->v.v_angle.x = pEdict->v.idealpitch;
	pEdict->v.v_angle.y = pEdict->v.ideal_yaw;


	pEdict->v.angles.x = pEdict->v.v_angle.x * (1.f / 3.f);
	pEdict->v.angles.y = pEdict->v.v_angle.y;
	pEdict->v.angles.z = pEdict->v.v_angle.z = 0;
}

[The Storm]

Could you check when the bot is on the ladder if the movetype is MOVETYPE_FLY?

pEdict->v.movetype == MOVETYPE_FLY

Also I see in EPB that there is special code that handles ladder approaching

    if (paths[pBot->curr_wpt_index]->flags & W_FL_LADDER)
    {
        if (pBot->wpt_origin.z < pEdict->v.origin.z)
        {
            if ((pEdict->v.movetype != MOVETYPE_FLY) &&
                    (pEdict->v.flags & FL_ONGROUND) && !bIsDucking)
            {
                // Slowly approach ladder if going down
                pBot->f_move_speed = wpt_distance;
                if (pBot->f_move_speed < 150.0)
                    pBot->f_move_speed = 150.0;
                else if (pBot->f_move_speed > pEdict->v.maxspeed)
                    pBot->f_move_speed = pEdict->v.maxspeed;
            }
        }
    }

[Neoptolemus]

Yeah I took a look at that bit of code. From what I can see though it simply checks if the bot is about to go down a ladder and slows down to ensure it doesn't go flying off the edge.

I added a bit of code which draws the direction in which the bot wants to move if the movetype == MOVETYPE_FLY. This is the result:





The red line is the bot's path, the yellow line is the direction the bot wants to move. The bot is looking at the top of the ladder (which is invisible, but it definitely works as I can climb it fine) and is trying to move forward (as shown by the yellow line). I have commented out all of the movement code so that all the bot is trying to do is move towards the next point in the path (so no trying to check if the point is reachable, no pushing away from walls etc.)

There must be something missing because the bot is frozen at the foot of the ladder, no movement at all. It's as if the moment the movetype becomes MOVETYPE_FLY, the bot is completely unable to move. It can't even move sideways.

[The Storm]

Ok, just for the test could you set the 5th argument of the RunPlayerMove function - "upmove" to the max moving speed as soon as the bot movetype become MOVETYPE_FLY? Lets see what happens then.

Also it almost seems like there could be something wrong again with the msecval. Could you try one of the alternative methods that I had described earlier?

And lastly it may sounds a bit rubbish but are you sure that you are still calling RunPlayerMove when the bot hit the ladder?

[Immortal_BLG]

I think this is because RunPlayerMove receives view angles instead of move angles, which should be oriented same as red line (upwards)...

To traverse ladder:
1) pEdict->v.movetype == MOVETYPE_FLY
2) bot move angles which receives to RunPlayerMove should direct at top of ladder
3) bot forwardSpeed != 0.0
So from this point I think that you have missed something from this...

Sorry for bad english...

[The Storm]

@Immortal_BLG Yep you are totally correct, how I overlooked that...