What do you guys think ?

[frag.machine]

I am working on that HUD scripting support, and it's quite functional ATM. However, I must say I am not happy with the results. Why, you may ask ?

Well, when I started it, I was aiming for something simple to implement and use even in vanilla GLQuake. But if you think about it for a while, you'll see that the actual problem is more complex than looks at first.

Example: the health inidicator from the original sbar. If your health drops below 25 points, it uses the red digits, otherwise, the normal ones. How to implement this with a simple to use hud script language ? I have something that works more or less like this:

Code: Select all

hud if $health < 25 goto use_red_digits
hud font 2
hud print 20 20 $health
hud break
hud label use_red_digits
hud font 3
hud print 20 20 $health
hud break


Where $health is the client's health, font 2 and font 3 are the regular 12x12 number and its red version, respectively.

This is a simple problem, however what if we wanted to draw, let's say, a graphic colored bar ? Things will get more complicated, and soon I found myself implementing a full featured client side script language, with conditionals, loops and vars. And even with all this added complexity, I always can think in something that would be cool to implement but would require more programming capability. I am not happy with this approach. I want something SIMPLE.

The alternative to that is to delegate all flux control to the server, using QuakeC to spam stuffcmd() when required. That would turn the problem above in something like:

Code: Select all

void () updateHUDHealth =
{
    if (self.health < 25)
    {
      stuffcmd ("hud font 3\n");
    }
    else
    {
      stuffcmd ("hud font 2\n");
    }

    stuffcmd ("hud print 20 20 ");
    stuffcmd (ftos (self.health));
    stuffcmd ("\n");
};


The problem with that is obviously the judicious use of stuffcmd() to interact with the HUD. I already can see some people shuddering with the idea.

So, what do you guys think about this ? Should I keep working in this client side scripting language, or should only implement a bare bones console command and delegate all control to server side QuakeC ?

[Baker]

Frag.machine, here is my thought ... I think your HUD scripting should live in a hudinfo.txt file or some such thing and be disattached from QuakeC kind of like effectsinfo.txt. I mean map or a progs.dat lives in a gamedir folder.

And I think your HUD scripting could quickly create a boom in people wanting to make their own HUDs or do experimentation. It need not be as complex as sbar.c. Anything is more than what we got now and CSQC is a bit steep of a challenge at the moment IMHO for beginners.

I could easily imagine running some contests with your new HUD scripting or the PSP guys playing around with it.

Anyway, my 2 cents ... right, wrong or even way off base.

[Mexicouger]

I'd rather do it the hard way and Manually code the HUD in sbar.c. Not very hard to do.

[dreadlorde]

goto in hud scripting language? :p

Just hard code it.

[mankrip]

If you want to make it simple to use, strip any unecessary complexity out of it. This includes the red digits, the animations in the HUD icons, and so on.

And don't make a scripting language, make a definition language that reads values for stuff like "display this icon at that position when this variable has that value". Example:

Code: Select all

icon shotgun
{
file "gfx.wad"
image "shotty"
x_position 30
y_position 180
variable self.items
condition &
value IT_SHOTGUN
}

icon pause
{
file "gfx/pause.lmp"
x_position center
y_position top
variable cl_paused
condition is
value true
}

icon intermission
{
file "gfx/inter.lmp"
x_position center
y_position top
variable sv_intermission
condition is
value true
}

hud ingame
{
icon shotgun
}

hud intermission
{
icon intermission
}

hud pause
{
icon pause
hud ingame
}

[gnounc]

hud css lol.
I'd like to see that, I've wanted to do hud work but have never bothered. I think if hud css existed I'd jump at it.

[frag.machine]

@Baker: I see your point: better have something not so flexible than nothing.

@mk: I liked the idea; gives some flexibility at the same time doesn't become a full interpreter.

I'll think a bit more about, you guys surely helped. Thanks to all.

[mh]

I'd rather do it the hard way and Manually code the HUD in sbar.c. Not very hard to do.

True enough, but not very flexible for mods either. You just have to look at the mess that is the Hipnotic and Rogue (especially Hipnotic) code to know that. Staying with sbar.c basically means that every mod that wants to use a slightly different HUD layout, or add/remove elements, needs an engine update. Best of luck co-ordinating that across all engines.

