unofficial LaunchELF v4.30

[user112]

@dlanor:
Err... What about the IPCONFIG.DAT?

[V3nn3tj3]

yea, i have a good old V7, but i can't read RW discs ....

[dlanor]

Originally Posted by user112

@dlanor:
Err... What about the IPCONFIG.DAT?

I'm not sure I understand your question, but possibly you wonder exactly how uLE searches for that file, since I recently changed how uLE searches for other files such as "ELISA100.FNT". And ooops!, it seems I spoke to soon in a recent post about that release when saying: "all files to be used by uLE may be stored in a SYS-CONF/ folder on either MC"; since the program still searches for "IPCONFIG.DAT" only on "mc0:/".

I'll probably change that in the next release, so that file too will use an "uLE:/" pseudo path, causing the search to include the launch folder of uLE as well as "SYS-CONF" on both MCs.

Best regards: dlanor

[user112]

@dlanor:
Yes, I mean http://psx-scene.com/forums/425205-post4656.html
and http://psx-scene.com/forums/425232-post4657.html

I don't suggest on using exactly that method to load it, as any would work. And I would be really glad to get rid of that SYS-CONF folder.

[E P]

Originally Posted by dlanor

@E P:
In testing the PAL v15 PStwo I bought a few days ago, I was surprised to note that the TV mode initialization works differently from all previous PS2 models I've tried (v7, v10, v11).

Apparently mode 0 no longer means 'auto' adaption to the console region standard TV mode, which had the same effect as mode 2 (PAL) on my old PAL PS2s, but instead it sets NTSC mode, just like mode 1.

Hum, that's rather odd. I don't remember hearing about this before unless it was partly a reason for allowing the selector to become an option. Previously the original LaunchELF just went with an auto detection method as I remember it. I wonder if SMS does anything special in regards to the auto detection method. I assume the original LaunchELF used a method similar to that of ps2menu as much of LaunchELF is primarily based on ps2menu.

I had planed on possibly getting a slim ps2 myself. However, after getting a new computer monitor a month a go I'm now leaning towards saving up for a PS3. Many of my core favorites games are now becoming available with FFXIII a little more than a year away. Right now, I still have my hands full with the PS2 so for the moment I'm pretty much content. Especially with all the latest new developments here.

The PS2PSXe sounds quite spectacular, I did have my hunches but my lips remained sealed, and I would have offered ffgriever some assistance in testing. However, I only have around 10 to 15 games mostly common ones for the PSX/psone and the thread noted users with a smaller library of common games need not apply for testing. Personally I don't know if I could have let the cat out of the bag so soon. Hopefully all the speculation by users will die down soon enough.

Originally Posted by dlanor

So we need a reliable way of testing what the regional TV standard is for the running console, and we can't just rely on MC contents for this (B?DATA-SYSTEM folder name etc) since some people prepare MCs for region-independent use, having multiple setups on a single MC.

Sure, maybe someone already has a method for making a proper determination. Then all we have to do is change uLE's method for choosing the proper TV mode once we get a better idea of how to do it correctly.

[dlanor]

Like the subject says, I've just released uLE v4.18, in the first post of this thread as usual.

LaunchELF v4.18 (2008.07.09)
-Modified loading of IPCONFIG.DAT to use "uLE:/" (so also found in uLE dir). If no initial IPCONFIG.DAT is found, any new one edited will be saved as "mc0:/SYS-CONF/IPCONFIG.DAT".
-Fixed a number of bugs affecting display and functionality of the default commands "Configure", "Load CNF++", "Load CNF--" for various combinations of settings for skin and menu control. Note that direct button linking was not affected, so pressing the correct button always gave the correct response. But highlighting a command and pressing the 'OK' button did not always work.
-Consolidated some PAL/NTSC GUI menu routines, and corrected a slight error in the placement of button text for D-pad 'Right' button


@user112:
This release really should give you what you asked for earlier, in that uLE can now find all external files in its own 'home' folder, and will look for them in mc?:/SYS-CONF/ only when not found in the folder of uLE.

@all:
The 'new' search method always looks first in the folder of uLE, followed by /SYS-CONF/ of both MC slots, but it is only a few files for which this is used automatically, since you aren't expected to configure their paths. Those files are: LAUNCHELF.CNF (which always used this method), ELISA100.FNT (gained this ability in v4.17), and IPCONFIG.DAT (gained the ability in this new v4.18 release). The same method can also be used for all configurable files of uLE, such as LNG, FNT, KBD, etc, but then you have to configure the use of "uLE:/" path yourself. This can be done when browsing to the file location, by using the R3 button instead of the regular OK button to confirm choice of the selected file.

