Ideas for a possible UlaunchELF v4.17

[katananja]

Hello Guys,

I was thinking if is possible to have UlaunchELF to format MC, create/restore dump from MC, I know that there is other tools that do this but wouldn't be nice to have this solutions in one software to make it more complete without the need to carry a pen drive to do this simple tasks.

Thank you.

[gildor]

Now i'm not saying it should not be added as that is ultimately up to the developers, but i don't htink this is a good idea as i have kids and boot off MC, if somehow the kids where to get to that option it could really mess things up, and believe me kids can get into anything they put their minds to,

[katananja]

This can be solved by adding a option in the CNF file to hide the options that can "damage" the data by accident.

[JNABK]

ule can simply boot MC Killer {McFormat} already, so wouldnt this just be a bloat to ule?

I dont see this becoming a new option any time soon, though it is a good suggestion if it can be improved to format cards that MC Killer cant, like AR Max EVO's MC Format can do.

[TnA]

Yes, it will increase size, but I hope, if it is possible not to much.
If it can do a format with Sony's method from ROM (or custom maybe with given drivers) without increasing the size, it would be a "nice to"- but not must-have.

[dlanor]

Originally Posted by katananja

I was thinking if is possible to have UlaunchELF to format MC, create/restore dump from MC, I know that there is other tools that do this but wouldn't be nice to have this solutions in one software to make it more complete without the need to carry a pen drive to do this simple tasks.

If you are carrying uLE around, then you are also carrying around the media it is stored on, whether that is a USB stick, a PS2 memory card, or a CD/DVD disc. And whatever medias you use, they can also be used to store other elfs like McKiller/McFormat, which can easily be launched by uLE. So I don't really see any need for an internal formatting function, although I'm not opposed to it either, since it relates to maintenance of filesystems, much like HddManager and the FileBrowser do. Even so, I don't think we will add it in. At least not at this time.

Originally Posted by gildor

Now i'm not saying it should not be added as that is ultimately up to the developers, but i don't htink this is a good idea as i have kids and boot off MC, if somehow the kids where to get to that option it could really mess things up, and believe me kids can get into anything they put their minds to,

If we do add an 'McFormat' function later, it will most likely be in the form of another "MISC/" subprogram. Thus it can be completely hidden simply by making a CNF that has no button defined for the formatter, and likewise no button defined for 'FileBrowser' or 'Configure'. It is then impossible for the kids to reach any of those functions.

Best regards:

[katananja]

I think it is a must have tool inside uLE because you don't need to carry different tools with you, and as you might know there is cases that some apps doesn't run in some models but uLE is much more compatible with almost any model, thanks to coolaan i can run uLE in my 10K now.

I'm not a programmer but there is some open source tools available like dd (http://www.gnu.org/software/coreutils/), mkdosfs, badblocks (http://projects.sourceforge.net/) that, i think, would be very easy to the guys that know how to program, adapt that to uLE. But don't think only in memory cards, imagine using uLE to recover your pen drive/MC with bad block using that tools.

Is very practical, you don't need a PC to do it and every one happens to have some time in life, trouble with MC and pen drivers with bad block, why not be able to solve that with your PS2 and one single tool?

I was imagining options like:

- Check MC/MASS for bad block.
- Format MC or MASS.
- Generate MC image.
- Restore MC image.

Or if you have HDD dump/format/check the HDD also. I don't know the file system used in MC but i think that with this open source tools could be possible to format this other types of memory cards also.

[katananja]

Originally Posted by dlanor

If you are carrying uLE around, then you are also carrying around the media it is stored on, whether that is a USB stick, a PS2 memory card, or a CD/DVD disc. And whatever medias you use, they can also be used to store other elfs like McKiller/McFormat, which can easily be launched by uLE.

That is the problem, this tools doesn't work with my 10k for example, why not have this options to uLE (that runs in almost any PS2 now) and use uLE not only to browse or copy but to do maintenance also? I don't know, something like uLE Advanced

[vsub]