I guess it's OK if what you're working on is a specific mod that uses a specific engine. When it's not OK is when you're working on a mod that you want to run on all (or as many as possible) engines, or an engine that you want to run all (or as many as possible) mods. Sometimes you just got to look outside of your own personal immediate needs.

Aside from anything else code like this has no business being in an engine (the same goes for menu.c, r_part.c and good chunks of cl_tent.c, by the way).

It's a shame that CSQC is so complex and over-engineered. If it was possible to cut it down to the bare bones - i.e. a basic client-side scripting language that just ran some code, as opposed to this monster that interacts with entities and protocols and does a hostile takeover of so much of the engine, then we would have had widespread uptake of it by now and none of this would be necessary.

The fact that it's heavily documented from the mod-makers perspective, but not even remotely documented at all from the engine coder's perspective doesn't help matters either.

Anyway, I like the idea of a HUD CSS language. It seems a good compromise between flexibility and simplicity, and it would be a good idea to start bashing out requirements.

[TimeServ]

It's a shame that CSQC is so complex and over-engineered. If it was possible to cut it down to the bare bones - i.e. a basic client-side scripting language that just ran some code, as opposed to this monster that interacts with entities and protocols and does a hostile takeover of so much of the engine, then we would have had widespread uptake of it by now and none of this would be necessary.

For something that does client-side coding in sync with how Quake works entities I think the heavy engine modding is just unavoidable. On the other hand I'd think most QC modders just want a few temporary effects and a HUD change up. For temporary effects I think CSQC isn't so bad for the QC itself but for a HUD you have to redo the whole positioning and formatting digits which sucks. You don't gain any enhancements for HUDs that engines may provide either unless it's reimplemented in the QC.

I have to say though I don't think of CSS as something simple... but now that I think if it maybe something like that could be used as a MenuQC alternative as well.

[Spike]

Q2 has a scripted sbar. move x,y; pic foo, etc. its a bit limited in what it can do, and it depends upon precache_pic type stuff from the gamecode in order to function, but it gets the job done.

regarding csqc, one of the design features is that you can use it to draw models and stuff for the hud if you so choose. What you gain in simplicity you loose in versitility. I agree there could be a few more helper builtins, just as there could be a helper qc lib, but 200 builtins instead of ~50 extras hinders any sort of efforts for compatibility.
is the theory anyway.
if the engine were a little cleaner, a 'hostile takeover' would be somewhat less 'hostile'. I mean, if you don't want to add all the various hooks and protocol adaptations and entity handling then you don't have to. but if you don't, what the heck is the use of any of it?

[leileilol]

And here's the Q3TA example (okay, so i lied, it's OATA). It builds this hud. It always assumes a virtual 640x480 screen space. (and in DP CSQC, doing huds is quite annoying as you also have to throw in conditions for a 16:10/16:9 aspect or it'll crop your sbar off)

RTCWMP does the same approach, but they hardcode the timer and the compass in cgame

[Mexicouger]

While we are on the Subject of HUD coding, how hard would it be to create a bulitin that Draws an image? I just feel that it wouldn't be that hard to do, But could be wrong.

Just an idea

[mh]

While we are on the Subject of HUD coding, how hard would it be to create a bulitin that Draws an image? I just feel that it wouldn't be that hard to do, But could be wrong.

Just an idea

QC builtins run on the server but images are drawn on the client, so so you need to define some protocol changes for it and work on the basis that latency is gonna be unavoidable (even SP games have some latency in Quake).

[Spike]

telejano has some builtins to add/remove pics on the client (relative to some part of the screen). Doesn't support animations, so each change/tweek/etc requires a call in ssqc.
You can't do UIs with it, but huds can work. Assuming you force the user's viewsize to 120 to get rid of the engine's default hud (required if you want something that could potentially work with multiple engines via the same extension). Its somewhat painful to then implement every single hud element and number change, etc.

[mh]

There's also Nehahra's ShowLMP thing, but that's ghastly and is really only intended for simple icons (like a skull onscreen when you die).