[kasperl]

Originally posted by Bobboau
yeah, and wich graphics to use, I think we decided useing a relitive position for every thing would be better (becase we have available non-standard resolutions) so rather than two sets for coordanants for each resolution there would be one set of coordanants that would be between 0.0 and 1.0 (you multiply that by the current resolution to get the actual screen coordanants)

uhm, bob, this sounds pretty nice, but your are gonna auto-resize all the graphics too, right? i can sense some major ugliness on the lower reses otherwise.

[Trivial Psychic]

Hud additions I'd like to see are (as I've said in the past), 1) allowing more space in the escort list, so you can track say 6 ships instead of just 3, 2) space for 3 banks of primaries and 4 banks of secondaries, 3) to go along with the cloak or any other tertiary that needs it... a fourth bar to the ETS, and a consumption bar like you've got for weapons & engines.

Later!

[taylor]

I missed all of the HUD discussions then.  It's obviously been thought out though I guess it's going to wait a little while.  I'll go track down those threads and try to catch up on the conversation.

added options for our new graphical improvements

I'm willing to start work on an additional screen here if somebody has a list of options to start with.  Artwork can wait for now since a lot could probably be reused.

the tertiary loadout screen is to have the first list

That's a good idea, screen real estate here and on the HUD are pretty tight.  This would solve weapon loadout but the HUD is a little different.  A quick look at a 640x480 screen and I think that if the countermeasure count is moved then 3 primary and 4 secondary weapons would work.  Auto Target/Speed would move down and the cm guage would be level with the ETS guage.  Fourth ETS guage shouldn't be a problem.  A third consumption bar would fit on the inside the weapon one.  Not sure about the expanded escort list though, space would be a real issue on 640x480 because of the comm window.

[kasperl]

IMHO: coders, don't design the HUD, put the whole thing in a table instead of Hardcoding the entire thing. that way your talents can be used doing more important things, and every campaign/user/ship can make their own decisions.

[Bobboau]

also we wanted an ability to select diferent countermeasures (forgot about that one, would be yet another scrolling list thing)

as for graphical options, we wanted to have graphical controle over, I think the assorted lighting effects (specular and ambient,  we wanted a seperate slider for each), I will want one  (after 3.6) for subdivision (trueform) and decals, there were a  bunch of others I can't think of at the moment.

[taylor]

IMHO: coders, don't design the HUD

I deffinitely agree with you here.  The point of moving to a table format is so that only the person designing the new HUD has to worry about how it works.  My only concern is changes that would adversely effect the OC.  The expanded escort list falls into this catergory, unless an option is added that mission designers will have to use to get something other than the default value.  Somebody else can think about that though, my only real project at the moment is knocking about 750K of crap off the *nix patch.

the assorted lighting effects (specular and ambient, we wanted a seperate slider for each)

specular_exponent_value & Cmdline_ambient_factor?  I take it these are cmdline only and not stored values (ie. saved to the pilot file)?  This is a good bit more than ui work so it would probably be a good idea for everyone to decide which ones should be a ui setting and which should remain a cmdline setting.  The pilot file version is going to have to be bumped for the values that get stored and old pilot files upgraded so it would be best to not do this too much.  This would also break backwards compatibilty and it gets to be a pain to keep stuff working on multiple pilot file changes.  I've already got to do it for icculus.org FS1 and now PPC support on both projects so can I speak from experience.