Recent Posts

Pages: [1] 2 3 ... 10
Ah, a button list that could provide background-less pseudo-buttons would be fine. Mouseover text is fine. Speaking of mouseover, it's not in yet, right?
Private Alpha Discussion / Re: Proposed "Find Planet" screen
« Last post by x4000 on Today at 09:32:37 AM »
At the rate BadgerBadger is going, you are going to have to add him to the credits as an assistant/volunteer coder or something like that. So far I have seen BadgerBadger code some new map types, though I don't know if they will be in the base game, added the ability to name save games, and now this.

No kidding!
Private Alpha Discussion / Re: Proposed Save Game Update
« Last post by x4000 on Today at 09:32:05 AM »
Generally speaking, I'd suggest a few changes, but that's the general idea.  Notes:

1. Bear in mind that on Windows and I think also OSX the file path limit is once again 256 characters.  They changed this back sometime in the last couple of years because it allows for faster file lookups.  To me that's just asking for trouble, because I remember well what FAT32 was like, but still.  So keeping everything as brief as possible is good.

2. Additionally, not using period as a separator is good, because that's going to change the type of file that many OSes see it as -- depends on the config.

3. I'd use an initial separator to split the thing into two parts -- the player's part, and then the metadata part.  Something brief, in ASCII, that wouldn't be otherwise be present in a filename.  I'd suggest a mult-character thing like ~# as the thing.  That combination is unlikely to be in someone's filename in that order.

4. So at this point you have mySave~#<datahere>.save.

5. When it comes to the data, it needs to be brief as can be thanks to the aforementioned filesystem limits.  That means no identifies, for one, and for two having a single-character separator for items in the list.  Then doing a split operation on that metadata string using that single character, and getting the results by index in the resulting array.  So for instance,

6. When it comes to the metadata itself, it's then a matter of trying to compress it as much as possible into as few characters as possible. 

- So for instance, rather than writing out Clusters in the first index as the map type, having little abbreviations like CL or whatever would be good. 

- If you have a number that will always be less than 256 in value but might be more than 9, then cast that to a char and just append that instead (though there are some special characters for various OSes, and those create enough landmines that they wouldn't be a good idea in a filename.  Inside a file it's fine, but you can't use something like * in a filename on windows, and on certain other OSes, too.)  Then cast back from the char to an int to get the data back later.  You then always use one character for those numbers rather than 1-3.  Savings!

- If it's always going to be 9 or fewer, then just put the number.  For a bool, use a 0 or 1 rather than writing out the text.  Etc.
AI War II / Re: Updates 6/20: Mr. Hammond, the phones are working.:)
« Last post by x4000 on Today at 09:19:20 AM »
Technically that could be done simply by creating a new prefab buttonlist with a new button assigned into it that just doesn't have any background, etc.  It's extraordinarily flexible.  It would still catch mouseover and such, which is the only downside -- if that isn't desirable, then another control could be created.

But yes, there are other controls we plan on, in general.  There's some table-based stuff that we have in the source code but not hooked up that does some pretty advanced stuff.
AI War II / Re: Updates 6/20: Mr. Hammond, the phones are working.:)
« Last post by BadgerBadger on Yesterday at 10:04:05 PM »
Speaking of the GUI, I'm wondering if there are plans for additional GUI elements. I am going to wish upon a star and ask if there's a possiblity to get some text whose location and content can be set in C# code like the buttons in a buttonset. Specifically I'm looking for the ability to have a variable number of buttons appear (this can be done right now with a ButtonSet), but with text labels associated with the buttons. The problem now is I don't see any obvious way to do that with BasicText, since for me the location and number of the buttons isn't determined until the code runs, so hard coding the locations in KDL_UIWindows.xml seems hard. I could try coding every location possible for the text labels and then try to set them in C#, but that seems fraught with peril.

I'd be fine to have just something that looks "slightly less like a button or a bit different" and isn't clickable rather than BasicText.

I know y'all are limited in what you can do given everything else on Arcen's plate, but I figure I'll ask!
Private Alpha Discussion / Re: Proposed Save Game Update
« Last post by BadgerBadger on Yesterday at 12:09:22 PM »
So my file name would be "mySave.METADATA:<fields here>.save" or something to that effect? I considered doing something similar with Extended Attributes, but didn't want to try to use those cross platforms (and I'm not sure if all file systems support them). If anyone wants to look at the file names they will be a bit messy, but that said I really like the idea.

