[John McFo]

First of all: Hi there, new member (from germany) on board
I'm with Freespace 2 and FSSCP for a while now, but now as I'm starting with modding, I stumbled upon my first real problem.

The custom HUD gauges don't seem to work properly. I searched a lot on the HLP forums, tried everything I found and ended up with the thought, the custom HUD parsing code may be messed up...

I tried this code on build 20050622:

Code: [Select]

$Max Escort Ships: 6
#Custom Gauges
$Name: TestX
#End
#Main Gauges
$Default: (640 480)
$TestX: (8 380)
+Image: escort1
#End


... Works perfectly!

Then I added a few lines, so it looked like this:

Code: [Select]

$Max Escort Ships: 6
#Custom Gauges
$Name: TestX
[COLOR=orangered]$Name: TestY[/COLOR]
#End
#Main Gauges
$Default: (640 480)
$TestX: (8 380)
+Image: escort1
[COLOR=orangered]$TestY: (128 396)
+Image: escort3[/COLOR]
#End


Now what? No image left! Nothing.
I then removed that last line (+Image: escort3) and then...



First image (escort1) was back, but moved to position (8 128)!!?!?

Can anybody help me on this?

Greetings - John McFo

[WMCoolmon]

In hud/hudparse.cpp

Code: [Select]

static void parse_resolution(hud_info* dest_hud)
{
//Parse it
gauge_info* cg;
for(int i = 0; i < Num_gauge_types; i++)
{
cg = &gauges[i];
if(!cg->parent && cg->fieldname)
{

stuff_coords(dest_hud, cg);
}
}
}

Bolded line should be:

Code: [Select]

if(cg->parent == NULL && strlen(cg->fieldname))

Not 100% sure if that's it, but it is incorrect.

[John McFo]

I have an assumption what lines code may be subject of further investigation

As of hud/hudparse.h, these variables are more than just one int long (as the additional arrays like [2] or [NAME_LENGTH] indicate):

Code: [Select]


int custom_gauge_coords[MAX_CUSTOM_HUD_GAUGES][2];
int custom_gauge_sizes[MAX_CUSTOM_HUD_GAUGES][2];
char custom_gauge_images[MAX_CUSTOM_HUD_GAUGES] [MAX_FILENAME_LEN];
int custom_gauge_frames[MAX_CUSTOM_HUD_GAUGES];
char custom_gauge_text[MAX_CUSTOM_HUD_GAUGES] [NAME_LENGTH];
color custom_gauge_colors[MAX_CUSTOM_HUD_GAUGES];


This one in hud/hudparse.cpp looks suspitious to me:

Code: [Select]


(Rev. 2.23)
void parse_custom_gauge()
...
cg->coord_dest = HUD_VAR(custom_gauge_coords[Num_custom_gauges]);
cg->size_dest = HUD_VAR(custom_gauge_sizes[Num_custom_gauges]);
cg->image_dest = HUD_VAR(custom_gauge_images[Num_custom_gauges]);
cg->frame_dest = HUD_VAR(custom_gauge_frames[Num_custom_gauges]);
cg->text_dest = HUD_VAR(custom_gauge_text[Num_custom_gauges]);
cg->color_dest = HUD_VAR(custom_gauge_colors[Num_custom_gauges]);
...

changed in Rev. 2.24 to


cg->coord_dest = HUD_VAR(custom_gauge_coords[0]) + (Num_custom_gauges * [B]sizeof(int)[/B]);
cg->size_dest = HUD_VAR(custom_gauge_sizes[0]) + (Num_custom_gauges * [B]sizeof(int)[/B]);
cg->image_dest = HUD_VAR(custom_gauge_images[0]) + (Num_custom_gauges * [B]sizeof(int)[/B]);
cg->frame_dest = HUD_VAR(custom_gauge_frames[0]) + (Num_custom_gauges * [B]sizeof(int)[/B]);
cg->text_dest = HUD_VAR(custom_gauge_text[0]) + (Num_custom_gauges * [B]sizeof(int)[/B]);
cg->color_dest = HUD_VAR(custom_gauge_colors[0]) + (Num_custom_gauges * [B]sizeof(int)[/B]);


Shouldn't they be sizeof(int)*2 for coords and size, sizeof(int)*MAX_FILENAME_LEN for image etc. ?
Or even Num_custom_gauges * sizeof(custom_gauge)? ("custom_gauge" = pseudocode )

I come to this conclusion, because the second custom gauge I implemented overwrote things of my first gauge. Coords (X_gauge1 Y_gauge1) became coords (X_gauge1 X_gauge2)

Hit me twice, if my assumptions were incorrect for I have no further knowledge of the code as I only looked in the hud code several times to be sure I made no mistakes creating my own custom hud gauge.


Greetings - John McFo

[WMCoolmon]

Yeah; problem was, GCC doesn't like offsetof() being called on arrays.

That section of code should be:

Code: [Select]

cg->coord_dest = HUD_VAR(custom_gauge_coords[0]) + (Num_custom_gauges * (2*sizeof(int)));
cg->size_dest = HUD_VAR(custom_gauge_sizes[0]) + (Num_custom_gauges * (2*sizeof(int)));
cg->image_dest = HUD_VAR(custom_gauge_images[0]) + (Num_custom_gauges * (MAX_FILENAME_LEN * sizeof(char)));
cg->frame_dest = HUD_VAR(custom_gauge_frames[0]) + (Num_custom_gauges * sizeof(int));
cg->text_dest = HUD_VAR(custom_gauge_text[0]) + (Num_custom_gauges * (NAME_LENGTH * sizeof(char)));
cg->color_dest = HUD_VAR(custom_gauge_colors[0]) + (Num_custom_gauges * sizeof(color));

