[Horrendous GUI tangent]
originally posted by GrandpaTrout
I know the ENG screen is cramped for space, so feel free to amend as needed.
The only very non-standard thing I'm not sure I can easily lose is some red/green/blue distinctions that signify state information; if you're particularly keen on keeping to yellow, though, I'll think of other ways to show that info. Otherwise, most of the ENG overlay is just a (pretend) list-box -- that can be shrunk to accommodate the new title and footer easily enough, particularly as we're throwing out 640x480 support. I can't make its scrollbar operable, but I've sort of given up on that:D.
I doubt we're going to have much trouble with font standardisation, since there aren't many usable fonts in the game anyway; you might want to think about specifying 'normal button' fonts, whether/when inverse vs normal buttons are preferred, and the like, to keep the feel consistent, but we can probably survive with just a general 'more or less like the original' aim -- the original wasn't particularly consistent about what button styles and fonts meant, anyway.
I tried setting the border colors to change under select, but no effect. What do I need to do?
What I was suggesting for the text colour was this:
Code:
GUI.SetWindowStateColours( button,
0.9,0.9,0.9,
[b]1.0,1.0,1.0,[/b]
0.9,0.9,0.9);
which'll give the button title text a highlight-on-focus effect.
To get the same effect on the border, you'd certainly need SetWindowStateTextures -- SetWindowStateColours applies only to fonts, not to textures; if you want a textured window in shades of grey and white, you'll need a custom iff texture file in those colours (it's so easy to palette-cycle the original GUI elements, even I've managed it). Also, you may (I don't know) have to avoid GUI.CreateBorder() windows altogether if you're modifying the textures -- as you've doubtless gathered, the POG hwindow 'class' seems to hide a bunch of C++ window classes; what POG commands work properly with a window depends on which GUI.Create* command it was originally returned by. Anyway, you might be able to do a highlighting border by making it part of the button itself, rather than a separate border hwindow (these co-ordinates are rough, for which read 'wrong'):
Code:
GUI.SetWindowStateTextures
( exit_button, "texture:/images/gui/gui",
128, 42, 138, 62,
140, 42, 143, 62,
144, 42, 156, 62,
47, 42, 58, 62,
59, 42, 62, 62,
63, 42, 74, 62,
47, 42, 58, 62,
59, 42, 62, 62,
63, 42, 74, 62
);
The drawback is that GUI.SetWindowTextFormatting() has limited options for the positioning of text inside the resulting static window or button -- I've had to resort to two separate CreateButton() or CreateStaticWindow() objects, one for textures, the other for text, to get round that. As a final woe, if you want a custom-coloured border in non-yellow, you may have to create your own texture palette with the requisite squared-off edges, as I can't at a glance see an obvious way to get a border-shaped textured window out of SetWindowStateTextures() with the standard gui palette. Look on the bright side: since it's a standard exit button, it only need be created once!
I have no problem exporting the color settings. I could put in a function that sets windows to the standard colors (pass in a window). Or I can just declare some globals (like the iGUI package) and let anyone use them. Preferences?
My personal preference is for being able to 'eg.SetWindowStateColours(hwindow, egGreen, egFaded, egGreen, egFocused, egGreen, egFocused);' and let the eg.SetWindowStateColours() wrapper worry about converting that to three-part float colour instructions for each state. One enum for state (faded, neutral, focused, selected), another for each standard colour (red, green, blue, yellow, white, black...?), and a single internal function to convert to float components (3 parameters: colour, state, component) is all that needs. A second wrapper (SetStandardStateColours(hwindow)) that just does yellow, neutral/focused/selected, wouldn't be a bad idea. The key drawback of this approach is that it requires a dependency on the package exporting it -- it's so low-level, I can't see that being a problem in practice, but globals are more flexible in that respect.
It's not so easy to simplify SetWindowStateTextures() (which is a bleeding tedious function to use), though you can make colour-shifts a bit easier by having a palette repeat in multiple colours at well-defined offsets within one iff -- I suppose you could even extend that to focused-ness, but since we should mostly be re-using EOC-style GUI elements, I doubt there's a real need. I think Roi Danton's using colour palette-cycled texture palettes with a standard naming convention to get a similar reduction in the need for peering at a zoomed-in iff file for co-ordinates.
Don't know about the spin button idea. If I have to click the button 5 times, that is not much different that hitting buy 5 times. Perhaps a slider is best and replace sell all with sell slider amount. Add a buy slider amount.
You can use an on-hold event and a couple of properties to make a spin button speed up as its held down; I think I prefer the slider, too, though.
[/Horrendous GUI tangent]
FTL comms and Fast LDS. As long as your purchaser will pay sight unseen, he knows your pods are stored in system and he will get ownership. And secondly (for loadout etc) fast lds means that parts and weapons can be quickly transferred while you wait. This will be even more true if we "charge" the player a 30 min wait time for station docking.
I think I get the idea: short-hop pod movement is being done by dedicated craft, maybe even unmanned drones? Are you putting in a nominal storage and/or retrieval fee to reflect that?
the player cannot change the loadout of ships that are not directly nearby. My goals of chessboard are more to limit the actions of player ships without player present. It is my intent to force the player into the front line at every possibility. This is a flight sim first and foremost.
Ok, agreed on that (and a potential problem vanishes -- hurrah!).
I have no problem creating a faction detail screen, and a button to reach it. When do we let the player learn this? I guess we can start off giving it away. Later versions, we could require paying informants or something. Especially for hidden positive relationships. Tricky, tricky.
It is awkward; maybe somehow attach faction feelings to standing, and show them as unknown if standing is too low? Even without complicating the issue by adding multiple levels (such as the public, secure, secret already suggested for geography data), there's enough information that making it intelligible, never mind hiding/revealing it as appropriate, won't be easy.
How do you want to handle the rolling state? Should we release on blockpoints, where we have tried all components together? Say once a week. Otherwise, just release smaller packages with changed only files?
Dunno:). I was thinking roughly that each zip (not package -- that'd get irritating fast without something automated to manage it) be uploaded separately, so a few months along we're all downloading 'EpicFacGUI.zip update 18.3', rather than 'Epic Release 132.9a'. That said, I think you may have a point that only models, textures and sound really need this kind of treatment -- the nature of POG mods is that, even leaving source and headers in, we're unlikely to go over a few megs soon, if ever, so they might as well be bundled together to prevent confusion arising from people accidentally combining incompatible versions of packages.
Oh, dear, longest post ever. I really have to go and do some work...
