This is done, they load definitions from .bot files, there's a built-in map editor for editing waypoints too. Should perhaps have gone the entity file route but hey-ho.

Spent yesterday tearing hair out, but latest ezquake nightly should be able to run KTX, so local version coming soon.

Thats great Meag

You are doing a enourmous work in so many things in qw

Thanks a lot

This is awesome

Ok, finally reasonably happy with where things are so will stop adding things and try to get this version rounded off.

A list of the latest changes to KTX since 1.37 is here - the focus has clearly been on race mode and bot support. This will hopefully become KTX 1.38 in due course.

The bots currently run as a native library, instructions for downloading or building are here. You will need the latest ezquake client to run this, and there may be more changes in the future as we add .qvm support, though performance there won't be as good.

There are lots of places where the logic and movement isn't great - these will be bugs I introduced when converting the bots from monsters-in-disguise to proper clients. The most recent change that would cause bugs in KTX proper is the team-based hoonymode - multiple rounds with teams alternating spawns, then playing as normal until the round timelimit (so like hoonymode in regarding alternating spawns, not at all like hoonymode in that you respawn as normal). Hopefully this will help people learning the game - the game resets often so they're not getting thumped for 8 minutes straight, and they can practice keeping track of enemies/items for short periods of time then work their way up to longer round lengths. (said he, who is criminally bad at 2v2 anyway)

As ever, let me know of any issues.

Awsome Meag

Can you link to some manual how to create, or modify bot behaviour or routes.
Last night they were havind difficulties jumping to RA on bravado

I'd have to write the manual first unfortunately. You can run 'set k_fb_options 2' and reload the map, then 'botcmd' to see available commands - there are lots.
There's a number of cvars for bot behaviour and each skill level can be customised, I'll do a list at some point. Most of them are to do with aim though.



To properly change this (so they back off rather than miss the jump), then I'd have to run the simulation pre-jump at 77 fps rather than the current 10, which I don't really want to do as it's computationally expensive... could maybe make it an option for local games, or on duels only. Right now it is a hack that it expects to accelerate at x units for each of those 10 frames. Bravado is the kind of jump that they just couldn't do in standard version. To make it less computationally expensive we could generate & import .aas files but that will have to wait for another time.

I did just try them on bravado locally and they seemed okay though - they don't make the jump every time at skill 10, as skill increases so should air control.

IIRC using a null model 32x32x56 ent with movetype fly to simulate movement before moving the 'player' ent was only necessary when tracebox wasn't a builtin available to the QC. You might actually be able to run real player physics on bots now meag

Thanks, will look into this. To be clear, they are using real player physics when actually moving, just not in the "can I make this jump?" stage when they think they're about to fall off a platform. I'd like to have maybe four or five 'shapes' of jump that they can then try, so could maybe extend tracebox to execute multiple player moves, with lower skill bots defaulting to straighter jumps.

Found some more bugs today with powerup timing and team hoonymode, so there will be another update this weekend.

This is great! Thanks, Meag!

A quirky issue that I've just spotted is that if I use cl_delay_packet 55 then my screen/player will shake like crazy when the bot is nearby. A lower or higher packet delay seems fine though. I guess the packet timing is related to the lerping/interopolation of the player.

Okay, I've been playing with these offline bots and so far the obvious flaws are their increased acceleration and their tendency to jump into the lava in the DM4 mega room.

When spawning they seem to accelerate 25% faster than a human player. I could dismiss this if they were doing a bunny hop off the spawn, but they're able to instantly reach an high speed by simply running in a straight line. This combined with their quick respawn speed makes them very inhuman. Initially I wasn't too bothered about their acceleration as I thought I could probably fix it by playing against a lower skill level, but I've since noticed that even skill level 1 bots can accelerate at a crazy rate.

Is there a command to set their acceleration?

Try adding "k_fbskill_movement 0" in bots/configs/skill_all.cfg, but you'll be stuck with bots that can't jump to RA on bravado.

