Button code is still f*cked up...
 

Ok, here's the deal; there are 2 things I noticed:
1) Yesterday I played around with the waypoints in cs_iraq to see if I could fix them up - especially at the doors to the hostage rooms. Now as Pierre-Marie had told, I made the connections through the doors veeeery long (this time far beyond the highest apmd setting, approx. 300-350 units !!) and tried it out, and it didn't work. I tried two different WP layouts, and both failed.
2) On cs_siege2k (nice remake, 100% bot-compatible this time, WP available from me on request :D (but please in a new thread in WP forum, ok?)), I saw bots getting stuck exactly on the threshold of an open door and play that annoying "push the imaginary button" game again - until round end. The problem is that there are no buttons, and the doors open fine. I found out that the connections through these doors also had to be veeeeery long in order to work at all, although there's no button there.

Ok, so it seems that the suggested solution to make very long connections works as long as there are no buttons. Thus, problem 2) is avoidable and doesn't need to be fixed in the code.
If there are buttons, however, it fails miserably (see screenshots in ZIP). The bots try to reach the button on the other side of the wall and get stuck forever. Check the button flags on both screenies - the first shows the way I think this ought to be waypointed, the second one is an experiment, which would actually have worked, hadn't it been for the buggy button code.

If I understood you coders correctly, this is what bots do: If a path through a door is blocked by an entity like func_door or whatever the mapper used, the bot will check for a button nearby and push it before continuing. As soon as the obstacle is removed (i.e. the door is opened), the bots will leave the button alone because no obstacle is detected. If the button needs to be pushed every single time (auto-closing doors like in cs_iraq), a WP with button flag can be inserted near the button, preferably in a way that enforces that bots pass the button prior to attempting to go through the door.
BUT: In the "search for button" routine, do bots check if access to a button is blocked by a solid brush or anything else that blocks their path? Because I think that's the problem... they "see" a button on the other side of a wall and try to push it - which doesn't work in most cases.
Besides, they stray from waypointed navigation when going to buttons - thus, in cs_arabstreets, when I close the door, bots will bump into it, begin to search for a button, turn in the direction of the button and push into thin air, getting stuck forever again. I'd rather have them follow waypoint connections to get near that button. That would force waypointers to set nodes right next to buttons, but it would ensure that bots choose an appropriate approach angle to reach the button instead of walking towards it in a straight line, disregarding all obstacles (like protruding door frames) and getting stuck.

Re: Button code is still f*cked up...
 

I wanted report this problem with buttons, too. Maybe I didn't want so sharp words title...;)
I tryied about 5 times different configurations of WP near this garage's door (cs_arabstreets) to force bots to open it - still without success (but I was thinking I'm too bad waypointer). But if T Wrecks can't do this the same like me - something must be wrong in this button code. I tryied with and without "use_button" flag , I looked to the de_prodigy , but there is different situation - the door is not so big, so button near by doesn't need "use_button" flag. But what about cs_arabstreet - this garage door need or not this flag? How to force bots to open it?
BTW - now You have good ocassion to see if this garage door kills bots , too (during opening, exactly the same like these sliding doors at first floor).;)
Maybe some coder can say us what exactly happen in this situation? Why only bots are killed by opening doors and human-players not? Sorry for off-topic but there was some thread about this at MAPPING forum, but no one coder wanted to say something...:(

Re: Button code is still f*cked up...
 

well the door button code does this...
it checks if the door is being targeted by a button.
if so it'll goto the button and push it then go through the door..
but it also makes sure that the button isn't through a wall..

Re: Button code is still f*cked up...
 

Then how come I saw bots getting stuck and trying to push a button in those double sliding doors in cs_siege2k? Those doors don't have buttons and open fine without.
I got around this problem by placing the WPs in front of the door and behind of it very far from each other - if the code behaved as you say, this shouldn't stop bots from looking for a button! But it does.
Well, look at the screenshots... these bots are DEFINITELY targeting the door button on the other side of the wall, not the one that's on their side. This even happens if the WP with the button flag is WAY nearer to the correct button than to the other one (see first pic).

Re: Button code is still f*cked up...
 

oh you attached screenshots... :|

well I dunno whats wrong then..

Re: Button code is still f*cked up...
 

@sPlOrYgOn - here You have a demo (CS1.5) saved by me in no-clip mode and pwf file - if You want cs_iraq map (2 702 716 bytes created 1999.12.13 23:59), I can send You by e'mail with some needed wads files. When You 'll see this at Your computer, maybe this can help.

Re: Button code is still f*cked up...
 

this might help understand something about it:
some doors are triggered by a trigger_multiple.....meaning you walk through the invisible trigger........and the door opens.......this is done to make the door start opening before you actually touch it.....i have done this is some of my maps.....and since the door has a name...and is targeted.....the bot is stuck on the triggermultiple thinking it has to "use"...when it actually doesnt...

there are many ways to make doors work and not all of them can be flawlessly covered in one bit of button code :)

