User panel stuff on forum
  39 posts on 2 pages  First page12Last page
Server Talk
2017-06-27, 10:12
Administrator
160 posts

Registered:
Sep 2015
vb- wrote:
^ So far it's only available to play online. There's a server address in the top-most post with the details

meag: While you're doing all this can I suggest making the mod more modular in that waypoints are external files. Having to recompile to change one waypoint is ridic. You can do it in a really cheap way by simply loading ways as entities if you're not keen on spending much time on it


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.
2017-06-27, 18:35
Member
6 posts

Registered:
Apr 2017
Thats great Meag

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

Thanks a lot
2017-06-30, 19:45
Member
294 posts

Registered:
Feb 2006
This is awesome
ProjectQ1Q3, Frogbot Waypoint and Map Conversion Tutorial @ http://mickkn.mooo.com
2017-07-05, 15:53
Administrator
160 posts

Registered:
Sep 2015
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.
2017-07-05, 19:17
Member
6 posts

Registered:
Apr 2017
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
2017-07-05, 19:53
Administrator
160 posts

Registered:
Sep 2015
bgnr wrote:
Can you link to some manual how to create, or modify bot behaviour or routes.


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.

Quote:
Last night they were havind difficulties jumping to RA on bravado


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.
2017-07-06, 20:25
Member
232 posts

Registered:
Feb 2006
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
vb.drok-radnik.com
2017-07-06, 21:48
Administrator
160 posts

Registered:
Sep 2015
vb- wrote:
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.
2017-09-09, 07:21
Member
15 posts

Registered:
Apr 2017
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.
  39 posts on 2 pages  First page12Last page