The lack of air-control to stop them falling in lava on dm4 is known problem, I need to make them push sideways and rotate (think of playing end) to keep speed, currently they just push in the direction of the marker they want to land on, and it doesn't work.

For the record: they don't accelerate faster than a human player, but they do accelerate in a very inhuman way, if that makes sense. Humans could accelerate just as quickly but don't. If I make the width of the 'sweep' much wider then they look a little more human but because we're still using waypoints to get round the map, they start bumping into corners and falling off ledges. Try DMM4 on POVDMM4 skill 10 vs skill 11 to see them have better 'dodging' but less accurate movement. Eventually I'd like them to use AAS and use the waypoints just for movement hints but I'm not in position to be working on that right now.

That command helped to reduce their speed a little but even skill level 1 are still way too fast. They're being reported as having a 290 speed at the end of a game. That's Div 1 level!

I'd like to start a FFA server with Frogbots. Which KTX and MVDSV branches should I use?

You can use the latest branches from deurk, but build ktx with 'make build-dlbots' instead of 'make build-dl'. Also you can have bots auto-add & remove from the server as players drop, details here. We might need to add extra options to allow skill level etc to be locked.

When starting ezQuake I do the following:
/gamedir ktxbots
/sv_progtype 1
/sv_progsname qwprogs

but when I then try to enter 'map DM4' ezquake always fails and attempts to load povdmm4 instead, but it also struggles with that as it repeatedly displays a "connect: local" message in the console. It's only when I enter 'map dm4' a 2nd time that it actually works.

Is this a known bug or do I have something in my config that's causing a conflict?.

Mine does the same, I've a alias to do all the stuff and just change map ingame

Try changing config files to clear k_defmap?

Thanks, Meag. That fixed it!.

The k_defmap is in the file port1.cfg.

Hi Meag!,

How difficult would it be to build this on Windows using GCC? I've very little experience with compilers. Would I need to create a make file?.

Also, do you know why the original qc frogbots never allowed a spectator to observe the bots from their POV?.

I'm currently pondering creating a new bot using the frogbot as a framework. I just need to decide on which one to use, either yours or the original qc version. QC seems much more approachable and I could start hacking at it straight away. Your version looks incredibly complicated and I feel like I'd need to spend a week just to understand how to compile it. Although yours does come with a spectator mode and the latest version of KTX. So that's difficult to resist.

Standard way to build on Windows was to use Visual Studio, the project files are on github repo. Deurk was doing a lot of work on build environments earlier in the year but I'm not sure where it got to. There are free versions available - might be worth a go, rather than using alternative tools on Windows.



The .qc frogbots sent custom network packets to the client so that the client puts them in the scoreboard etc, but they aren't real clients, so if you ask mvdsv to track a particular player, mvdsv doesn't know who you're talking about.



Probably agree that .qc is more approachable, but the .c version isn't more complicated - the bot code was ported across using a .qc > .c converter, then tidied up. Lots of people just don't like KTX code though, so that's entirely possible. Benefit of .qc is that qwprogs.dat is platform-independent, but performance isn't great. You can compile a .qvm file for KTX which has the same benefit but .qvm for 64-bit mvdsv is broken, so it's not compatible anyway.

Might also be worth talking to molgrum about Chilling Spree - don't think they are Frogbot based. The big complaint of Frogbots in the past was that it was very intrusive to the rest of the mod, so it's probably not the easiest one to find your way around, if you use .qc or not.

Thanks for the tips! Time for more pondering now...

Just a tip:

If you delete all the lava escape waypoints/markers in the mega room on DM4 then the bot doesn't fall into the lava as much. Obvious downside is that it can no longer escape when it gets knocked into the lava by a grenade. But for somebody like me that likes trying to get 100 percent efficiency it was bloody annoying to have the bot fall into the lava and then spawn at RA and kill me just as dropped down into the RA area.

