Code Release

[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: 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'): 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...

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.

Nooooo. I like the Eng Screen just as it is. Packed with Engineering Data in multiple colors.

I have no problem with added color highlights. If you just get the title bar in green, that would be enough!

Thanks for the GUI Info! I admit I have only learned the very basics.

Button Text high light change is no problem. I think I will save the second. At the rate I am currently hitting brick walls (adding new factions is crashing my game today, ack!) I feel double the need to proof out all the main game concepts, and then return for polish. To many blind traps when we don't have the source.

I will look into adding the color setting features to EpicGui. (Actually, why don't I just give that file over to you? When it works as you like, I will change my code to make use of it.)

A tangent of my own here: How complex can the window textures be? I have been thinking about a mining simulation that has a "sonar" depth finder feature. It shows you the stuff below your mining drill before you spend funds cutting. But only relative rock hardness. I would need a few textures for say 5 hardness levels. Is this possible? How are texture coords calculated? Are they just x and y index? From top left edge of the image?

I think I prefer the slider, too, though.

They use this exact approach in FreeLancer. Works quite well.

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.

I had a few new ideas on this topic. From a gameplay goal, I am trying to keep the player from knowing that Maas is funding the Marauders, buy just looking at the faction screen. But we want the player to be able to know that Emerald and the CMC are currently fighting. The simplest solution I can think of is to make some organizations 'secret'. Those that have very low public profiles. The player can still see how that faction relates to the player (so he knows if he will be attacked), but secret factions never show up on the faction detail screen.

Later, it can be a special power of informers to remove the 'secret' cover. If you can find this factions base and plant someone, you can learn who they like and hate.

The implementation is a simple boolean global attached to factions we want extra hidden. Simple enough.

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?

I was thinking of charging a small fee for every stored pod. Another reason to encourage the player to keep pods in the world (where others can steal them). No code for that yet.

-Gtrout

originally posted by GrandpaTrout
A tangent of my own here: How complex can the window textures be? I have been thinking about a mining simulation that has a "sonar" depth finder feature. It shows you the stuff below your mining drill before you spend funds cutting. But only relative rock hardness. I would need a few textures for say 5 hardness levels. Is this possible?

Buttons and static windows mostly do a pretty decent job of displaying anything you can put in a 256x256 iff. I haven't tried putting any large images on buttons yet, so there may be flakiness there I haven't encountered. The texture you pass in is automatically scaled to match the button size: this can be a good thing, in that it means you don't have to be dead precise, but the scaling is sometimes on the touchy side -- in particular, it tends to lose edges when scaling down; scaling up is more reliable. If you just have a very specific small image you want displayed, it's best to match the button size to the source texture to keep things simple.

In principle, you could use successive SetWindowStateTextures() calls against a single object to do animation -- I assume this is how the colour-cycling on the 'LOADING' progress bar is done. Just resetting the textures seems to create significantly less overhead than destroying and recreating window objects.

How are texture coords calculated? Are they just x and y index? From top left edge of the image?

Yep, they're all x or y offsets starting from 0,0 (as displayed by most paint programs, handily). Each state (neutral, focused, selected -- though selected is rarely relevant unless you're in a list box) has three textures (left, middle and right); each texture is passed in as a pair of x,y offsets, the first indicating the top-left corner, the second the bottom-right. The left and right textures are used once, at each end of the window, and the middle texture repeats across the intervening length. You can omit the left and/or right sections (just pass in their co-ordinates as zero) if you don't need them. You can safely reverse top/bottom co-ordinates to flip textures vertically; not sure if I've ever tried the same for left/right.

I have updated the Middle States cluster geography. The prior version only had Casino stations. These should all be the correct station type from the Geography document

This version also renames all of the factions to match the proper Middle States faction. So all the stations should also have a correct faction name.

Oh, and the planets should be round, and not egg shaped.

Enjoy your new home!

www.i-war2.com/epic/files/MiddleStates2.0.zip

I do have some bad news to report: We are limited to 54 total factions. If I create more, it crashes the game. It looks like 54 was hard coded in somewhere. 54 might sound like a lot but that is only two factions per system. Our current faction list squeezed in with just one extra to spare. And this does not include random pirate factions, smaller corporations, and political parties, or pilots unions.

Perhaps some day I will find a work around.

-Gtrout

Our current faction list squeezed in with just one extra to spare. And this does not include random pirate factions, smaller corporations, and political parties, or pilots unions.

The player has to be listed as a faction. Is that correct? And the Navy faction did not appear on some of my material. Has it been included?

No confusion; just wrong or right ... Only Solutions

Yes, the player will show up as Mercenary. Until the new player name goes public. There is not exactly a Navy faction. There is the Emerald Alliance Navy. And the Empire Navy. The CDF and CMC Security. And Each Caliph has a navy. And the Royal Guard... You get the picture.

The reputation code handles this by holding a list of factions that form the police force of each system. Some systems have none. You can always escape a navy by fleeing to another area. I wanted a police faction for each major nation, but there is not enough faction spaces open for that. Here is one case where the source would be worth having. Such a small but key limitation. Well, if wishes were horses, beggers would ride.

For a full list of factions look in the middle states zip file in directory TEXT/faction_names.csv Everything is listed there.

-Gtrout