Printable Version of Topic

Click here to view this topic in its original format

RCBot Forums _ Svencoop 5 Angelscript _ Possible Bugs or Observed Issues Topic

Posted by: madmax2 Nov 30 2018, 08:19 PM

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.
http://img4.imagetitan.com/img.php?image=18_murks_button_config.jpg

http://img4.imagetitan.com/img.php?image=18_murks_button_paths.jpg

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...
http://img4.imagetitan.com/img.php?image=18_sc_doc_stuck_turret.jpg

#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.
http://img4.imagetitan.com/img.php?image=18_sc_doc_door_corner.jpg

Both of these may be rare occurance, but I haven't tried many different maps, so not sure?

Posted by: madmax2 Dec 2 2018, 07:33 PM

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?


Posted by: Cheeseh Dec 3 2018, 06:51 PM

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,

Posted by: madmax2 Dec 4 2018, 01:14 AM

QUOTE(Cheeseh @ Dec 3 2018, 10:51 AM) *

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... smile.gif
Fixed some things on desertcircle today, bots can raise all the flags now, if not under attack. rolleyes.gif

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?

Posted by: Cheeseh Dec 4 2018, 07:50 AM

QUOTE(madmax2 @ Dec 4 2018, 01:14 AM) *

Cool, thanks... Tested it out on murks & the default magnitude is much better... smile.gif
Fixed some things on desertcircle today, bots can raise all the flags now, if not under attack. rolleyes.gif
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.

Posted by: madmax2 Dec 4 2018, 11:32 PM

QUOTE(Cheeseh @ Dec 3 2018, 11:50 PM) *

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... smile.gif

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... rolleyes.gif

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... wink.gif)

Posted by: Cheeseh Dec 5 2018, 08:43 AM

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) blink.gif 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)


Posted by: madmax2 Dec 5 2018, 10:18 AM

Past 2am here, I'll try to give more feedback tomorrow... Been thinking about wpt types and was going to ask for some some kind of sequential or priority objective wpt, but maybe there is a better way? Would it be possible for bots to know when a task has been completed for important wpts? So it would not take an important wpt off the list until the task is completed?

Attached a WIP desertcircle wpt in case you want to see what bots are doing while I sleep.... rolleyes.gif


Attached File(s)
Attached File  desertcircle_wip_rcwa.zip ( 8.87k ) Number of downloads: 3376

Posted by: Cheeseh Dec 5 2018, 02:44 PM

QUOTE(madmax2 @ Dec 5 2018, 10:18 AM) *

Past 2am here, I'll try to give more feedback tomorrow... Been thinking about wpt types and was going to ask for some some kind of sequential or priority objective wpt, but maybe there is a better way? Would it be possible for bots to know when a task has been completed for important wpts? So it would not take an important wpt off the list until the task is completed?

Attached a WIP desertcircle wpt in case you want to see what bots are doing while I sleep.... rolleyes.gif


Heh I know what u mean. Problem is there is no exact way to tell if an objective has been reached unless some sort of script file is also created with each waypoint/map . And in angel script you can't capture network messages ! Until then.... Night

Posted by: madmax2 Dec 5 2018, 09:48 PM

QUOTE(Cheeseh @ Dec 5 2018, 06:44 AM) *

Heh I know what u mean. Problem is there is no exact way to tell if an objective has been reached unless some sort of script file is also created with each waypoint/map . And in angel script you can't capture network messages ! Until then.... Night

Would it be possible to do something like a trigger wpt that would be connected to the important/objective wpt. Waypointer would place the trigger wpt inside the entity that the button/switch/wheel controls. That way rcbot would know which entity goes with each objective wpt. Then that objective can be removed once triggered. So in this map I would put the trigger wpt in the top of the flag poles, connect it to the objective wpt below it. Or put it in the front door & connect it to the switch wpt. There still would be a use for important wpts that don't need a trigger wpt, like the ammo boxes in this map they won't use without them, some stuborn door buttons, etc.

Would that get around the angelscript network message problem?

This may or may not be useful. Did Debug search on a flag pole & the front door.
CODE
desertcircle 1st Flag Pole - flag at bottom

Bottom of Flag Pole
] as_command rcbot.search
[RCBOT]player frame=42.006104 distance = 0
[RCBOT]momentary_rot_button frame=0 distance = 37.896404
[RCBOT]env_sprite frame=2.423069 distance = 26.324957
[RCBOT]trigger_setorigin frame=0 distance = 116.597122
[RCBOT]ambient_generic frame=0 distance = 99.641068
[RCBOT]env_sprite frame=2.423069 distance = 26.324957
[RCBOT]trigger_multiple frame=0 distance = 25.856707

Top of Flag Pole
] as_command rcbot.search
[RCBOT]player frame=232.499756 distance = 0
[RCBOT]momentary_rot_button frame=0 distance = 168.601257
[RCBOT]ambient_generic frame=0 distance = 33.352058
[RCBOT]multi_manager frame=0 distance = 52.80862
[RCBOT]trigger_changetarget frame=0 distance = 39.93364
[RCBOT]trigger_setorigin frame=0 distance = 80.901672
[RCBOT]ambient_generic frame=0 distance = 101.622055
[RCBOT]trigger_changetarget frame=0 distance = 33.912003

desertcircle 1st Flag Pole - flag at TOP

Bottom of Flag Pole
] as_command rcbot.search
[RCBOT]player frame=16.337158 distance = 0
[RCBOT]momentary_rot_button frame=0 distance = 35.643337
[RCBOT]env_sprite frame=3.759975 distance = 183.830551
[RCBOT]trigger_setorigin frame=0 distance = 117.557297
[RCBOT]ambient_generic frame=0 distance = 99.987526
[RCBOT]env_sprite frame=3.759975 distance = 183.830551
[RCBOT]trigger_multiple frame=0 distance = 22.459909

Top of Flag Pole
] as_command rcbot.search
[RCBOT]player frame=100.664307 distance = 0
[RCBOT]momentary_rot_button frame=0 distance = 170.345108
[RCBOT]ambient_generic frame=0 distance = 35.126118
[RCBOT]multi_manager frame=0 distance = 55.081905
[RCBOT]trigger_changetarget frame=0 distance = 42.264057
[RCBOT]env_sprite frame=15.301189 distance = 25.443098
[RCBOT]trigger_setorigin frame=0 distance = 83.473213
[RCBOT]ambient_generic frame=0 distance = 103.341576
[RCBOT]env_sprite frame=15.301189 distance = 25.443098
[RCBOT]trigger_changetarget frame=0 distance = 34.661766

---------------------------------------
Before opening front door

front door switch
] as_command rcbot.search
[RCBOT]player frame=243.323486 distance = 0
[RCBOT]func_rot_button frame=0 distance = 30.561392
[RCBOT]multi_manager frame=0 distance = 40.015934
[RCBOT]trigger_changevalue frame=0 distance = 51.466194
[RCBOT]func_wall frame=0 distance = 32.353458


Inside front door
] as_command rcbot.search
[RCBOT]player frame=93.622314 distance = 0
[RCBOT]func_door_rotating frame=0 distance = 33.731117
[RCBOT]func_door_rotating frame=0 distance = 46.112

After opening front door

front door switch
] as_command rcbot.search
[RCBOT]player frame=193.327393 distance = 0
[RCBOT]func_rot_button frame=1 distance = 22.984444
[RCBOT]multi_manager frame=0 distance = 34.347763
[RCBOT]trigger_changevalue frame=0 distance = 43.834015
[RCBOT]func_wall frame=0 distance = 26.900099


Inside front door
] as_command rcbot.search
[RCBOT]player frame=86.020752 distance = 0
[RCBOT]func_door_rotating frame=0 distance = 86.291016
[RCBOT]func_door_rotating frame=0 distance = 90.63765

The only thing I see for the flag pole would be there is no sprite there until the flag is raised
CODE
[RCBOT]env_sprite frame=15.301189 distance = 25.443098

And for the front door I can't see a change? It must be in [RCBOT]func_door_rotating somehow, probably would need to look at it with an entity editor?

The problem with this map, if bots skip a flag and if they get to the next flag, they won't be able to raise it, and the spawn area doesn't advance. No matter what is done, that first flag will always be a problem due to the enemies spawning in line of site of the flag...

I think desertcircle could be a one of a kind map? It's wide open and no way to block them from going to the next flag. With most older maps areas are blocked off by openslater & it works just fine. For newer maps i'm not sure? Probably I should check some newer maps to see what they might need?

Posted by: Cheeseh Dec 5 2018, 10:43 PM

As I thought some kind of script might be needed for each important waypoint. It could look something like this...

CODE

56 env_sprite distance>100
89 func_button frame=0


I.e. important waypoint id 56 will only be ticked off if the nearest env_sprite is more than 100 units away. And 86 will be ticked off if the nearest button frame is 0. What do you think?

Can you think of any more examples for such a script?

Posted by: madmax2 Dec 6 2018, 04:32 AM

Oh good, wpt ID's smile.gif

That looks like it would work for the flags, but I don't really know anything about scripting. I could look for areas that might need scripts like this as I work on waypoints. Are you thinking you would need to code this into bot as needed, or thinking of adding a script system for users? I'm not sure how frequently this sort of thing is needed?

I did check button distance on several maps, most are under 30, some between 30 & 40, a few over 40, tetris maps have some non critical buttons at 50 (camera buttons).

Posted by: Cheeseh Dec 6 2018, 05:02 AM

QUOTE(madmax2 @ Dec 6 2018, 04:32 AM) *

Oh good, wpt ID's smile.gif

That looks like it would work for the flags, but I don't really know anything about scripting. I could look for areas that might need scripts like this as I work on waypoints. Are you thinking you would need to code this into bot as needed, or thinking of adding a script system for users? I'm not sure how frequently this sort of thing is needed?

I did check button distance on several maps, most are under 30, some between 30 & 40, a few over 40, tetris maps have some non critical buttons at 50 (camera buttons).


I think only needed on some major. It can be optional

Other things to add to accept would be

48 env_sprite null

For no sprites meaning complete

Or

54 after=2

I.e. this one must be done after 2 is complete


Still to think of a better format

Think it will work


Posted by: Cheeseh Dec 6 2018, 06:34 PM

Hey madmax, I implemented script code and added a script for desertcricle but it is still incomplete, maybe you can complete it -- mainly because I am unfamiliar with the map. ( Check the GIT for latest )

Scritps will be stored in /scr/ folder as ini files ( <mapname>.ini )

They are like CSV files, the format is the following

