Frikbot Item desirability

[Dr. Shadowborg]

Got it, integrated it into what I'm working with right now.

Status update:

Currently reading frik_obstacles right now. Brilliant! Madness! Insanity! Madness Wrapped with Insanity on a bun of Brilliance! Topped with more madness!

I haven't found what's going wrong just yet, but I can almost certainly say that AI_BLIND for anything other than tricky jumps is a big no-no though. Still working on it. May also lead to (but unrelated to) fixing the "fall off ledge, get stuck trying to get back up directly, when it's supposed to find a route back up instead" bug.

As a side note, I've found what I believe to be a bug in regards to AI_BLIND, but it may only be pertinent to teamplay / coop.

Now, I just hope they don't haul me off to the asylum, or invisible demons come to tear me apart or something.

[Lightning Hunter]

I certainly admire your patience for looking through that code. I have never been much of a coder, so I can barely make sense of any of the Frikbot code, much less rewrite it. It took me several days just to change the item desirability code.

Edit: Btw, I'm guessing the AI_Blind code you refer to has nothing to do with the blind flag? The blind flag is used by about 25-30% of the waypoints in my pack, so it's an important flag to keep. It prevents the bots from jumping over cracks on the floor or down steps when they should just be walking. I use the flag for all sorts of situations.

[Dr. Shadowborg]

Okay...this is almost facepalm simple, but...

