Bots get stuck at top of ladder

[sPlOrYgOn]

yea I was going to tell SoUlFaThEr of that ladder problem in de_train...
must have slipped my mind

on a side note...
I have just accidently deleted my most recent version of podbot's source code...

[biohazerd87]

I don't have it you never gave it to me you only gave me the DLL sorry man

[sPlOrYgOn]

lol don't worry..
only a few things got changed and the bug's fix is posted in the forums

[>BKA< T Wrecks]

Originally Posted by biohazerd87

Thanks man. I will try some of the noclip tricks but I found this way works the best. I play that map all the time and never have had a bot fall off that ladder

I believe you. My comment about the noclip trick was not directed at this specific spot or at any particular map. All I wanted to point out is that in some cases the distance between the upper ladder WP and the next normal WP on top can be so small that the "reached" radii of both WPs overlap. As a consequence, a bot going up the ladder might reach the upper ladder WP and at the same time think he had reached the next normal WP already.
Look at the balconies in cs_backalley or cs_hive_apc: If you climb up there, you'll see that the ladder ends almost directly in front of a railing. There's only a tiny space where you can stand. If you place a normal WP there, it will probably be too close to the upper ladder WP. As a result, bots won't be able to keep these two WPs apart. They will climb up the ladder and turn back immediately, thus getting stuck or falling down. In such cases you need a little trick to get a sufficient distance between the waypoints - like placing the first normal WP inside a wall or outside of a railing in noclip mode.

@sPlOrYgOn: Coders should only be given access to keyboards and programs without delete functions...

[KWo]

Originally Posted by biohazerd87

Again you are not discribing to me good enough about what the bits arn't doing correctly. Tell me in 25 words or less what EXACTLY they do when they climb the ladder. I'm not mad or anyhing and the only reason i did the waypoint Manual was so EVERYONE could use it. I wasn't sure about what you ment. I am getting a picture of what BKA was talking about

OK - I see - I still have some communication problem (sorry for my so bad English). Look at my first post and at my attachements. Then You will see what bot is trying to do. It try to go to the next normal wp across the floor (bot is still a little bit too down, so it can't reach the next normal WP, because the edge of the floor is the obstacle for bot). I'm sure - when I'm staying at the top of the ladder and I put the WP ladder in this place - in some previous version it was sufficient for bot to reach correctly the top of ladder and go to the next normal WP. Now this is not sufficient. You have switch on noclip mode , You have place the top ladder WP a little bit under end-top of the ladder and in this case bot reach correctly the top of the ladder and it can go to the next normal WP.
If my description is still not sufficient for You - You can experience this simply at Your computer. I show You how can You see this what I can see at my computer.
1. Take the latest sPlOrYgOn R2.1 complete version (with pwf files from SF).
2. Find in Your WPTDEFAULT directory the files de_train.pwf, de_train.pvi, de_train.pxp and move their to some another directory (for save these files if You want).
3. Open this sPlOrYgOn release and look to the WPTDEFAULT directory in his release and copy the file de_train.pwf (created 26.04.04 by SF) to Your PODBOT\WPTDEFAULT directory.
4. Start the game as a spectator on the map de_train on listenserver.
5. Observe the WP index number 222 what are bots trying to do during climbing.
6. Observe the WP index number 299 what are bots trying to do during climbing.
7. Write here what can You see.

I hope this should be much more understanding for You when You see this at Your computer.

[>BKA< T Wrecks]

Ah, yes. This was a clear description. Dammit, you're right! The same occurs between nodes 112 and 84.
Originally, when bots came up a ladder, they kept moving upwards a bit and kind of "jumped" onto top level. Now, upon reaching the upper ladder WP, they immediately look towards their next WP - in the example I mentioned, de_train 112 => 84, straight to the right and get stuck.
They no longer use the speed they get when climbing up a ladder to "catapult" themselves over the edge. I noticed the same in the WP set for de_rock I'm currently testing. So it wasn't my bad, it's the new dll.

[biohazerd87]

Ok I think I fixed it it worked for me everytime

Lets start from the waypoint 222. First thing to do is delete it. Put a new one in place as high as you can on the ladder like so

After adding the ladder waypoint make a pathwaypoint from point A to point B but make sure it is bidirection so buts can goto it and come from it.

Ok now on to waypoint 299 I think it is. Again delete it and make a new ladder waypoint as high as possible. Like so

BUT YOU HAVE TO DELETE THE PATHWAYPOINT FROM POINT A TO POINT B if you do not do this it is completely usless. Now make sure point B to point C has a bidirectional Pathwaypoint so bots can travel both ways. And if this doesn't help i will send you the fixed copy of the waypoints


THIS IS FOR SOULFATHER
in the picture below i have circled a flag called Crossing. I can't seem to find it in the waypoint editor. What is it and how do i get it?

[>BKA< T Wrecks]

Ok, the ladder problems can be solved by rewaypointing. BUT I don't feel the slightest motivation to fix up all waypoint files AGAIN! Besides, what do you want to do in places where both the ladder and the ceiling aren't high enough for this workaround? Nah, there's something in the code that has changed, and it must be changed back.
It makes no sense to stick to PB 2.5 WP compatibility when at the same time 90% of all waypoint sets with ladders are technically compatible, but totally ruined for gameplay. No way!

The crossing flag cannot be set manually. It's a flag that will be automatically added to all T important, CT important and camp waypoints. These are the points that will be "patrolled" by the bots. When spectating a game, you might witness a bot running into a corner where a camp WP is placed and then running back - they are "patrolling" the camp spot... Since most camp WPs are in some obscure corners, they are not used for normal navigation very often. But the "crossing" flag will attract bots to camp WPs every now an then.

[biohazerd87]

Originally Posted by >BKA< T Wrecks

Ok, the ladder problems can be solved by rewaypointing. BUT I don't feel the slightest motivation to fix up all waypoint files AGAIN! Besides, what do you want to do in places where both the ladder and the ceiling aren't high enough for this workaround? Nah, there's something in the code that has changed, and it must be changed back.
It makes no sense to stick to PB 2.5 WP compatibility when at the same time 90% of all waypoint sets with ladders are technically compatible, but totally ruined for gameplay. No way!

The crossing flag cannot be set manually. It's a flag that will be automatically added to all T important, CT important and camp waypoints. These are the points that will be "patrolled" by the bots. When spectating a game, you might witness a bot running into a corner where a camp WP is placed and then running back - they are "patrolling" the camp spot... Since most camp WPs are in some obscure corners, they are not used for normal navigation very often. But the "crossing" flag will attract bots to camp WPs every now an then.

These waypoints are not for PODbot 2.5 I am doing this in PODBOT 2.6mm R2.1. And the coding is fine it's not hard to fix it took me like 10 seconds don't be lazy lol

[Pierre-Marie Baty]

The FL_CROSSING flag is an old flag that is deprecated since POD-Bot 2.5 ; it was used internally in earlier versions for the bots to know that this waypoint was a choke point between both teams (hence a potentially dangerous waypoint). This flag isn't used anywhere anymore in the POD-Bot code.