Re: Button code is still f*cked up...
 

True. However, those doors in cs_iraq don't open before you have reached them. It's the classical case there: Go there, push button, wait a sec, walk through, door closes after a short time. No invisible triggers here (wish there were!) :(

Re: Button code is still f*cked up...
 

what if the button is targeting a multi trigger and the multi trigger is targeting the door..
then the bot would be trying to push the multi trigger

Re: Button code is still f*cked up...
 

yes, this is also done in de_prodigy afaik.

Re: Button code is still f*cked up...
 

Hm... that might be an explanation.

Just for curiosity: What advantage does that offer over a door that's triggered directly? Is it a problem if one and the same door is triggered by more than one button?

Wait a minute - wouldn't a trigger_multiple appear in the entity list of a BSP file? I'm asking because I just scanned cs_iraq.bsp, and there are only func_doors and func_buttons, no trigger_multiple. There IS a trigger_camera, however, and if that is visible, a trigger_multiple ought to be visible, too, or am I wrong?

Re: Button code is still f*cked up...
 

There is a little difference between doors on de_prodigy and cs_iraq (cs_arabstreets) - On de_prodigy the button for opening door is not at the same wall like the door - is at the "normal" (perpendicular) wall. On cs_iraq (cs_arabstreets) the buttons are at the same wall like the door. The button at one side maybe is "visible" by bot from another side of the wall. This can get them to stuck - because they know - "We have to open the door , but we don't see any button. We know - there is a button (at second side of the wall), but we don't see it".

Re: Button code is still f*cked up...
 

hey >BKA< T Wrecks vbmenu_register("postmenu_16760", true); could u have a look at cs_1701e if u can get time...it's got a similar button problem

there's 1 door and A Button either side. (terrorist spawn area) the thing is it's like a 5-10 sec delay b4 door opens or something ....but with bots the either keep pressing the open buttuons or not use it at all

Re: Button code is still f*cked up...
 

I did have a look at the map, and I know which door you mean. Unfortunately, I didn't have your WPs at hand, so I couldn't test this with bots. Gonna do that today.

Re: Button code is still f*cked up...
 

i found the most horrible thing about the map..if u try save the hostage without going through the door's they get stuck in that dark corridor just b4 u go down n up that ramp towards rescue zone :'(

...

i've tried many things to make those buttons work....(the lift has been redon and works well now)

i think the solution: needs to be that the bot's can't press the button again for 2-5 secs will help alot on many maps....but in the end it's just a patch solution ....and not a proper fix (plz include this if possible in next beta :D)

Re: Button code is still f*cked up...
 

Man, I could really cry... I'm waypointing cs_bbicotka right now, and with that button code, it's unplayable. It's too narrow to place waypoints far away from doors, and besides there are 2 lifts that are unusable for bots anyway... but with waypoints having to be near the lifts and doors (narrow corridors), bots always get stuck and play "press the invisible little button that only I can see". Why are they unable to move once they see a button?

From what I've seen, the button code only does the following in many, many cases:
1) Bot stands still like glued to the ground, even in places where there is no button.
2) Bot looks left or right, pushes a button (if there is one, and if there isn't, it pushes thin air), looks forward again... and stops moving altogether.

If they at least pushed a button and then walked back to the WP they came from, but no... :'(

Re: Button code is still f*cked up...
 

damn...being a narrow map u porbably can't do my work around :(

this buttom code really needs to be fixed..............PMB plz help us:'(

Re: Button code is still f*cked up...
 

*BUMP*

I think this topic needs some more attention than it's currently getting, but I also have some new screenies and suggestions.

There are several problems:
1. Bots seem to make this button check all the time - even at doors that are untriggered. This leads to bots getting stuck in such doors.
2. When they have found a button, they mostly freeze instead of walking to it.
3. If they walk towards the button, they take a straight line to it, ignoring all obstacles in their way, disobeying all waypoints in their reach. So they mostly get stuck, too.

And here are some thoughts on how to solve thes problems:
1. Could the button check be limited to triggered doors? Why do waypoints near normal doors cause a button search routine? Why does placing waypoints further away from the door prevent this? The connection A<=>B still leads through a func_door, no matter how big or small the distance.
2. + 3. Couldn't bots detect which WP is nearest to the button (and thus the path to this WP), follow a waypointed path to this point and THEN cover the last remaining distance to the button with unwaypointed navigation (if necessary)?

See these screenies:
(The map is cs_ark, the door is right at CT spawn, and the "buttons" are really just trigger areas - once you step closely up to the button, the trigger gets activated and the door starts opening. No use key required here.)

Re: Button code is still f*cked up...
 

2. When they have found a button, they mostly freeze instead of walking to it.


3. If they walk towards the button, they take a straight line to it, ignoring all obstacles in their way, disobeying all waypoints in their reach. So they mostly get stuck, too.


fixing these 2 will improve the button code alot......

especially following wp's ..they don't seem to do that at all once they got to a button :( therefore making one way pathh from button to door doesn't always work....and in the latest dll it seems only some bots do this others get stuck aka sit at the button.

Re: Button code is still f*cked up...
 

(2) is actually the main problem.
The problem is that POD-bot only knows ONE and ONLY ONE goal, it is the path it's following.
You want to make it able to temporarily disregard this goal (sorta "put it in the background") and find ANOTHER goal (push the button) with ANOTHER path that it must follow, and THEN, switch back to the primary, main goal.
It's quite a big change in the POD-bot code.
Although I agree: this will need to be done, sooner or later.

Once this will be working (running several goals at once, I mean), then the bot will be able to not only open doors, but to do a whole lot of incredible things :)

Re: Button code is still f*cked up...
 

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

Re: Button code is still f*cked up...
 

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

Re: Button code is still f*cked up...
 

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 :P

[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]

Re: Button code is still f*cked up...
 

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

Re: Button code is still f*cked up...
 

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

Re: Button code is still f*cked up...
 

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? ???:(

Re: Button code is still f*cked up...
 

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

Re: Button code is still f*cked up...
 

Well this is what I changed in the navigation..
It now depends more heavily on the waypointer's abilities :D
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]

Re: Button code is still f*cked up...
 

@ 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.

Re: Button code is still f*cked up...
 

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. ;)