(# are comments)

CODE

#WID, prev, entity search, parameter, operator, value
51,    -1,    env_sprite,  distance,        >,  150
100,    51,   env_sprite,  distance,        >,  180


WID is waypoint ID
prev is previous important waypoint that needs to be complete
entity_search is the name of the nearest entity to check (.e.g env_sprite)
parameter is one of the following (more may be added)operator is the operator to apply on parameter and value
possible parameters arevalue is the value to check the parameter against using the operator

In the desertcircle example

CODE

51,    -1,    env_sprite,  distance,        >,  150


waypoint 51 must be an "important" waypoint. and no previous waypoint is required, i.e. -1 (anything less than zero will also be acceptable). It will search the nearest env_sprite and if the distance is greater than 150 units, then the important waypoint will be considered "COMPLETE"

If the parameter is "null" then it will check to make sure that an env_sprite doesn't exist within 512 units
CODE

51,    -1,    env_sprite,  null,        null,  null


The second important waypoint I added was this one

CODE

100,    51,   env_sprite,  distance,        >,  180


meaning important waypoint ID 100 can only be done once waypoint ID 51 is complete

run in developer mode 1 and add one bot to see some debug "SCRIPT" output.

can you try to comeplete the desertcircle one ? then we can think about other maps and any other "parameters" we might need.

If a script doesn't eists then the bots will just do what they did previously

Posted by: madmax2 Dec 6 2018, 06:58 PM

Nice smile.gif , I'll give it a try today... Have some distractions going on this morning ...

Posted by: Cheeseh Dec 6 2018, 07:12 PM

QUOTE(madmax2 @ Dec 6 2018, 06:58 PM) *

Nice smile.gif , I'll give it a try today... Have some distractions going on this morning ...


Cool, I also ajust added an hplanet script (need to use the hplanet waypoints in the rcw/ folder tho, not store) . they need help with the first gate at the water but after that they should follow every objective in order. I just made an update as I just found a bug in the script stuff, so download again maybe...

btw you can also do this now

as_command rcbot.search <distance>

e.g.


as_command rcbot.search 512


will show all entities nearby in 512 units which is what the script will use

also I'm going to change it to use entity index instead of just classname, as they appear to be the same each time and then we can focus on a particular entity that doesn't need to be so nearby

Edit:
So it now uses entity index instead of classname so we can choose a particular entity


desert circle I made is like this so far

CODE

#WID, prev, entity search, parameter, operator, value
51,    -1,    54,  distance,        >,  150
100,    51,   60,  distance,        >,  180
190,   100,   71,  distance,        >,  179


search will now output the ID

CODE


] as_command rcbot.search 100
[RCBOT]2 : player frame=66.735565 distance = 0.000001
[RCBOT]63 : weapon_handgrenade frame=0 distance = 8
[RCBOT]77 : weapon_357 frame=0 distance = 8
[RCBOT]186 : func_pushable frame=0 distance = 95.700264
[RCBOT]187 : func_pushable frame=0 distance = 91.161781
[RCBOT]196 : multi_manager frame=0 distance = 94.747131
[RCBOT]199 : scripted_sequence frame=0 distance = 38.285847
[RCBOT]205 : func_button frame=0 distance = 28.884043
[RCBOT]280 : weapon_9mmhandgun frame=0 distance = 8
[RCBOT]281 : weapon_crowbar frame=0 distance = 8
[RCBOT]282 : weapon_medkit frame=0 distance = 8




now hplanet script looks like

CODE

#WID, prev, entity search, parameter, operator, value
71,    -1,    204, distance,        >,  280
91,    -1,    205, frame,        =,  1
129,    71,   238,  frame,        =,  1
164,   129,  336,  frame,        =,  1
176,   164,   325, null, null, null
180,   176,   391, frame, =, 1
196,   180,   400, frame, =, 1
193,   196,   423, distance, >, 180


I also added a teleport_wpt <wpt id> command

Posted by: madmax2 Dec 6 2018, 08:37 PM

Ok I have the new one smile.gif . Will have to study this some, as scripts are not my strong point blink.gif .

Posted by: Cheeseh Dec 6 2018, 11:00 PM

QUOTE(madmax2 @ Dec 6 2018, 08:37 PM) *

Ok I have the new one smile.gif . Will have to study this some, as scripts are not my strong point blink.gif .

great. Also added another argument to the teleport_wpt command

teleport_wpt important

will teleport you to a random 'important' waypoint

Posted by: madmax2 Dec 7 2018, 01:14 AM

QUOTE(Cheeseh @ Dec 6 2018, 03:00 PM) *

great. Also added another argument to the teleport_wpt command

teleport_wpt important

will teleport you to a random 'important' waypoint

Nice, smile.gif

Finally got to this, here is what I did so far...

CODE
#WID, prev, entity search, parameter, operator, value
51,    -1,    54,  distance,        >,  150
#100,    51,   60,  distance,        >,  180
99,    51,    60,  distance,        >,  200
190,   99,   71,  distance,        >,  179
307,   190,   114, distance,        >,  180