In frik_obstacles try replacing this: (it's the very first traceline called)

Code: Select all

traceline(start, stop - '0 0 256', TRUE, self);

with this:

Code: Select all

traceline(start, stop - '0 0 1024', TRUE, self);

This *should* help with coagula2 and also seems to help with lavadeaths on dm4. If they go off the edge, they probably needed help doing it (He was "pushed"! >=D) / flubbed a jump or made a rather humanlike mistake. (at least I noticed fewer of them)



I'm going to be looking into the grenade / rocket button shooting thing next. (also, while I'm there, firing grenades a distant targets when they should know that they'll never make it...)

[Lightning Hunter]

Seriously, even I know what that code does by eyeballing it, and I'm a noob coder! Why didn't anyone notice it?

Anyway, I just now monitored the bots in Coagula2 for a while, and they did indeed fall significantly less. In fact, all the bots had positive scores, rather than -20 after 5 minutes. The bots could actually beat a player on skill 3 in Coagula2 now. I noticed the bots shoot down at other bots/players now, rather than charging off a cliff to attack.

The primary reason they die now is if they get pushed off a ledge, and try to get back up to the waypoint they were previously at. I'm guessing the issue with the bots trying to walk back up a cliff is mostly solved by them not jumping off the cliff in the first place, however.

I will continue to monitor the bots and see how this affects their behavior. My only complaint is that the bots kind of stand in place when they shoot at other players from the top of a cliff. It would be nice if they jumped or moved around a bit, but this might complicate things and cause them to suicide. I prefer the bots suicide less. The dodge code might be best left untouched for this reason.

[Dr. Shadowborg]

Okay...I have no idea if this will work in regards to using grenades against buttons as I belatedly realized that the only map I remember actually having a button to shoot was dm2. (thus I have no map to test this properly on, any suggestions?)

Anyway:

In bot_fight.qc, within bot_weapon_switch, replace this:

Code: Select all

else if ((self.ammo_rockets >= 1) && (it & 16))

with this:

Code: Select all

else if ((self.ammo_rockets >= 1) && (it & 16) && self.enemy.solid != SOLID_BSP) // DRS: Grenades don't explode on buttons...

Then, in bot_fight_style, add this:

Code: Select all

// DRS: Buttons should be shot with shotguns, nails or rockets (they shouldn't shoot rockets if the range is too close by default),
// not grenades because grenades don't explode on buttons
if(self.enemy.solid == SOLID_BSP && self.weapon == IT_GRENADE_LAUNCHER)
   bot_weapon_switch(foedist);

Blind flags disable frik_obstacles and most likely combat code related to dodging. As for them standing around in spots, it's probably their combat AI attempting to close in on you (for sweet spot range), but being overridden because frik_obstacles is telling them that doing that = messy demise.

[Lightning Hunter]

I couldn't remember which maps had this bug, so I modified Ztnbase to have 4 grenade launchers around a button opening a door to red armor. I removed all other important items, so the bots always go straight for the armor. I can confirm with the old code that the bots almost always shoot at the button with the grenade launcher. The new code does indeed prevent this, but it also seems to prevent the bots from ever switching to the grenade launcher again. They might use grenades for a second after they initially pick it up to attack another bot, but don't ever use it once they switch to a new weapon.

If you need to test this for yourself, I uploaded the test version of Ztnbase.bsp here, along with the waypoints:
http://fbe.am/u1n

[Dr. Shadowborg]

Thanks, that helped a lot, try this:

In bot_fight.qc, within bot_weapon_switch, replace my previous code:

Code: Select all

else if ((self.ammo_rockets >= 1) && (it & 16) && self.enemy.solid != SOLID_BSP) // DRS: Grenades don't explode on buttons...

with:

Code: Select all

else if ((self.ammo_rockets >= 1) && (it & 16) && (self.enemy.solid != SOLID_BSP || self.enemy == world)) // DRS: Grenades don't explode on buttons...

Totally forgot that the world is SOLID_BSP, so I had to add an exclusion for if self.enemy was the world.

This will work fine for vanilla, and any mods that switch weapons instantly, mods that have weapon switching frames will need to be more anal-retentive about specifying shootable entities.

[Lightning Hunter]

That's much better. Thanks again for doing these updates. Did you manage to figure out how to set a distance limit on the grenade launcher, so the bots don't try to shoot another player/bot that is out of range?

Also, there are a few other problems that I forgot to mention in my earlier list:

-This may already be fixed, but the bots sometimes shoot secret doors with the Rocket Launcher, hurting themselves in the process.

-Precise mode sometimes stays on for bots, even after they have finished passing through the waypoints with the precise flag turned on. They also sometimes ignore the flag altogether and run through a waypoint with precise at full speed... No idea why this happens. I'm not sure if you can fix this or not, but it is hilarious watching the bot sometimes walk around in slow motion because they failed to turn off precision mode.

-Teleporters are sometimes buggy with bots, but I'm not sure if this would be impossible to fix or not (I would put this last on your list of priorities). Sometimes, bots will enter a teleporter, and somehow be on the wrong path and go back toward a waypoint they can't reach. It's hard to explain exactly what is happening, but they just don't seem to always register that they passed through a teleporter. This can be helped somewhat with the precision flag, but not always. There is a map I just waypointed recently that had a troublesome teleporter. The bots would pass through the teleporter, then run toward a waypoint on the other side of the map - colliding in to random walls along the way. I can upload that map if you want to look at this issue.

[gnounc]

awesome work gentlemen. i'm watching this thread with interest.

The teleporter code sounds like an interesting problem to solve. how do you waypoint a bot to use teleporters currently?

Sounds like (if there isnt already) there should be a function call to recheck waypoints immediately after a bot is spit out of the teleporter.

Do bots currently take into account how far one path is vs another path?
And do they take into account the distance saved by using a teleporter?
if not that sounds like fun to fix.

[Dr. Shadowborg]

That's much better. Thanks again for doing these updates. Did you manage to figure out how to set a distance limit on the grenade launcher, so the bots don't try to shoot another player/bot that is out of range?

You...You want a what?

* Cold sweat breaks out on Dr. Shadowborgs forehead, as his eyes fixate on something that appears to be perched on Lightning Hunter's shoulder

*there is nothing actually there*

* Dr. Shadowborg runs away screaming something about "complex math problems, nononononononononono!"

Actually, in theory, it's as simple as setting maximum engagement range for the grenade launcher to something like 620 qu. In practice though, the grenade launcher is a weapon with highly variable range. Its gonna be a little harder to fix, but I'm working on it. I'll let you know when I've got something worked out.

Also, there are a few other problems that I forgot to mention in my earlier list:

-This may already be fixed, but the bots sometimes shoot secret doors with the Rocket Launcher, hurting themselves in the process.

Need map for testing.

-Precise mode sometimes stays on for bots, even after they have finished passing through the waypoints with the precise flag turned on. They also sometimes ignore the flag altogether and run through a waypoint with precise at full speed... No idea why this happens. I'm not sure if you can fix this or not, but it is hilarious watching the bot sometimes walk around in slow motion because they failed to turn off precision mode.

Dunno about this one, I'll put it on todo.

-Teleporters are sometimes buggy with bots, but I'm not sure if this would be impossible to fix or not (I would put this last on your list of priorities). Sometimes, bots will enter a teleporter, and somehow be on the wrong path and go back toward a waypoint they can't reach. It's hard to explain exactly what is happening, but they just don't seem to always register that they passed through a teleporter. This can be helped somewhat with the precision flag, but not always. There is a map I just waypointed recently that had a troublesome teleporter. The bots would pass through the teleporter, then run toward a waypoint on the other side of the map - colliding in to random walls along the way. I can upload that map if you want to look at this issue.

Need map to test.

awesome work gentlemen. i'm watching this thread with interest.

The teleporter code sounds like an interesting problem to solve. how do you waypoint a bot to use teleporters currently?

Sounds like (if there isnt already) there should be a function call to recheck waypoints immediately after a bot is spit out of the teleporter.

Do bots currently take into account how far one path is vs another path?
And do they take into account the distance saved by using a teleporter?
if not that sounds like fun to fix.

The bots use waypoints with a telelink flag (teleport link) set.

I think they already are designed to pick the shortest route to whatever item they've decided to go after.

[Lightning Hunter]

Yes, I just realized there is probably no simple solution for the Grenade launcher range. Come to think of it, there is some code in the Small Mod Compilation for the Ogre that enhances the grenade launcher aim. Maybe you can borrow some code from that (although it won't have a range restriction). The source is publicly available. I uploaded Ogre.qc and ai.qc from the mod for you (I'm not sure which QC file the code you need is in, but I assume it is in one of these two files).
Download here: http://fbe.am/u29

I searched for quite a while, but unfortunately could not find a specific map that has an area with a 100% chance of the precision bug or rocket launcher bug. I only observe those bugs occasionally when I'm waypointing. I'll have to do some further searching and let you know if I come across a map with those problems. In the meantime, you can ignore those two issues.

On the other hand, I was lucky enough to find a map that has the teleport bug almost 100% of the time. I'm sorry the map has to be so large (it has 6 waypoint files), but I helped you out by deleting ALL important items except a Quad damage that I added on the other side of the teleporter. you will likely see the bug within 15-30 seconds if you add a bot and follow it around using the chasecam. The bot might collect the Quad damage from the back way without teleporting, in which case you can restart the map or wait for the Quad to respawn. The teleporter that causes problems is right next to a pit of water. When bots go through this teleporter, they get confused and run to a different waypoint than the one they are supposed to. After teleporting, you will notice the bots run off a ledge, in to some water, and stare at a wall to reach a waypoint they can't get to. They do eventually reset the path, but only after they mess everything up first. I'm guessing something happens that makes them not register that they went through the teleporter, and makes them try to get to the wrong waypoint.
Download the map here:
http://fbe.am/u2b

If you can manage to fix how the bots use the teleporter on Dranzdm4, then you will probably fix them on every map. Believe me, I have seen this bug quite frequently while waypointing. I always wished the Frikbots could use teleporters better. The worst is when the Frikbots encounter strings of teleporters. They get confused as to which waypoint they are on, and run in to random walls. Like I said, I think they sometimes fail to register that they passed through the teleporter.

The bots use waypoints with a telelink flag (teleport link) set.

I think they already are designed to pick the shortest route to whatever item they've decided to go after.

Yes, I can confirm that bots use teleporters to calculate the shortest path to an item. They will sometimes use strings of teleporters like nobodies business.

[Dr. Shadowborg]

On the other hand, I was lucky enough to find a map that has the teleport bug almost 100% of the time. I'm sorry the map has to be so large (it has 6 waypoint files), but I helped you out by deleting ALL important items except a Quad damage that I added on the other side of the teleporter. you will likely see the bug within 15-30 seconds if you add a bot and follow it around using the chasecam. The bot might collect the Quad damage from the back way without teleporting, in which case you can restart the map or wait for the Quad to respawn. The teleporter that causes problems is right next to a pit of water. When bots go through this teleporter, they get confused and run to a different waypoint than the one they are supposed to. After teleporting, you will notice the bots run off a ledge, in to some water, and stare at a wall to reach a waypoint they can't get to. They do eventually reset the path, but only after they mess everything up first. I'm guessing something happens that makes them not register that they went through the teleporter, and makes them try to get to the wrong waypoint.
Download the map here:
http://fbe.am/u2b

If you can manage to fix how the bots use the teleporter on Dranzdm4, then you will probably fix them on every map. Believe me, I have seen this bug quite frequently while waypointing. I always wished the Frikbots could use teleporters better. The worst is when the Frikbots encounter strings of teleporters. They get confused as to which waypoint they are on, and run in to random walls. Like I said, I think they sometimes fail to register that they passed through the teleporter.

Problem with that download: Missing dranzdm4.wa1

[Lightning Hunter]

Argh, how did I miss that? Now it should be there:
http://fbe.am/u2D

By the way, are there any differences that you've seen yet between Revisions B & C vs. fbx+ for the Frikbots? Or have you had a chance to look at that yet?

[r00k]

if i were to guess, i'd say nades toss 600 units?

Code: Select all

missile.velocity = missile.velocity * 600;

sure it can bounce but i doubt anything over 1000 units would be hit....

[Dr. Shadowborg]

By the way, are there any differences that you've seen yet between Revisions B & C vs. fbx+ for the Frikbots? Or have you had a chance to look at that yet?

Nothing indepth as yet, but cursory examination seems to indicate that B does not have frik_file support, C does, and fbx+ also has frik_file support. Igor9 appeared to have added randomized player spawns which go beyond the scope of the actual frikbot code itself.

Just guessing, I'd say that of the older releases, FBX+ was the definitive version. It is now superceded by my version (the indevelopment / bugfixing version) immediatly followed by the version you have with the bugfixes / enhancements from my version applied.

if i were to guess, i'd say nades toss 600 units?

Code: Select all

missile.velocity = missile.velocity * 600;

sure it can bounce but i doubt anything over 1000 units would be hit....
if i were to guess, i'd say nades toss 600 units?

sure it can bounce but i doubt anything over 1000 units would be hit....

Velocity != Distance. Ironically, rockets in quake are not rocket science, grenades unfortunatly are.

On level ground, a grenade fired horizontally will only travel around 312-320 qu before hitting ground and bouncing. If you aim upwards, you can extend that to around +-512qu. Add to that height advantages / disadvantages... (the higher your target is from you, the less range you have, the lower the target is from you, the more range you have)

Where the shrieking madness enters into the picture is Ziggurat Vertigo. Or more accurately gravity

In actual use, when does a player EVER actually use just ONE grenade though? It's more of a close range version of the RL, with the addition of being useful for suppression fire, indirect fire and constricting target movement with lots of little explody bombs.