I also noticed that there's less CPU performance spikes since deleting the waypoints. I guess that's because there's less waypoints for the AI to search through now!

Interesting. Maybe when the bot is approaching the edge of the bridge, it is being considered touching the marker in the lava, and then deciding movement from there instead of the bridge. I think there's a z-offset field that the markers can have set, which has maybe been cleared during the transition... I'll check it out.

AAS is a priority!

I suspect it's because of the speed boost you've given your bot. I'm still confused as to where their speed is coming from.

To prevent the bots from being easily spammed I've also removed the RA teleporter from the path in the RA area on DM4. This makes them less willing to go through the teleporter and more likely to rocket jump up to the upper exit. They got Lordlame tactics!!

But still, despite removing the teleporter from the path, the bot will still go through the teleporter sometimes. The reason could be the same reason as to why your bot would fall into the lava in the mega room - because of their speed boost they're overrunning their waypoint target. In this case it's not so bad though because it's nice that they come out of the teleporter sometimes because it makes them less predictable.

I'll see about uploading the bot file later and I'll post a link to it.

DM4 bot file is here

Result of changes:

Bot will no longer dive into the lava in the mega room. I think the issue was that the way point in the center of the bridge was connected directly to the RL way point and the bot was struggling to jump over the corner gap.

Bot will be less likely to walk out of the RA teleporter and instead it'll rocket jump up to the upper exit.

Bot will not drop down into RA area and so won't be get spammed while waiting for RA to spawn.

Bot will no longer go into mega. This change has had the biggest impact on improving the bot's difficulty. Previously it would constantly be running into the mega room and giving up its advantage and then getting spammed when trying to leave.

A tip for anybody playing these bots on DM4:

If like me you like playing against skill 20 bots on DM4 then because of how good their LG is you'll inevitably find yourself camping the YA entrance ready for a quick escape. This means that if you kill the bot while standing at the YA entrance then you're always going to be telefragged because of the evil KT2 spawn mode. So to prevent smashing your fist through your monitor, use KT Safety spawns instead. That's command k_spw 1.

Last week I've compiled the latest mvdsv and ktx, and played a few matches against the new frogbots. I didn't find any bugs or experienced any server crashes.

My only issue with the bots, is its speed! Even with skill set to zero, the bots are way too fast! If you could add some speed limitation, based on the skill level of the bot, this would probably fix the problem.

Thanks and keep up the good work!

btw.: will you release a howto make the .bot files?

I also thought they were too fast and Meag suggested I add the command 'k_fbskill_movement 0' to a 'skill_all.cfg' file in the ktxbots folder. This didn't really help and so I suggest try also adding this command: 'k_fbskill_wiggleframes 1'

Creating bot files is quite kludgy and so I can't remember the exact details, but use the command k_fboptions 2 and then reload a map to see all the waypoints. You can then use 'botcmd' to return a list of waypoint related commands. The commands mostly modify the nearest viewed waypoint.

I could make them not wiggle-run (as lemon suggests) but then modern maps like bravado would be terrible, as they would never make the jump to red.



I will, I had plans to do a short video series on adding bot support to a particular map - unfortunately some maps are still unsuitable due to lifts, awkward geometry etc. I might give it a go on foogs's latest map when it's stable.

I played a few more (a lot) matches with bots and here are my thoughts on the matter (for now):


The bots are too fast, and this is especially disturbing when playing against low level bots. Couldn't you restrict the bot speed until it wanted to perform a trick jump?
The bots are too difficult at level zero! Their aim is too good and they are way too aggressive.
Why the bots are removed after each match? This is not the normal behavior of frogbots! I think that is preferable to remove the bot manually, or when you load a map without bot support.
Playing FFA against a bunch zero skilled bots (6 or more), is really difficult.
Could you add the function to auto populate a FFA (maybe the other modes too) server with bots, and remove them as real players join the server? This is something really useful and lacking on frogbot!



Keep up the good work!