I added the last flag and changed the 2nd flag, but not tested yet. Wanted to ask a couple questions before it got to late for you (well perhaps it's to late now rolleyes.gif )...

I changed the 2nd flag because my important wpt is the wpt just before the wpt at the bottom of the flag. I've been using wait & staynear flags in combination with importants at some buttons and wheels, it seemed to help them see the buttons/wheels. Is this unnessesary now, or just do what works best?

Also, does the important need to be right on the button/wheel/flag? My guess is it doesn't need to be and what I did at the 2nd flag should work?

CODE
important(99) --- staynear,wait(bottom of flag pole)(100)

At the explosives I have this before it blows, its removed after it blows:

CODE
[RCBOT]97 : func_breakable frame=0 distance = 57.762028

So can I do this?

CODE
219,   190,   97,  null,  null,  null

Insert that between 3rd & 4th flags and modify last flag prev to 219

Then at the front door switch I have this...

CODE
[RCBOT]104 : func_rot_button frame=0 distance = 16.802603

So I would do this (important is currently on the wpt before the switch wpt & i'm skipping the 2nd explosive area for now):

CODE
335,   219,   104, frame,  =,  1

And again change last flag prev to 335

So, I will end up with this:

CODE
#WID, prev, entity search, parameter, operator, value
51,    -1,    54,  distance,        >,  150
#100,    51,   60,  distance,        >,  180
99,    51,    60,  distance,        >,  200
190,   99,   71,  distance,        >,  179
219,   190,   97,  null,  null,  null
335,   219,   104, frame,  =,  1
307,   335,   114, distance,        >,  180

Wanted to ask is spacing not important, on these comma seperated ini's?

Posted by: Cheeseh Dec 7 2018, 07:07 AM

Looking good. Yes spaces are not important

Also you might have noticed I added x , y and z as possible parameters. The search will show this now too. I think is is better tham distance for some thinga sucg as the flags and doors etc.

Yes if the entity dissapears use null,null,null should work

Let me know how they do on the map now

The important waypoint needs to be within about 100 units of the button near the flag so bots know which button to press.

Posted by: madmax2 Dec 7 2018, 07:59 AM

Well I went to test my script and somethings not working right? I cleaned it up it now looks like this:

CODE
#WID, prev, entity search, parameter, operator, value
51,     -1,    54,  distance,        >,  150
99,     51,    60,  distance,        >,  200
190,    99,    71,  distance,        >,  179
219,   190,    97,      null,     null,  null
335,   219,   104,     frame,        =,  1
307,   335,   114,  distance,        >,  180

Bots seem to be freezing up when my script is enabled in the spawn room (i'm adding them manually, not from quota)...

developer 1 shows this as soon as bot is added.

CODE
Created bot [m00]3gg
[RCBOT]CheckScriptOperator 14.408648>150
[RCBOT]CheckScriptOperator result is FALSE
[RCBOT]SCRIPT Waypoint 51 BotWaypointScriptResult_Incomplete
[RCBOT]CheckScriptOperator 14.408648>150
[RCBOT]CheckScriptOperator result is FALSE
[RCBOT]SCRIPT isObjectiveComplete(script.previous_id) != BotWaypointScriptResult_Complete
[RCBOT]SCRIPT Waypoint 99 BotWaypointScriptResult_Previous_Incomplete
[RCBOT]SCRIPT no script found for wpt id 102
[RCBOT]SCRIPT Waypoint 102 BotWaypointScriptResult_Error
[RCBOT]SCRIPT no script found for wpt id 104
[RCBOT]SCRIPT Waypoint 104 BotWaypointScriptResult_Error
[RCBOT]CheckScriptOperator 14.408648>150
[RCBOT]CheckScriptOperator result is FALSE
[RCBOT]SCRIPT isObjectiveComplete(script.previous_id) != BotWaypointScriptResult_Complete
[RCBOT]SCRIPT isObjectiveComplete(script.previous_id) != BotWaypointScriptResult_Complete
[RCBOT]SCRIPT Waypoint 190 BotWaypointScriptResult_Previous_Incomplete
[RCBOT]CheckScriptOperator 14.408648>150
[RCBOT]CheckScriptOperator result is FALSE
[RCBOT]SCRIPT isObjectiveComplete(script.previous_id) != BotWaypointScriptResult_Complete
[RCBOT]SCRIPT isObjectiveComplete(script.previous_id) != BotWaypointScriptResult_Complete
[RCBOT]SCRIPT isObjectiveComplete(script.previous_id) != BotWaypointScriptResult_Complete
[RCBOT]SCRIPT Waypoint 219 BotWaypointScriptResult_Previous_Incomplete
[RCBOT]CheckScriptOperator 14.408648>150

So I thought perhaps this was pointing to the first wpt in the script?

CODE
[RCBOT]CheckScriptOperator 14.408648>150
[RCBOT]CheckScriptOperator result is FALSE
[RCBOT]SCRIPT Waypoint 51 BotWaypointScriptResult_Incomplete

So I rechecked the first flag with search...

CODE
[RCBOT]54 : env_sprite frame=5.738934 distance = 14.485841    <--- flag is down

[RCBOT]54 : env_sprite frame=4.834347 distance = 183.264664   <--- flag is up

Does that mean I need to increase the distance value closer to say 180 ? But the more I think about it, that appears to be working correctly?

The other thing I noticed that may or may not be related is these errors, it doesn't look right to me unsure.gif :

CODE
[RCBOT]SCRIPT no script found for wpt id 102
[RCBOT]SCRIPT Waypoint 102 BotWaypointScriptResult_Error
[RCBOT]SCRIPT no script found for wpt id 104
[RCBOT]SCRIPT Waypoint 104 BotWaypointScriptResult_Error

So I tried to teleport to wpts 102 & 104, and it just sends me to the wrong wpt a couple wpts away. Teleport_wpt works correctly if I go to known good wpts. Those wpts don't appear to exist!

QUOTE
The important waypoint needs to be within about 100 units of the button near the flag so bots know which button to press.

I believe all are within 100, but I'll double check that...

Request: With old rcbot, I think we could put godmode & notarget on the bots. That would speed up testing objectives greatly... smile.gif

Suggestion: Make scripts readable from the store folder like rcwa, for now i'm making extra copies in the scr folder To protect my modifed ini's. Along the same idea, I believe other AS plugins can use the store folder? You might want have rcbot subfolders in store, to keep modified/saved rcbot files (rcwa & ini) separate?



Posted by: Cheeseh Dec 7 2018, 08:28 AM

QUOTE

developer 1 shows this as soon as bot is added.

CODE

Created bot [m00]3gg
[RCBOT]CheckScriptOperator 14.408648>150
[RCBOT]CheckScriptOperator result is FALSE
[RCBOT]SCRIPT Waypoint 51 BotWaypointScriptResult_Incomplete




This looks Okay, its just saying that 14 > 150 is FALSE (distance from flag is not > 150) so the waypoint 51 is an incomplete objective (as flag is still at bottom), and bots should try to go to that one. > 180 might be more correct. But if it works fine, no need to change. Also you could try using "z" instead of distance to make things maybe easier.

QUOTE


The other thing I noticed that may or may not be related is these errors, it doesn't look right to me unsure.gif :

CODE

[RCBOT]SCRIPT no script found for wpt id 102
[RCBOT]SCRIPT Waypoint 102 BotWaypointScriptResult_Error
[RCBOT]SCRIPT no script found for wpt id 104
[RCBOT]SCRIPT Waypoint 104 BotWaypointScriptResult_Error




These are "important" waypoints that haven't been put into the script. Check when teleporting again, does it take you to an important waypoint. If it does, remove the waypoint type "important" or add a line to the script. Either way the "BotWaypointScriptResult_Error" is just saying "bots will ignore this waypoint".

QUOTE


Request: With old rcbot, I think we could put godmode & notarget on the bots. That would speed up testing objectives greatly... smile.gif



Yeah I think that'd be good. Maybe a bot_dont_shoot too so bots don't get hung up trying to attack enemies

QUOTE

Suggestion: Make scripts readable from the store folder like rcwa, for now i'm making extra copies in the scr folder To protect my modifed ini's. Along the same idea, I believe other AS plugins can use the store folder? You might want have rcbot subfolders in store, to keep modified/saved rcbot files (rcwa & ini) separate?


yeah that's what I've also been thinking.... I will move these around tonight

Posted by: madmax2 Dec 7 2018, 10:51 AM

I partly figured out what is causing the problem. I know why I could not teleport to wpts 102 & 104. They were objective wpts that I added for the old rcbots, so they would exit the spawn room. They are just past the weapons in the spawn room exits which I guess are warpzones. teleporting didn't take me anywhere near the spawn exits. The other reason there are wpts in those exits is the spawn room is not part of the main area, so if I connect a path from one side of the exit to the other side, the path goes sideways into the wall...

The thing I can't explain is this "fix" for the old bots was working for rcbot-AS until I enable the script. Then they either won't leave the spawn room or are very very slow to do so. If I teleport the bots out of the spawn room with the script running, they take off running. If I disable the script, bots will leave the spawn room as I have it waypointed. If I remove the important flags from the 2 waypoints in the warpzones by noclipping underneath, then bots again won't leave the spawn room! This was the same symptom I had with the old rcbots.

For some reason the scripts break my wpt fix here? Maybe I can tweak it, try to get them to jump into the exits some how. Could be a problem without notouch... I'll try tommorrow, unless you can figure out something from the script or code end??? Oh just noticed the time, zzzzzzzzz..... blink.gif

Posted by: Cheeseh Dec 7 2018, 11:03 AM

did you connect a path from the spawn room "warpzone" waypoint to the destination. Is it a teleport waypoint? You can try removing the teleport flag if it doesn't help. Use notouch and increase mp_respawnwavetime (i think) to go into observer mode long enough to change the waypoint in the warpzone

Posted by: madmax2 Dec 7 2018, 05:29 PM

QUOTE(Cheeseh @ Dec 7 2018, 03:03 AM) *

did you connect a path from the spawn room "warpzone" waypoint to the destination. Is it a teleport waypoint? You can try removing the teleport flag if it doesn't help. Use notouch and increase mp_respawnwavetime (i think) to go into observer mode long enough to change the waypoint in the warpzone

Just got up blink.gif . I'll have to check the path, it is possible it's not connected all the way thru. If the path to the destination was causing them to miss the exits some, I probably didn't connect it? It's not a teleport wpt, I could try that too? While I was sleeping last night tongue.gif , I thought perhaps they needed to be added to the script somehow, with equal importance? I'll try your suggestions first... Have food shopping to do first though... wink.gif

Posted by: Cheeseh Dec 7 2018, 07:09 PM

I've changed the code so it looks in the rcw folder for the scripts or store folder (checks store folder first)

I updated desertcircle.ini

looks like you wrote 99 instead of 100 (at least that's the waypoint ID on my desertcircle rcw) The wpt id must be the 'important' waypoint id. I put the rcw in git too with the ini. I've also changed the distances to use 'z'.

CODE

#WID, prev, entity search, parameter, operator, value
51,     -1,    54,  z,        >,  314
100,     51,    60,  z,        >,  1000
190,    99,    71, z,        >, 558
219,   190,    97,      null,     null,  null
335,   219,   104,     frame,        =,  1
307,   335,   114,  z,        >,  1109


The waypoints at warp zones are now not important waypoints and have paths to the exits, bots go through them when they spawn. The problem was that because the important waypoints were not in the script and they did not have paths to the exit, they were ignored, and bots couldn't find paths to the other waypoints. so best keeping paths to waypoints via teleports. Also if the teleport is a shortcut you should make it a 'teleport' waypoint. If it isn't a shortcut, no need.

Posted by: madmax2 Dec 7 2018, 10:29 PM

Yeah, my important wpt is at 99, it's not the wpt at the bottom of the flag pole, its the one just before. Been busy with a couple things today, so just getting back to this... When I saw those important wpts in the warpzones, I thought that might be a problem, but sounds like I didn't have the paths connected all the way through, as well. So when removing the important flags, of course they would just want to camp out in the spawn room. That all make sense now rolleyes.gif .

I will check out what you did and merge in any changes to the wpt that are needed...

QUOTE
I've also changed the distances to use 'z'.


Is z better for some reason, and will distance or z work now?

Posted by: madmax2 Dec 8 2018, 08:13 AM

After that spawn room issue, I finally got to see them working with a script... smile.gif

Been doing some more testing & tweeking the desertcircle wpt & script. I have them working good at most the flags. And they do work at the switch, but that may need a bit more tweeking? The big problem is at the 1st tower explosives.

This only works for one cycle:

CODE
219,   190,    97,      null,     null,  null


But i'm not sure if it is causing a problem, except it looks like it breaks the script? I do know they pressed the switch after this, but they went past it a few times before doing so, as if there was no script? I need to test that again... I don't think it should do this?

CODE
[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 219 COMPLETE (NOT AVAILABLE)   <--- this, 1st tower explosives, null
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 AVAILABLE  <--- switch
[m00]wh3y blew up.
L 07/12/2018 - 22:55:44: "[m00]c0w<3><BOT><players>" stats: frags="94.44" deaths="12" health="0"
[m00]c0w was killed by a Soldier.
[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 219 AVAILABLE                 <--- then this
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 INCOMPLETE (NOT AVAILABLE)    <--- switch I'm certain the switch was not pressed at this time, because I saw it pressed later
[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 219 AVAILABLE
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 INCOMPLETE (NOT AVAILABLE)


Also, I think bots might be ignoring some unscripted important wpts when using a script. I removed 219 from the script, and I never saw them go to it after that, and they didn't blow the first tower. I should retest that to be sure that they just are not missing the explosives with their crowbar? They would blow this tower well without a script and my most recent wpt.

Note: wpt 99 works way better for bots raising the 2nd flag...

Thanks for adding this script system, I can see now it will help a great deal... Bots are much better focused on the flags in this map now... smile.gif

Posted by: Cheeseh Dec 8 2018, 09:26 AM

bots do ignore unscripted waypoints, if you want bots to always go there just put -1 as the entity index - (but bots will always try to go back even if they cant)


Any way I found an issue, turned out bots preferred to move towards trigger_once's before using momentary buttons, so I've changed the order. I might add this to script.

I hopefully fixed the explosive issue as the entities are now remembered at initialization only, and checked against their current status.

I've added ability to put godmode, notarget on bots now.

Also in the spawn room it might be a good idea to put some more waypoints in so bots can choose either sniper or solder more often based on where they spawn, at the moment theres only one waypoint in the middle of the room and bots spawning near the sniper zone are running towards the soldier one.





Posted by: Cheeseh Dec 8 2018, 03:14 PM

just edited the sc_doc waypoint and added a script for that, you can check it out. (should have really added comments to script)

Posted by: madmax2 Dec 8 2018, 05:29 PM

Great stuff smile.gif ... I just grabbed the new one... Will try to get desertcircle update released today, hopefully... I'll try to get the script working on the explosives...

Did you use my updated sc_doc rcwa from my pack? It was much better than the previous ones...

Posted by: Cheeseh Dec 8 2018, 05:32 PM

QUOTE(madmax2 @ Dec 8 2018, 05:29 PM) *

Great stuff smile.gif ... I just grabbed the new one... Will try to get desertcircle update released today, hopefully... I'll try to get the script working on the explosives...

Did you use my updated sc_doc rcwa from my pack? It was much better than the previous ones...


Hey madmax. Yeah i think it was the latest one . Althoguh i remobed the important waypoints in the wall now as they seem to be doing ok without them with the script.... The momentary door with the wedge is still a bit troublesome though

Posted by: madmax2 Dec 8 2018, 05:40 PM

Ok, I'll look at that too. So with the momentary buttons fix, wpts don't need to be noclipped into the buttons. Yeah, those were done for the old bots when they couldn't see the buttons. I probably should just remove wpts like that?

QUOTE
Also in the spawn room it might be a good idea to put some more waypoints in so bots can choose either sniper or solder more often based on where they spawn, at the moment theres only one waypoint in the middle of the room and bots spawning near the sniper zone are running towards the soldier one.

Yep, saw that too, done...

QUOTE
I've added ability to put godmode, notarget on bots now.

Thanks smile.gif

Nice, thanks Poka...
|
|
|
\/

Posted by: Poka Dec 8 2018, 05:42 PM

I made waypoints for the sc_tropical map series. The bots can finish all the maps without problems by themselves. It works fine on Windows listenserver but on my Linux dedicated server the script isn't updating. unsure.gif

Listenserver

CODE

"We have found the Blue key ! We can open all Blue doors !"
[RCBOT]SCRIPT Waypoint 6 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 22 AVAILABLE
[RCBOT]SCRIPT Waypoint 65 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 74 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 81 ERROR (NOT IN SCRIPT)
[RCBOT]SCRIPT Waypoint 102 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 112 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 123 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 131 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 133 INCOMPLETE (NOT AVAILABLE)


Dedicated server
CODE

"We have found the Blue key ! We can open all Blue doors !"
[RCBOT]SCRIPT Waypoint 6 AVAILABLE
[RCBOT]SCRIPT Waypoint 22 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 65 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 74 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 81 ERROR (NOT IN SCRIPT)
[RCBOT]SCRIPT Waypoint 102 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 112 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 123 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 131 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 133 INCOMPLETE (NOT AVAILABLE)



Attached File(s)
Attached File  sc_tropical.zip ( 5.67k ) Number of downloads: 2026

Posted by: Cheeseh Dec 8 2018, 06:30 PM

Could be the entity index isn't the same. Will need to see how the striper plugin worked for hl and do the same thing. Could be will need to bring back in classname instead of index and some other stuff

Posted by: madmax2 Dec 8 2018, 09:24 PM

Bad news, explosives/breakables still seem to be a problem. Initially I thought it was working good, it went for several cycles ok, they even did the switch afterwards, but then the breakable became available again. Then I noticed later it again showed COMPLETE (NOT AVAILABLE)! It seems to go back and forth now, and that makes the switch part do the same, but I think its the breakable causing it? It may have to do with bots dieing & respawning, but it didn't seem to track with that, seems more random?

1st tower changed to wpt 452, they crowbar the explosives better, 1st bot does it now

CODE

[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT ENTITY 97 NOT FOUND
[RCBOT]SCRIPT Waypoint 307 AVAILABLE
[RCBOT]SCRIPT ENTITY 97 NOT FOUND
[RCBOT]SCRIPT Waypoint 335 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT ENTITY 97 NOT FOUND
[RCBOT]SCRIPT Waypoint 452 COMPLETE (NOT AVAILABLE)
[m00]wh3y was killed by a Soldier.
L 08/12/2018 - 11:35:56: "MadMax2<5><STEAM_ID_LAN><players>" stats: frags="29.00" deaths="1" health="100"
[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 452 AVAILABLE
[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 452 AVAILABLE

Posted by: Cheeseh Dec 8 2018, 09:57 PM

did you update to the latest source ? I noticed a bug where the entity would only update once the first bot is added, also it uses "EHandle" now so once the breakable disappears it should stay that way in the code (I would think anyway....) entity indexes get re-used which is why it might flicker in and out. But using the "Ehandle" method it shouldn't do it, so no idea why. Also if you use as_reloadplugins during play it might break the script

edit:

crap noticed the bug -- it was continuously updating the entity when it shouldn't... updated the git

@Poka, are you able to run as_command rcbot.search whilst connected as client on your dedicated server to see what the differences in entity index are?

If there is no pattern I guess for now you'll need to make separate inis for dedicated / listen server

Posted by: Poka Dec 8 2018, 10:25 PM

QUOTE(Cheeseh @ Dec 8 2018, 11:57 PM) *

@Poka, are you able to run as_command rcbot.search whilst connected as client on your dedicated server to see what the differences in entity index are?


On listenserver for example the first func_button is
CODE

[RCBOT]371 : func_button frame=0 distance = 41.510525 (x=-752,y=-1552,z=-380)


and on dedicated 371 is
CODE

[RCBOT]371 : func_wall frame=0 distance = 1589.815918 (x=-1815,y=-2241,z=-298)


So yeah thats the problem

Posted by: Cheeseh Dec 8 2018, 10:28 PM

QUOTE(Poka @ Dec 8 2018, 10:25 PM) *

On listenserver for example the first func_button is
CODE

[RCBOT]371 : func_button frame=0 distance = 41.510525 (x=-752,y=-1552,z=-380)


and on dedicated 371 is
CODE

[RCBOT]371 : func_wall frame=0 distance = 1589.815918 (x=-1815,y=-2241,z=-298)


So yeah thats the problem


are you able to find the entity index of the button ? ....and some others to see if there is any pattern? Also what kind of dedicated server is it? windows or Linux?

Posted by: Poka Dec 8 2018, 10:57 PM

QUOTE(Cheeseh @ Dec 9 2018, 12:28 AM) *

are you able to find the entity index of the button ? ....and some others to see if there is any pattern? Also what kind of dedicated server is it? windows or Linux?


CODE

371 -> [RCBOT]375 : func_button frame=0 distance = 1800.630371 (x=-752,y=-1552,z=-380)
374 -> [RCBOT]378 : func_button frame=0 distance = 807.25647 (x=-1688,y=-3360,z=-380)
376 -> [RCBOT]380 : func_button frame=0 distance = 2159.506592 (x=-1880,y=-1448,z=-588)


Yeah theres definitely a pattern smile.gif The first values are from listenserver on Windows and the latter from dedicated server on linux.

The first value the search was able to find on the dedicated server was

CODE

[RCBOT]5 : player frame=3.457172 distance = 0 (x=-881.473328,y=-3347.683838,z=-347.96875)


so it skips the first 4 ones for some reason


Actually now that I think about it, my dedicated server has always 4 bots running so are they counted towards the index too?


Tried adding one more bot (5 total plus me) and now I also got all the player entities correctly
CODE

[RCBOT]1 : player frame=156.495102 distance = 1151.827637 (x=-1170.932861,y=-2341.823242,z=-347.96875)
[RCBOT]2 : player frame=24.04043 distance = 1121.362793 (x=-581.648376,y=-2306.43335,z=-347.96875)
[RCBOT]3 : player frame=28.526785 distance = 1730.447754 (x=-1469.914429,y=-1840.262695,z=-347.96875)
[RCBOT]4 : player frame=145.006577 distance = 1294.488281 (x=-1468.301636,y=-2336.510742,z=-347.997498)
[RCBOT]5 : player frame=255.729248 distance = 0 (x=-752.03125,y=-3414.776367,z=-347.96875)
[RCBOT]6 : player frame=123.813286 distance = 1115.819824 (x=-893.496643,y=-2307.960449,z=-347.96875)


and the button is still

CODE

[RCBOT]375 : func_button frame=0 distance = 1863.051758 (x=-752,y=-1552,z=-380)


so that wasnt the problem

Posted by: Poka Dec 8 2018, 11:22 PM

Nvm

Posted by: madmax2 Dec 9 2018, 12:16 AM

QUOTE(Cheeseh @ Dec 8 2018, 01:57 PM) *

did you update to the latest source ? I noticed a bug where the entity would only update once the first bot is added, also it uses "EHandle" now so once the breakable disappears it should stay that way in the code (I would think anyway....) entity indexes get re-used which is why it might flicker in and out. But using the "Ehandle" method it shouldn't do it, so no idea why. Also if you use as_reloadplugins during play it might break the script

edit:

crap noticed the bug -- it was continuously updating the entity when it shouldn't... updated the git

Oh no, Crap again ohmy.gif Tried dec 9 build c5625fca742c0f5596297bab412b8a97263addc3

Had bot notargeted at 1st flag and the important wpt was not getting checked off the list...

Then I noticed bots are not respawning after they die!!! ohmy.gif

Which build are you using Poka? Have you tried newest?

Posted by: Poka Dec 9 2018, 12:21 AM

QUOTE(madmax2 @ Dec 9 2018, 02:16 AM) *

Oh no, Crap again ohmy.gif Tried dec 9 build c5625fca742c0f5596297bab412b8a97263addc3

Had bot notargeted at 1st flag and the important wpt was not getting checked off the list...

Then I noticed bots are not respawning after they die!!! ohmy.gif

Which build are you using Poka? Have you tried newest?


Yeah Im using the latest one. The bots either suicide or get killed and never spawn again sad.gif

IPB Image

Posted by: madmax2 Dec 9 2018, 12:26 AM

Yeah sad.gif ... Cheeseh's probably gone to bed too... Might have to revert back to previous version if I want to do any more tonite...

[edit]I guess we can forgive him lol ... We are on like the 28th build!!! been keeping track...

Posted by: Poka Dec 9 2018, 12:33 AM

QUOTE(madmax2 @ Dec 9 2018, 02:26 AM) *

Yeah sad.gif ... Cheeseh's probably gone to bed too... Might have to revert back to previous version if I want to do any more tonite...


For me the problem seems to have started at 9a3326686c24a642f26097e4f3ac704ae71fba93
The bots just keep suiciding but they can still spawn laugh.gif


Posted by: madmax2 Dec 9 2018, 12:43 AM

QUOTE(Poka @ Dec 8 2018, 04:33 PM) *

For me the problem seems to have started at 9a3326686c24a642f26097e4f3ac704ae71fba93
The bots just keep suiciding but they can still spawn laugh.gif

Thats about 2 builds back, wierd. I haven't had spawning problem until now. I did notice them running past important wpts that were not checked off the list, but I think that was a few builds back???

Posted by: Cheeseh Dec 9 2018, 10:38 AM

QUOTE(madmax2 @ Dec 9 2018, 12:43 AM) *

Thats about 2 builds back, wierd. I haven't had spawning problem until now. I did notice them running past important wpts that were not checked off the list, but I think that was a few builds back???


wtf -- I thought they were only supposed to do this in survival mode --- oh well, reverted it for now until the bug is fixed....

https://github.com/rcbotCheeseh/RCBotSven5/commit/3e697a45fe8fb6429e446e53ab9023142bdb2134

bots will still suicide if there is nothing to do, e.g. they are not near any waypoints so that they should respawn (in case they got stuck in a chasm or something)

Posted by: Poka Dec 9 2018, 02:34 PM

Listenserver seems to be working again. The bots work on non-scripted maps on linux dedicated server too but on the scripted ones they're confused and keep suiciding due to the different indexes.

Has anyone tried running on windows dedicated server?

Posted by: Cheeseh Dec 9 2018, 04:06 PM

QUOTE(Poka @ Dec 9 2018, 02:34 PM) *

Listenserver seems to be working again. The bots work on non-scripted maps on linux dedicated server too but on the scripted ones they're confused and keep suiciding due to the different indexes.

Has anyone tried running on windows dedicated server?


try the latest version and put

script_entity_offset 4

into the bot config.ini as a new line for dedicated server , see if it works , i can't test. this will add 4 to all offsets when loaded (it can also be negative to subtract)

Posted by: Poka Dec 9 2018, 04:26 PM

QUOTE(Cheeseh @ Dec 9 2018, 06:06 PM) *

try the latest version and put

script_entity_offset 4

into the bot config.ini as a new line for dedicated server , see if it works , i can't test. this will add 4 to all offsets when loaded (it can also be negative to subtract)


Yeah that did the trick smile.gif

Posted by: Poka Dec 9 2018, 05:07 PM

I also noticed that the 'end' flag is somehow broken while waypointing for the sc_tropical maps. If you add it then the bots will very frequently commit suicide. I tried also with the map intruder and as soon as I removed the 'end' flagged waypoint they stopped suiciding and continued to play normally.

Posted by: Cheeseh Dec 9 2018, 08:57 PM


see if the latest commit helps,

Posted by: Poka Dec 9 2018, 09:40 PM

QUOTE(Cheeseh @ Dec 9 2018, 10:57 PM) *

see if the latest commit helps,


Thank you, everything seems to be working now smile.gif

Posted by: Cheeseh Dec 9 2018, 10:52 PM

QUOTE(Poka @ Dec 9 2018, 09:40 PM) *

Thank you, everything seems to be working now smile.gif

noticed entities wouldn't update on mine for sc_tropical_final2. I edited to code so that the waypoints are loaded at a later time after entities are loaded so now it should catch them

Posted by: madmax2 Dec 10 2018, 12:51 AM

It appears all of this has been fixed with the latest build. It's looking good so far smile.gif
Build c00084726725531ece3dd4ccaa4349adf89ceaac

I set the 1st flag z setting back to 314, because I saw a bot not raise it all the way. It seems good now with this new build smile.gif

I was also having trouble with flag sprites getting stuck, causing bots not to know the objective was complete. I thought this was a wpt issue, but explosions or the explo cheat may be causing it. I've gone through it at least twice now, w/o using the explo cheat, and no stuck flags...

[edit 12-12-18] Build e5412e95d015794e02f9da45c6c49b991053fe3b - I have seen the 3rd & 4th flags get stuck w/o using the explo cheat, so it doesn't seem to be that. Those 2 flags still had staynear givetypes right on the flag poles. I now suspect it has to do with bots getting to close to the flag poles. So I have removed all staynear givetypes on flag poles. Hopefully I won't have to move the wpts?

Now I can try to finish this... Awesome work Cheeseh biggrin.gif

QUOTE
OLD Info
QUOTE(Cheeseh @ Dec 9 2018, 02:52 PM) *

noticed entities wouldn't update on mine for sc_tropical_final2. I edited to code so that the waypoints are loaded at a later time after entities are loaded so now it should catch them

Looks like I was testing with previous commit 76effe132c5e94c12043fa276ec2e2f937e5a999

I'll post this and go re-test, see if this is still happening. It seemed kinda random?

But with the prior build, a notargeted bot went thru all the scripted wpts this time... smile.gif

CODE
L 09/12/2018 - 15:07:55: "[m00]y0ghur7<8><BOT><players>" stats: frags="20.83" deaths="0" health="17"
[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 307 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 452 COMPLETE (NOT AVAILABLE)
OK, Let's go!


But next time bots didn't check off the 1st flag after raising it. This is with notarget on the bot. I also restarted the map, not the game. I think I saw it happen after restarting the game too, but need to double check for that. I also lowered the z to 300, it still happens. z to the flag when up is 316. The other flags work well at your settings, just a couple units lower. So it doesn't seem like it would be the z setting? unsure.gif

Also, If the script works correctly at the 1st flag, it appears to work correctly for all scripted wpts. But twice now, if I restart just the map, it may fail at the explosives like this:

CODE
[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 AVAILABLE
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 452 INCOMPLETE (NOT AVAILABLE)
OK, Let's go!
OK, Let's go!
[m00]ch33s3 was killed by a Castle Tower.
[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 AVAILABLE                   <--- skipped to here
[RCBOT]SCRIPT Waypoint 452 COMPLETE (NOT AVAILABLE)    <--- completed without blowing the tower
[RCBOT]SCRIPT Waypoint 51 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 99 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 COMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 AVAILABLE
[RCBOT]SCRIPT Waypoint 452 COMPLETE (NOT AVAILABLE)
OK, Let's go!


Seem like restarting the map should be enough to reset everything???
OLD Info

Posted by: Cheeseh Dec 12 2018, 07:42 PM

Great, BTW Poka you're right about maxplayers changing the entity index. For this reason all entity indexes must be taken when maxplayers is 8 . The offset for this will be automatically added.

Posted by: Poka Jan 2 2019, 02:57 PM

I was thinking of making some waypoints for the Half-Life campaign and faced a problem. As soon as the big door opens at the start of hl_c01_a1, all the waypoints turn invisible blink.gif

Posted by: Cheeseh Jan 3 2019, 11:48 PM

QUOTE(Poka @ Jan 2 2019, 02:57 PM) *

I was thinking of making some waypoints for the Half-Life campaign and faced a problem. As soon as the big door opens at the start of hl_c01_a1, all the waypoints turn invisible blink.gif


may have something to do with the map having lots of beams -- and the limit is reached once the door opens (for some reason).... might have to do it blindly for now sad.gif

Posted by: Cheeseh Jan 4 2019, 09:40 AM

QUOTE(Cheeseh @ Jan 3 2019, 11:48 PM) *

may have something to do with the map having lots of beams -- and the limit is reached once the door opens (for some reason).... might have to do it blindly for now sad.gif


Thanks to w00tguy , I've added his code to remove any beams when waypoints are on.... so you should be able to see the waypoints now with the latest code...

Posted by: madmax2 Jan 9 2019, 05:38 AM

I think a bug has popped up in the script system sad.gif . I went to test some changes I made to the desertcircle.rcwa, ammo box wpts, etc... I spotted these errors:

[RCBOT]SCRIPT Waypoint 452 ERROR (NOT IN SCRIPT)
[RCBOT]SCRIPT Waypoint 455 ERROR (NOT IN SCRIPT)

Both of those are for the breakable explosives under the towers. I thought perhaps I screwed something up editing the wpt, but the wpt & script looked good!!!

So I went back to testing the wpt/script that is currently in the uploaded pack, yep the errors are there. Well I know this was working so I tested out the build from about the time I edited it (12-12-18), no script errors...

Anyways, what I found is the last build I have that has no errors is:

desertcircle - script works on 12-28-18 build: 9f4cbd34ddd83f3304342be66c48de5a88134203

CODE
[RCBOT]SCRIPT Waypoint 51 AVAILABLE
[RCBOT]SCRIPT Waypoint 99 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 452 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 455 INCOMPLETE (NOT AVAILABLE)

With the same rcwa & script, script began failing on 1-3-19 build: 377d980aca4ff55de80d38da70986bbf10d31a4c

CODE
[RCBOT]SCRIPT Waypoint 51 AVAILABLE
[RCBOT]SCRIPT Waypoint 99 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 190 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 307 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 335 INCOMPLETE (NOT AVAILABLE)
[RCBOT]SCRIPT Waypoint 452 ERROR (NOT IN SCRIPT)
[RCBOT]SCRIPT Waypoint 455 ERROR (NOT IN SCRIPT)


My current script:

CODE
#WID, prev, entity search, parameter, operator, value
51,     -1,    54,   z,     >,  312
99,     51,    60,   z,     >,  1000
190,    99,    71,   z,     >,  555
452,   190,    97,   null, null, null
455,   452,   103,   null, null, null
335,   455,   104,   frame, =,  1
307,   335,   114,   z,     >,  1107


NOTE: my current waypoint & script (in my pack) are different than the git. I suspect the git one is failing too... Both tower explosives are now in my script, wpts 452 & 455. Both of these wpts are clipped into explosive crates so bots will crowbar them reliably. Just to be sure it had nothing to do with that, I made a test wpt/script and moved the important wpts out of the explosive boxes, there was no change, the errors persisted, so it is not that...

I've checked all builds since the 1-3-19, including 1-8-19, they all fail the breakable check. I don't know if there were any builds between 12-28-18 and 1-3-19, that don't have? 12-28-18 is the last build I know works without errors... So something in the breakable check broke after that build...


Posted by: Cheeseh Jan 9 2019, 07:39 PM

Hi madmax -- I fixed it now, it was introduced when I added the new 'not equals' operator, it now accepts 'null' again

Posted by: madmax2 Jan 9 2019, 11:37 PM

QUOTE(Cheeseh @ Jan 9 2019, 11:39 AM) *

Hi madmax -- I fixed it now, it was introduced when I added the new 'not equals' operator, it now accepts 'null' again

Cool, Thanks... smile.gif Now I can finish my desertcircle update... smile.gif

Posted by: madmax2 Jan 13 2019, 12:22 AM

It appears only 2 of the 5 ammo/health resupply crates on desertcircle are func_door, so they just stand by the last 3 dry.gif . Could you have them use func_rot_button as well as func_button & func_door to use the crates?

CODE
3rd & 4th & 5th crates don't have func_door, only func_rot_button

] as_command rcbot.search
[RCBOT]1 : player frame=73.050896 distance = 0 (x=-3395.754639,y=54.838615,z=466.006927) visible=1,solid=3,angle.x = -8.254395, angle.y = -175.57251 active = 1
[RCBOT]67 : weapon_uzi frame=0 distance = 8 (x=-3395.754639,y=54.838615,z=474.006927) visible=0,solid=0,angle.x = -8.254395, angle.y = -175.57251 active = 1
[RCBOT]162 : func_rot_button frame=0 distance = 83.948189 (x=-3477,y=48,z=486) visible=1,solid=0,angle.x = 0, angle.y = 0 active = 1
[RCBOT]295 : trigger_multiple frame=0 distance = 79.089066 (x=-3472,y=44,z=448) visible=0,solid=1,angle.x = 0, angle.y = 0 active =


Thanks in advance... wink.gif

Saw the first flag get stuck again, so I moved the flag important wpt away from the pole, I think that will fix it?

Hopefully will have all the sticking flags fixed soon, seems to be a matter of positioning the important wpt. 1st & 2nd & 4th flags should be good now... Still testing 3rd flag...

Posted by: Cheeseh Jan 13 2019, 02:56 PM

I always use the z option rather than distance. So you shouldn't need to move the waypoint if you use that. I also noticed the flags got sick before which is why i added the 'active'option to script with the hope of using it but couldn't find anything useful unless you can... Tried to decompile the map to get some idea but no brushes would load so just got lost.

Posted by: madmax2 Jan 13 2019, 06:18 PM

I've been using z for a while now. What happened this last time was the sprite got stuck about 1/4 way up the pole, usually it is stuck near the bottom half. The action was completed and the next flag was enabled, so just the sprite stopped moving. It would seem to be a map bug, but I haven't confirmed this happens with players. Removing staynears on some flags has helped, on others moving the flag pole wpt has helped, or like in the case of the 2nd flag I moved the important flag to the wpt just before the normal wpt on the flag. Not having the important wpt right against the flag pole seems to be the most reliable solution.

Anyway, it has been getting much better, it's just so random. The only flags I'm not 100% sure of are the last 2, but I think they are OK now. The last flag still has an important wpt right on the pole, but I haven't seen that flag get stuck since removing the staynear on it and adding a wait flag to the normal wpt just before the important, a long time & many game tests.

I was experimenting last night with adding a few more scripted wpts, non-entity (-1) wpts for navigation/goto points after the main objectives are done. After putting the ammo/health wpts back in, they mainly want to circle the outer areas and not use the middle or reverse path to the front door. It seems to be working, as they now use those paths smile.gif . I don't have ammo/health on the first crate so bots will multi-path and use the both trench's there at the start of the map, so that contributes to them circling the outer area. I do want them to do that some, just not all the time.

Posted by: madmax2 Jan 19 2019, 09:51 PM

Cheeseh,

Do you know of any things that might break the scripts? When I was working on desertcircle, the script broke again (about 2 builds ago), the explosives/breakables re-enabled after all goals were done. I didn't notice it right away, so it kinda screwed my test session. The only thing I can think of, was I think I did a waypoint_load a some point. I had changed a couple wpt flags then did the load later. I didn't touch the important wpts that session, I would assume that could cause a script failure?

Last night, sc_doc script failed once, to detect the first door had been opened (#198). I was doing a lot of disconnects & restarting the map and it did that. Disconnected again, restarted and it was ok after that, so just a minor hiccup I guess. More concerned about things I might do that could cause a script failure while tweaking the wpt ?

Posted by: Cheeseh Jan 20 2019, 11:12 AM

QUOTE(madmax2 @ Jan 19 2019, 09:51 PM) *

Cheeseh,

Do you know of any things that might break the scripts? When I was working on desertcircle, the script broke again (about 2 builds ago), the explosives/breakables re-enabled after all goals were done. I didn't notice it right away, so it kinda screwed my test session. The only thing I can think of, was I think I did a waypoint_load a some point. I had changed a couple wpt flags then did the load later. I didn't touch the important wpts that session, I would assume that could cause a script failure?

Last night, sc_doc script failed once, to detect the first door had been opened (#198). I was doing a lot of disconnects & restarting the map and it did that. Disconnected again, restarted and it was ok after that, so just a minor hiccup I guess. More concerned about things I might do that could cause a script failure while tweaking the wpt ?


The only thing i know will break the scripts is maxplayers. It should be 8 when creating the scripts. But it will work it out after that. If the map has changed it might also break the script , check if the latest svencoop update hasnt changed any maps you are working on.

Other than that, the existing waypoint IDs should always remain the same even if you delete some. I've noticed sometimes waypoints don't appear to load...maybe AS bug , anyway bear in mind that the bot will load the waypoint file and script in the store folder first. If it doesn't exist will load from the rcw folder.

Posted by: madmax2 Jan 20 2019, 07:42 PM

My max_players has been set to 8 (default). I'll be going back to desertcircle next, i'll see if it happens again?

I haven't updated Sven on this PC, since XP is no longer supported by Sven or Steam. I updated the 1-19-19 build (d3ec0c131d96959c890dced23e7a7939518ed08c) yesterday. Wasn't sure if it would be a problem, but it is still working with the previous sven version smile.gif .

CODE
AngelScript

    Added new hooks: PickupObject::CanCollect, PickupObject::Materialize, PickupObject::Collected.
    DamageInfo.pVictim is no longer constant. (Fixes casting issues.)
    Documentation: Changed how hook description is handled and added description for all existing hooks.
    The plug-in manager can handle multiple plug-in lists now.
    Updated AngelScript to version 2.33.0 (22nd December 2018).
        IMPORTANT: Arrays no longer contains a "length" property. Getting the length of an array must be done with "array.length()" instead of "array.length".


Not sure what I will do going forward on the XP PC, keep sven at the older version or risk updating it? So long as the bots continue to work i'd prefer to keep it static. I can check for map changes in the change logs and on my other PC. Map changes are usually minor... smile.gif

Posted by: madmax2 Feb 10 2019, 06:16 AM

Build tested: d3ec0c131d96959c890dced23e7a7939518ed08c (1-19-19)

Possible Bug with Barney waypoints? (Not scripted barney/important wpts)

While working on the first Last map bots were initially moving fine. At some point bots began to sort of freeze and stop moving, and refused to press the button to activate the teleporter. After some confusion, I discovered it started when I put important givetypes on the 2 barney wpts that were already in the rcwa. After Removing the important givetypes bots began functioning & moving normal again.

Bots would seem to move normally at the beginning of the map, but as they got closer to the teleport room, they would move in a stop & go fashion. Move a few wpts, then stop for a minute or longer, then move again. When they got to the teleporter button they refused to press it most of the time, and they were very reluctant to step into the teleporter. I'm not sure if they would step into the teleporter, because I had been teleporting bots to the other side and working on that area of the map. On the other side of the teleporter, bots were showing the same stop & go symptom. So the teleport room probably doesn't have anything to do with the problem, it just appeared that way to me? the teleport destination is near the barney wpts, but not close. Just strange they would not press the teleport button...

I ran debug on the bots while in this state, and speed would be 100% but they were not moving, also task was null. Sometimes both bots would not be moving, other times one bot would freeze but the other was moving. So a bot could freeze or start moving independently of another bot...

The 2 barney wpts are fairly close in proximity, located at these security doors, one behind the other. This is the first and only map I've tried to use barney wpts... Oh, I also tested this on sc5.17 (XP), not sc5.18...

1st barney wpt
http://img4.imagetitan.com/img.php?image=19_last-barney1.jpg

2nd barney wpt
http://img4.imagetitan.com/img.php?image=19_last-barney2.jpg

debug - teleport room
http://img4.imagetitan.com/img.php?image=19_last-teleportroom1.jpg

debug - teleport button - bots refuse to press it! (or were extremely slow?)
http://img4.imagetitan.com/img.php?image=19_last-teleportbutton.jpg

debug - teleport destination, near the barney wpts
http://img4.imagetitan.com/img.php?image=19_last-ht.jpg

Posted by: Cheeseh Feb 10 2019, 11:54 AM

Hey madmax, will have a look later. Will let you know how the barney waypoints work just in case you might see what they are doing, don't know why their tasks are null though, maybe need to debug the task in the console to get a history of how they go into that state.

Btw Barney waypoints must also be important waypoints

1. Bot wants to go to an important waypoint which is also a barney waypoint
2. Bot has recently seen a barney/otis
2.1 bot goes to barney/otis
2.2 bot uses barney/otis
2.3 bot goes to barney waypoint
2.4 bot waits for barney to arrive
2.5 bot finishes task

I was thinking maybe point 2.4 that the bots might be getting stuck. But their task should still be WaitForEntity or something.




Posted by: madmax2 Feb 10 2019, 09:53 PM

QUOTE(Cheeseh @ Feb 10 2019, 03:54 AM) *

Hey madmax, will have a look later. Will let you know how the barney waypoints work just in case you might see what they are doing, don't know why their tasks are null though, maybe need to debug the task in the console to get a history of how they go into that state.

Btw Barney waypoints must also be important waypoints

1. Bot wants to go to an important waypoint which is also a barney waypoint
2. Bot has recently seen a barney/otis
2.1 bot goes to barney/otis
2.2 bot uses barney/otis
2.3 bot goes to barney waypoint
2.4 bot waits for barney to arrive
2.5 bot finishes task

I was thinking maybe point 2.4 that the bots might be getting stuck. But their task should still be WaitForEntity or something.

Ran more tests today. Bots can take otis to a barney wpt (if I teleport a bot to the area). The problem shows up before that, at or before the teleport. On my first run today it did not happen, but every time after that it did. To be sure it wasn't something I did with the waypoint, I made the wpt more basic by changing a oneway path to 2 way, removing some extra important wpts in the area, as well as wait & staynear, then I removed one barney so there is just one barney/important wpt.

I think I caught it at failure in the console:

CODE
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - THINK] CanHeal(monster_human_grunt_ally)
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - THINK] CanHeal(monster_human_grunt_ally)
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] pDoor !is null
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] m_currentRoute.length () == 0
[RCBOT][DEBUG - NAV] NavigatorState_ReachedGoal
[RCBOT][DEBUG - TASK] CFindPathTask COMPLETE
[RCBOT][DEBUG - TASK] m_pTasks.length() == 0
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 126
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 126
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 126
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 126
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 126
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED


I think it failed as soon as bots entered this teleport room. Bots are forced to stay in this room by a oneway path on the door. The teleport wpt has an openslater on it and i've tested both 1 & 2 paths to the destination room from the teleport wpt. Again, if the important givetype is removed from the barney wpt, bots will start moving normally again...

http://img4.imagetitan.com/img.php?image=19_last-2019-02-10-0002.jpg

Still on older build (1-19-19), I'll retest on latest build as soon as I'm done with this post. Assume it failed on new build if I don't report otherwise...

------------------------------------------------
[Edit] Build: eaeddeec3faaeb2724078a95535785f678593ea4

Ugh, found a problem in the wpt I was testing on (uploaded wpt is OK). That purple wpt in the image is a teleport wpt ohmy.gif . I must of hit the wrong key there, recently? I removed it & retested 3 games, the problem still persists, but slightly different symptoms...

Bots still do the stop & go movement when they near or enter the teleport room. They now will press the button to open the teleport, but it is a very, very slow process. Once the teleport opens, bots will go through the teleport and seem to move normally afterwards. So the problem does seem to be related to the teleport/openslater wpt and the barney/important wpt used together on the same map?

Ran debug again:

CODE
[RCBOT]debugging nav
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] m_currentRoute.length () == 0
[RCBOT][DEBUG - NAV] NavigatorState_ReachedGoal
[RCBOT][DEBUG - TASK] CFindPathTask COMPLETE
[RCBOT][DEBUG - TASK] m_pTasks.length() == 0
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 134
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 134
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 134
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 134
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 134


And farther down in console:

CODE
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 129
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 129
[RCBOT][DEBUG - NAV] Navigator State FOUND_GOAL...

[RCBOT][DEBUG - NAV] m_fExecutionTime < g_Engine.time
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] m_currentRoute.length () == 0
[RCBOT][DEBUG - THINK] CanHeal(player)
[RCBOT][DEBUG - TASK] CBotTaskWait COMPLETE
[RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete
[RCBOT][DEBUG - NAV] NavigatorState_ReachedGoal
[RCBOT][DEBUG - TASK] CFindPathTask COMPLETE
[RCBOT][DEBUG - TASK] m_pTasks.length() == 0
L 10/02/2019 - 15:27:12: "MadMax2<1><STEAM_ID_LAN><players>" stats: frags="7.93" deaths="0" health="100"
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 162
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 162
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 162
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 162
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED

Posted by: Cheeseh Feb 11 2019, 08:41 AM

Hmm, remember that if you use a teleport waypoint, then the path will only be valid when the teleport is active and arrives at the teleport destination that the path goes to. If the path is invalid and their current waypoint is a teleport waypoint then they will be stuck. Check if that is the problem. If it is, try adding a regular waypoint next to the teleport waypoint that has a fall back route. As it looks like the bot is continually choosing waypoint 162 as the current waypoint, and it should choose a different waypoint if it failed, which seems to me there may be no other waypoints nearby?

Posted by: madmax2 Feb 12 2019, 10:50 PM

QUOTE(Cheeseh @ Feb 11 2019, 12:41 AM) *

Hmm, remember that if you use a teleport waypoint, then the path will only be valid when the teleport is active and arrives at the teleport destination that the path goes to. If the path is invalid and their current waypoint is a teleport waypoint then they will be stuck. Check if that is the problem. If it is, try adding a regular waypoint next to the teleport waypoint that has a fall back route. As it looks like the bot is continually choosing waypoint 162 as the current waypoint, and it should choose a different waypoint if it failed, which seems to me there may be no other waypoints nearby?

Been shoveling snow the last couple days, was to exhausted last night to test/reply... blink.gif

Retested/checked, That is not the problem. Think my last post was too wordy and you missed the point? unsure.gif

The current uploaded waypoint in my pack works perfectly at the teleport. Bots press the teleport button quickly and enter the teleport quickly. It currently does not have any important+barney wpts, just two barney wpts. If you add an important givetype to a barney wpt, save and restart the map, you will see the problem at the teleport room. Bots will pause on random wpts in that room for minutes. It took 8+ minutes for a bot to go to the teleport button & press it today (There is an important wpt at the button). None of this happens when there is no important+barney wpt in the map.

It's a very strange problem... ohmy.gif

Posted by: madmax2 Feb 13 2019, 09:36 PM

QUOTE(madmax2 @ Feb 12 2019, 02:50 PM) *

Been shoveling snow the last couple days, was to exhausted last night to test/reply... blink.gif

Retested/checked, That is not the problem. Think my last post was too wordy and you missed the point? unsure.gif

The current uploaded waypoint in my pack works perfectly at the teleport. Bots press the teleport button quickly and enter the teleport quickly. It currently does not have any important+barney wpts, just two barney wpts. If you add an important givetype to a barney wpt, save and restart the map, you will see the problem at the teleport room. Bots will pause on random wpts in that room for minutes. It took 8+ minutes for a bot to go to the teleport button & press it today (There is an important wpt at the button). None of this happens when there is no important+barney wpt in the map.

It's a very strange problem... ohmy.gif

The problem seems to be bots can no longer see the important wpt at the teleport button, when there is a important+barney wpt in the map. I can get them to press the teleport button better if I add an ammo/health givetype to it, as they think it is a dispenser. They still pause on wpts in & around the teleport room, but will go through the teleport once it is on. Bots will return to the button & turn the teleport off & on until they forward spawn. Kind of a wacky work-around. blink.gif

It's not that important that bots can use otis in this map, they can finish the map without him. I can leave otis for the players. Just thought this problem could effect other maps too?

Posted by: madmax2 May 15 2019, 07:34 PM

Hey Cheeseh,

I'm still working on my dods rcw, but wanted to ask about bot suicides on rcbot-AS.

While working on sc_royals2, I never noticed bots suicide when they appeared to be stuck for a while. I never saw any suicide messages in the console either. Should I see a suicide message from rcbot?

Also, is it the bots "speed" that determines when to suicide? I ran debug a few times when they were stuck, most of the time the speed was around 50% dipping to 45%. There was other times when speed was under 10%. I think there was one time it would stay under 10%, but most times it's variable. Say 5% for 10 seconds then goes to 18% for a few seconds then back down to around 5%, etc...

Anyways, I never could confirm they would suicide in stuck situations? blink.gif

Hmm, I just thought of a way I could test for suicides, teleport a bot into a wall and see if it will suicide? rolleyes.gif

Posted by: Cheeseh May 27 2019, 08:51 AM

QUOTE(madmax2 @ May 15 2019, 08:34 PM) *

Hey Cheeseh,

I'm still working on my dods rcw, but wanted to ask about bot suicides on rcbot-AS.

While working on sc_royals2, I never noticed bots suicide when they appeared to be stuck for a while. I never saw any suicide messages in the console either. Should I see a suicide message from rcbot?

Also, is it the bots "speed" that determines when to suicide? I ran debug a few times when they were stuck, most of the time the speed was around 50% dipping to 45%. There was other times when speed was under 10%. I think there was one time it would stay under 10%, but most times it's variable. Say 5% for 10 seconds then goes to 18% for a few seconds then back down to around 5%, etc...

Anyways, I never could confirm they would suicide in stuck situations? blink.gif

Hmm, I just thought of a way I could test for suicides, teleport a bot into a wall and see if it will suicide? rolleyes.gif


sorry didn't notice your message for a while.

The bots suicide when they have failed all possible tasks available to them. which could be when they fall in to a pit where there are no waypoints or when walk into a place where there is no way out. So it isn't to do with speed exactly.

Posted by: madmax2 May 28 2019, 07:47 PM

QUOTE(Cheeseh @ May 27 2019, 12:51 AM) *

sorry didn't notice your message for a while.

The bots suicide when they have failed all possible tasks available to them. which could be when they fall in to a pit where there are no waypoints or when walk into a place where there is no way out. So it isn't to do with speed exactly.

Okay, I was thinking the old rcbots used speed to determine when to suicide, the "config bot_stuck_speed" setting. The big problem on sc_royals2 was at that skull post, I never could get them to suicide, and getting free from the post is very difficult. It's kinda a map flaw, a sticky spot. It just took a long time to find a waypoint configuration that seemed to work ok there. There was a couple other places bots got stuck, adding or moving waypoints seemed to correct the problems... On maps with flaws, with waypoints nearby, this might be an issue to look at? No rush, I've been busy with other things the last few weeks, Spring stuff. I Still have several waypoints to convert, I plan to get back to it at some point... wink.gif

Posted by: Ryusho Aug 20 2019, 02:50 AM

So I was just recently trying to make waypoints for the HL1 Campaign for this bot, and for some reason at the start of some maps, shortly after the "Chapter text" Dissappears, all waypoints and paths dissappear from visibility, quite often for some reason I don't know why, but they do even if I have them set to On, and they will not become visible unless I restart the map and only then they may sometimes stay on, other times they disable themselves

Posted by: Cheeseh Aug 20 2019, 06:20 PM

QUOTE(Ryusho @ Aug 20 2019, 03:50 AM) *

So I was just recently trying to make waypoints for the HL1 Campaign for this bot, and for some reason at the start of some maps, shortly after the "Chapter text" Dissappears, all waypoints and paths dissappear from visibility, quite often for some reason I don't know why, but they do even if I have them set to On, and they will not become visible unless I restart the map and only then they may sometimes stay on, other times they disable themselves


This is because there is a limit to the number of beams that can be displayed. In the latest version, when you put waypoints on, all beams are deleted to make space for waypoint beams. uYou can try putting waypoints off then back on again to see if that helps and make sure you are using the latest. there are some entities that keep firing beams with beams which cause it. Which map was it?

Posted by: Ryusho Sep 8 2019, 08:21 PM

QUOTE(Cheeseh @ Aug 20 2019, 12:20 PM) *

This is because there is a limit to the number of beams that can be displayed. In the latest version, when you put waypoints on, all beams are deleted to make space for waypoint beams. uYou can try putting waypoints off then back on again to see if that helps and make sure you are using the latest. there are some entities that keep firing beams with beams which cause it. Which map was it?


I had it happen at the start of the first Campaign map, before you even get to where it's dangerous, so the one before the incident, and then I have had it happen just after the incident, so first two missions technically, I believe it would be hl_c01_a1 and hl_c02_a1

Posted by: Poka Aug 5 2020, 10:20 AM

Hey,

I've been messing around with the bots for some time now in the Half-Life campaign and noticed some bugs.

In hl_c03 the switch that opens the freezer door is a func_door_rotating so bots don't know how to open it but it can be fixed by adding that entity in CFindButtonTask.

In hl_c05_a2 the switches are normal rot_buttons but I think the bots are checking the frame value and it can be 1 even when the door is closed so bots are confused.

IPB Image

And in hl_c10 there's a shootable button behind the fence that disables the electricity and opens the door but the bots don't know how to deal with shootable buttons.

IPB Image

That's all for now tongue.gif
I'm also running a server with RCBots at 95.216.199.22:27015 if anyone is interested

Posted by: Cheeseh Aug 5 2020, 08:55 PM

thanks for the info.

I've added func_door_rotating to the list , will update soon.

The frame value is used to tell if the button has been pressed which is always the case. The reason bots are probably confused is that the waypoint next it it is probably an 'important' waypoint, which bots will simply find the nearest button and press it. Bots shouldn't need 'important' waypoints next to doors, they should be able to find them automatically. Automatically waypoints become 'important' waypoints next to buttons just top save time for novice waypointers, so its probably best to remove the important type and try.

The bots seem to have trouble identifying doors with multi_managers and buttons I'm still working on it, possibly continue tomorrow, getting late.

Posted by: Poka Aug 5 2020, 09:24 PM

QUOTE(Cheeseh @ Aug 5 2020, 11:55 PM) *

The frame value is used to tell if the button has been pressed which is always the case. The reason bots are probably confused is that the waypoint next it it is probably an 'important' waypoint, which bots will simply find the nearest button and press it. Bots shouldn't need 'important' waypoints next to doors, they should be able to find them automatically. Automatically waypoints become 'important' waypoints next to buttons just top save time for novice waypointers, so its probably best to remove the important type and try.


The problem is that theres two switches on that one door. The first one opens it and then they get in and the second switch closes it (and teleports them to a new area). When the bots die and come back to that door the switch is still on frame 1 even though the door is closed so they would need to use the switch again to open the door but they just try to run through the the door.

It's quite rare to have door opening system like that though so maybe it's not something to prioritize.

Posted by: madmax2 Aug 9 2020, 09:50 PM

Hi Poka,
Nice, how far into the HL campaign are you? Are you attempting the whole campaign?

Hey Cheeseh,
I was going to report bots not shooting some enemies on sc_activist (barneys, otis, & swat), but I see you fixed that, nice work smile.gif . I think I tested that a month ago and the problem was there, it must of been a recent fix?
=================================
But on sc_activist2, bots don't attack zord. They need to use grenades to hurt him, bullets do nothing... (they don't shoot at him, either)

"Super-Mega Containment Zord" in red on hud

CODE
[RCBOT]25 : monster_gargantua frame=148.953857 distance = 80.819305 (x=-57.912491,y=-674.03125,z=-212.582733) visible=1,solid=3,angle.x = 0, angle.y = 180 active = 1


Also, The lift button wasn't working for either old metamod or new AS bots. The waypoints will need some rework there, because some are noclipped into the button, and I did a search and found the button wasn't exactly where I thought it was... Guess I should check the git rcwa's, not sure if there were some changes done?

Lift button is centered in lift shaft on right wall about half way up, its one large button for both top & bottom.
When lift is up frame=1 when down frame=0
CODE
[RCBOT]282 : func_button frame=1 distance = 24.779984 (x=-88,y=-767.5,z=-75) visible=1,solid=4,angle.x = 0, angle.y = 0 active = 1
[RCBOT]282 : func_button frame=0 distance = 24.779984 (x=-88,y=-767.5,z=-75) visible=1,solid=4,angle.x = 0, angle.y = 0 active = 1

So I might be able to script it, Though the size and position might be a problem?
=================================
I've been working on some fixes for crystal, but I got stuck on the HT on top of the box into the vent, for several hours, the other day... It's a very difficult HT and I have them towering under the opening to the vent, but I can't get the top bot to stand up (like the old metamod bots would do), then crouch jump into the vent. I've done a few fixes/tweaks before this point. So, for now, I will set up the HT for bots to crouch for the player, and test/fix the other parts of the waypoint, then upload it. I started work on this from the git rcwa. It might need a script, but I will see how well it works without one first...

Posted by: Poka Aug 10 2020, 09:54 AM

duplicate post

Posted by: Poka Aug 10 2020, 10:32 AM

QUOTE(madmax2 @ Aug 10 2020, 12:50 AM) *

Hi Poka,
Nice, how far into the HL campaign are you? Are you attempting the whole campaign?

I'm doing a bit here and there when I think the bots could potentially make through the whole map. Maybe eventually I'll have something for all the maps.

Also ran into a null pointer in hl_c11_a1 right when the door opens and the bots freeze. The problem seems to be with bots trying to use gauss.

CODE

Angelscript: Not allowed: in section 'c:/program files (x86)/steam/steamapps/common/sven co-op/svencoop/scripts/plugins/botmanager/botweapons.as', at (520, 21):Angelscript:  Function Angelscript: DoWeapons:
Angelscript: Message: Null pointer access
ERROR: Angelscript: CASBaseCallable::Call: Execution of function 'BotManager::Think' failed!
ERROR: Angelscript: CScheduler::Think: execution of function BotManager::Think failed!



Posted by: Cheeseh Aug 10 2020, 07:44 PM

QUOTE(madmax2 @ Aug 9 2020, 10:50 PM) *

Hey Cheeseh,
I was going to report bots not shooting some enemies on sc_activist (barneys, otis, & swat), but I see you fixed that, nice work smile.gif . I think I tested that a month ago and the problem was there, it must of been a recent fix?


I updated the IsEnemy func based on the svencoop classification for enemies which might have fixed it

QUOTE(madmax2 @ Aug 9 2020, 10:50 PM) *

But on sc_activist2, bots don't attack zord. They need to use grenades to hurt him, bullets do nothing... (they don't shoot at him, either)


Bots don't attack gargantuas unless they have an explosive weapon such as a grenade/rpg etc. But they won't use grenade unless they are in a good distance so they might not even use them at all. Still an improvement required. But if there is an rpg available perhaps best to make a script to make bots go there until the gargantua is killed.

QUOTE

Also, The lift button wasn't working for either old metamod or new AS bots. The waypoints will need some rework there, because some are noclipped into the button, and I did a search and found the button wasn't exactly where I thought it was... Guess I should check the git rcwa's, not sure if there were some changes done?



I'm going to update the bots such that they will ppress a button until the 'frame' changes instead of it turning '1', the point of that code was just to let bots know they were successful pressing the button so they can do something else - if frame changes then they will at least try to press the button until it changes (either on or off) which might fix the button issue.

QUOTE

lso ran into a null pointer in hl_c11_a1 right when the door opens and the bots freeze. The problem seems to be with bots trying to use gauss.

I'll put a null check in for the minigun code and add gauss gun to the weapon list

Posted by: madmax2 Aug 11 2020, 12:28 AM

I just looked at the git (8-10-20 build), some really good improvements smile.gif ... But bots shooting hornets has got to be one of the funniest things I've seen any bots do laugh.gif . It just gives your bots some comic personality wink.gif . I know it can cause some problems for the bots, but haven't seen anything to serious. Perhaps you could think about making that optional, a cvar to turn off hornet shooting? Just a thought, but no problem if you don't want to do that, I can live with the change wink.gif ... Thanks for all your hard work...

Posted by: Poka Aug 12 2020, 06:22 PM

Came across a weird bug in hl_c11_a5. When a bot uses this func_rotating_door leading into the pipes it just rotates right through the bot and you get a null pointer error. blink.gif

EDIT: I think the problem is that the wheel attached to the door gets killtargeted when the door opens and the bot is still trying to use it

CODE

ERROR: Angelscript: CASBaseCallable::Call: Execution of function 'BotManager::Think' failed!
ERROR: Angelscript: CScheduler::Think: execution of function BotManager::Think failed!
Angelscript: Not allowed: in section 'c:/program files (x86)/steam/steamapps/common/sven co-op/svencoop/scripts/plugins/botmanager/utilfuncs.as', at (48, 2):Angelscript:  Function Angelscript: UTIL_EntityOrigin:
Angelscript: Message: Null pointer access


IPB Image

Posted by: Cheeseh Aug 13 2020, 09:10 PM

I will try to have a look into it tomorrow

Posted by: Cheeseh Aug 14 2020, 07:22 PM

QUOTE(Cheeseh @ Aug 13 2020, 10:10 PM) *

I will try to have a look into it tomorrow


I Believe I've fixed it now

Posted by: Poka Aug 15 2020, 12:40 PM

QUOTE(Cheeseh @ Aug 14 2020, 10:22 PM) *

I Believe I've fixed it now


Yeah no more crashing. Good work smile.gif

Posted by: Poka Aug 18 2020, 07:12 AM

I did some xen waypointing and here are some things I ran into:

1) Couldn't get the bots to longjump with the crouchjump waypoint

2) Bots like to shoot at tentacles. Not sure why it's commented out in IsEnemy() but adding it there seemed to work.

3) Bots don't shoot at Gargantua even though they have weapons like the rocket launcher and egon

4) Bots shoot at Nihilanth before destroying the crystals. Could fix maybe by having the bots check for the existence of n_recharge type targetnamed info_targets (https://twhl.info/wiki/page/monster_nihilanth) and having them ignore Nihilanth if they exist. Breaking the func_breakable crystals seems to killtarget them.

Posted by: Cheeseh Aug 18 2020, 03:40 PM

Thanks. Will look into them

Posted by: madmax2 Aug 18 2020, 06:49 PM

QUOTE
1) Couldn't get the bots to longjump with the crouchjump waypoint

I tried to fix jumpers a while back, and I couldn't get the bots to make the long jumps with crouchjump wpt. They kept falling short. It is a different jump from normal, but they are not getting the distance the old rcbots were getting...

QUOTE
3) Bots don't shoot at Gargantua even though they have weapons like the rocket launcher and egon

Bots need to be able to grenade them, too. Some maps don't have those super weapons available.

[edit] For longjump in sc5, It's actually easier than it used to be, you can actually hold the crouch through the jump. I think with sc4.8, you had to release the crouch key just as you hit jump key. It looks like they are pressing the crouch key & jump key at the same time. It should be run, hold crouch key, then press jump key (don't release crouch until through the jump).

Posted by: Cheeseh Aug 19 2020, 07:03 AM

QUOTE(madmax2 @ Aug 18 2020, 07:49 PM) *

I tried to fix jumpers a while back, and I couldn't get the bots to make the long jumps with crouchjump wpt. They kept falling short. It is a different jump from normal, but they are not getting the distance the old rcbots were getting...
Bots need to be able to grenade them, too. Some maps don't have those super weapons available.

[edit] For longjump in sc5, It's actually easier than it used to be, you can actually hold the crouch through the jump. I think with sc4.8, you had to release the crouch key just as you hit jump key. It looks like they are pressing the crouch key & jump key at the same time. It should be run, hold crouch key, then press jump key (don't release crouch until through the jump).


