Cannot restore saves in ulaunch.

[therock003]

every once in a while a backup me evolution soccer replays on the mass storage i have via launchelf.I do it with cut->psu paste.

This time i accidentally cut pasted my league file as well,so i select the psu file,i then do an mcpaste but it pastes it as a psu back in the mc and as a result it is shown as a corrupt file.

[dlanor]

every once in a while a backup me evolution soccer replays on the mass storage i have via launchelf.I do it with cut->psu paste.

This time i accidentally cut pasted my league file as well,so i select the psu file,i then do an mcpaste but it pastes it as a psu back in the mc and as a result it is shown as a corrupt file.

You have simply misunderstood how to use these commands.

"mcPaste" is an older backup method which copies files and folders just as they are, but adds an extra file for non-MC storage devices to keep track of MC-specific attributes and timestamps of all files in each save, as well as of the save folder itself. This ensures that the same command can also restore those attributes etc when that save is restored to MC. Note that this backup method requires you to use mcPaste both when making the backup to non-MC media, and when restoring that backup to MC again. Otherwise the extra file will be ignored.

Also, if you use mcPaste to copy something to MC other than a folder containing such an extra file, then the command will just work like a normal Paste operation, which is why you got that PSU file stored on the memory card.

The mcPaste method worked quite well to backup gamesaves, but only for saves whose files and folders all had names that would be legal on non-MC file systems, which is not always the case. MC files and folders can have various special characters in their names which are impossible to use on most other file systems. Like trying to back up a gamesave to 'host:', storing it on a Windows PC, when the file/folder names contain the colon character ':', or backslash '\'. That obviously can't work since Windows will refuse to allow such names. To cope with such needs I invented the "psuPaste" method. (Basing it on the already existing PSU file standard, which I was not involved in inventing.)

As you already know, this method will create a PSU file for each folder that is copied from MC to non-MC media, and in the same fashion it can be used to restore those original folders when you psuPaste those PSU files back to an MC. Like with mcPaste, this restoration will also restore the original file attributes and timestamps, regardless of what attributes etc the PSU file happened to get in backup storage, but also regardless of what the PSU name may have been changed to in order to keep it legal on the backup medium.

To summarize:
Your mistake was only to assume that two different commands should be used for making a backup and then later restoring it, when in fact you should use the same command for both operations. And the recommended command to use is of course psuPaste, since that is the newer method, designed to cope with all types of saves known to us.

Best regards: dlanor

[therock003]

You are completely right my bad,and thanx for explaingn in detail for me to get it!

A couple of more questions unrelated to the subject though.

1)Does ulaunch display any warning dialogue before overwriting files?Cause i psu pasted a file on the mass storage and a file with the same name existed,and it was overwritten without confirmation,and i lost a save!

Is there any way to restore that file,maybe from windows?

B)What is the best mcformat tool?MCkiller or mcformat?I used the second onw on my 2 corrupted mcards.

[dlanor]

You are completely right my bad,and thanx for explaingn in detail for me to get it!

A couple of more questions unrelated to the subject though.

1)Does ulaunch display any warning dialogue before overwriting files?

No. That would mean having to reply to a redundant prompt every time a file is intentionally replaced by a new version. (something developers do many times each day.) To me that is a worse hassle than accidental overwrites, which can usually be avoided by other methods.

The simplest such method is of course to check what's in the destination directory before giving the command to copy new stuff into it.

Another method is to set a special PSU-related control variable in the CNF file, which will then extend the PSU filenames so as to include the timestamp from the original gamesave folder, converted to ascii text and appended between the normal PSU filename and the ".psu" extension.

This can give you PSU filenames like in this example:
"BASLUS-2084700_2007-04-18_16-31-44.psu"

Or alternately huge filenames like this one (for the same gamesave):
"BASLUS-2084700_La Pucelle (1) Chapter1 LV20_2007-04-18_16-31-44.psu"

