Describing the Quake Command System

[Baker]

[Baker]

[taniwha]

QF uses hash tables for the commands and cvars. When a sorted list is needed (tab-completion, cmdlist, cvarlist), the hash-table keys (cmd/cvar names) are extracted into an array and passed through qsort. The hash table code is used all over the place, so it's quite well tested .

[Baker]

[Baker]

[taniwha]

QF's completion isn't very smart yet. It certainly doesn't complete parameters, and I'm pretty sure it doesn't work after semicolons. It does, however, provide a list of all possible cvars and commands (including aliases?) that match the current "head". Certainly less annoying that id's very basic version.

Re parsing: may I suggest QF's plist code? It's actually quite self-contained (only dependencies are dstrings and hash tables, and all three modules are documented). There are some dependencies on sys (Sys_Printf etc) and mathlib/compat (min/max and strequal), but they're trivial to replace.

(include/QF/qfplist.h and libs/util/qfplist.c) ()
(include/QF/hash.h and libs/util/hash.c)
(include/QF/dstring.h and libs/util/dstring.c)

[Baker]

[Baker]

Woohoo! My own command interpreter + command buffer is working.

It doesn't do a hell of a lot (no parsing except grabbing a single line at a time and then removing it). But the code is short, easy to follow and by building from the ground up I have to understand every inch of what I am doing.

Still, 3 years ago ... even a basic command interpreter was a sci-fi concept to me. The nice little bonus from doing this is an increased understanding of client<-->server communications. Not much difference between the command buffer and filling up the buffer to send stuff to clients.

[mh]

DirectQ puts them all (cmds, cvars, aliases) into individual lists, then builds a master list containing pointers to the originals. This is sorted alphabetically (also using qsort) and then is searched using a binary search at runtime. There's a more elegant way of doing the original lists using C++ inheritance, and an STL container would be a nicer way of managing the whole thing, but right now it's not that big a problem.

The runtime binary search is actually important - otherwise executing the command buffer involves a lot of linear array walking and string comparison. With id1 this isn't so bad, but when you start adding a heap more cmds and cvars and when you run a mod that's stuffcmd-happy it can become a slightly noticeable problem.

Autocompletion is a bit of a nuisance; having it added to map, save, load, playdemo, timedemo and game is nice for the player, but it involves a lot of opening files, parsing them to get info out, validation, autocomplete list building, and other crap when a game is loaded - one of the reasons why DirectQ's game changing code is painfully slow compared to other engines. (Quakespasm has it on maps but it doesn't validate the map, so ammo box models get included in the list.)

[taniwha]

Yeah, the hash tables made a noticeable difference 12 years ago, and that was for overkill. They make an even bigger difference for alias-heavy mods (eg, TF).

The hassles you mention for tab-completion is one reason I never took QF beyond just command/cvar completion. Although a bit of extra work for the programmer (and potentially annoying for the user) is to not pre-scan the lookups (especially map and skybox), but to cache them individually on first usage. And then, when the gamedir changes, do a partial flush of the caches (this would be hard to get right and possibly not worth the hassle: full flush would be more robust). However, most commands and cvars would have fixed parameters (if any!) and thus wouldn't be an issue. For certain commands (and most cvars), just a simple value is expected: completion could just print a help message.

Handling tab completion for commands and cvars seems pretty obvious to me: have a "complete" callback in the command/cvar struct that either returns a completion string or dumps a message. Or both, even.

[mh]

[taniwha]

That bad, huh? What about caching the file lists in the gamedirs? Each gamedir is fully indexed and any overlapping entries (caused by gamedir inheritance) are appropriately pruned. Rescan checks are done by checking the timestamp of the cache file against the timestamps of the directories in the gamedir tree.

[Spike]

thread it?

[taniwha]

Most of the hit is probably IO. If so, threading will only make it worse. Unless you mean putting it in a background thread: that certainly should ease the pain.

[Spike]

aye, put the prescan in a separate thread, so you can still actually load a map/join a server/etc while its busy waiting for the disk.
I hate loading screens. You'd best have a VERY good excuse for them if they last longer than 3 seconds.