A bug with uLaunchELF 3.59 ??

[ahmadka2]

well, i decided to give the skinning features of this great program today, and i fell into a sticky stop...

i updated the uLE in my memory card to the latest 3.59 version...then, i copied some skins of it in my directory:

hdd0:+AHMADKA\Directory\File-Managers\uLaunchELF\Skins\ (copied here)

and I loaded a skin, and applied it....then when i restarted the ps2, and thus restarted uLE, on startup uLE started to initiate the HDD, obviously to load the skin...but this is the bug --> uLE froze at the 'Loading HDD Modules' message...

to fix this, i restarted the ps2 without the ps1 disc and went into browser...i deleted the 'corrupted data' which contained the SYSTEM.CNF for uLE 3.59....then i triggered uLE again to get it to function properly.....now i had to make all the settings again...

to fix the image issue, i copied the image into the memory card, from where it loads OK at the startup....

a second thing i would like to point out:

when uLE first froze, i took out the HDD, and then triggered uLE, thinking it might say there is no HDD present, and may present me with some options...
but again, it froze at the 'Loading HDD Modules'....maybe add a HDD Check, on whether its even connected or not ??? :)

but this does NOT mean that i am not a fan of uLE....r u kidding ? i love uLE :D

[ps2dragon]

Looks like you found the path length limitation in uLE, although I'm not sure if it has to do with the general max path length, or something specific to the length of the skin path.

I think it either has to do with the variable "MAX_PATH = 1025" or "char skin[MAX_PATH]" in the "launchelf.h" source file.

EXAMPLE:
- WORKING PATH = "hdd0:/+MAIN/Directory/File-Managers/uLaunchELF/Skins/jellies_.jpg" (65 chars)
- NON-WORKING PATH = "hdd0:/+MAIN/Directory/File-Managers/uLaunchELF/Skins/jellies_6.jpg" (66 chars)

So there seems to be a limit of 65 characters in the skin path. Going over that limit will cause the loading of HDD modules to hang if loading the skin from the HDD.

I was thinking that maybe it would be a good idea to program uLE to ignore the LAUNCHELF.CNF file upon loading if holding a button, the same way the Infinity Chip is designed. This way, whenever there is a problem with some incorrect setting in uLE, or the system hangs do to a bug related to the LAUNCHELF.CNF file, you can choose to skip using the LAUNCHELF.CNF file and restore your old settings. This would make it a lot easier in correcting the problem, instead of having to install an older version of uLE. I have to do this to fix my uLE everytime when there is a bug, because using an older version like v3.41 does not use the newer settings from the LAUNCHELF.CNF file.

[dlanor]

Looks like you found the path length limitation in uLE, although I'm not sure if it has to do with the general max path length, or something specific to the length of the skin path.

I think it either has to do with the variable "MAX_PATH = 1025" or "char skin[MAX_PATH]" in the "launchelf.h" source file.
Of course not. If that had been the case, then the limit would not have been the much lower number you tested below.

But it could be due to some too short char array used for some intermediate copy of the path string. I'll have to make some experiments myself and search for the cause of this error.

EXAMPLE:
- WORKING PATH = "hdd0:/+MAIN/Directory/File-Managers/uLaunchELF/Skins/jellies_.jpg" (65 chars)
- NON-WORKING PATH = "hdd0:/+MAIN/Directory/File-Managers/uLaunchELF/Skins/jellies_6.jpg" (66 chars)

So there seems to be a limit of 65 characters in the skin path. Going over that limit will cause the loading of HDD modules to hang if loading the skin from the HDD.
I'll look into it ASAP.

I was thinking that maybe it would be a good idea to program uLE to ignore the LAUNCHELF.CNF file upon loading if holding a button, the same way the Infinity Chip is designed. This way, whenever there is a problem with some incorrect setting in uLE, or the system hangs do to a bug related to the LAUNCHELF.CNF file, you can choose to skip using the LAUNCHELF.CNF file and restore your old settings.
That's not a bad idea, except that we have already defined some usage for all existing buttons... But we can of course redefine the startup behaviour, such that launch keys pressed before the menu is displayed are considered invalid. This way we can use any key we want to inhibit the CNF loading (or make some other startup-related choice).

This would make it a lot easier in correcting the problem, instead of having to install an older version of uLE. I have to do this to fix my uLE everytime when there is a bug, because using an older version like v3.41 does not use the newer settings from the LAUNCHELF.CNF file.
Yes, I know what you mean. For me this is not so big a problem, because my mod-chip has several DevX boot modes, so I usually install a new version/setup only for the main Dev1 mode. Then I copy that setup to the other modes, but only after thorough testing has shown the setup to be problem free. (A day or two of normal usage should reveal most problems.)

If you have a Matrix Infinity chip, then you can do the same, as both its Dev1 programs can have separate CNF files, in "mc0:/BOOT/" and "mc0:/MATRIXTEAM/", while the Dev2 program will look for its CNF in "mc0:/SYS-CONF". All in all, that gives you the ability to have up to three completely independent uLaunchELF boot setups, even if you only have a single MC.

Best regards: dlanor