It looks like that was the only section of code with that change made, and that would very likely cause the problem you were describing.

[Nuke]

does this mean your working on them again

[WMCoolmon]

Well the current system is pretty flexible - I haven't seen anyone use it at all in any mission (or heard about it). You should be able to define several gauges, and also do stuff like change the image frame in-mission, change the text, and IIRC even move it around.

I did have some thoughts about making a much more flexible system, but I never got past the "dynamic variables" stage (basically Bobb's expression thing).

Ideally, it'd:
- use the new expression code
- use the new GUI code (So you could interact with the HUD via the mouse, drag stuff around, and use interface objects in it...this would require some reworking of the interface as well, which would help mods use it.)
- Take advantage of the new render-to-target stuff. (So you could render it to a specific texture on a ship, maybe this could even be worked into the materials system somehow with the ability to specify a hud gauge by name in materials.tbl and apply it however you wished.)
- Be much more flexible in general. I'd really, really like to see some sort of scripting system ala Torque. Maybe work it into the SEXP system somehow so that SEXPs would automatically be functions, as well as the expression system. Doing something with the existing TBL format seems very constraining, but I still have my pathological fear/dislike of the SEXP system syntax.

Fixing all the bugs in the current system and maybe reworking the weapons gauge to use the current system would probably be more beneficial in the short run. I'm sure it's riddled with bugs (Besides the aforementioned ones), it's just that nobody uses it enough to figure them out.

[Nuke]

im sure id make use of the advanced system, but seeing as im no good with fred i doubt id use it as it stands. id definately make working gauges in some of my ships. though id wait till all the underlaying stuff is done first (the materials system and such). im definately intrested in making a completely reworked hud for pirate fighters

[John McFo]

My experience on this is:
Gaming people (including modder, artists, level designer etc.) tend to use the tools given to them. They rarely demand new tools from the developers, as they have in mind that won't happen too often, given their experience with commercial products (like Halflife, Quake, Starcraft, --insert your fav game here-- ). Mostly their demands are worked around or met by exploits of the given engine (I have seen awesome scripting workarounds in Halflife ).
Give them a new tool - they *might* use it. Give them a great new tool - they *will* use it.

- Take advantage of the new render-to-target stuff.
[...]
- Be much more flexible in general. I'd really, really like to see some sort of scripting system ala Torque. Maybe work it into the SEXP system somehow so that SEXPs would automatically be functions, as well as the expression system.

Since this would be a great addition to FS2, you can bet on new uses of this would be created you never even imagined. *thinks* Eg. a destroyed subsystem would lead to the accompanying (? help, I'm german) hud gauge to flicker or even disappear. And this wouldn't be one of the creative uses of that system.

Greetings

John McFo

[karajorma]

The problem is that the SCP code in new features very quickly but the hosted projects use them rather slowly because we're overstreched as it is.

Now of course I'm not saying that the coders should stop adding new things. Just that it's not surprising if people don't get around to using them for ages.

[John McFo]

Another "problem" could be that new features aren't well documented as depicted in numerous other threads. To stay on topic, the custom hud gauge documentation is spreaded to at least three threads and the wiki entry is in some ways out of date (#Gauges entry, support of escort gauge commands missing).

Greetings

John McFo

[karajorma]

I agree. Sometimes I run FRED and notice a feature I'd never even heard of.

[Starman01]

I second that. Actually, custom HUD-Gauges are something we would really like to use in WCS, escpecially when we are possible to move everything around

@WMC : Can you not put a good tutorial on how to use it (so that people like me, who have no idea from the code can understand it )

[DaBrain]

SoL just has to change something about the layout too.

We need to alter the HUD a lot. Documentation would be most useful.

[WMCoolmon]

I did write up an incomplete guide awhile back. Only a few gauges are setup to use the system though.

[Starman01]

Afaik, your previous version allowed only the movement of a view hud-parts ? Can we now move everything ?

[WMCoolmon]

Originally posted by WMCoolmon
Only a few gauges are setup to use the system though.

IIRC, the shield mini icon in the center of the screen, the current target and player ship shield displays, and the escort list are setup to use it.

[Nuke]

Originally posted by karajorma
The problem is that the SCP code in new features very quickly but the hosted projects use them rather slowly because we're overstreched as it is.

Now of course I'm not saying that the coders should stop adding new things. Just that it's not surprising if people don't get around to using them for ages.

this is indeed true. typically one has to wait for features to mature awhile before they are stable and functional in each and every new build. it is also hard to predict what will actually work when an offitial build comes around. so people might not want to implement something in their mod that may not work in the next offitial build.

[WMCoolmon]

CVS has been updated, I can't really make a Win32 build right now (seeing as how I don't have Win32 installed), but any new builds should have the fixes in. I haven't tested 'em though.

[Bobboau]

Originally posted by WMCoolmon
maybe this could even be worked into the materials system somehow with the ability to specify a hud gauge by name in materials.tbl and apply it however you wished

already got some code in place