I don't like to have something like that inside ule because I always will be afraid that I'll do something by accident and delete all my saves.My memory card is 64mb and I have more than 20mb of saves or saves for around 30 games and not just one save per game.But that's just my opinion

[katananja]

Originally Posted by vsub

I don't like to have something like that inside ule because I always will be afraid that I'll do something by accident and delete all my saves.My memory card is 64mb and I have more than 20mb of saves or saves for around 30 games and not just one save per game.But that's just my opinion

You still can keep using the previous version, since there are no "new bug" to fix, you use this "special" version if you need the advanced functions.

[Petyka]

Instead of formatting, I think an automatic MC backup would be more convenient. A new small application could do a whole MC backup to a user selected destination with the proper file handeling.

[katananja]

Originally Posted by Petyka

Instead of formatting, I think an automatic MC backup would be more convenient. A new small application could do a whole MC backup to a user selected destination with the proper file handeling.

Did you try mcPaste?

[dlanor]

Originally Posted by katananja

I think it is a must have tool inside uLE because you don't need to carry different tools with you,

I disagree. Did you ever see a (physical) toolbox with only a single tool in it ?

The 'swiss army knife' approach may seem appealing to some people, but such tools are really for emergency use only. In cramming all kinds of tools into a minimal package it always becomes necessary to make compromizes which also affect functionality in a bad way. Specialized tools designed for one specific purpose often do a better job.

and as you might know there is cases that some apps doesn't run in some models but uLE is much more compatible with almost any model, thanks to coolaan i can run uLE in my 10K now.

Even so, we can't redesign uLE to include all tools that lack such compatibility.

I'm not a programmer but there is some open source tools available like dd (http://www.gnu.org/software/coreutils/), mkdosfs, badblocks (http://projects.sourceforge.net/) that, i think, would be very easy to the guys that know how to program, adapt that to uLE.

The point is not how easy it is to adapt them for compilation into uLE, but rather how easy it is to adapt them for use with Sony's MC FAT filesystem, using low-level access functions of the available MC modules, which differ widely from access functions of normal storage devices on normal computers, as used in existing versions of the tools you mentioned.

That adaption would probably be a major work in itself.

But don't think only in memory cards, imagine using uLE to recover your pen drive/MC with bad block using that tools.

Which effectively would require having two very similar tools implemented, since there is huge difference in low-level access functions for USB sticks and for MCs on the PS2. And there is also a big difference between FAT32 as used on mass: and the FAT system used on MCs, which also makes it hard to handle both with the same tool.

Is very practical, you don't need a PC to do it and every one happens to have some time in life, trouble with MC and pen drivers with bad block, why not be able to solve that with your PS2 and one single tool?

Because it would be serious overkill to include a complex tool for use "some time in life". The MC space this tool consumes (by bloating uLE) is wasted in every session, not just on the rare occasions when the tool is used. So this is a very good example of something that should be implemented as a separate tool rather than integrated with uLE.

I was imagining options like:

- Check MC/MASS for bad block.
- Format MC or MASS.
- Generate MC image.
- Restore MC image.

Or if you have HDD dump/format/check the HDD also. I don't know the file system used in MC but i think that with this open source tools could be possible to format this other types of memory cards also.

The kind of tool you describe here would be a major project in its own right, and would most likely bloat uLE significantly. So this is simply not going to happen...

Btw: The MISC/HddManager subprogram of uLE can already format an HDD. As for checking HDD integrity using tools based on the open sources you mention, I don't think that would work, since the filesystem of PS2 HDDs is Sony specific.

Best regards: dlanor

[katananja]

Originally Posted by dlanor

I disagree. Did you ever see a (physical) toolbox with only a single tool in it ?

The 'swiss army knife' approach may seem appealing to some people, but such tools are really for emergency use only. In cramming all kinds of tools into a minimal package it always becomes necessary to make compromizes which also affect functionality in a bad way. Specialized tools designed for one specific purpose often do a better job.

Even so, we can't redesign uLE to include all tools that lack such compatibility.

The point is not how easy it is to adapt them for compilation into uLE, but rather how easy it is to adapt them for use with Sony's MC FAT filesystem, using low-level access functions of the available MC modules, which differ widely from access functions of normal storage devices on normal computers, as used in existing versions of the tools you mentioned.

