Coding Frikbots to be scared of heights
-
- Posts: 169
- Joined: Wed Nov 28, 2007 6:15 am
Coding Frikbots to be scared of heights
Does anyone here know of a way to code Frikbots to be afraid of falling off ledges during a fight? The biggest reason why Frikbots commit suicide and/or get stuck is because they jump off ledges when they see another bot/player. This gets them off course, and they attempt to get back up to where they were before the battle started (and they run in to a wall or jump off a cliff as a result). In maps with a void, the bots will consistently run to their death while attempting to charge a bot/player. The way I see it, all of these problems would be resolved if the bots simply refused to jump off ledges unless a waypoint told them to do so. Otherwise, they commit suicide and get stuck far too often. In Unreal Tournament, bots will shoot down at players standing near an edge, but will not jump down to join a fight unless a waypoint is nearby that allows them to do so. With the Frikbots, they charge forward during a battle regardless of what the waypoints tell them to do... This results in many suicides in void maps, and also results in bots getting stuck up against walls.
Here is an example video showing the Frikbots suiciding almost non-stop in a map called "Coagula2". This map was waypointed by me. The bots will navigate the map flawlessly when they are alone (no suicides at all). As soon as other bots are added however, they constantly jump to their deaths while attempting to charge other bots across gorges and off ledges:
http://www.youtube.com/watch?v=8UEtncOZA0o
Anyone have any ideas? I think the Frikbots would get stuck and die significantly less if this issue were resolved.
Here is an example video showing the Frikbots suiciding almost non-stop in a map called "Coagula2". This map was waypointed by me. The bots will navigate the map flawlessly when they are alone (no suicides at all). As soon as other bots are added however, they constantly jump to their deaths while attempting to charge other bots across gorges and off ledges:
http://www.youtube.com/watch?v=8UEtncOZA0o
Anyone have any ideas? I think the Frikbots would get stuck and die significantly less if this issue were resolved.
Re: Coding Frikbots to be scared of heights
Probably a double traceline check - a traceline forward some 128 units, and then from there a traceline down, and then detect contents progressively upward for hazards
i should not be here
-
- Posts: 169
- Joined: Wed Nov 28, 2007 6:15 am
Re: Coding Frikbots to be scared of heights
Any idea how this can be implemented in the code? I'm not a coder, or I would do it myself (I can do minor modifications to existing code, but not anything complicated like this). My current project is waypointing, and I've now completed 650 maps. There are a handful of void maps that the bots end up with negative scores on, and other maps they get stuck all the time because of jumping wildly off cliffs to attack other bots.leileilol wrote:Probably a double traceline check - a traceline forward some 128 units, and then from there a traceline down, and then detect contents progressively upward for hazards
Any coder willing to help would be effectively improving bot performance on 650 maps, and I would be VERY grateful. I am currently working with a different coder on creating a zombie mod for the Frikbots, which makes it even more necessary to have improvements like this. I would of course give full credit to all those who help on this project. I plan on releasing a full waypoint pack, complete with nearly 700 supported maps (when I'm done), a zombie mod, and hopefully improved Frikbots.
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Coding Frikbots to be scared of heights
Be careful. traceline is among the most expensive builtins in QuakeC, CPU wise. Adding 2 tracelines per bot every time they move (tipically every 1/10th of second) can affect the general game performance.
And not trying to troll or start a flame war, but this is one of those occasions where navigation meshes would be useful.![Wink ;)](./images/smilies/icon_wink.gif)
/me ducks for cover![Razz :P](./images/smilies/icon_razz.gif)
And not trying to troll or start a flame war, but this is one of those occasions where navigation meshes would be useful.
![Wink ;)](./images/smilies/icon_wink.gif)
/me ducks for cover
![Razz :P](./images/smilies/icon_razz.gif)
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC
(LordHavoc)
![Smile :)](./images/smilies/icon_smile.gif)
-
- Posts: 169
- Joined: Wed Nov 28, 2007 6:15 am
Re: Coding Frikbots to be scared of heights
Well, 650 maps are already perfectly waypointed, so discussing navigation meshes is a waste in this thread. The Frikbots are the best bots for Quake, navigation-wise. They can navigate through any map or scenario, and collect 99% of all the powerups successfully. Navigation is not the issue. The issue is their combat AI, which tells them to go charging off cliffs when they see another player/bot. If this one issue were fixed, they would be dramatically improved. I'm sure there is no need to invent a whole new bot when we already have a superior bot that supports 650 maps. It just needs a few tweaks.frag.machine wrote:Be careful. traceline is among the most expensive builtins in QuakeC, CPU wise. Adding 2 tracelines per bot every time they move (tipically every 1/10th of second) can affect the general game performance.
And not trying to troll or start a flame war, but this is one of those occasions where navigation meshes would be useful.
/me ducks for cover
Re: Coding Frikbots to be scared of heights
This piqued my curiosity, and I'm a Definitive Waypoint fan, so I tried digging into the Frikbot functions. I don't have an answer but maybe have narrowed-down the issue.
frik_obstacles is the only check for ledges and is called from BotFrame. frik_dodge_obstruction is called from frik_walkmove and frik_movetogoal. frik_dodge_obstruction does just that (and recognizes plats) but does not detect ledges. During combat bot_fight_style calls frik_walkmove, so I guess this is why bots in combat walk around columns but ignore cliffs.
Comment from frik_dodge_obstruction:
// perform a walkmove check to see if the obs_dir is still obstructed
// walkmove is less forgiving than frik_obstacles, so I dunno
// how well this will work
Could this function be improved to check ledges? Perhaps it was left out for performance. But is it really noticeable?
frik_obstacles is the only check for ledges and is called from BotFrame. frik_dodge_obstruction is called from frik_walkmove and frik_movetogoal. frik_dodge_obstruction does just that (and recognizes plats) but does not detect ledges. During combat bot_fight_style calls frik_walkmove, so I guess this is why bots in combat walk around columns but ignore cliffs.
Comment from frik_dodge_obstruction:
// perform a walkmove check to see if the obs_dir is still obstructed
// walkmove is less forgiving than frik_obstacles, so I dunno
// how well this will work
Could this function be improved to check ledges? Perhaps it was left out for performance. But is it really noticeable?
-
- Posts: 169
- Joined: Wed Nov 28, 2007 6:15 am
Re: Coding Frikbots to be scared of heights
I'm sure FrikaC could shed some light on this.qbism wrote:This piqued my curiosity, and I'm a Definitive Waypoint fan, so I tried digging into the Frikbot functions. I don't have an answer but maybe have narrowed-down the issue.
frik_obstacles is the only check for ledges and is called from BotFrame. frik_dodge_obstruction is called from frik_walkmove and frik_movetogoal. frik_dodge_obstruction does just that (and recognizes plats) but does not detect ledges. During combat bot_fight_style calls frik_walkmove, so I guess this is why bots in combat walk around columns but ignore cliffs.
Comment from frik_dodge_obstruction:
// perform a walkmove check to see if the obs_dir is still obstructed
// walkmove is less forgiving than frik_obstacles, so I dunno
// how well this will work
Could this function be improved to check ledges? Perhaps it was left out for performance. But is it really noticeable?
-
- InsideQC Staff
- Posts: 1120
- Joined: Sat Oct 16, 2004 3:34 pm
Re: Coding Frikbots to be scared of heights
Upon some consideration of this, some ideas on solving this:
1. Two traceline check is too expensive and imprecise.
2. engineside walkmove stuffs IIRC can cause issues going over mesh / hole filled floors. (as in, they will refuse to go over them)
Lower expense options:
1. Avoidance Markers and triplines.
Avoidance marker: Basically a marker / lighthouse entity that the frikbot looks for and stays the heck away from. Perhaps definable avoidance radius? IIRC, frikbots are already programmed to avoid certain entities like grenades, so this is in theory easy to impliment... Entity load could be significant though.
Tripline: Basically an entity that has an angle set along a course (following a ledge) or perhaps a special waypoint chain. Frikbot would check it's surroundings for these, then perform a dual vlen distance check, if the bot is too close, then instruct the combat AI to veer away from vectors in this direction.
Dual vlen distance check:
1. If danger entity / entity chain is found, go distance of frikbot from entity along the defined angle direction, then perform a second vlen distance check from that point. If bot is too close, combat AI is instructed to move away from this point.
I don't have time at the moment to make the code for this, so I'm just submitting it as some ideas / proposals for you or somebody who wants to help with it. If I have time later, I'll try to see what I can come up with.![Wink :wink:](./images/smilies/icon_wink.gif)
1. Two traceline check is too expensive and imprecise.
2. engineside walkmove stuffs IIRC can cause issues going over mesh / hole filled floors. (as in, they will refuse to go over them)
Lower expense options:
1. Avoidance Markers and triplines.
Avoidance marker: Basically a marker / lighthouse entity that the frikbot looks for and stays the heck away from. Perhaps definable avoidance radius? IIRC, frikbots are already programmed to avoid certain entities like grenades, so this is in theory easy to impliment... Entity load could be significant though.
Tripline: Basically an entity that has an angle set along a course (following a ledge) or perhaps a special waypoint chain. Frikbot would check it's surroundings for these, then perform a dual vlen distance check, if the bot is too close, then instruct the combat AI to veer away from vectors in this direction.
Dual vlen distance check:
1. If danger entity / entity chain is found, go distance of frikbot from entity along the defined angle direction, then perform a second vlen distance check from that point. If bot is too close, combat AI is instructed to move away from this point.
I don't have time at the moment to make the code for this, so I'm just submitting it as some ideas / proposals for you or somebody who wants to help with it. If I have time later, I'll try to see what I can come up with.
![Wink :wink:](./images/smilies/icon_wink.gif)
-
- Posts: 169
- Joined: Wed Nov 28, 2007 6:15 am
Re: Coding Frikbots to be scared of heights
The Frikbots have a blind flag with waypoints that allows them to walk over floors with holes, but I'm not sure how that would work with this. I use the blind flag any time the Frikbots are walking over floors with holes, because it prevents them from performing unnecessary jumps. We don't really have to worry about that, because it has been taken care of with the waypoints.Dr. Shadowborg wrote:Upon some consideration of this, some ideas on solving this:
2. engineside walkmove stuffs IIRC can cause issues going over mesh / hole filled floors. (as in, they will refuse to go over them)
This is not a bad idea at first, but I've already waypointed 650 maps. This means I would have to go back through all of them and add these markers (and I definitely don't have the patience for that). I don't mind adding them to a few void maps, but it wouldn't resolve a lot of the other issues. The other major issue is when bots jump off a ledge to join a battle (in a non-void map) and try to get back up to where they were before the battle started (and end up running against a wall). This could be resolved by resetting the Frikbots path when they have fallen a certain distance (which is not a bad idea at all).Avoidance marker: Basically a marker / lighthouse entity that the frikbot looks for and stays the heck away from. Perhaps definable avoidance radius? IIRC, frikbots are already programmed to avoid certain entities like grenades, so this is in theory easy to impliment... Entity load could be significant though.
This is something that would have to be placed, right? Once again, it would take a very long time to add these to all the maps I already waypointed. Also, I'm worried that if bots are too scared of an edge, they won't follow any waypoints that direct them to jump off an edge.Tripline: Basically an entity that has an angle set along a course (following a ledge) or perhaps a special waypoint chain. Frikbot would check it's surroundings for these, then perform a dual vlen distance check, if the bot is too close, then instruct the combat AI to veer away from vectors in this direction.
I'm sure one of your ideas could work though, Shadowborg (if someone was willing to code it).
Re: Coding Frikbots to be scared of heights
Could try calling frik_walkmove instead of walkmove, then call frik_obstacles from frik_walkmove. frik_walkmove simulates client input rather than doing walk physics directly. It seems to reduce running off catwalks into lava on dm4. Occasionally, bots will start a jump to a catwalk below but then miss when strafing enemies mid-flight. That's probably a different logic issue... I guess the alternative is to ignore enemies while falling and become an easy air-shot victim!
In bot_move.qc frik_dodge_obstruction function:
Further down in frik_walkmove:
In bot_move.qc frik_dodge_obstruction function:
Code: Select all
//qbism remove: yaw = vectoyaw(self.obs_dir);
//qbism remove: if (walkmove(yaw, 32))
if (frik_walkmove(self.obs_dir)) //qbism add
self.b_aiflags = self.b_aiflags - AI_OBSTRUCTED;
Code: Select all
float(vector weird) frik_walkmove =
{
// okay so it's not walkmove
// sue me
weird = normalize(weird); //qbism add. does it really matter?
self.keys = self.keys & 960 + frik_KeysForDir(weird);
//qbism remove: frik_dodge_obstruction();
frik_obstacles(); //qbism add
frik_recognize_plat(TRUE);
-
- Posts: 169
- Joined: Wed Nov 28, 2007 6:15 am
Re: Coding Frikbots to be scared of heights
Hi Qbism, thank you for helping. ![Smile :)](./images/smilies/icon_smile.gif)
I modified the code you suggested, but the bots still seemed to fall to their deaths quite consistently in void maps. If you decide to modify the code further, I recommend you download this map: Coagula2.zip
If you add just one bot in Coagula2, it will rarely, if ever, fall in to the void. However, as soon as you add more than one bot, they jump to their deaths constantly while battling other bots. It's a good map to test any code changes you attempt.![Smile :)](./images/smilies/icon_smile.gif)
![Smile :)](./images/smilies/icon_smile.gif)
I modified the code you suggested, but the bots still seemed to fall to their deaths quite consistently in void maps. If you decide to modify the code further, I recommend you download this map: Coagula2.zip
If you add just one bot in Coagula2, it will rarely, if ever, fall in to the void. However, as soon as you add more than one bot, they jump to their deaths constantly while battling other bots. It's a good map to test any code changes you attempt.
![Smile :)](./images/smilies/icon_smile.gif)
Re: Coding Frikbots to be scared of heights
Sorry that it didn't help. I'll look at it again with that void map when I get a chance. In dm4 I guessed (without looking at the waypoints) that bots were attempting to jump to catwalks but maybe just walking off ledges and sometimes getting lucky!
quake2 has an invisible 'nomonster' brush that is an obstacle to monsters. A 'nobot' brush might be nice for frikbot.
quake2 has an invisible 'nomonster' brush that is an obstacle to monsters. A 'nobot' brush might be nice for frikbot.
-
- Posts: 169
- Joined: Wed Nov 28, 2007 6:15 am
Re: Coding Frikbots to be scared of heights
I'm not a coder, so I don't know for sure what you did - but by glancing at your new code, it appears as if you are telling the Frikbots to look for obstacles. I would think that doesn't work on void maps, because the void is not calculated as an obstacle (the bots don't see it as a danger). Only lava would be calculated as an obstacle, as far as I know. The bots don't die as often on DM4 as they do void maps like Coagula2, because they avoid lava. I could be wrong about how your code works, though.qbism wrote:Sorry that it didn't help. I'll look at it again with that void map when I get a chance. In dm4 I guessed (without looking at the waypoints) that bots were attempting to jump to catwalks but maybe just walking off ledges and sometimes getting lucky!
This would only work if bots were still allowed to pass through the brush when waypoints tell them to. The problem with some of these void maps is that the bots ignore what the waypoints tell them to do when they attack another bot, and go suicide in the void as a result. The bots need to just follow instructions of the waypoints regardless of whether or not they are in a fight.quake2 has an invisible 'nomonster' brush that is an obstacle to monsters. A 'nobot' brush might be nice for frikbot.
Re: Coding Frikbots to be scared of heights
Can't judge this by the function name... frik_obstacles also looks for gaps and decides if they're jumpable. Obviously, though, just replacing the function is not enough to keep bots from backpedaling or strafing right over the furthest edge of the map.
Re: Coding Frikbots to be scared of heights
Some good news! [edit: not really, see post on next page. please ignore]
...OK, I missed a spot in frik_obstacles replacement. Go into frik_movetogoal:
What you will see is much fewer silly falls. That moment of eureka will soon be replaced by the realization that sometimes bots will just stand near the edge taking long shots instead of breaking off and heading to the next item.
...OK, I missed a spot in frik_obstacles replacement. Go into frik_movetogoal:
Code: Select all
way = normalize(way);
self.keys = self.keys & 960 + frik_KeysForDir(way);
//qbism remove: frik_dodge_obstruction();
frik_obstacles(); //qbism add
frik_recognize_plat(TRUE);
Last edited by qbism on Fri Mar 28, 2014 9:59 pm, edited 2 times in total.