View Issue Details

IDProjectCategoryView StatusLast Update
0002071FSSCPHUDpublic2010-12-11 04:29
ReporterKeldorKatarn Assigned ToSwifty  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformIBM PCOSMS WindowsOS VersionVista SP2
Product Version3.6.11 
Target Version3.7.2 
Summary0002071: Make custom gauges fully flexible in hud_gauges.tbl
DescriptionThis includes several issues:

- Fix per ship gauges parsing. (this must be completed first) (0001936)
- Let custom gauges inherit color of a hard coded main gauge.
- Ability to select whether a custom gauge or one of the customizable main gauges do move in pan view or remain static.
TagsNo tags attached.

Relationships

parent of 0001936 resolvedSwifty Per ship custom gauge entries in hud_gauges.tbl do not seem to work 
parent of 0002075 closedSwifty Possibility for custom gauges to inherit color of a main gauge 
parent of 0002076 resolvedSwifty Possibility to specify for custom and tbl-customizable gauges move in pan view or remain static 

Activities

KeldorKatarn

2009-12-21 12:32

reporter   ~0011454

I opened the two remaining children tickets:

0002075
0002076

KeldorKatarn

2009-12-21 15:42

reporter   ~0011457

As a parent ticket, I guess this should be put into the 3.6.12 roadmap instead it's child.

Swifty

2010-01-22 08:06

developer   ~0011560

Hey KK. I read all of your tickets and I'm well aware of the bugs and features you want resolved for the HUD system.

I guess I should tell you that I'm in the middle of restructuring most if not all the HUD code into something more modular. The planned new HUD code will be object oriented which will enable us have multiple instances of a HUD gauge rendered in different areas.

I'm working my best to get all HUD gauges that are listed in hud_gauges.h to be customizable through hud_gauges.tbl. This will include options such as which viewer modes the gauges can be displayed in, whether they are a reticle following gauge, the upper left hand coords of the gauge, the default color, etc. And the features you suggested such as parent gauge colors for custom gauges.

Ultimately, having an objected oriented system will allow us to have HUD gauges rendered on cockpit models, something I'm very well aware that WCS needs. The plan is to have HUD gauges given a texture name and the UVs to render a particular HUD gauge within hud_gauges.tbl. I've already hacked up a proof of concept code that renders the radar gauge to a cockpit model. Now I just got to clean up the HUD code so this feature won't be an awful looking hack.

Hopefully, I'll have all this finished by April.

KeldorKatarn

2010-01-30 22:17

reporter   ~0011607

Combi-Patch attached for 0002075 and 0002076. It's a combination patch because it affects the same lines of code and I cannot create them separately based the same revision. And since they're both part of this anyway...

This adds the ability to use
+Inherit Color from: center of reticle
+Move in Pan View: true

for custom gauges (and for the afterburner and weapon energy gauges for now, since those move in pan view by default, which mods might want to deactivate).
+Color: is ignored if +Inherit Color from: is specified. it is also ignored for all retail gauges since those can be assigned a color ingame. +Move in Pan View: is ignored for all retail gauges except the two energy gauges.

2010-01-30 22:17

 

custom_color_and_panview.patch (15,362 bytes)   
Index: code/hud/hud.cpp
===================================================================
--- code/hud/hud.cpp	(revision 5859)
+++ code/hud/hud.cpp	(working copy)
@@ -1300,12 +1300,24 @@
 		//Display the gauges
 		for(i = 0; i < Num_custom_gauges; i++)
 		{
-			if(current_hud->custom_gauge_colors[i].red != 0 || current_hud->custom_gauge_colors[i].green != 0 || current_hud->custom_gauge_colors[i].blue != 0)
+			color* gauge_color;
+
+			// Inherit color if color parent is specified.
+			if (current_hud->custom_gauge_color_parents[i] >=0 && current_hud->custom_gauge_color_parents[i] < NUM_HUD_GAUGES)
+ 			{
+				gauge_color = &HUD_config.clr[current_hud->custom_gauge_color_parents[i]];
+			}
+			else
 			{
+				gauge_color = &current_hud->custom_gauge_colors[i];
+			}
+
+			if(gauge_color->red != 0 || gauge_color->green != 0 || gauge_color->blue != 0)
+			{
 				//No custom alpha gauge color...
-				gr_init_alphacolor(&current_hud->custom_gauge_colors[i], current_hud->custom_gauge_colors[i].red, current_hud->custom_gauge_colors[i].green, current_hud->custom_gauge_colors[i].blue, (HUD_color_alpha+1)*16);
+				gr_init_alphacolor(gauge_color, gauge_color->red, gauge_color->green, gauge_color->blue, (HUD_color_alpha+1)*16);
 
-				gr_set_color_fast(&current_hud->custom_gauge_colors[i]);
+				gr_set_color_fast(gauge_color);
 			}
 			if(strlen(current_hud->custom_gauge_text[i]))
 			{
@@ -1314,7 +1326,14 @@
 			}
 			if(image_ids[i].first_frame != -1)
 			{
-				GR_AABITMAP(image_ids[i].first_frame + current_hud->custom_gauge_frames[i], current_hud->custom_gauge_coords[i][0], current_hud->custom_gauge_coords[i][1]);
+				if (current_hud->custom_gauge_moveflags[i])
+				{
+					GR_AABITMAP(image_ids[i].first_frame + current_hud->custom_gauge_frames[i], current_hud->custom_gauge_coords[i][0] + HUD_nose_x, current_hud->custom_gauge_coords[i][1] + HUD_nose_y);
+				}
+				else
+				{
+					GR_AABITMAP(image_ids[i].first_frame + current_hud->custom_gauge_frames[i], current_hud->custom_gauge_coords[i][0], current_hud->custom_gauge_coords[i][1]);
+				}
 			}
 
 			//So we're back to normal
Index: code/hud/hudconfig.cpp
===================================================================
--- code/hud/hudconfig.cpp	(revision 5859)
+++ code/hud/hudconfig.cpp	(working copy)
@@ -47,6 +47,48 @@
 };
 
 HUD_CONFIG_TYPE HUD_config;	// Player HUD configuration