Re: Button code is still f*cked up...
 

lol, now people are getting scared when they send me waypoints... :D

Ok, I ought to say that I only fired up cs_ark quickly, and in the very first round, after maybe 15 seconds, the first bot got stuck - exactly the way they used to behave before. I didn't test with other maps so far, but I'll have a look at your demo waypoints as soon as I have Steam installed again.

Good to know that the button code is making better progress than I thought. The fact that they no longer get stuck where no button even exists is already a big step - it made cs_bbicotka playable!

Re: Button code is still f*cked up...
 

No - I didn't say they don't get stuck now at doors or butons. I said only some of them aren't the problem for bots now. They still get stuck but not so often like before. I asked to sPlOrYgOn to trigger the situation when bot get stuck and write all parameters as a chat or console print to understand why this bot got stuck (what condition is missing to pushing - when I go and push this button bot unstuck - so it means need only push button and all will be OK).
;)

Re: Button code is still f*cked up...
 

And I didn't say or think that everything was fixed, *lol*. :P
I just said that cs_bbicotka was impossible to play before and is perfectly enjoyable now.

I had a look at cs_arabstreets... of course, at that garage door, there is no button flag needed. Then again, in order to watch how the bots are doing, you had to add one, or they would have ignored the buttons... 9_9 and now I saw after two seconds what you had told so often before: bots really died in that door. And they still get stuck quite often. But confusingly enough, that door near the hostages has stopped to kill bots apparently. I remember that a bot only had to touch it in order to die - is something wrong with my brain? I mean, something more than I already know? :D

I don't have cs_house and was too lazy to d/l, so no tests here...

But I had a look at cs_iraq, and - 1337-o-matic! - this map works now!!! Bots hardly get stuck, and in most cases, they can free themselves eventually. It's A LOT better than it used to be!

Now for some tests concerning the bots' navigation... :)

Re: Button code is still f*cked up...
 

Another thing is - if You don't put this flag there, they never will try to close this door. But closing this door is nice - then other bot has to open it.
If there isn't this flag bot will try to push this button only when the door is closed.

Finaly You got this garage door as a bot's killer. About this sliding door - I asked sPlOrYgOn to don't touch the door during opening , because this was blocked the door during opening at cs_iraq. I don't know if he did this already or not.

There is some specific situation. Bot sometimes open the door reaching the button from the other door's side. But player can do the same - if You are at the left side of the door and You push "use" the door will open. Normal button You can see at the right door's side, but at the other side there is also the button - and this bot or player can reach throw the wall.

Finaly You are more happy now then before - when You started this thread, I suppose. The progress is visible in this topic, but need more time and tests. When sPlOrYgOn will write to code this part to ask bot what it need (print_console - all parameters needed for button push conditions) then probably problem should be simply to solve.

Re: Button code is still f*cked up...
 

I have changed more of the button code!!
I'd say it's almost 100% working for doors and buttons..
http://www.mapzap.org/files/podbot/podbotBETA.zip

I've found a big problem with prev_wpt_index...
it was only updated when the bot got stuck..
but now It's updated each time the bot gets a new wpt..
this was the cause to a lot of problems.. including bots shooting breakables that aren't there...

and this beta includes the botaim plugin code!
and also includes the getgamedirfix plugin code!
2 of PMB's plugins :D

Re: Button code is still f*cked up...
 

Megawatt: unit for measuring power
Megaw00t: unit for measuring the euphoria whenever sPlOrYgOn releases a new beta...

I'd say 10,000 megaw00t at least!! 99% working button code??! Now that sounds TOO good to be true. I just downloaded it, can't wait to test tomorrow... /drools

AND botaim code included. Man, you rock! :)