For either format, having the timestamp included should ensure that each new gamesave gets a unique PSU filename.

To find out more about these settings you should read the LAUNCHELF.CNF file that is supplied with each release. It is heavily commented, and it is the best available documentation on what features the CNF file offers. (This goes beyond what's available in the configuration menus of uLE.) In fact there are lots of features documented only in this CNF file, so it's worth the effort to study it.

Cause i psu pasted a file on the mass storage and a file with the same name existed,and it was overwritten without confirmation,and i lost a save!

Is there any way to restore that file,maybe from windows?

No.

B)What is the best mcformat tool?MCkiller or mcformat?I used the second onw on my 2 corrupted mcards.

I believe those two are just different versions of the same thing, but I'm not well informed on their details, so I have no definite answer. I've used MCkiller once myself after an MC got corrupted, so apparently they both work.

Best regards: dlanor

[ps2dragon]

B)What is the best mcformat tool?MCkiller or mcformat?I used the second onw on my 2 corrupted mcards.

I made a post about these two programs in the uLaunchELF forms here. A few posts down E P explains that they are indeed different programs. I recommend MC Killer...

[therock003]

I'm bumping this thread after a long time so plz never mind the initial title.

I just want to adress some follow-up questions if I may. Sorry but there's been a long time since the first post and i want to get this right.

A)So mcPaste is never to be used (Why does it still exist though as an option since it really is archaic)?It's copy psuPaste to both occasions (copying from m-card to non-mc ,and vice versa)?When psupasting back to the mcard i guess it should unpack the .psu right?

B)Are the timestamps retained with the psuPaste method as well?

C)Does this work with psx saves also?Or do i need to handle this differently? Cause i'm pretty sure that the .psu format is for ps2 save files only.

D)Why are the transfer speed so slow? I guess mcards must have a really slow access time due to their manufactured status right? I mean it isnt a software limitation, is it?BTW when i select lots of saves to be copied at once it sometimes gets stuck. Thankfully last time i tried i didnt lose any saves for having to reset after the programm stopped responding when i attempted to copy the whole memory card to my flash drive.

[suloku]

A)So mcPaste is never to be used (Why does it still exist though as an option since it really is archaic)?It's copy psuPaste to both occasions (copying from m-card to non-mc ,and vice versa)?When psupasting back to the mcard i guess it should unpack the .psu right?

If you backup the gamesaves to ps2's hdd you can broswe them as if they where on the MC, which is really useful. For some reason I like this format more than psu, and I have lots of old saves stored in this "folder format".

B)Are the timestamps retained with the psuPaste method as well?

Yes, but I'm not sure about restoring into a virtual memory card.

C)Does this work with psx saves also?Or do i need to handle this differently? Cause i'm pretty sure that the .psu format is for ps2 save files only.

I did some research about that, but I cannot remember what I concluded. I pressume they are raw single savegame files, which is a format I only found supported by psx game edit (.mcs), even thought there are another apps that produce single savegame files but they most likely add some header to it.

D)Why are the transfer speed so slow? I guess mcards must have a really slow access time due to their manufactured status right? I mean it isnt a software limitation, is it?BTW when i select lots of saves to be copied at once it sometimes gets stuck. Thankfully last time i tried i didnt lose any saves for having to reset after the programm stopped responding when i attempted to copy the whole memory card to my flash drive.

If it gets stuck it seems to me a problem with your usb drive.

[dlanor]

I'm bumping this thread after a long time so plz never mind the initial title.

I just want to adress some follow-up questions if I may. Sorry but there's been a long time since the first post and i want to get this right.

A)So mcPaste is never to be used (Why does it still exist though as an option since it really is archaic)?It's copy psuPaste to both occasions (copying from m-card to non-mc ,and vice versa)?When psupasting back to the mcard i guess it should unpack the .psu right?