+ 
+char Hud_Gauge_Names[NUM_HUD_GAUGES][NAME_LENGTH] = {
+	"lead indicator",
+	"target orientation",
+	"closest attacking hostile",
+	"current target direction",
+	"mission time",
+	"reticle",
+	"throttle",
+	"radar",
+	"target monitor",
+	"center of reticle",
+	"extra target info",
+	"target shield",
+	"player shield",
+	"power management",
+	"auto-target icon",
+	"auto-speed-match icon",
+	"weapons display",
+	"monitoring view",
+	"directives view",
+	"threat gauge",
+	"afterburner energy",
+	"weapons energy",
+	"weapon linking",
+	"target hull/shield icon",
+	"offscreen indicator",
+	"comm video",
+	"damage display",
+	"message output",
+	"locked missile direction",
+	"countermeasures",
+	"objective notify",
+	"wingmen status",
+	"offscreen range",
+	"kills gauge",
+	"attacking target count",
+	"warning flash",
+	"comm menu",
+	"support gauge",
+	"lag gauge"
+};
 
 // specify the max distance that the radar should detect objects
 // See RR_ #defines in HUDconfig.h.
Index: code/hud/hudparse.cpp
===================================================================
--- code/hud/hudparse.cpp	(revision 5859)
+++ code/hud/hudparse.cpp	(working copy)
@@ -26,6 +26,7 @@
 hud_info default_hud;
 hud_info ship_huds[MAX_SHIP_CLASSES];
 extern int ships_inited; //Need this
+extern char Hud_Gauge_Names[NUM_HUD_GAUGES][NAME_LENGTH];
 
 float Hud_unit_multiplier = 1.0f;	//Backslash
 
