Possible Bugs or Observed Issues Topic |
Possible Bugs or Observed Issues Topic |
madmax2 |
Nov 30 2018, 08:19 PM
Post
#1
|
RCBot Guru Group: Waypointers Posts: 957 Joined: 2-March 12 From: USA, WA state Member No.: 2,162 |
Possible Bugs or Observed Issues Topic
Thought I should start a topic to report observed issues or bugs, not strictly related to waypointing... This first item has been resolved with some hacky waypointing, but I don't think bots were seeing or able to reach the buttons in the wall. Distance was reported by debug to be 76, perhaps that is to far? I have not tried latest build yet, the wpt is nearly done, but needs a bit of polish though... 11-28 build I finally got something to work on the first closed locked door on murks. I've put hours overall to make it work. It was the same problem with the old rcbots at these doors. So I started out with the wpt config I had with the old bots, noclipped wpt into the button, but that wasn't working. I almost gave up when I just stumbled on a config that works, after moving wpts around and using combinations of normal, important, wait and staynear flags. But just like with the old bots its a forced configuration. I don't think Bots are seeing the func_button in the panel. Before I got this working they would just run up against the door pressing use a few times, then go over to the important wpt, but not press use, then go back to unopened door & repeat. If I added an openslater on other side of door they would go over to the button/panel, but would not press it, with any of a dozen different configurations... Well this is actually working well now, but as you can see the path is through the wall. In fact I used this config at the 2nd problem door and it works there too. I have also been able to remove the important flag & it still works. Config is wait---important or wait---normal, but path must go through wall from the wait wpt. It won't work from the important wpt. Never did try path from wait thru the door? That probably won't work unless it is close to the button? I did a rcbot.search while right up against the panel, and button distance is about 76, perhaps that is the reason? CODE ] as_command rcbot.search [RCBOT]player frame=232.552887 distance = 0 [RCBOT]func_button frame=0 distance = 76.595879 [RCBOT]func_door LOCKED!! [RCBOT]func_door frame=0 distance = 120.178703 [RCBOT]func_door LOCKED!! [RCBOT]func_door frame=0 distance = 134.249481 [RCBOT]func_illusionary frame=0 distance = 168.824387 [RCBOT]multi_manager frame=0 distance = 43.174778 [RCBOT]weapon_crowbar frame=0 distance = 8 [RCBOT]weapon_9mmhandgun frame=0 distance = 8 [RCBOT]weapon_medkit frame=0 distance = 8 So for a test I removed the path thru the wall to make them fail to press the button again. Also placed openslater on other side of door to make them go to the button. Same failure is present without openslater, just easier to find it in in console this way... Ran debug task on a bot, and get this... I think maybe they are not facing correct direction, looks like they attempt once to press it? CODE ] as_command rcbot.debug_bot [m00]wh3y [RCBOT]Finding player [m00]wh3y [RCBOT]UTIL_FindPlayer MadMax2 [RCBOT]UTIL_FindPlayer [m00]wh3y [RCBOT]iBestMatch == 9 [RCBOT]Debug '[m00]wh3y' (if bot) [RCBOT][DEBUG - TASK] COMPLETE [RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete [RCBOT][DEBUG - TASK] CFindPathTask COMPLETE [RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete [RCBOT][DEBUG - TASK] COMPLETE [RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete [RCBOT][DEBUG - TASK] func_button <--- button task [RCBOT][DEBUG - TASK] CFindButtonTask COMPLETE <--- button task complete [RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete [RCBOT][DEBUG - TASK] bot.setMove(m_pCharger.pev.origin) [RCBOT][DEBUG - TASK] bot.setMove(m_pCharger.pev.origin) <--- slew of these in console, removed some [RCBOT][DEBUG - TASK] bot.setMove(m_pCharger.pev.origin) [RCBOT][DEBUG - TASK] bot.setMove(m_pCharger.pev.origin) [RCBOT][DEBUG - TASK] bot.setMove(m_pCharger.pev.origin) [RCBOT][DEBUG - TASK] CUseButtonTask FAILED <--- button task failed [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask FAILED L 28/11/2018 - 12:56:22: "MadMax2<1><STEAM_ID_LAN><players>" stats: frags="0.00" deaths="0" health="100" [RCBOT][DEBUG - TASK] CFindPathTask FAILED L 28/11/2018 - 12:56:24: "[m00]wh3y<3><BOT><players>" stats: frags="0.00" deaths="0" health="100" [RCBOT][DEBUG - TASK] COMPLETE [RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete [RCBOT][DEBUG - TASK] CFindPathTask COMPLETE [RCBOT][DEBUG - TASK] m_pTasks.length() == 0 [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask FAILED [RCBOT][DEBUG - TASK] CFindPathTask COMPLETE [RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete [RCBOT][DEBUG - TASK] COMPLETE [RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete [RCBOT][DEBUG - TASK] func_button <--- button task repeats [RCBOT][DEBUG - TASK] CFindButtonTask COMPLETE [RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete [RCBOT][DEBUG - TASK] bot.setMove(m_pCharger.pev.origin) Other observe issues (have not tried latest build yet, maybe "bots avoid last failed path" fixed #2?) : #1 Saw bot stuck on turret, not sure how it happened & only saw once? Tried placing another wpt nearby, but he wouldn't use it or suicide, seem pretty stuck... #2 This happened after removing a staynear flag from other side of the door. He was constantly pressing use in the corner & wouldn't go to the button. So I put the staynear back on the same wpt, I had to restart the map, but haven't seen it happen again. Both of these may be rare occurance, but I haven't tried many different maps, so not sure? |
madmax2 |
Dec 2 2018, 07:33 PM
Post
#2
|
RCBot Guru Group: Waypointers Posts: 957 Joined: 2-March 12 From: USA, WA state Member No.: 2,162 |
I think I figured out why the vent covers in sc_doc were sometimes present and sometimes not there. I suspect it was due to me using the Massive Explosion cheat in other areas of the map. Using it may break scripts from working correctly. This became apparent while I was working on murks. About halfway into the map there is a glass partition a mini garg must break, it occurs just as a player enters the room, the garg is pre-placed and always there just waiting for the script to run. I was unknowingly killing the gard from using the massive explosion cheat from other areas of map, which means he wasn't there to break the partition.
It seems some maps have "leaks" in them, allowing the explosions to bleed through? Is there a way to adjust the strength of the massive explosion cheat? |
Cheeseh |
Dec 3 2018, 06:51 PM
Post
#3
|
Admin Group: Admin Posts: 3,066 Joined: 11-September 03 From: uk Member No.: 1 |
I've reduced the default explo magnitude to 512
you can now change to magnitude with as_command rcbot.explo <magnitude> Just another waypoint tip: You can put in some waypoints, even crouch ones, behind common cover areas, sandbags for e.g. or wall columns that bots can use to take cover, |
madmax2 |
Dec 4 2018, 01:14 AM
Post
#4
|
RCBot Guru Group: Waypointers Posts: 957 Joined: 2-March 12 From: USA, WA state Member No.: 2,162 |
I've reduced the default explo magnitude to 512 you can now change to magnitude with as_command rcbot.explo <magnitude> Just another waypoint tip: You can put in some waypoints, even crouch ones, behind common cover areas, sandbags for e.g. or wall columns that bots can use to take cover, Cool, thanks... Tested it out on murks & the default magnitude is much better... Fixed some things on desertcircle today, bots can raise all the flags now, if not under attack. QUOTE Just another waypoint tip: You can put in some waypoints, even crouch ones, behind common cover areas, sandbags for e.g. or wall columns that bots can use to take cover, Ok, will try to do that more, been focused on the other issues. Maybe I can add some to desertcircle tonite... btw, notouch doesn't seem to work (restarts the map?)? Maybe you haven't implemented it? |
Cheeseh |
Dec 4 2018, 07:50 AM
Post
#5
|
Admin Group: Admin Posts: 3,066 Joined: 11-September 03 From: uk Member No.: 1 |
Cool, thanks... Tested it out on murks & the default magnitude is much better... Fixed some things on desertcircle today, bots can raise all the flags now, if not under attack. Ok, will try to do that more, been focused on the other issues. Maybe I can add some to desertcircle tonite... btw, notouch doesn't seem to work (restarts the map?)? Maybe you haven't implemented it? No touch doesn't work the way I'd want. It just puts you in observer mode. I guess observer move kills the player so in survival mode it will restart the map. |
madmax2 |
Dec 4 2018, 11:32 PM
Post
#6
|
RCBot Guru Group: Waypointers Posts: 957 Joined: 2-March 12 From: USA, WA state Member No.: 2,162 |
No touch doesn't work the way I'd want. It just puts you in observer mode. I guess observer move kills the player so in survival mode it will restart the map. Ok, not a huge deal, been managing without it so far... Been working on desertcircle today, noticed they were having trouble blowing the 1st tower, more than the 2nd tower, but both needed to be better. At the first one bots were shooting the wall, not the explosives. I fixed the problem with some waypointing voodoo/hackery, important wpt and a Staynear wpt noclipped into a crate with forced path. They still shoot the wall, but now they get close enough swinging their crowbar to blow the tower 100%, when they go to the important wpt. I didn't have an important wpt at the 2nd tower room, because to many important wpts seems to make them bypass the 1st tower room more, just a guess on that? They would blow the 2nd tower, but it might take many passes on thier way to the front door button/lever. They would shoot in there, but not do enough damage I guess, didn't check to see if they were missing the crates though? I added a couple forced loop paths through the crates, and that may be enough, without putting an important wpt in there, seems to work so far... One thing that would of made this easier, would of been the grenade wpt, but it works now... Also spent time on that front door button/lever, they don't press it reliably, It's probably worst than 50% of the time. I changed the paths there so they can come back to it & press it, which I have seen them do a few times (but without enemies in the area). I have a forced path thru the button now, which is something that worked for the old bots, but I don't think it really helps with the AS rcbots, but doesn't seem to hurt either? As long as the wpt in the button is not the important wpt, important wpts seem to work better when they are visible to the bots. I think I noticed bots are less likely to press the button if the 2nd tower is not destroyed first. I saw something like this in the console, a lot of them: [RCBOT]pBreakable.pev.target != '' <--- (from a search, guess I didn't save the debug_bot info, meh) I did run debug search & bot on most of this. I'll probably add the wpt to the pack tonite, after I recheck the flags, they usually won't raise the 1st flag, but can do the other 3 flags, if they get some cover fire/protection from the player... Request: add the wpt ID# to waypoint_info (not a huge issue, could be useful, just something I noticed a while back, just add to your long list... ) |
Cheeseh |
Dec 5 2018, 08:43 AM
Post
#7
|
Admin Group: Admin Posts: 3,066 Joined: 11-September 03 From: uk Member No.: 1 |
I'll probably add wpt ID displaying soon
[RCBOT]pBreakable.pev.target != '' means that they have chosen to make the breakable an enemy because it triggers something -- so they should have been trying to shoot it... The important waypoints (and end waypoints) work like check points. Each time they reach one it is ticked off and they don't go back to it again unless they have no where else to go (i.e. if they have already been to all important waypoints). Important waypoints are also checked off if the bots cannot find a path to them. So there might be an occasion when bots cannot find a path to their next important waypoint and then they complete the first important waypoint, meaning all important waypoints will be checked off and then they might go back to the first one instead of the next one. (confusing) it may be a kind of bug -- still need to think how to treat important waypoints better. I'd like to rename them to 'objective' or 'checkpoint' for that. end waypoints are the same except they are more likely to go to them and don't get ticked off when they reach them (if I remember correctly) |
Lo-Fi Version | Time is now: 9th October 2024 - 06:51 AM |