I had a look at the code and long jumps atent actually implemented. I addrd code last night but not tested, will do that tonight before updating

I might have removed the "explosive" property from the grenade weapon so bots don't use them randomly, i will check . Eventually will need to add proper grenade code

Posted by: Cheeseh Aug 19 2020, 09:05 PM


I added some prelim longjump code u can try

Posted by: Poka Aug 20 2020, 08:21 AM

QUOTE(Cheeseh @ Aug 20 2020, 12:05 AM) *

I added some prelim longjump code u can try


Now they can do the longjump but there's still a problem with the direction where they do it laugh.gif The bots keep looking at random directions and when they perform the longjump they'll end up jumping in the direction they're facing which isn't very often the next waypoint.

Posted by: madmax2 Aug 20 2020, 05:01 PM

QUOTE(Cheeseh @ Aug 19 2020, 12:03 AM) *

I had a look at the code and long jumps atent actually implemented. I addrd code last night but not tested, will do that tonight before updating

I might have removed the "explosive" property from the grenade weapon so bots don't use them randomly, i will check . Eventually will need to add proper grenade code

Thanks, I missed this yesterday... smile.gif I've been working on the crystal rcwa, and a script for that map...

QUOTE
Now they can do the longjump but there's still a problem with the direction where they do it [X]laugh.gif The bots keep looking at random directions and when they perform the longjump they'll end up jumping in the direction they're facing which isn't very often the next waypoint.