@@ -43,26 +44,26 @@
 #define HUD_VAR(a) offsetof(hud_info, a)
 
 gauge_info gauges[MAX_HUD_GAUGE_TYPES] = {
-	{ NULL,			HUD_VAR(Player_shield_coords),	"$Player Shield:",			396, 379, 634, 670,	0, 0, 0, 0, 0, -1, -1 },
-	{ NULL,			HUD_VAR(Target_shield_coords),	"$Target Shield:",			142, 379, 292, 670,	0, 0, 0, 0, 0, -1, -1 },
-	{ NULL,			HUD_VAR(Shield_mini_coords),	"$Shield Mini:",			305, 291, 497, 470, 0, HUD_VAR(Shield_mini_fname), 0, 0, 0, -1, -1 },
-	{ NULL,			HUD_VAR(Aburn_coords),			"$Afterburner Energy:",		171, 265, 274, 424, HUD_VAR(Aburn_size), HUD_VAR(Aburn_fname), 0, 0, 0, -1, -1 },
-	{ NULL,			HUD_VAR(Wenergy_coords),		"$Weapons Energy:",			416, 265, 666, 424, HUD_VAR(Wenergy_size), HUD_VAR(Wenergy_fname), 0, 0, 0, -1, -1 },
-	{ NULL,			HUD_VAR(Wenergy_text_coords),	"$Weapons Energy Text:",	439, 318, 708, 509, 0, 0, 0, 0, 0, -1, -1 },
-	{ NULL,			HUD_VAR(Escort_coords),			"$Escort List:",			486, 206, 865, 330, 0, HUD_VAR(Escort_filename[0]), 0, HUD_VAR(Escort_htext), 0, -1, -1 },
+	{ NULL,			HUD_VAR(Player_shield_coords),	"$Player Shield:",			396, 379, 634, 670,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
+	{ NULL,			HUD_VAR(Target_shield_coords),	"$Target Shield:",			142, 379, 292, 670,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
+	{ NULL,			HUD_VAR(Shield_mini_coords),	"$Shield Mini:",			305, 291, 497, 470, 0, HUD_VAR(Shield_mini_fname), 0, 0, 0, 0, 0, -1, -1 },
+	{ NULL,			HUD_VAR(Aburn_coords),			"$Afterburner Energy:",		171, 265, 274, 424, HUD_VAR(Aburn_size), HUD_VAR(Aburn_fname), 0, 0, 0, 0, HUD_VAR(Aburn_move_flag), -1, -1 },
+	{ NULL,			HUD_VAR(Wenergy_coords),		"$Weapons Energy:",			416, 265, 666, 424, HUD_VAR(Wenergy_size), HUD_VAR(Wenergy_fname), 0, 0, 0, 0, HUD_VAR(Wenergy_move_flag), -1, -1 },
+	{ NULL,			HUD_VAR(Wenergy_text_coords),	"$Weapons Energy Text:",	439, 318, 708, 509, 0, 0, 0, 0, 0, 0, 0, -1, -1 },
+	{ NULL,			HUD_VAR(Escort_coords),			"$Escort List:",			486, 206, 865, 330, 0, HUD_VAR(Escort_filename[0]), 0, HUD_VAR(Escort_htext), 0, 0, 0, -1, -1 },
 
 	//Mini-gauges
-	{ &gauges[2],	HUD_VAR(Hud_mini_3digit),		"$Text Base:",				310, 298, 502, 477,	0, 0, 0, 0, 0, -1, -1 },
-	{ &gauges[2],	HUD_VAR(Hud_mini_1digit),		"$Text 1 digit:",			316, 298, 511, 477,	0, 0, 0, 0, 0, -1, -1 },
-//	{ &gauges[2],	HUD_VAR(Hud_mini_2digit),		"$Text 2 digit:",			213, 298, 346, 477,	0, 0, 0, 0, 0, -1, -1 },
-	{ &gauges[2],	HUD_VAR(Hud_mini_2digit),		"$Text 2 digit:",			313, 298, 506, 477,	0, 0, 0, 0, 0, -1, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_htext_coords),	"$Header Text:",			489, 208, 869, 331,			0, 0, 0, 0, 0, -1, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_list),			"$List:",					0, 12, 0, 13,		0, 0, 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_entry),			"$Ship:",					0, 11, 0, 11,		0, HUD_VAR(Escort_filename[1]), 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_entry_last),		"$Last Ship:",				0, 11, 0, 11,		0, HUD_VAR(Escort_filename[2]), 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_name),			"$Ship Name:",				3, 0, 4, 0,			0, 0, 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_integrity),		"$Ship Hull:",				128, 0, 116, 0,		0, 0, 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_status),			"$Ship Status:",			-12, 0, -11, 0,		0, 0, 0, 0, 0, HG_NOADD, -1 }
+	{ &gauges[2],	HUD_VAR(Hud_mini_3digit),		"$Text Base:",				310, 298, 502, 477,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
+	{ &gauges[2],	HUD_VAR(Hud_mini_1digit),		"$Text 1 digit:",			316, 298, 511, 477,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
+//	{ &gauges[2],	HUD_VAR(Hud_mini_2digit),		"$Text 2 digit:",			213, 298, 346, 477,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
+	{ &gauges[2],	HUD_VAR(Hud_mini_2digit),		"$Text 2 digit:",			313, 298, 506, 477,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
+	{ &gauges[5],	HUD_VAR(Escort_htext_coords),	"$Header Text:",			489, 208, 869, 331,			0, 0, 0, 0, 0, 0, 0, -1, -1 },
+	{ &gauges[5],	HUD_VAR(Escort_list),			"$List:",					0, 12, 0, 13,		0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[5],	HUD_VAR(Escort_entry),			"$Ship:",					0, 11, 0, 11,		0, HUD_VAR(Escort_filename[1]), 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[5],	HUD_VAR(Escort_entry_last),		"$Last Ship:",				0, 11, 0, 11,		0, HUD_VAR(Escort_filename[2]), 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[5],	HUD_VAR(Escort_name),			"$Ship Name:",				3, 0, 4, 0,			0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[5],	HUD_VAR(Escort_integrity),		"$Ship Hull:",				128, 0, 116, 0,		0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[5],	HUD_VAR(Escort_status),			"$Ship Status:",			-12, 0, -11, 0,		0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 }
 };
 
 //Number of gauges
@@ -103,6 +104,10 @@
 		/**************************************************/
 	}
 
+	// Pan View Move Flag defaults
+	hud->Aburn_move_flag = true;
+	hud->Wenergy_move_flag = true;
+
 	//Neither
 	strcpy_s(hud->Shield_mini_fname, "targhit1");
 	strcpy_s(hud->Escort_filename[0], "escort1");
@@ -262,6 +267,35 @@
 			stuff_ubyte(&junk_byte);
 		}
 	}
+	if(optional_string("+Inherit Color from:"))
+	{
+		*HUD_INT(dest_hud, cg->color_parent_dest) = -1;
+		stuff_string(buffer, F_NAME, NAME_LENGTH);
+		
+		if(cg->color_parent_dest)
+		{
+			for (int idx = 0; idx < NUM_HUD_GAUGES; idx++)
+			{
+				if (stricmp(buffer, Hud_Gauge_Names[idx]) == 0)
+				{
+					*HUD_INT(dest_hud, cg->color_parent_dest) = idx;
+					break;
+				}
+			}
+		}
+	}
+	if(optional_string("+Move in Pan View:"))
+	{
+		if(cg->moveflag_dest)
+		{
+			stuff_boolean(HUD_BOOL(dest_hud, cg->moveflag_dest));
+		}
+		else
+		{
+			bool junk_bool;
+			stuff_boolean(&junk_bool);
+		}
+	}
 	return 1;
 }
 
