![]() |
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...
Quote:
this buttom code really needs to be fixed..............PMB plz help us:'( |
Re: Button code is still f*cked up...
3 Attachment(s)
*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 :) |
All times are GMT +2. The time now is 09:07. |
Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.