laugh.gif , perhaps a wait to a crouchjump helps??? I need to see this... biggrin.gif

Posted by: Cheeseh Aug 20 2020, 06:10 PM

QUOTE(Poka @ Aug 20 2020, 09:21 AM) *

Now they can do the longjump but there's still a problem with the direction where they do it laugh.gif The bots keep looking at random directions and when they perform the longjump they'll end up jumping in the direction they're facing which isn't very often the next waypoint.


I will add that in. tongue.gif

Posted by: Cheeseh Aug 20 2020, 07:08 PM

QUOTE(Cheeseh @ Aug 20 2020, 07:10 PM) *

I will add that in. tongue.gif


should be improved now

Posted by: madmax2 Aug 20 2020, 10:10 PM

Hi Cheeseh,

Could you explain this? (I looked at git, looks like the longjump module is required)

QUOTE
bots without longjump try to avoid crouchjump waypoints

Do you mean the long jump module? I just downloaded and will test shortly... thanks...

[EDIT]
Ok, I Tested on jumpers platforms, and the longjump is working good, everyone gets longjump module. smile.gif
(Build ba9c657879496775d1b0896cf4296334e3e4636f)

I checked a few other maps, and the requirement to have the module will break some existing good waypoints. Could you remove that requirement? The waypointer can either force bots to the longjump module, or it could be scripted like you did the RPG on vger, or added to the map cfg. Bots would just do a low jump without the module, which should work ok on existing wpts and could be useful. I guess another way to go would be to have a longjump and crouchjump wpt, but that may not be needed? I can't test it without the longjump module right now.