@@ -426,6 +460,8 @@
 		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));
+		cg->color_parent_dest = HUD_VAR(custom_gauge_color_parents[0]) + (Num_custom_gauges * sizeof(int));
+		cg->moveflag_dest = HUD_VAR(custom_gauge_moveflags[0]) + (Num_custom_gauges * sizeof(bool));
 
 		required_string("$Name:");
 		//Gotta make this a token
Index: code/hud/hudparse.h
===================================================================
--- code/hud/hudparse.h	(revision 5859)
+++ code/hud/hudparse.h	(working copy)
@@ -33,6 +33,8 @@
 	int Wenergy_size[2];
 	char Aburn_fname[MAX_FILENAME_LEN];
 	char Wenergy_fname[MAX_FILENAME_LEN];
+	bool Aburn_move_flag;
+	bool Wenergy_move_flag;
 	//Hudescort
 	int Escort_coords[2];
 
@@ -58,6 +60,8 @@
 	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];
+	int custom_gauge_color_parents[MAX_CUSTOM_HUD_GAUGES];
+	bool custom_gauge_moveflags[MAX_CUSTOM_HUD_GAUGES];
 
 //	int gauge_text_sexp_vars[MAX_HUD_GAUGE_TYPES];
 //	int gauge_frame_sexp_vars[MAX_HUD_GAUGE_TYPES];
@@ -98,6 +102,8 @@
 		memset( custom_gauge_frames, 0, sizeof( custom_gauge_frames ) );
 		memset( custom_gauge_text, 0, sizeof( custom_gauge_text ) );
 		memset( custom_gauge_colors, 0, sizeof( custom_gauge_colors ) );
+		memset( custom_gauge_color_parents, 0, sizeof( custom_gauge_color_parents ) );
+		memset( custom_gauge_moveflags, 0, sizeof( custom_gauge_moveflags ) );
 	}
 } hud_info;
 
@@ -115,6 +121,8 @@
 	size_t frame_dest;	//Storage spot for frame info
 	size_t text_dest;	//Storage spot for text value
 	size_t color_dest;	//Storage spot for color value
+	size_t color_parent_dest;	//Storage spot for color value
+	size_t moveflag_dest;	//Storage spot for pan view move boolean
 	int placement_flags;
 	int show_flags;	//Show outside ship?
 	//int (*update_gauge)(gauge_info* cg);	//Function to update the gauge
@@ -127,6 +135,7 @@
 #define HUD_INT(a, b) ((int*)((char*)a + b))
 #define HUD_CHAR(a, b) ((char *)((char*)a + b))
 #define HUD_COLOR(a, b) ((color *)((char*)a + b))
+#define HUD_BOOL(a, b) ((bool *)((char*)a + b))
 
 //Variables
 extern int Num_custom_gauges;
Index: code/hud/hudtarget.cpp
===================================================================
--- code/hud/hudtarget.cpp	(revision 5859)
+++ code/hud/hudtarget.cpp	(working copy)
@@ -4821,6 +4821,7 @@
 {
 	float percent_left;
 	int	clip_h,w,h;	
+	int nose_offset_x = 0, nose_offset_y = 0;
 
 	if ( Aburn_bar_gauge.first_frame == -1 ){
 		return;
@@ -4842,13 +4843,19 @@
 	clip_h = fl2i( (1.0f - percent_left) * current_hud->Aburn_size[0] + 0.5f );
 
 	bm_get_info(Aburn_bar_gauge.first_frame,&w,&h);
+
+	if (current_hud->Aburn_move_flag)
+	{
+		nose_offset_x = HUD_nose_x;
+		nose_offset_y = HUD_nose_y;
+	}
 	
 	if ( clip_h > 0) {
-		GR_AABITMAP_EX(Aburn_bar_gauge.first_frame, current_hud->Aburn_coords[0] + HUD_nose_x, current_hud->Aburn_coords[1] + HUD_nose_y,w,clip_h,0,0);		
+		GR_AABITMAP_EX(Aburn_bar_gauge.first_frame, current_hud->Aburn_coords[0] + nose_offset_x, current_hud->Aburn_coords[1] + nose_offset_y,w,clip_h,0,0);
 	}
 
 	if ( clip_h <= current_hud->Aburn_size[0] ) {		
-		GR_AABITMAP_EX(Aburn_bar_gauge.first_frame+1, current_hud->Aburn_coords[0] + HUD_nose_x, current_hud->Aburn_coords[1]+clip_h + HUD_nose_y,w,h-clip_h,0,clip_h);
+		GR_AABITMAP_EX(Aburn_bar_gauge.first_frame+1, current_hud->Aburn_coords[0] + nose_offset_x, current_hud->Aburn_coords[1]+clip_h + nose_offset_y,w,h-clip_h,0,clip_h);
 	} 	
 }
 
@@ -4857,6 +4864,7 @@
 {
 	int x;
 	bool use_new_gauge = false;
+	int nose_offset_x = 0, nose_offset_y = 0;
 
 	// Goober5000 - only check for the new gauge in case of command line + a ballistic-capable ship
 	if (Cmdline_ballistic_gauge && Ship_info[Player_ship->ship_info_index].flags & SIF_BALLISTIC_PRIMARIES)
@@ -4870,6 +4878,12 @@
 			}
 		}
 	}