I'll figure out how to extract the necessary information (I think most of that data is in the World_AIW2.Instance , or a member of that object, like World_AIW2.Instance.Setup.MapType.InternalName) and give this a try later.
Private Alpha Discussion / Re: Proposed Save Game Update
« Last post by x4000 on Yesterday at 11:41:31 AM »
My suggestion is to encode that into the name of the savegame itself, not into the file data.  Then when showing savegames, cut off the metadata and just show the user-entered data.  The metadata is thus incredibly fast to read, and can be based off of abbreviations for map types, etc.
Private Alpha Discussion / Re: Proposed Save Game Update
« Last post by BadgerBadger on Yesterday at 11:00:56 AM »
Yeah, I don't think a picture is really optimal.

 I'm trying to come up with a better UI mechanism for organizing save games. I think it would be cool to present the user with blocks of saved games, saying "These are your saved games from a Cluster Map, seed XXX, AI difficulty YYY", then show all those saved games, then a new block of saved games. Then organize each block by wall clock time. This way the user gets much more useful information about their saved games, and there's no need to alter the information being saved, we just need to run a few read operations and then present stuff to the user. It's possible that if a user has hundreds and hundreds of save files this might be a bit of a performance overhead depending on how costly the "Read save game" function is, but that would require experimentation to check on.

Example: lets say I saved games from X active campaigns. I'm imagining presenting the user with X separate columns of saved games (sorted by wall clock time), with text over each one saying which campaign it was. Then it would sort the columns by wall clock time, so I would always know which campaign I've been working on most recently.

The information I'm interested in is stuff that hopefully can't change (one does not change map type or game seed mid game), and I'd be trying to only do read operations, so hopefully I would be unable to corrupt things.
Private Alpha Discussion / Re: Proposed Save Game Update
« Last post by x4000 on Yesterday at 10:29:33 AM »
We use a really specific sort of character buffer that Keith created, so it's not quite just a comma-separated list, though that's certainly a big part of it.  Ints and floats and so forth are stored with pretty different sorts of data from what a pure text file would do.  There are serialization and deserialization classes that you can call, but one of the key tenets of them is that no metadata is stored and so you have to know exactly what order to pull things out in, and if anything is even slightly out of place then the entire file is unreadable.  This is a very efficient way of storing the data, because metadata about what each piece of data is is incredibly space-consuming when you're talking about that much data.

Granted, having some sort of "header area" that works differently would in theory be possible, but that's something Keith would have to come up with and make a callback for.  That's worth a mantis request, for basically being able to insert arbitrary data in a certain subsection of the start of the savegame.  A centrally-controlled callback for then passing you that data back as a string (or something) would then be something he'd need to create.  The balance between efficiency and usability-for-modders is something he'd need to carefully engineer, so it's not a quick thing (unless it is, heh).

The other point I'd like to make in general is that including things like screenshot thumbnails is in general not a great idea in my opinion.  To do a screenshot requires a screenshot to be taken (of course), which in itself is a pretty sizeable hitch in unity, and then you need to scale that down, which requires System.Drawing to work properly, and that creates a lot of garbage as well as more data.  You then have to encode the data in some fashion, whether that's jpeg or png or whatnot, to make it not absolutely monstrous in size in the savegame itself.  Embedding that isn't a problem, but the amount of a visual hitch you introduce any time there's an autosave is going to be notable.

If you're trying to get a screenshot of a specific thing (like the galaxy map), then you first have to switch the game to viewing that at the correct zoom, let it sit for at least one frame, then take a screenshot, then return everything to the way it was before you did that.  Think of it like photography.  I can't photograph the layout of your house without going to your house, taking off the roof, renting a helicopter, and actually taking the photo.  Then I need to put the house back together, return the helicopter, go back to whatever I was doing before, and probably explain myself to you and the police. ;)

There are some ways that we could make things like that easier if we wanted to, but there are a lot of complexities with that having to do with bounding boxes, field of view, offscreen cameras, and object active/inactive states.  It would get rid of the worst of the "now we have to put things back" problem, but it would still cause a visual hiccup as well as a literal flash of some other part of the game.  There are STILL other ways around that, but then we're talking offscreen cameras and render buffers and such... and that certainly would be more tractable and could avoid the visual hitching, etc.    But you run into that potentially taking a week or more to figure out all the details of.

And at the end you have a tiny screenshot that probably looks pretty much like all the other screenshots, and the load game scene loads really slowly because of having to extract all that metadata, convert it to jpeg, then convert it to the unity Image format with DTX1 or DXT5 compression, and so on.  That part would be wiiiiicked slow.

Anyhow, metadata is a lot easier to handle than the screenshots bit. ;)  Usually for screenshots it's easier if the screenshot is saved next to the savegame as its own file, and if you don't have too many savegames.  I did this in Shattered Haven, for instance.  It worked well there, partly because there was no autosave, but also because each screen was visually pretty different.
AI War II / Re: Updates 6/20: Mr. Hammond, the phones are working.:)
« Last post by x4000 on Yesterday at 10:13:28 AM »
Cheers, thanks.

In terms of the GUI, I have no direct information on that; that's a Keith thing.  As soon as he's done with the current batch of ships, then he's going to be focusing on usability/playability/fun/balance in general, of which the GUI is a huge part.  Blue obviously will be involved with that a lot as well from an artistic standpoint, but there's just a lot that needs to be done in general to make things functional there.
Pages: [1] 2 3 ... 10