IPB

Welcome Guest ( Log In | Register )

4 Pages V « < 2 3 4  
Reply to this topicStart new topic
> Possible Bugs or Observed Issues Topic
Cheeseh
post Jan 9 2019, 07:39 PM
Post #61


Admin
*****

Group: Admin
Posts: 3,017
Joined: 11-September 03
From: uk
Member No.: 1



Hi madmax -- I fixed it now, it was introduced when I added the new 'not equals' operator, it now accepts 'null' again
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jan 9 2019, 11:37 PM
Post #62


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jan 13 2019, 12:22 AM
Post #63


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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...
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Jan 13 2019, 02:56 PM
Post #64


Admin
*****

Group: Admin
Posts: 3,017
Joined: 11-September 03
From: uk
Member No.: 1



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.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jan 13 2019, 06:18 PM
Post #65


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jan 19 2019, 09:51 PM
Post #66


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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 ?
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Jan 20 2019, 11:12 AM
Post #67


Admin
*****

Group: Admin
Posts: 3,017
Joined: 11-September 03
From: uk
Member No.: 1



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.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jan 20 2019, 07:42 PM
Post #68


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Feb 10 2019, 06:16 AM
Post #69


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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
IPB Image

2nd barney wpt
IPB Image

debug - teleport room
IPB Image

debug - teleport button - bots refuse to press it! (or were extremely slow?)
IPB Image

debug - teleport destination, near the barney wpts
IPB Image
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Feb 10 2019, 11:54 AM
Post #70


Admin
*****

Group: Admin
Posts: 3,017
Joined: 11-September 03
From: uk
Member No.: 1



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.



User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Feb 10 2019, 09:53 PM
Post #71


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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

IPB Image

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
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Feb 11 2019, 08:41 AM
Post #72


Admin
*****

Group: Admin
Posts: 3,017
Joined: 11-September 03
From: uk
Member No.: 1



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?
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Feb 12 2019, 10:50 PM
Post #73


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Feb 13 2019, 09:36 PM
Post #74


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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?
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post May 15 2019, 07:34 PM
Post #75


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post May 27 2019, 08:51 AM
Post #76


Admin
*****

Group: Admin
Posts: 3,017
Joined: 11-September 03
From: uk
Member No.: 1



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.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post May 28 2019, 07:47 PM
Post #77


RCBot Guru
*****

Group: Waypointers
Posts: 845
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



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
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Ryusho
post Aug 20 2019, 02:50 AM
Post #78


Member
**

Group: Members
Posts: 36
Joined: 25-December 08
Member No.: 1,436



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
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Aug 20 2019, 06:20 PM
Post #79


Admin
*****

Group: Admin
Posts: 3,017
Joined: 11-September 03
From: uk
Member No.: 1



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?
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

4 Pages V « < 2 3 4
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



- Lo-Fi Version Time is now: 25th August 2019 - 05:41 AM