Maps that will break include, sc_persia, sc_royals2, sc_royals3, sc_psyko, the crouchjump is in main path. Part of shattered and murks won't work, there may be some in last series too. I've only looked at 10 maps. Some waypoints could be easily fixed (remove crouchjump or change to jump), maybe some not so easy (sc_royals2 cavern jumps)? There could be a lot of untested wpts in the git that will break?

You probably don't need this, but here is a debug of the current rope crouchjump at the 2nd pegs area, on sc_persia. Bots won't cross the rope, unless I change it to a normal jump. I changed it back to crouchjump and teleported the bot back before the rope...

CODE
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - TASK] CBotTaskWaitNoPlayer COMPLETE
[RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete
[RCBOT]ID = 90 FLAGS = ,crouchjump
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - TASK] CBotTaskWaitNoPlayer COMPLETE
[RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete
L 20/08/2020 - 18:00:29: "[m00]3gg<14><BOT><players>" stats: frags="21.40" deaths="5" health="100"
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - TASK] CBotTaskWaitNoPlayer COMPLETE
[RCBOT][DEBUG - TASK] m_pCurrentTask.m_bComplete
[RCBOT]ID = 90 FLAGS = ,crouchjump
L 20/08/2020 - 18:00:36: "MadMax<13><STEAM_ID_LAN><players>" stats: frags="95.21" deaths="0" health="1"
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] touchedWpt()
] as_command rcbot.teleport [m00]3gg
[RCBOT]teleported [m00]3gg
[RCBOT][DEBUG - NAV] touchedWpt()
[RCBOT][DEBUG - NAV] BotNavigator FAIL
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 84
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 84
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] RCBotWaypointBeliefSorter Chose Waypoint 148 (0)
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 84
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] RCBotWaypointBeliefSorter Chose Waypoint 151 (2)
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 84
[RCBOT][DEBUG - NAV] NavigatorState_Fail
[RCBOT][DEBUG - TASK] CFindPathTask FAILED
[RCBOT][DEBUG - NAV] m_iCurrentWaypoint == 84

