[Zacam]

So, to expand upon the title and to layout the ground work on this little competition, this is a little idea I had in IRC after I unsucessfully tried to re-save the hud gauges calculator spreadsheets from XLS to ODS, only to not have it work out so well. It would also handily address the additional complication of "why do we need 2 spreadsheets?".

The idea is this: Code the (cross platform) framework (and preferably a consistent UI) in whatever strikes your fancy or skill. It must operate similarly to the spread sheets in that you can choose between an FS1 HUD and an FS2 HUD, input your desired resolution and have an output tab (You can either then copy/paste from that tab, or actually have it write out the generated contents in a file automagically).

Must be able to handle Triple-head resolutions as well.

But wait, we're not quite done. That would be too easy I think. It must also be able to acknowledge that custom layouts will exist as well that a mod may want to provide numerous resolutions for that won't be in alignment with either FS1 or FS2. So, it must also be able to parse in a single resolution custom hud gauges table/tbm and from that, be able to generate output for that hud layout at the specified resolution (or resolutions).

I highly recommend giving the spread sheets a look over, and any credits that you post for your application should give mention of them and their author Kolgena and contributor Fury (or maybe I have those the other way around, but in any case, a good mention for both of them is mandatory) and if desired, an obligatory mention of myself.

In case nobody has them, I've duplicated them here: FS-HudCalcs-xlsx-v2.7z

[Zacam]

So, a bump and title change. Since I can't really declare a competition without a reward, I'll make it a Suggestion/Request.

Would really like to hear some feedback on the idea or that somebody finds it an interesting enough challenge to have some ideas.

[JGZinv]

All I can say is that the number one problem I have with creating a completely custom HUD as is now, besides feature/mod specific stuff,
is the documentation on the wiki last I looked was either incomplete or read sort of like a soviet submarine manual (IE tells you very little
about how to get a desired result, just states "this value is a float" etc etc etc).

Having built in links to pages on the wiki, and possibly examples of non FS related HUD designs (particularly custom gauges that have been created) may help spur more HUD development.
This could be in a Help button pop up perhaps, in the proposed application.

[FreeSpaceFreak]

It must also be able to acknowledge that custom layouts will exist as well that a mod may want to provide numerous resolutions for that won't be in alignment with either FS1 or FS2. So, it must also be able to parse in a single resolution custom hud gauges table/tbm and from that, be able to generate output for that hud layout at the specified resolution (or resolutions).

The spreadsheets, too, have limited ability to cope with custom HUD layouts... try setting the wingman display on the left of the screen, for instance (enter 5 instead of 932), see what comes out. So just copying the arithmetic from there won't do the trick. But then how should it work?

The most obvious solution for fully flexible customized layouts would be to just scale the centre position of each gauge to fit the screen. But then the issue is that the gauges themselves do not scale. They shouldn't, too, but it complicates the math. Some things are supposed to line up (the threat indicators on the reticle, for instance), which won't be preserved with simple scaling. In addition, there would probably be gauges all over the screen, since 'closely spaced' at 1024x768 becomes a long way out at 1920x1080 (notice the difference between the in-game HUD config screen, crammed full of gauges, and the actual in-game HUD which is much more spacious).

So then it's back to "scaling by group", pretty much like the spreadsheets currently do it, but in a more flexible way. In the table to be parsed, there would need to be some indication (probably in a comment after each gauge) of which group a gauge belongs to, the centre point of the group would be calculated and then scaled. The X and Y offset of the gauge would remain constant wrt the group centre. This way, spacing is only introduced between the groups, and lined-up gauges remain lined up (if they're in the same group, obviously).

Thoughts, ideas, criticism?

[Zacam]

Well, I was thinking that maybe a utilization of the Contemplates code path could be used to give people the ability to create in a WYSIWYG environment.

Say, start them with a 640x480 or something rendering/manipulation window. Select/load/define your element gauges which it places in "default" positions. You move them around (and/or hide/show them) and when you are satisfied, you "lock" it and "generate" size/resolution scaled placements based on where you put things.

This way you get your placement of where you want things to be generated as the baseline, which then can be used to set them to the defined resolutions to where you want them placed. Maybe even a preview function (possibly in "scaled" zoom & pan-able mode for the larger resolutions) where you can double check and correct any drift on a per resolution basis.

Then, you hit "Finalize" which dumps it all out into a usable TBM file.