In essence what you say here is fully correct. It is indeed "psuPaste" that is intended for use, both in creating new backups of gamesaves on non-MC media, and for restoring such ".psu" file gamesaves from non-MC media to normal gamesave folder form on an MC.

But since mcPaste was created first, people may still have such backups stored, which would become useless if I was to remove the "mcPaste" command from uLE. and in addition to this there are some people (like suloku) who prefer the "mcPaste" method, as it allows easy access to the contents of the gamesave even in backup form. (This has both good and bad points, as it also allows easy damage to the content.)

So mcPaste will remain in the program, both to provide backwards compatibility with all backups made with it, and also to satisfy those who find it more to their taste than the newer psuPaste command.

But regardless of taste, there is no arguing with the fact that psuPaste can successfully handle some saves that mcPaste would fail to handle correctly.

B)Are the timestamps retained with the psuPaste method as well?

Yes.

psuPaste restores all contents of a gamesave, as well as its containing folder, to have exactly the same names, timestamps, and attribute flags as in the original gamesave on MC before the original backup operation was started.

mcPaste was of course designed to do exactly the same thing, though by slightly different methods, but due to those differencies it was unable to handle some of the possible gamesave names that may exist on a real PS2 MC, but which are impossible to use on some other backup media.

That is the original reason why I created psuPaste, so that backup could be made in a form independent of the original gamesave names and their potential incompatibility to filename rules on other media.

C)Does this work with psx saves also?Or do i need to handle this differently?

Normal PS1 files on normal PS1 memory cards are just simple files which need no special treatment beyond normal Paste. The PS1 does not have any complex filesystem, handling everything as multiples of 8KB blocks. And since it has no real-time clock there can be no timestamps to worry about.

PS1 files backed up by the Sony browser to a PS2 MC are a little different, as they are stored inside a folder. How you back that up is really up to you, and you can use psuPaste to do it if you like, but then restoration of it must also be by psuPaste to a PS2 MC, followed by using the Sony browser to restore that to a PS1 MC.

It is really easiest to do it by direct copying of PS1 saves using the normal Paste command to transfer the save files between the PS1 MC and the backup medium.

Cause i'm pretty sure that the .psu format is for ps2 save files only.

That is indeed its intended usage.

D)Why are the transfer speed so slow? I guess mcards must have a really slow access time due to their manufactured status right? I mean it isnt a software limitation, is it?

No, you are correct in assuming that this is hardware dependent. It is also very much dependent on the size of the MCs, with the 64MB MaxMemory units being horribly slow in comparison with the original 8MB Sony units.

BTW when i select lots of saves to be copied at once it sometimes gets stuck. Thankfully last time i tried i didnt lose any saves for having to reset after the programm stopped responding when i attempted to copy the whole memory card to my flash drive.

Transfer glitches can never be fully insured against, and may even be due to hardware problems. Simple things like 'not-so-firm' insertion of a USB key can do it.

And some consoles even have a marginal alignment of their MC connectors, so that a few MCs get bad contact pressure. They may then work perfectly in one connector but not in the other, or work perfectly on one PS2 but not on another. But if you have one of those consoles, then you are probably already aware of this.

Best regards: dlanor

[therock003]

Normal PS1 files on normal PS1 memory cards are just simple files which need no special treatment beyond normal Paste.

Well i have gathered as such. A simple observation leads to the conclusion that they are plain raw files. In addition, do you know of a way to convert them to valid psx savefiles for use with PC applications such as PSXGameSaveEdit? I noitced that the difference between these aw files and the .psx formt is a couple of additional lines on the start of the .psx file containing information of the product id and game id just before the SC_. I noticed that by opening both formats with a hex editor.

The PS1 does not have any complex filesystem, handling everything as multiples of 8KB blocks. And since it has no real-time clock there can be no timestamps to worry about.

What do you mean by realtime clock? You mean in comparison with ps2 saves, that use the system's time clock and store it as valid infromation inside the timestamp?

