Code Release

Umkay, well all that works now is the save/load subscreen, and all the other screens dont even show up, also, if i save and launch again, instead of the tug i had before, i have the command section, also, in the base subscreen i have absolutely nothing i am able to do but save and load. I likes the last revision better, it actually worked.

___________________
Epic Modeller - Buda5 Modeller

The Man with the really big ship, aka the Columbia Class Super Danube

'Wow' doesn't really cut it, but it's about the best I can muster over this medium. I've barely scratched the surface of what's in here, but I like it so far.

The GUI standardisation is an excellent idea (will retro-fit it on the ENG screen asap, and use for loadout interface). What are your thoughts on colour? I take it from the examples here the original yellows are staying, with the green and white exceptions in the EpicGUI package standard throughout. I'm fairly keen on sticking with yellow unless there's a pressing reason not to, but if you're intending to allow non-yellow in some contexts, it might be worth exporting another function so a handful of standard colours can be referred to by name and focused-ness, rather than floats (I've got something like this in flm_ut, which I can modify for inclusion in EpicGUI if you want it).

The only change to the standard elements I'd suggest off-hand is a distinct focused colour on the exit button text (1.0,1.0,1.0 might do), and a similar highlight-on-focus for its border, if you can be bothered to fiddle with the state textures.

Initial thoughts on a couple of elements:

Cargo Comp:

The cargo list is a bit overwhelming. Subheadings might be awkward to do well; maybe split into two lists, the upper one a list of categories that can be applied as filters? Filters to show only what a station sells, only what it buys, and only what the player has stored (or nearby) would also be helpful.

'Sell All' is a nice idea, but it'd be more helpful if the listed sell price also showed (in parens?) what the 'sell all' price will be, for the arithmetic-impaired among us.

For cargo that's likely to be moved in bulk, a 'multi-buy' button of some sort would be useful. Maybe add a standalone integer spin-box or slider control, and apply its value to both 'buy' and 'sell' transactions? Total nit-pick: the '$' character in PS's font looks a bit manky; also, although US$ will probably be the galactic currency in a couple of centuries, the symbol seems a little incongruous to me -- something more neutral might be preferable ('C', 'XAU', just drop it altogether...).

Thinking along 'it isn't a Frontier total conversion, honest' lines, a feature allowing the player to retrieve a current price list remotely from a known station in the current system (using special equipment and/or a per-use charge) might help with buying decisions. I wouldn't personally go as far as X-Tension's 'best price' functions, since I like to feel I have at least some input into in-game decisions, but others might like it.

Am I correctly understanding that, once you've 'stored' a nearby pod (converted it to inventory), you can 'unload' it (turn it back into a pod) from anywhere in that system? This makes sense from a gameplay and coding point of view, but what's the 'realistic' justification?

Question for loadout: assuming it can work from nearby pods or inventory interchangeably, am I looking for iInventory.NumberOfCargoType(<type>) + tPodUtil.NumberOfCargoType(<loadout ship>, <type>, 10.0, 0)? If this is how it's supposed to work, could you make tPodUtil.RemoveType return a count of how many pods it successfully destroyed? I'd then destroy nearby pods first, and fall back to iInventory calls if they run out.