That adaption would probably be a major work in itself.

Which effectively would require having two very similar tools implemented, since there is huge difference in low-level access functions for USB sticks and for MCs on the PS2. And there is also a big difference between FAT32 as used on mass: and the FAT system used on MCs, which also makes it hard to handle both with the same tool.

Because it would be serious overkill to include a complex tool for use "some time in life". The MC space this tool consumes (by bloating uLE) is wasted in every session, not just on the rare occasions when the tool is used. So this is a very good example of something that should be implemented as a separate tool rather than integrated with uLE.

The kind of tool you describe here would be a major project in its own right, and would most likely bloat uLE significantly. So this is simply not going to happen...

Btw: The MISC/HddManager subprogram of uLE can already format an HDD. As for checking HDD integrity using tools based on the open sources you mention, I don't think that would work, since the filesystem of PS2 HDDs is Sony specific.

Best regards: dlanor

Dude, calm down, is just an idea.
I'm not telling or demanding no one to do it, or that will be done in the next versions.

[dlanor]

Originally Posted by katananja

Did you try mcPaste?

mcPaste is an old method which can only handle MC files with names that obey the same rules as the backup media. This means that gamesaves with names containing characters like ':', '\', and so on, can not be stored on mass: or on a PC via host:.

Another drawback of mcPaste is that it relies on creating an extra file in each folder backed up, to keep track of timestamps and PS2-specific file flags, so that those can be restored when/if the backup is transferred to MC again (using mcPaste).

But there are cases where mcPaste is still useful, when you need the ability to access/edit the files of a gamesave directly, and yet be able to restore original timestamps etc later.


The best uLE command for making full MC backups is psuPaste, since it can handle gamesaves with 'illegal' characters in file/folder names, as those names are then stored only inside the PSU files. Another advantage is that each gamesave folder is backed up as a single PSU file, containing all the gamesave files from that folder, plus their original filenames, timestamps, and PS2-specific flags, all of which will be restored whenever psuPaste is used to put the gamesaves back on MC again. And the construction of filenames for PSU files can be modified (read release CNF) to include folder names and game titles as well as the gamesave timestamp info. NB: game titles are as shown by the Sony browser, except that characters not in the uLE font (eg: japanese kana) will be replaced by underscores ('_'), and characters illegal on the destination media will also be replaced that way.

Just be aware that homebrews using subfolders on MC (NOT really valid for MC) will not be backed up correctly, since the PSU file standard has no way of dealing with subfolder levels (as they should not exist on MC). So a 'myPS2' installation can not be backed up by psuPaste, and neither can the new 'Skins' subfolder SMS has implemented inside its SMS folder. So such application folders should be backed up by normal 'Paste' instead.

One simple procedure to make a full MC gamesave backup is this:

1: Start FileBrowser
2: Browse to the MC
3: Press 'Square' to mark all content
4: Press R1 to open popup and choose 'Copy' command
5: Browse to backup location on hdd0:, mass: or host:
6: Press R1 to open popup and choose 'psuPaste' command

That will create backup PSU files for each folder on the MC.

Best regards: dlanor

[dlanor]

Originally Posted by katananja

Dude, calm down, is just an idea.

I'm perfectly calm. I just wanted to explain to you why I disagree with your suggestion.

I'm not telling or demanding no one to do it, or that will be done in the next versions.

I didn't take it that way either, but only as your suggestion for something that you'd like to see implemented. The only reason I wrote a lengthy reply was to make it clear that there are valid reasons why including this in uLE would not be a good idea.

Best regards: dlanor

[katananja]

Originally Posted by dlanor

I'm perfectly calm. I just wanted to explain to you why I disagree with your suggestion.

I didn't take it that way either, but only as your suggestion for something that you'd like to see implemented. The only reason I wrote a lengthy reply was to make it clear that there are valid reasons why including this in uLE would not be a good idea.

Best regards: dlanor

No problem, i thought that you want to rip my head off.