+ 
+	if (current_hud->Aburn_move_flag)
+	{
+		nose_offset_x = HUD_nose_x;
+		nose_offset_y = HUD_nose_y;
+	}
 
 	if(use_new_gauge)
 	{
@@ -4877,8 +4891,8 @@
 		int y;
 		int max_w = 100;
 		float remaining;
-		currentx = current_hud->Wenergy_coords[0] + 10;
-		currenty = current_hud->Wenergy_coords[1];
+		currentx = current_hud->Wenergy_coords[0] + 10 + nose_offset_x;
+		currenty = current_hud->Wenergy_coords[1] + nose_offset_y;
 		if(gr_screen.max_w_unscaled == 640) {
 			max_w = 60;
 		}
@@ -4980,7 +4994,7 @@
 			sprintf(buf,XSTR( "%d%%", 326), fl2i(percent_left*100+0.5f));
 			hud_num_make_mono(buf);
 		//	gr_string(Weapon_energy_text_coords[gr_screen.res][0], Weapon_energy_text_coords[gr_screen.res][1], buf);
-			gr_string(current_hud->Wenergy_text_coords[0] + HUD_nose_x, current_hud->Wenergy_text_coords[1] + HUD_nose_y, buf);
+			gr_string(current_hud->Wenergy_text_coords[0] + nose_offset_x, current_hud->Wenergy_text_coords[1] + nose_offset_y, buf);
 		}
 
 		hud_set_gauge_color(HUD_WEAPONS_ENERGY);
@@ -5002,11 +5016,11 @@
 		bm_get_info(Wenergy_bar_gauge.first_frame+2,&w,&h);
 		
 		if ( clip_h > 0 ) {
-			GR_AABITMAP_EX(Wenergy_bar_gauge.first_frame+2, current_hud->Wenergy_coords[0] + HUD_nose_x, current_hud->Wenergy_coords[1] + HUD_nose_y, w,clip_h,0,0);		
+			GR_AABITMAP_EX(Wenergy_bar_gauge.first_frame+2, current_hud->Wenergy_coords[0] + nose_offset_x, current_hud->Wenergy_coords[1] + nose_offset_y, w,clip_h,0,0);
 		}
 
 		if ( clip_h <= current_hud->Wenergy_size[0] ) {
-			GR_AABITMAP_EX(Wenergy_bar_gauge.first_frame+3, current_hud->Wenergy_coords[0] + HUD_nose_x, current_hud->Wenergy_coords[1] + clip_h + HUD_nose_y, w,h-clip_h,0,clip_h);		
+			GR_AABITMAP_EX(Wenergy_bar_gauge.first_frame+3, current_hud->Wenergy_coords[0] + nose_offset_x, current_hud->Wenergy_coords[1] + clip_h + nose_offset_y, w,h-clip_h,0,clip_h);		
 		}
 
 		// hud_set_default_color();
custom_color_and_panview.patch (15,362 bytes)   

Swifty

2010-02-08 20:15

developer   ~0011621

I'm sorry, Keldor. The thing is that the current HUD code is an absolute mess. It's unmaintainable with it's cryptic macros, use of comma operators, uses of structs which then aren't used again. The semantics are messed up, hell, the syntax is screwed up too. The current specifications for hud_gauges.tbl is pretty much going to be rewritten. the current hud_gauges.tbl code isn't even finished; You can only change the positions of a few HUD gauges.

It's going to be pointless working in your fixes when we've got something already in the pipeline that will handle all your requests. Especially if the current specifications you're writing for is going to be deprecated.

I'll tell you what. I pretty much have the new gauge code finished save for various gauges. Let me finish up the gauges that you need and I'll get them ready for testing and release. If you can give me a hud_gauges.tbl that you guys are intending to use, I'll rework it to use the new syntax.