Also, just to be a total pain: if (and it's quite an if) it proves possible to model significant activity in non-current systems, how do we cope with the possibility that the player might want to change the loadout of a player-faction ship in a neighbouring system? At the moment, it looks like tSysInventory is providing a nice transparent way of handling localised inventory through iInventory calls for the current system, but I can't see any way (short of checking g_trout_sys_inv_save_<system>_<type> myself, which may actually be the right solution) to check other systems. May not be worth worrying much about this for now, as it's pretty hypothetical.

Reputation screen:

Nitpicks: Should 'Heroic' be 'Heroism' for consistency (or 'Infamy' 'Infamous', etc)? And 'Renoun' is spelt 'Renown'. I'm seeing slight graphical corruption (at 800x600, GF2) at the left and right edges of the reputation summary slider borders on the right-hand shady bar -- do they need to be a bit taller? Finally, I think the highlights on the list boxes should probably be disabled.

It'd be nice if factions' known relationships to one another, as well as to the player, could be displayed on this screen; is that what the currently unused lower part of the left-hand shady bar is reserved for?

On faction relation damage varying according to severity of aggression: I like the concept a lot, but that's easy to say when you're not the one who has to detect it -- I know it's hard enough just accurately determining what damage the player's been doing to whom. I do think operating a 'no survivors' policy ought actually to minimise the impact on reputation: it's not a pleasant thought, but it does make sense, unless something unique to the situation means no-one but the player could've been responsible, and I shudder to think how you'd detect that. There'd have to be some way for it to go wrong, otherwise there's no deterrent. Just brainstorming: maybe most destroyed craft eject very low-brightness escape pods (invisible outside ~10km) that head straight for the nearest safe port? Achieving a 'no survivors' outcome would still be possible, but quite difficult -- try and fail, with even one witness, and you'll be wanting to leave the system in a hurry.

If you don't see any obvious problems with it, could you include your c:/pog/include/ files in a later (or separate) release (particularly tEconCargoTypes, which we could possibly start using as a standard replacement for CargoTypes about now; couldn't see it in the current files, though I may not've looked hard enough).

Assuming we've space (probably not a major issue until sound and texture files start bulking it up), what does everyone think of putting a rolling copy of the Epic 'mods' directory on the site? CVS is probably overkill with so few people working on it, but something like this would save us neolithic 56k'ers downloading the whole thing for every update, and it might be generally helpful to have an agreed reference point for the current state of the mod.

Idle curiosity: what're all them 'STR_' things -- are you using a preprocessor?

Just a few quick comments before I crash for the night:

well all that works now is the save/load subscreen

Darn it! I have to stop and automate my build procedure. Grrrr. I will back up the thread to the prior version. Tomorrow nights revision will be fixed and have the Middle States cluster geography included.

The GUI standardisation is an excellent idea (will retro-fit it on the ENG screen asap

I know the ENG screen is cramped for space, so feel free to amend as needed. The key color elements were to put a strong green stripe (title) at the top, and a white stripe above and below (text). Otherwise I am sticking with yellow. This way we get a "not just the same old EOC" feel, but don't take a wild deviation that says we are in Buda5 world or somewhere equally distant.

I will have questions on GUI tomorrow. And a more complete response. G'Night.

-Gtrout

The only change to the standard elements I'd suggest off-hand is a distinct focused colour on the exit button text (1.0,1.0,1.0 might do), and a similar highlight-on-focus for its border, if you can be bothered to fiddle with the state textures.

I tried setting the border colors to change under select, but no effect. What do I need to do?

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?

I agree on adding the filters to the cargo screen. And glad to change the credit marker. Not sure how to do the remote pricing list. Need to think about that (it would be nice to be able to look at own inventory in the current system whenever you wanted, could do something...). 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.

Am I correctly understanding that, once you've 'stored' a nearby pod (converted it to inventory), you can 'unload' it (turn it back into a pod) from anywhere in that system? This makes sense from a gameplay and coding point of view, but what's the 'realistic' justification?

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.

the player might want to change the loadout of a player-faction ship in a neighbouring system?

I have a few preferences on how loadout should work:
1. The player must be near a station that can handle the loadout task. A shipyard, repair station, service depot, navy yard. Any ship to have loadout changed must be within 10km of the same station. (we could even launch a flurry of drones to simulate the reload, but that is unneeded eye candy).
2. It would be nice to reload at a "supply ship", so make it possible to use a sim as the center of the 10km, not just a station. I put a special marker property on trade ships for the cargo screen.

This means 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.

It'd be nice if factions' known relationships to one another, as well as to the player, could be displayed on this screen; is that what the currently unused lower part of the left-hand shady bar is reserved for?

It would be nice. It is also key information that I would like the player to have to collect. 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.

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?

We will need to break out things like backgrounds, models, and sound.

Models alone just forced me to become a DSL user.

-Gtrout

Code Release Two

Starts the player in the new Middle States Cluster. Otherwise only a few small bug fixes.

www.i-war2.com/epic/files/CodeReleaseTwo_a.zip

Note:

This is a cluster prototype. All the stations are casino stations and they are all junker factions. The planets have randomized diameters and textures, but the colors are all the same. (need someone to work over planet textures). But there is enough here to see get a feel for the structure of the cluster, plan background images, station locations, and consider geography changes.

Hot4Darmat: Nice job on the Geog document. After spending hours with it in detail, it repays the effort.

-Gtrout

Downloaded, ill play a bit with it tomorrow, see if i can stumble across any bugs, like usual. Ill be gone from this Thursday till march 8 or something, going to Florida, but i hope to have something with the SD to show before then, mabye some more picts with as many of the textures as i have done in it.

___________________
Epic Modeller - Buda5 Modeller

The Man with the really big ship, aka the Columbia Class Super Danube