Print

[geniusalz]

I figured scripting has just about everything needed to make a gamesave manager, so I'm starting work on that.

Will need support for the following though:
Reporting what controller/port a memory card "drive" corresponds to.
An explanation of how memcard drive letters are formed.  If that's done already, please post a link .


Displaying xbx images, and reading values from ini files can be done already, and that's about all that's needed for the manager.


And mastermind is almost playable now.

Edit: Finding the AS manual pretty helpful  

[BenJeremy]

Oh, that's a nasty question. Really. (Not your faults, though, it's M$' fault!!)

Drive letters for memory cards are fixed. I had to patch my libraries to make it work right, since the first two memory card slots are "F:" and "G:" (See my problem?) - so for MXM, the letters are bumped up by two. It's based strictly on position, and from a programming standpoint, there is no way to map device paths (like the partitions on the hard drive), so there's no obvious way to run apps from a memory card, either.

Simply moving a card from one slot to another, and refreshing the root drive list in FlashFXP while running MXM will give you a good idea of how they are mapped.




 <

[geniusalz]

I was thinking of trying it myself, but couldn't find my damn memory card.

As for the gamesave manager, I'm using the xml structure from filemanager; works very nicely, flattspott.

MXM had some trouble loading a few xbx images.  It waits a few seconds, then probably 'times out' and doesn't load the image.  This causes long loading times for the script.

If you want, I can post the 'misbehaving' images for you to look at. (that sentence sounds bad )

Edit: Alternately, for now, you could just reduce the 'timeout', so it wouldn't take that long to load.

[BenJeremy]

Well, I'll revamp the routine altogether soon. It will use the Avalaunch method first, then fall back to the XBX search.  <

[geniusalz]

The "walking the xbe" method?

If so, I'm not talking about xbe's here, I'm talking about the TitleImage.xbx files found in E:\UData\*

Anyway, the ones that don't load are in "DDS" format, as opposed to "XPR0" (it says that in the beginning of the file, when viewed in a hex editor).  That might be the problem  <

[koldfuzion]

MXM handles DDS though. (my preferred overlay format.)
 <

[geniusalz]

Yeah, I know.

It's probably just the way it's packed in the xbx, or that MXM doesn't look for DDS in xbx.

Anyway, some gamesaves don't contain a gameid.ini file, causing me insane amounts of grief.  Instead, they store the title in "TitleMeta.xbx", which is in unicode format.  

Being unicode, every other char is 0, which causes MXM to think the string terminated.  Therefore, only the first char of every line is read using the normal file read routines.

I managed to get the titles of a few games that have TitleName=whatever right at the beginning of the file (using buffers), but some other games have multiple languages defined in the xbx file, which requires more work *sigh*

BJ, can you add a simple AS command that reads a unicode file, converting it to ASCII, or write a custom routine to read the title from those TitleMeta.xbx files?

This post has been edited by geniusalz: Jun 15 2004, 02:28 AM <

[BenJeremy]

I'll look into that.There's definitely a need to read/write unicode.  <

[flattspott]

QUOTE

MXM had some trouble loading a few xbx images. It waits a few seconds, then probably 'times out' and doesn't load the image. This causes long loading times for the script.

This might also have something to do with 5 second delay too. Maybe?  <

[geniusalz]

Yeah, probably, but other programs read images in that format just fine.  <

[pelago]

Excuse me for jumping in here, as I'm not a WIP tester, but there are definitely titleimage.xbx files in the game save area from commercial games that MXM (0.9n6) cannot display, even though the MS dashboard and UnleashX (for example) can. Worms 3D is one, and I've come across at least one more which I can't remember right now. If you want me to email the non-working xbx files somewhere for testing, or hex dump them, or whatever, let me know.

EDIT: the other game is Hunter: The Reckoning.

This post has been edited by pelago: Jun 16 2004, 07:50 PM <

[pelago]

QUOTE (geniusalz @ Jun 15 2004, 03:11 AM)

Anyway, some gamesaves don't contain a gameid.ini file, causing me insane amounts of grief.  Instead, they store the title in "TitleMeta.xbx", which is in unicode format.

Me again. I don't know if you're aware, but the gameid.ini files that you may have found on your hard disk are not put there by original Xbox games. They were generated by older versions of Xbox Saves Manager (http://www.xbox-saves.com/) as a descriptive text for the game title and save title. Newer versions of Xbox Saves Manager don't even make these ini files, presumably because they caused some problems. Anyway, the average user probably won't have any of these gameid.ini files.

Hope this helps.

This post has been edited by pelago: Jun 16 2004, 07:51 PM <

[geniusalz]

Silly me, not researching anything before jumping into development
Thanks for the heads up.

And I noticed those non-loading images too.  Seems MXM recognizes xbx files with XPR0 images only.

[pelago]

This gamesave manager sounds great. Is the idea that this will replace the MS dash equivalent? I.e. allow deleting of saves and copying of saves to memory cards? That will be cool and will save me going into MS dash for that.

Can I make a suggestion? Could your gamesave manager allow copying/moving of saves from the official gamesave area (i.e. UDATA/TDATA) to another part of the Xbox hard disk (user selectable), and back again? I realise that saves moved out of UDATA/TDATA wouldn't be visible to games, and that is in fact the point.

I would use such a feature for two things (both of which I've done recently via manual methods):

1, 'Backing up' saves prior to taking your box to a LAN party, or lending it to a friend (so if someone else mucks up your saves, you can restore them later from the 'hidden' part of the hard disk).

2, Using downloaded saves from the Internet (which involves moving out your existing save first, as usually the downloaded ones can't coexist with your own ones, which you might want to go back to).

I realise that some of this stuff can be done by buying Xbox memory cards to back up saves onto, but I don't have any cards and I have a 120GB HDD in my Xbox with plenty of space on it which it would be nice to use, and anyway some saves don't fit on a card! Also, I realise that this can be done with Xbox Saves Manager (the Windows program which connects to the Xbox via FTP and copies to and from UDATA/TDATA), but in my case my Xbox and PC aren't close together so FTP is a hassle, so I prefer to do all this kind of thing on the Xbox itself if possible.

As I say, I've done both of these things recently with manual methods, namely using the UnleashX file manager, but it's tricky as you need to find out the right folders for the saves. Regarding the downloaded saves, I burnt the downloaded ones on a CD and copied them to UDATA/TDATA, backing up my own saves first. It would be great if your gamesave manager had a feature to do this itself (maybe call it Export/Import) as it could do the looking up of HexIDs and so on itself.

Let me know if this isn't clear - I have a tendancy to waffle. ;-)

This post has been edited by pelago: Jun 23 2004, 09:22 AM <

[geniusalz]

I see what you mean.  Fortunately, that is possible with just a few lines of code.

i.e. When specifying memcards, and the HD save area, I can also define a HD 'backup' area.

E:\UDATA\ 'Normal' save area
H:\ - O:\ Memcards... (still need to look into those)
E:\Backup or F:\Backup 'Backup' area

Since you seem to know a little about saves, I have the following questions:
Is E:\TDATA ignored while copying gamesaves?  I understand that is where game settings are saved.

And while copying gamesaves to memcards and back, you simply copy the save folder, right?  <