Posted by: Cheeseh Aug 21 2020, 11:44 PM

Hi madmax . Just convert the crouchjump waypoints to jump

Use the command

as_command rcbot.waypoint_convert_type <type_from> <type_to>


for example


as_command rcbot.waypoint_convert_type crouchjump jump

Then save waypoints

Otherwise i can add add cvar to enable/disable

Posted by: madmax2 Aug 22 2020, 06:53 PM

QUOTE(Cheeseh @ Aug 21 2020, 04:44 PM) *

Hi madmax . Just convert the crouchjump waypoints to jump

Use the command

as_command rcbot.waypoint_convert_type <type_from> <type_to>
for example
as_command rcbot.waypoint_convert_type crouchjump jump

Then save waypoints

Otherwise i can add add cvar to enable/disable

Yeah, I forgot about that rolleyes.gif ... I think a cvar is a good idea. My preference would be to have longjump module disabled by default. I don't think there are many maps that would require it. I was thinking we should keep backwards compatibility with the old converted wpts in the git. To be honest, I can't remember where I used crouchjump on most maps, but usually, I only used it because it worked better than a regular jump, for some situations. I'm sure more of my rcw's have crouchjumps, but most of the time, I use a normal jump.

I checked the cavern jumps on sc_royals2, I used a crouchjump at the first jump (it sets the timing for all the other jumps). I changed it to a jump, and bots over shoot the 1st jump 90% of the time. I did see a bot make it across, but most of them fail/fall. So I tried combined jump+crouch and it was worst, bots would land on first stone, but would be out of position for next jump and just jumped sideways, they wouldn't pull back to the staynear wpt. The jumps in this map were very touchy/difficult, so I expected I would at least need to test this area.

