Turning HUDs into a .txt file instead of engine code ...

[leileilol]

Right now my favorite way to do huds is in sbar.c. The sad thing is, I find that even easier than using csqc

[Mexicouger]

Right now my favorite way to do huds is in sbar.c. The sad thing is, I find that even easier than using csqc

Same here. It is pretty easy

[goldenboy]

Whatever you do, please no XML... that's unreadable in a text editor.

[Spike]

You guys need to think what fits best also to the modder, not only to the engine developer.

In all seriousness, and I'm not trying to be funny here...

Screw the modder.

Make the hud customisable for the end user, document that, and you'll have a lot more interest in it.
Doing that properly, intuitively, is smegging hard.
Yeah, the modder should be able to provide a nice pretty default, add additional info to it, new weapons, new teamplay stuff, etc. But at the end of the day, its the end user that will end up staring at the thing for ages at a time.

CSQC is good for modders imposing a specific hud. Hard-coded to match the mod and art style, but not all mods are designed for engine $NAME. Stopping such mods from having a custom hud is somewhat rude.
If that makes any sense at all.
Users, modders, then engine devs who would adapt sbar.c anyway.

[leileilol]

Agreed, instead let's have huds in Chrome javascript markup just like modern 'fast' web browsers

[mh]

This can't be said loudly enough:

Make the hud customisable for the end user

And nor can this:

Whatever you do, please no XML

Those two pretty much sum up another reason why I would favour COM_Parse format. It's standard across absolutely everything else in Quake. It's simple to use - if the end user knows how to edit an autoexec.cfg file they know how to edit COM_Parse format. It's human-readable. It's actually incredibly flexible - map files use it, entities use it, save games use it.

Something based on Q3A shader format would be another good option if COM_Parse is really objectionable, but the plea is for a format that's some way standard, sane, easy to use, and easy to implement. We don't need yet another wacko custom format that needs it's own wacko custom parser that's only used for one thing and nothing else.

[leileilol]

Something based on Q3A shader format

Actually Q3TA (Team Arena, NOT regular q3ui) uses its scripted menu system to define HUD elements. I find it a bit hard to work with (doing new huds completely from scratch, at least). For example (OA's 'missionpack' hud)

This kind of hud standard carries over in RTCW and Enemy Territory (though the compass isn't part of the hud system, that one's hardcoded)

[frag.machine]

Something based on Q3A shader format would be another good option if COM_Parse is really objectionable

The only problem with COM_Parse is: it doesn't fit to the task. Period. As I said before, it was designed for key/value pairs, and once one start to define a way to customize HUDs using this format he/she will notice how clumsy the solution becomes (been there, done that). You will want more flexibility to be able to, let's say, put a picture in the screen using only one text line.

That said, I would like to make clear that I don't really expect that Baker start from where my code was left, because it actually was in the end a failed experiment, exactly because it turned into something far more complex for the end user (either a modder or a player) than what I wanted. However, since it basically is functional code, there maybe one thing or other useful there, so it wouldn't be a complete waste of effort. Heck, even if Baker decide to not use anything at all from that, it had the value of avoiding another similar failed experiment.

OTOH what mh and other pointed here is valid, too: adding another text parsing mechanism would be undesirable. And thinking a bit more about that I realized that we may already have something more fit to the task than COM_Parse. A good compromise between reuse of built-in parsing capability and the required flexibility can be obtained by simply having a "hud" console command. This command could then use COM_Args function as required. There are some collateral advantages on this approach:

a) HUD's could be defined in autoexec.cfg or any other .cfg file;
b) HUD's could be manipulated directly from the console (excellent option for modders experimenting with new ideas or players unsatisfied with the current layout);
c) HUD's could be defined/manipulated via QuakeC/stuffcmds.

So in the end, my suggestion is: add a HUD_f() function, and put all the control on it.

[mh]

A good compromise between reuse of built-in parsing capability and the required flexibility can be obtained by simply having a "hud" console command. This command could then use COM_Args function as required. There are some collateral advantages on this approach:

a) HUD's could be defined in autoexec.cfg or any other .cfg file;
b) HUD's could be manipulated directly from the console (excellent option for modders experimenting with new ideas or players unsatisfied with the current layout);
c) HUD's could be defined/manipulated via QuakeC/stuffcmds.

So in the end, my suggestion is: add a HUD_f() function, and put all the control on it.

I'm liking the sound of that approach a lot.

[frag.machine]

Evolving the idea a bit more:
x, y: screen coordinates;
w,h: width and height values;
$var: that's maybe the trickiest part. This can be "$health", "$currentammo", "$armorvalue", "$armotype", etc. Basically, a symbol representing a gameplay/engine parameter;
alpha,red,green,blue: alpha and color shfit values.

To clean the entire HUD:

Code: Select all

hud clr


To draw a numeric value with big font:

Code: Select all

hud big <x> <y> <$var> [alpha] [<red> <green> <blue>]


To draw a literal string or variable:

Code: Select all

hud txt <x> <y> <"message"|$var> [alpha] [<red> <green> <blue>]


To draw a picture:

Code: Select all

hud pic <x> <y> <"path"> [alpha] [<red> <green> <blue>]


To draw a .bsp or .mdl model:

Code: Select all

hud bsp <x> <y> <"path"> [alpha] [<red> <green> <blue>]


Code: Select all

hud mdl <x> <y> <"path"> [alpha] [<red> <green> <blue>]


To draw a colored rectangle (like the players' shirt and pants color in the deathmatch score, or maybe a health bar):

Code: Select all

hud bar <x> <y> <w> <h> <red> <green> <blue> [alpha]


Of course I am not dealing with things like "what if I want to draw the health value in red if below 25 ?". But it's just an idea.

[Baker]

I like the idea of manipulating the HUD from the console and the rest of the posts here are certainly on the right track.

I like Frag Machine's most recent post.

[Spirit]

Be aware that ezQuake let's you design the HUD as you like and even has a mouse-driven HUD editor.