Again, apologies, Keldor. I just don't want your project to use an unsupported feature by the time it releases. I don't want to do that to you guys. :(

KeldorKatarn

2010-02-08 20:55

reporter   ~0011623

So you're effectively saying that in the future anyone who's already written a hud_gauges.tbl can scrap it and start over?

great way of doing things, guys! Thumbs up!

portej05

2010-02-09 04:38

reporter   ~0011624

KK: Cheers, we'll let you know when the changes come through.

KeldorKatarn

2010-02-10 19:41

reporter   ~0011625

just wanted to emphasize this... deprecating the current hud_gauges.tbl syntax is a NO-GO for us. if that happens we'll split off and go total custom build.

As it stands right now we'll most likely do that anyway since we're not very happy with recent developments. But changing hud_gauges.tbl will definatly be a reason to do it.

Also rendering to cockpit doesn't help us at all. We've already cut that possibility and also cockpits look horrible without shadow functionality, so that is a no-go for us at the moment anyway.

So we'd really appreciate to just get the functionality that my patch provides. We don't need anything else.

And for future support I'd really recommend NOT to deprecate the table. I don't see why that is necessary anway. The syntax is fine and can be extended without problems to other HUD elements. So why change it just because the code changes? That would break all hud_gauges.tbl tables currently in use by MODs.

chief1983

2010-02-10 22:56

administrator   ~0011626

I could get a mod that has released content with the old syntax being upset, but a mod that's still in development not able to adjust some syntax of a table that doesn't affect game balance? I really don't see what the fuss here is about KK. The original method was never that great and the syntax was confusing to most people to the point that even the wiki didn't really help make anything clear to me. Sure it's more work but so is rewriting the HUD code so it doesn't suck and we've got a coder doing that right now. I'd tell you to bitch at the coder who wrote the original implementation, but _surprise_ he's not even around anymore. Sorry you're getting caught in the crosswinds of a change like this, if I had realized a year ago how bad the HUD code actually was I'd have probably suggested we just immediately end support for it then until it could be fixed, and suggest that no one use it.

portej05

2010-02-11 04:17

reporter   ~0011629

KeldorKatarn: I'm off the SCP team now, so I can say this. WCS needs to realise that it's not their engine. If you want to fork, that's fine, but I've warned the SCP team of the dangers of giving you any support whatsoever. Develop against the available features and heed the advice of the SCP team if you ever want your mod to be forwards compatible.

Backslash

2010-02-11 05:39

developer   ~0011631

That was quite an about face, KK, WHY is depreciating the current hud_gauges.tbl syntax a no-go?

No, really, listen to this hypothetical situation: Imagine someone writes a new system that works exactly as WCSaga wants it: custom gauges specified per-ship, with inherited colors and slew view flag/options. The syntax is a bit different, but that's ok, no released mod is using that old broken syntax anyway.

Is there a problem? What is the problem?

Now imagine there's a coder, Swifty, actually working to implement this, and on top of that even nicely offering to modify your table for you so that it works right away. THIS IS THE CASE. Zeck, if he hadn't offered the latter I'd do it for you.

KeldorKatarn

2010-02-11 12:08

reporter   ~0011634

Maybe, just maybe, because I know what we have now works as we need it. And maybe just maybe I don't trust the SCP to get ANYTHING done in time anymore since that's never been the case in the last 4 years.

And about the table... sorry but I still don't see the need for any change in the syntax. And your offer is fine... IF this ever gets done in time for us to use it. But what about other small mods in the works, what about small mods that are using the stuff? Small campaign mods for Saga or other stuff in development. Why are you dropping support for those guys just because they haven't released yet?

You were constantly telling us this or that couldn't be done because it'd break backwards compatibility and now you're suggesting a huge break. Maybe I'm not JUST concirned about US but also about people you already dis some modifications to our prologue and other stuff based on newer builds and put a lot of work into those tables already.

And about these changes... well sorry... right now I have NO idea what the SCP is doing at all.. one side tells us we won't get anything anymore because 3.6.12 is feature complete, someone else tells us they're working on stuff, then the next person comes and tells something totally different altogether.

We were assured that we'd get everything we need in time for release. That's why we were asked to provide a list with that stuff and mark all of it in Mantis so it could be added to the roadmap. Now suddenly all that doesn't seem to be true anymore and now we're hearing stuff that works isn't fixed anymore with existing code but totally rewritten from scratch and we're suppose to believe that this will be ready in time?

Well SORRY if we're starting to have REAL doubts about the so called "support". SO far we got very little. SO far we had to implement about 90% of our needed stuff ourselfs, had to provide the code ourselves after weeks of zero progress and even then got shouted at when that code wasn't liked by everyone until it went into trunk usually after weeks and weeks of discussions.

So to bring this to the point. I am so strongly against this because it would be the first feature to be release-ready in 4 years that is actually bugfree and release ready enough for us to use it.
And to get that slim change we're expected to drop something that is working fine at the moment, so risk an already working functionality.

And you honestly can't see why I might have objections??

Tolwyn

2010-02-11 12:22

reporter   ~0011636

Just to sum it up in a civilized and calm manner: there was always a tradeoff between what we want and what we get.

But I'd like to point out following: at this stage of the project we can not allow to rely on a major development, that might or might not be ready in time. I also have my reservations that the new system will be ready by the time we hit beta, as discussed with portej on icq two days ago.

And no, we are not under the impression that we own the engine - considering that, as Keldor said, we had to develop 90% of all fixes on our own.

A fork was never an option, but if you put the future of the project on the line, it might become the only viable option, if you remove features we need. Not to mention that Goober brought up the possibility of the fork on his own.

chief1983

2010-02-11 15:30

administrator   ~0011638

Last edited: 2010-02-11 15:32

Look, Swifty thinks he can get the rewrite to feature parity with what's currently available within a couple of weeks. Even if it's a bit longer than that, that's hardly a long amount of time, and we could at least revisit this issue then. He's not one of the coders you've dealt with in the past, you keep assuming that the SCP is a constant, when it's been in a high state of flux for the better part of a year now. So if you're mostly worried about the deadlines being met, I think it's fair to at least give Swifty a chance before you write him off.

You're right, a lot of mod teams do need to rely on their own coding to get features in. FotG still has some feature needs to meet and I'm sure I'll get more vocal as the immediacy of our need for them increases.

If you have the code ready for this stuff, I assume committing it wouldn't actually interfere with what Swifty's doing. You'd be able to continue development using the current syntax, but when Swifty gets the code to feature parity, would there be any reason not to upgrade as long as you have enough time to verify and test before release?

Also, we're not removing features. They'll still be there, but their syntax will hopefully be more intuitive. So it's not like it's going to prevent you from ever finishing the mod.

Tolwyn

2010-02-11 15:35

reporter   ~0011639

As long as we get the fix in place and the new system gets ready before the release, we can, of course, modify our data set. As I said, I am more concerned about the "what if" scenario. What if the feature does not get ready in time? And it is not that I am not giving Swifty (or anybody else for that matter) a chance. It's just that I know from my own bitter experience that sometimes higher powers prevent you from doing any actual work. It's always handy to have a fall back plan.

chief1983

2010-02-11 15:45

administrator   ~0011640

Like I said, I personally don't have any problem with allowing development on the current HUD code, I would prefer to see a little more testing done before patches are submitted but as it's hopefully being gutted soon I'm not too worried about its reliability compared to other areas of the code. Since I believe KK already has KK ready for the other two parts of this ticket we should probably go ahead with getting those in for you to use.

KeldorKatarn

2010-02-11 16:03

reporter   ~0011641

The code patch file is already attached since 2010-01-30

chief1983

2010-02-11 16:06

administrator   ~0011642

Ah, so it is. Was thinking it would be on the child tickets, never thought to look here.

KeldorKatarn

2010-02-11 16:10

reporter   ~0011643

As already stated earlier, I put it here because it adds both features in one go. I can't do it differently because they change the same codelines, so I cannot do them independently.

chief1983

2010-02-11 16:30

administrator   ~0011646

Committed in 5901.

KeldorKatarn

2010-02-11 22:50

reporter   ~0011649

One further patch required (even for non-Saga).
The Escort List child gauges have a wrong parent (wrong index).
Also right now ship-specific-gauges inherit the wrong coordinates for child gauges.

patch attached.

2010-02-11 22:50

 

child_gauges.patch (3,271 bytes)   
Index: code/hud/hudparse.cpp
===================================================================
--- code/hud/hudparse.cpp	(revision 5902)
+++ code/hud/hudparse.cpp	(working copy)
@@ -53,17 +53,17 @@
 	{ NULL,			HUD_VAR(Escort_coords),			"$Escort List:",			486, 206, 865, 330, 0, HUD_VAR(Escort_filename[0]), 0, HUD_VAR(Escort_htext), 0, 0, 0, -1, -1 },
 
 	//Mini-gauges
-	{ &gauges[2],	HUD_VAR(Hud_mini_3digit),		"$Text Base:",				310, 298, 502, 477,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
-	{ &gauges[2],	HUD_VAR(Hud_mini_1digit),		"$Text 1 digit:",			316, 298, 511, 477,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
-//	{ &gauges[2],	HUD_VAR(Hud_mini_2digit),		"$Text 2 digit:",			213, 298, 346, 477,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
-	{ &gauges[2],	HUD_VAR(Hud_mini_2digit),		"$Text 2 digit:",			313, 298, 506, 477,	0, 0, 0, 0, 0, 0, 0, -1, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_htext_coords),	"$Header Text:",			489, 208, 869, 331,			0, 0, 0, 0, 0, 0, 0, -1, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_list),			"$List:",					0, 12, 0, 13,		0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_entry),			"$Ship:",					0, 11, 0, 11,		0, HUD_VAR(Escort_filename[1]), 0, 0, 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_entry_last),		"$Last Ship:",				0, 11, 0, 11,		0, HUD_VAR(Escort_filename[2]), 0, 0, 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_name),			"$Ship Name:",				3, 0, 4, 0,			0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_integrity),		"$Ship Hull:",				128, 0, 116, 0,		0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
-	{ &gauges[5],	HUD_VAR(Escort_status),			"$Ship Status:",			-12, 0, -11, 0,		0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 }
+	{ &gauges[2],	HUD_VAR(Hud_mini_3digit),		"$Text Base:",				310, 298, 502, 477,	0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[2],	HUD_VAR(Hud_mini_1digit),		"$Text 1 digit:",			316, 298, 511, 477,	0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+//	{ &gauges[2],	HUD_VAR(Hud_mini_2digit),		"$Text 2 digit:",			213, 298, 346, 477,	0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[2],	HUD_VAR(Hud_mini_2digit),		"$Text 2 digit:",			313, 298, 506, 477,	0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[6],	HUD_VAR(Escort_htext_coords),	"$Header Text:",			3,  2, 4,  1,	    0, 0, 0, 0, 0, 0, 0, 0,        -1 },
+	{ &gauges[6],	HUD_VAR(Escort_list),			"$List:",					0, 12, 0, 13,		0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[6],	HUD_VAR(Escort_entry),			"$Ship:",					0, 11, 0, 11,		0, HUD_VAR(Escort_filename[1]), 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[6],	HUD_VAR(Escort_entry_last),		"$Last Ship:",				0, 11, 0, 11,		0, HUD_VAR(Escort_filename[2]), 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[6],	HUD_VAR(Escort_name),			"$Ship Name:",				3, 0, 4, 0,			0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[6],	HUD_VAR(Escort_integrity),		"$Ship Hull:",				128, 0, 116, 0,		0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
+	{ &gauges[6],	HUD_VAR(Escort_status),			"$Ship Status:",			-12, 0, -11, 0,		0, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 }
 };
 
 //Number of gauges
@@ -598,8 +598,6 @@
 		required_string("#End");
 	}
 