It would be good if we could put cvar's into a map specific cfg to include with waypoints going forward. Perhaps in the config folder, can we do this now? Sven updates might wipe the map cfg's in map folders, not sure about that though? I know they replace the BotManager.as.

Posted by: Cheeseh Aug 23 2020, 10:06 AM

hi madmax . for now the bot only loads "quota" and "script_entity_offset" per config or per map config. I will need to update that - and try to add a cvar to enable/disable long jump requirement per map -

in RCBot AS the bots just did a regular jump anyway at "crouchjumps" . that was my reasoning behind making crouchjump a "long jump only" waypoint. My reasoning behind not allowing bots without longjump to avoid "crouchjumps" is so they can try to find a longump module first. but if you think a "crouchjump" might be better than a regular jump, in reality they only hold crouch button for under <0.2 seconds and then press jump, so I don't know if that will bring any advantage.

Posted by: madmax2 Aug 23 2020, 07:56 PM

I'm not sure why, but the old CJ seems to yield a flatter jump than a normal jump, the distance is different. I was thinking that might still be useful in maps that don't have the module. Any change you made to the timing to get longjump working, probably changed the CJ timing w/o the module too.

Would it be easier to add the cvar without the cfg support, so I could test that on royals2, and some other maps? Or would a new longjump wpt type be easier to implement, but perhaps that would defeat the purpose of the change? Sorry, I'm kinda being picky , lol... I do see your reasoning, it doe's make sense, and may fix some existing wpts in the git where the module is required to advance...

[Edit] Ran a test with a straight long approach. Jump+crouch is more like crouch into a hop, it's very short. CJ looks like it's about 75 or 80% of a normal jump. It may not be flatter.

Posted by: danylopez123 Feb 11 2021, 04:36 PM

I was thinking that maybe you could implement an option to make the bots press E if they are stuck with Players/Bots.
That is to be used with wootguy's AntiBlock: https://github.com/wootguy/AntiBlock

Posted by: madmax2 May 24 2021, 08:24 PM

I've noticed bots no longer use the wrench/crowbar when enemies are like 0 distance or very close. Perhaps they only use the crowbar when they are out of ammo? I'd like to see them use the wrench/crowbar when enemies are 0 distance or very very close, rather than trying to reload guns. I'm thinking this might help bots move forward in vents better when there are headcrabs? Just want to see them whack the headcrabs (& other enemies) again... laugh.gif

[Edit] Okay, my bad. I should of checked this on another map. On abandoned bots are using the wrench when they just have the glock at the beginning. If they pick up better weapons then they don't use the wrench/crowbar. On yabma you start with the python/357 then quickly get a shotgun and there is ample ammo, so I never saw bots use the wrench. So I guess it's in the weapon priority settings... In some ways I like it the way it is, but I would like to see a bit more crowbar use too, like on headcrabs at close range. Maybe after exhausting their ammo in the clip, rather than reload when touching enemies, use the crowbar/wrench, something like that??? On yabma, 3 pitdrones would surround a bot and the bot would reload the shotgun 1 shell at a time & shoot. Just would be nice if there was some way to get them to use the crowbar a bit more, but not over use it, if you know what I mean... I probably should check a few more maps, see what they are doing with melee weapons...

[Edit] I observed a bot with the uzi switch perfectly to the wrench when an enemy was close, then reload & continue shooting the uzi after the enemy was dead. Just like it was a glock. So it seems bots won't do that with some weapons, like the shotgun, mp5, 357, or the M16 (not sure about the M16? by the time they had it, they had the other weapons too, but I never noticed them melee at all on yabma).

I'm still checking the 1st vent in yabma, want to make a few more test runs though that area, make sure the latest patch is good... I see you updated the git, so i'm updating to the latest build... smile.gif

Posted by: madmax2 Nov 8 2021, 07:12 PM

Hey Cheeseh,

It's good you improved bot suicide logic, but I've been seeing bots suicide just running between wpts, for no apparent reason. It seems to need some tweaking...? (build c7064288c)

Often, They don't look like they are hanging on anything, they seem to be moving at normal speed. Also, Saw a bot suicide while moving a pushable. It happens frequent enough, you should see it within minutes. I'm not sure if it happens when engaging with enemies, it may only happen when no enemies are near by? I've seen it a number of times just before a bot reaches the End wpt. I haven't tried debug yet...

Posted by: Cheeseh Nov 9 2021, 06:47 AM

QUOTE(madmax2 @ Nov 8 2021, 07:12 PM) *

Hey Cheeseh,

It's good you improved bot suicide logic, but I've been seeing bots suicide just running between wpts, for no apparent reason. It seems to need some tweaking...? (build c7064288c)

Often, They don't look like they are hanging on anything, they seem to be moving at normal speed. Also, Saw a bot suicide while moving a pushable. It happens frequent enough, you should see it within minutes. I'm not sure if it happens when engaging with enemies, it may only happen when no enemies are near by? I've seen it a number of times just before a bot reaches the End wpt. I haven't tried debug yet...


Yeah I'm also seeing it and will change it probably again. I mainly put it in for cases when the bots simply couldn't move but then O thought there could be cases when they could move, but just stick in a locked area for example. I'll change it back to purely stuck tonight for the time being

Posted by: madmax2 Nov 10 2021, 04:34 AM

QUOTE(Cheeseh @ Nov 8 2021, 10:47 PM) *

Yeah I'm also seeing it and will change it probably again. I mainly put it in for cases when the bots simply couldn't move but then O thought there could be cases when they could move, but just stick in a locked area for example. I'll change it back to purely stuck tonight for the time being

Okay, sounds good... You may include my last yabma rcwa & scripts, if you like (5c)... smile.gif
http://rcbot.bots-united.com/forums/index.php?s=&showtopic=2212&view=findpost&p=15304

[Edit] I saw you uploaded a new build, no more random suicides, Thanks... smile.gif