Source Code Project Mantis - FSSCP
View Issue Details
0002071FSSCPHUDpublic2009-12-20 08:592010-12-10 23:29
Assigned ToSwifty 
PlatformIBM PCOSMS WindowsOS VersionVista SP2
Product Version3.6.11 
Target Version3.7.2Fixed in Version 
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.
parent of 0001936resolved Swifty Per ship custom gauge entries in hud_gauges.tbl do not seem to work 
parent of 0002075closed Swifty Possibility for custom gauges to inherit color of a main gauge 
parent of 0002076resolved Swifty Possibility to specify for custom and tbl-customizable gauges move in pan view or remain static 
Attached Filespatch custom_color_and_panview.patch (15,362) 2010-01-30 17:17
patch child_gauges.patch (3,271) 2010-02-11 17:50
patch color_inheritance_bugfix.patch (1,015) 2010-02-11 20:04

2009-12-21 07:32   
I opened the two remaining children tickets:

2009-12-21 10:42   
As a parent ticket, I guess this should be put into the 3.6.12 roadmap instead it's child.
2010-01-22 03:06   
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.
2010-01-30 17:17   
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-02-08 15:15   
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. :(
2010-02-08 15:55   
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!
2010-02-08 23:38   
KK: Cheers, we'll let you know when the changes come through.
2010-02-10 14:41   
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.
2010-02-10 17:56   
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.
2010-02-10 23:17   
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.
2010-02-11 00:39   
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.
2010-02-11 07:08   
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??
2010-02-11 07:22   
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.
2010-02-11 10:30   
(Last edited: 2010-02-11 10: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.

2010-02-11 10:35   
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.
2010-02-11 10:45   
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.
2010-02-11 11:03   
The code patch file is already attached since 2010-01-30
2010-02-11 11:06   
Ah, so it is. Was thinking it would be on the child tickets, never thought to look here.
2010-02-11 11:10   
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.
2010-02-11 11:30   
Committed in 5901.
2010-02-11 17:50   
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 20:04   
Crap sorry. My color inheritance code has a small bug.
Patch attached.
2010-02-12 12:40   
Committed in r5908
2010-12-10 23:29   
Done in antipodes 7.

Issue History
2009-12-20 08:59KeldorKatarnNew Issue
2009-12-20 15:06chief1983Relationship addedparent of 0001936
2009-12-21 07:32KeldorKatarnNote Added: 0011454
2009-12-21 10:42KeldorKatarnNote Added: 0011457
2010-01-17 17:47chief1983Description Updated
2010-01-17 18:21chief1983Relationship addedparent of 0002075
2010-01-17 18:22chief1983Relationship addedparent of 0002076
2010-01-17 18:23chief1983Assigned To => chief1983
2010-01-17 18:23chief1983Statusnew => assigned
2010-01-17 18:23chief1983Target Version => 3.6.12 RC1
2010-01-22 03:06SwiftyNote Added: 0011560
2010-01-22 03:08SwiftyAssigned Tochief1983 => Swifty
2010-01-30 17:17KeldorKatarnNote Added: 0011607
2010-01-30 17:17KeldorKatarnFile Added: custom_color_and_panview.patch
2010-02-08 15:15SwiftyNote Added: 0011621
2010-02-08 15:55KeldorKatarnNote Added: 0011623
2010-02-08 23:38portej05Note Added: 0011624
2010-02-10 14:41KeldorKatarnNote Added: 0011625
2010-02-10 17:56chief1983Note Added: 0011626
2010-02-10 23:17portej05Note Added: 0011629
2010-02-11 00:39BackslashNote Added: 0011631
2010-02-11 07:08KeldorKatarnNote Added: 0011634
2010-02-11 07:22TolwynNote Added: 0011636
2010-02-11 10:30chief1983Note Added: 0011638
2010-02-11 10:32chief1983Note Edited: 0011638
2010-02-11 10:35TolwynNote Added: 0011639
2010-02-11 10:45chief1983Note Added: 0011640
2010-02-11 11:03KeldorKatarnNote Added: 0011641
2010-02-11 11:06chief1983Note Added: 0011642
2010-02-11 11:10KeldorKatarnNote Added: 0011643
2010-02-11 11:30chief1983Note Added: 0011646
2010-02-11 17:50KeldorKatarnNote Added: 0011649
2010-02-11 17:50KeldorKatarnFile Added: child_gauges.patch
2010-02-11 20:04KeldorKatarnNote Added: 0011651
2010-02-11 20:04KeldorKatarnFile Added: color_inheritance_bugfix.patch
2010-02-12 12:40chief1983Note Added: 0011659
2010-08-05 16:05chief1983Target Version3.6.12 RC1 => 3.7.2
2010-12-10 23:29The_ENote Added: 0012541
2010-12-10 23:29The_EStatusassigned => resolved
2010-12-10 23:29The_EResolutionopen => fixed