-	calculate_gauges(&default_hud);
-
 	if(ships_inited)
 	{
 		//Parse main ship gauges
@@ -669,6 +667,8 @@
 		}
 	}
 
+	calculate_gauges(&default_hud);
+
 	// close localization
 	lcl_ext_close();
 }
child_gauges.patch (3,271 bytes)   

KeldorKatarn

2010-02-12 01:04

reporter   ~0011651

Crap sorry. My color inheritance code has a small bug.
Patch attached.

2010-02-12 01:04

 

color_inheritance_bugfix.patch (1,015 bytes)   
Index: code/hud/hudparse.h
===================================================================
--- code/hud/hudparse.h	(revision 5902)
+++ code/hud/hudparse.h	(working copy)
@@ -71,6 +71,8 @@
 	hud_info( )
 		: loaded( false )
 	{
+		int i;
+
 		memset( resolution, 0, sizeof( resolution ) );
 		memset( Player_shield_coords, 0, sizeof( Player_shield_coords ) );
 		memset( Target_shield_coords, 0, sizeof( Target_shield_coords ) );
@@ -102,8 +104,12 @@
 		memset( custom_gauge_frames, 0, sizeof( custom_gauge_frames ) );
 		memset( custom_gauge_text, 0, sizeof( custom_gauge_text ) );
 		memset( custom_gauge_colors, 0, sizeof( custom_gauge_colors ) );
-		memset( custom_gauge_color_parents, 0, sizeof( custom_gauge_color_parents ) );
+		//memset( custom_gauge_color_parents, 0, sizeof( custom_gauge_color_parents ) );
 		memset( custom_gauge_moveflags, 0, sizeof( custom_gauge_moveflags ) );
+
+		for (i = 0; i < MAX_CUSTOM_HUD_GAUGES; ++i) {
+			custom_gauge_color_parents[i] = -1;
+		}
 	}
 } hud_info;
 