PS1 files backed up by the Sony browser to a PS2 MC are a little different, as they are stored inside a folder. How you back that up is really up to you, and you can use psuPaste to do it if you like, but then restoration of it must also be by psuPaste to a PS2 MC, followed by using the Sony browser to restore that to a PS1 MC.

You mean there's a way to store PSX saves inside a PS2 memory card? How can that be done? So far i only knew that you need a PSX mcard for PSX games.

No, you are correct in assuming that this is hardware dependent. It is also very much dependent on the size of the MCs, with the 64MB MaxMemory units being horribly slow in comparison with the original 8MB Sony units.

Transfer glitches can never be fully insured against, and may even be due to hardware problems. Simple things like 'not-so-firm' insertion of a USB key can do it.

And some consoles even have a marginal alignment of their MC connectors, so that a few MCs get bad contact pressure. They may then work perfectly in one connector but not in the other, or work perfectly on one PS2 but not on another. But if you have one of those consoles, then you are probably already aware of this.

Best regards: dlanor

Do we have any indication as to what these transfer speeds are? Cause they seem to be limiting the mcard considerably.

Anyway as to the plugging mcards and USB i am certain that they are inserted properly. The freezing of this kind has only happened in cases of copying the whole mcard. Every time i have tried copying 1-3 saves it seems to work fine. I dont know why that happens though...And i do use an official Sony 8MB.

[dlanor]

Well i have gathered as such. A simple observation leads to the conclusion that they are plain raw files. In addition, do you know of a way to convert them to valid psx savefiles for use with PC applications such as PSXGameSaveEdit? I noitced that the difference between these aw files and the .psx formt is a couple of additional lines on the start of the .psx file containing information of the product id and game id just before the SC_. I noticed that by opening both formats with a hex editor.

I don't have any universal tool for doing such things, but one obvious way to do it would be to use existing files of that type, for the game in question, and using a hex editor to patch in the contents of your real x*8192 byte PS1 gamesaves (transferred to the PC by uLE host: interface or via USB stick).

What do you mean by realtime clock? You mean in comparison with ps2 saves, that use the system's time clock and store it as valid infromation inside the timestamp?

Yes. I simply mentioned it as one more complication we don't need to worry about for PS1 saves, since that console didn't have any real-time clock and therefore never could use timestamps.

You mean there's a way to store PSX saves inside a PS2 memory card?

Not from a PS1 game. But they can be copied there using the Sony browser.

How can that be done?

The Sony browser can be used to backup PS1 games from a PS1 MC to a PS2 MC, and will then create a new folder on the PS2 MC for each PS1 gamesave backed up, using that folder to contain the raw x*8192 byte gamesave file. These saves differ from the normal PS2 saves in that they have no "icon.sys" file nor the icon file(s) this normally specifies, as the icon to be used is incorporated inside each PS1 gamesave file.

So far i only knew that you need a PSX mcard for PSX games.

Yes, that is true. In-game you can only save to a PS1 MC.
Such saves can only come to a PS2 MC through copying.

Do we have any indication as to what these transfer speeds are? Cause they seem to be limiting the mcard considerably.

The only 'indication' is what you yourself can observe. The speed varies greatly between different makes, and even between different generations of cards from the same manufacturer. The only constant in this is that for cards from the same maker and generation the larger cards are always MUCH slower than the smaller cards.

A 64 MB card of the Datel MaxMemory kind is quite irritatingly slow (I have two of these).

Anyway as to the plugging mcards and USB i am certain that they are inserted properly. The freezing of this kind has only happened in cases of copying the whole mcard. Every time i have tried copying 1-3 saves it seems to work fine. I dont know why that happens though...And i do use an official Sony 8MB.

I don't think it is a problem with the MC. More likely then a problem with the USB device and/or its drivers. Do you use the internal drivers of uLE, or have you selected some external drivers ? And which uLE version are we then talking about ?

Best regards: dlanor