Button code is still f*cked up...

[sPlOrYgOn]

I'll try to do it but I don't have much time these days...

[sPlOrYgOn]

better button code has been implemented!
try it.. they get stuck a lot less!
http://www.mapzap.org/files/podbot/podbotBETA.zip

[>BKA< T Wrecks]

Wow, cool! Thank you, man! Gonna d/l and try it right away... impressions and test results later!

/rushes off to the other computer to fire up CS

[Edit]
Hmm... bad news. On my 1.5 installation, I get a crash in podbot_mm.dll as soon as I fill the server with bots (using the bot menu). Some bots connect, "Game commencing!" appears, and... CRASH. Tried 2 times, crashed 2 times.
[/Edit]

[Edit2]
Tried to test with 1.6, but impossible... Steam keeps crashing. > Yup, just tested a third time - it directly reboots my PC. Gotta reinstall Steam, I guess.
[/Edit2]

[sPlOrYgOn]

sorry..
heres the info.. http://forums.bots-united.com/showth...9706#post19706
and the new dll
http://www.mapzap.org/files/podbot/podbotBETA.zip

[>BKA< T Wrecks]

OK, no problem. I don't have much time this weekend, but I hope I'll be able to test this new dll.

[>BKA< T Wrecks]

OK, I've finally had some time to test the dll. Thanks for pointing me at the other thread, the new dll worked fine in terms of stability.
Here's what I observed:
1) cs_ark: Walk-up-to buttons; bots still get stuck like before. They still ignore brushes blocking their path to the button, and once they are stuck, they only move the upper half of their body, helplessly turning left and right. So unfortunately, no improvement in this respect.
2) cs_bbicotka: Lots of doors without buttons in narrow corridors; bots used to get stuck at or in doors, trying to push a button that wasn't there. This problem seems to be totally fixed! I didn't see one bot that got stuck in a normal door. Good work!

However, I observed something else. What did you to to their navigation? In cs_bbicotka, there are two loooooong staircases (8 or 9 storeys!). With earlier dlls, bots made their way up and down pretty easily, although there are -quite logically- 2 sharp 180° turns for each storey. With the new dll, bots got carried out of the curve and bumped into walls all the time. They also had terrible problems to get through narrow doorways. It was really horrible to look at; all those bots running into walls, jumping around, running into the next wall... what happened? ???

[KWo]

Write in console:
meta list
and tell us what the version of podbot_mm.dll are You using?

[sPlOrYgOn]

Well this is what I changed in the navigation..
It now depends more heavily on the waypointer's abilities
or.. should I say the waypointer's knowledge of the waypoint's radius
Heres what's new... It used to be that the bot thought it had reached a waypoint when it was within 50 units of the waypoint's origin (this only pertains to normal unflagged waypoints).
But now the bot thinks he has reached a waypoint when he is within the waypoint's radius...
I think this makes the bot act more normal in wide open areas...
[edit]
I'm thinking of changing this back to how it used to be..
[/edit]

[>BKA< T Wrecks]

@ KWo: The version with button probs, but good navigation was the dll from June, 26. The one with less button probs, but changed navigation is from July, 8. (I'm too lazy to go to the other PC to get the exact version numbers right now).

@ sPlOrYgOn: In theory, this is fine. However, bots cannot brake down from high speed to zero and perform 90° turns. They move a bit like cars; if their speed exceeds a certain limit, they won't be able to follow sharp curves the way they ought to. Especially when running downstairs, bots will gather very much speed - too much to perform a 180° turn without problems, unless it's properly waypointed (short distances, small radii). From my waypointing experience, I can anticipate where a bot will have problems following waypoints and place nodes and connections acordingly. The staircase in question worked perfectly; I tried it with the old dll, and the bots didn't even touch the walls in the staircase and hardly had problems in the other narrow areas of the map! With the new dll, they had loads of problems even though all connection went right through the middle of doorways etc, in a 90° angle, and with all radii set to zero! According to what you said, lowering the radius to zero should make my bots stick exactly to the waypoints, but they don't do that. There must be something else that causes problems. Maybe their turnspeeds are somehow limited while navigating? Or does their speed make them react too late when realizing that they just reached a node?
Anyway, whatever you change: Please bear in mind that changing the bots' navigation could render ALL waypoint files out there pretty much useless, as waypoints would have to be adapted to the new way those bots navigate!
If you can change this radius thingy (which I don't regard as an inherently bad idea at all!) without making all good and thoroughly made waypoint files look like shit, then I will be the last one to protest. The way it is now, however, doesn't convince me at all.

Besides, I think that a rather natural-looking navigation through open areas can be reached (at least to a fair degree) by placing a dense and well thought-through pattern of waypoints... you see, the bots' navigation has always depended on the waypointer's abilities.

[KWo]

About this button.
I'm tring since few weeks all betas from sPlOrYgOn and every beta I can see some progress. Yes - bots get stuck still too often, but many doors and buttons isn't for them the problem. Need only make some tests to ask bots why they get stuck (print parameters to the console) and all should be clear. Here You have same pwf's - You can try and look at these maps I tested. For de_rats for now I don't have a soloution. These pwf are not for "art" but only to show the examples of using buttons and how bots are tring to open some doors or push light-switches. So please don't comment if there are some "art" waypointing mistakes.