Note that this search method does not work well when launching uLE from HDD, as no program launched that way is told what partition it's running from. So after IOP reset all contact with the launch folder is lost, and uLE will only be able to find config files in the /SYS-CONF/ folders of MCs.

There is a trick to get around that limitation, by configuring the CNF_Path setting to indicate the active uLE folder, using a full uLE-style HDD path (which includes partition). But it still won't work with all Dev2 implementations, as they seem to use incompatible launch/driver methods. For such cases you can only rely on config files in the /SYS-CONF/ folders.

Best regards: dlanor

[ytifle]

Nice, thx!

Working like a charm on v6 pal (booted with MCB 1.5)

Keep Releasing ^^

[user112]

Thanks!

[Aemaeth]

Today I was going to buy a divx reader from ebay, 60 €... but an error during the loading of the address has brought me here.

Reading your posts I learned how to create a divx for my beloved ps2, you made me spare a lot of time and money, I have to thanks you all ^_^

[Ba'al]

There still seems to be a bug when reassigning Left and Right to something other than Load CNF-- and ++.
When I initially add the left and right launch keys through the text editor, then go to Misc/LoadCNF, it works whether I press the arrows themselves or scroll down to highlight and launch them that way. However, it failed to work either way the next time I turn on the console.
Version 4.18 partially fixed the problem: scrolling down to choose them works now, but pressing left or right still fails to do anything.

[dlanor]

Originally Posted by Ba'al

There still seems to be a bug when reassigning Left and Right to something other than Load CNF-- and ++.
When I initially add the left and right launch keys through the text editor, then go to Misc/LoadCNF, it works whether I press the arrows themselves or scroll down to highlight and launch them that way. However, it failed to work either way the next time I turn on the console.
Version 4.18 partially fixed the problem: scrolling down to choose them works now, but pressing left or right still fails to do anything.

Thanks for the report. I'll check this out ASAP.

Best regards: dlanor

[dlanor]

Like the subject says, I've just released uLE v4.19, in the first post of this thread as usual.

LaunchELF v4.19 (2008.07.17)
-Fixed a bug preventing launch keys D-Pad Left and D-Pad Right from working correctly, when redefined from defaults, and only one menu page was used (== only one CNF)
-Fixed missing implementation of "uLE:/" search for some device related configurable files (mainly alternate USB drivers and regional keyboard maps)


@Ba'al:
Please retest the CNF that you reported the bug for earlier, and report your results with uLE v4.19. It should be working correctly now, as tested with my duplication of the error you described, but I still want it confirmed for your setup too.

You also said that pressing Left or Right worked when loading the CNF with the "MISC/Load CNF" command, but not when the CNF was loaded normally by launching uLE. I don't see how that is possible, as the CNF is loaded identically for these two cases. When I reproduced the bug here it always behaved the same, blocking response to these button presses, both after "Load CNF" command and after relaunch. Please doublecheck that again using uLE v4.18, because if this aspect of your original report is correct I am still missing something, since I can't reproduce that behaviour.

Best regards: dlanor

[dlanor]

Like the subject says, I've just released uLE v4.20, in the first post of this thread as usual.

LaunchELF v4.20 (2008.07.17)
-Implemented an icon mode for the FileBrowser, where each file/folder name will now be prefixed with a small coloured icon. The icon shape for folders is different from that for files, and three different colours are used. One for folders, another for ELFs, and a third for all other files.
-Implemented a new CNF variable 'FB_NoIcons', which may be set to disable the new FileBrowser mode. By default it is zero, enabling the new mode. There is no entry in the configuration menus for this variable, so you must add or change it by text editor (as yet).

The icon colours can be set in the normal configuration submenu "Screen Settings...", whose colours are (re)used for the icons as follows.

Folders use Color5 == 'Graph2'
ELFs use Color4 == 'Graph1'
All other files use Color3 == 'Normal'

Best regards: dlanor

[katananja]

Congratulation dlanor!!
Thank you!

[JNABK]

@dlanor

the new 'micro icons' look just fine as they are, but i have a suggestion for you to consider.

The current default colors for Color5 [Graph1] and Color6 [Graph2] just dont look right for the icons as a default color. I have a really crappy TV i use to test skins for those who might not have a quality TV, so i used it to view the new icos. The blue and pink are a bit bright and it was difficult to see a * marked .ELF file. My screen capture is better than what the crappy TV displays, but its also a crappy, cheap card. See 'old_settings.jpg' to see what i mean.
I changed the 2 settings {new_setting.jpg} and thought they might be a better "default" setting for them, as they are also more in tune to what would be expected for those 2 icons. Plus when marked, they show much better even on my crappy TV and TV card.

Color5 [Graph1]
R-FF
G-FF
B-FF

Color6 [Graph2]

R-60
G-60
B-00

Its not a bug or anything, but just a suggestion for the next release.


edit
I did a quick run thru of most of my recent skins and for the most part, the icons dont really have any issue with them, a few are right on the border, but not as bad as they cant be seen properly.

I also tested them using the above suggested colors and they all work fine with those 2 colors.

So no need for me to change all those skins again.....whew! But future skins will be made with the icon colors in the CNF along with the other colors.


Great job on the "eye-candy" !

[urbigbro]

@dlanor:
You just keep amazing me! I remember r0dent mentioning the existence of LBR, then I lusted for it's cool fonts and icons, and only days later ule has cool icons. I don't think anyone even had time to formally request it and the feature is implemented

Thanks again dlanor!

P.S. Does ule have the option of using larger fonts, when implementing an alternate font. I'm fairly sure it didn't before, but you might have added it to ule while I was typing this post

[dlanor]

Originally Posted by JNABK

@dlanor

the new 'micro icons' look just fine as they are, but i have a suggestion for you to consider.

The current default colors for Color5 [Graph1] and Color6 [Graph2] just dont look right for the icons as a default color. I have a really crappy TV i use to test skins for those who might not have a quality TV, so i used it to view the new icos. The blue and pink are a bit bright and it was difficult to see a * marked .ELF file.

I'm aware of the problem, but I wasn't sure what colours to choose for the new defaults. I felt it was better to get some implementation out there ASAP, to generate some feedback (like yours ).

Color5 [Graph1]
R-FF
G-FF
B-FF

White ? Seriously ?
We already have three neutral colours as defaults. One black and two shades of grey. (Not to mention that the still unused colours are also zeroed.) So I think it would be a bit much having yet another one, thus making more than half of the used colours neutral. I'm not throwing your suggestion out the window though, but I'd like to see some more feedback stating that this would be acceptable to others.

But then again, most users will probably have skins redefining the colours, so the new default might not matter very much.

Color6 [Graph2]
R-60
G-60
B-00

I guess this one is OK by me though it looks a bit 'drab'. But that pretty much describes the 'coloration' (mostly neutral) of the CNF-less uLE anyway, so I guess it fits right in there...

I did a quick run thru of most of my recent skins and for the most part, the icons dont really have any issue with them, a few are right on the border, but not as bad as they cant be seen properly.

This means that you've done your job properly in designing them, by following the same outline as the internal non-skin frame rectangle.

Even that internal frame makes the room for icons a bit tight, so that the leftmost icon pixels will overlay that border too. But I can't move the icon much further to the right as there are now only 2 blank pixels between visible pixels of the icon and visible pixels of the file/folder name. (One blank edge pixel of each definition is already overlaid.) To move it further I'd have to shrink the space available for names, which I'm reluctant to do.

I also tested them using the above suggested colors and they all work fine with those 2 colors.

Yes, I think so too.

So no need for me to change all those skins again.....whew! But future skins will be made with the icon colors in the CNF along with the other colors.

That will be better of course, so you can optimize the choice of colours for best visibility relative to the background picture.

Great job on the "eye-candy" !

Believe it or not, but the clincher making me go for this was all functional, having nothing to do with pleasing appearances. On a couple of occasions I've had to browse PC folders via host:, and had trouble telling the difference between long-named folders and long-named files. With the old uLE methods the only difference in their display is either the filetype extension or the final '/', which both demand that the entire name can fit in the available display, which isn't always the case. The only way to fix that was to add a prefix symbol of some kind, and icons are the traditional way of doing this on modern computers.

So with me it's still all about functionality, as you may soon see in my replies to those who will (most probably) start to nag me about making the icons 'prettier'...

Best regards: dlanor