color_inheritance_bugfix.patch (1,015 bytes)   

chief1983

2010-02-12 17:40

administrator   ~0011659

Committed in r5908

The_E

2010-12-11 04:29

administrator   ~0012541

Done in antipodes 7.

Issue History

Date Modified Username Field Change
2009-12-20 13:59 KeldorKatarn New Issue
2009-12-20 20:06 chief1983 Relationship added parent of 0001936
2009-12-21 12:32 KeldorKatarn Note Added: 0011454
2009-12-21 15:42 KeldorKatarn Note Added: 0011457
2010-01-17 22:47 chief1983 Description Updated
2010-01-17 23:21 chief1983 Relationship added parent of 0002075
2010-01-17 23:22 chief1983 Relationship added parent of 0002076
2010-01-17 23:23 chief1983 Assigned To => chief1983
2010-01-17 23:23 chief1983 Status new => assigned
2010-01-17 23:23 chief1983 Target Version => 3.6.12 RC1
2010-01-22 08:06 Swifty Note Added: 0011560
2010-01-22 08:08 Swifty Assigned To chief1983 => Swifty
2010-01-30 22:17 KeldorKatarn Note Added: 0011607
2010-01-30 22:17 KeldorKatarn File Added: custom_color_and_panview.patch
2010-02-08 20:15 Swifty Note Added: 0011621
2010-02-08 20:55 KeldorKatarn Note Added: 0011623
2010-02-09 04:38 portej05 Note Added: 0011624
2010-02-10 19:41 KeldorKatarn Note Added: 0011625
2010-02-10 22:56 chief1983 Note Added: 0011626
2010-02-11 04:17 portej05 Note Added: 0011629
2010-02-11 05:39 Backslash Note Added: 0011631
2010-02-11 12:08 KeldorKatarn Note Added: 0011634
2010-02-11 12:22 Tolwyn Note Added: 0011636
2010-02-11 15:30 chief1983 Note Added: 0011638
2010-02-11 15:32 chief1983 Note Edited: 0011638
2010-02-11 15:35 Tolwyn Note Added: 0011639
2010-02-11 15:45 chief1983 Note Added: 0011640
2010-02-11 16:03 KeldorKatarn Note Added: 0011641
2010-02-11 16:06 chief1983 Note Added: 0011642
2010-02-11 16:10 KeldorKatarn Note Added: 0011643
2010-02-11 16:30 chief1983 Note Added: 0011646
2010-02-11 22:50 KeldorKatarn Note Added: 0011649
2010-02-11 22:50 KeldorKatarn File Added: child_gauges.patch
2010-02-12 01:04 KeldorKatarn Note Added: 0011651
2010-02-12 01:04 KeldorKatarn File Added: color_inheritance_bugfix.patch
2010-02-12 17:40 chief1983 Note Added: 0011659
2010-08-05 20:05 chief1983 Target Version 3.6.12 RC1 => 3.7.2
2010-12-11 04:29 The_E Note Added: 0012541
2010-12-11 04:29 The_E Status assigned => resolved
2010-12-11 04:29 The_E Resolution open => fixed