LAUNCHELF.CNF format?

[zzthex]

Hi All,

I'm going to burn uLaunchELF to a DVD, to make a DVD with some ELFs I'd like to boot. The problem is, I have no idea what format the LAUNCHELF.CNF file should be in. I'm going to burn the LAUNCHELF.CNF to the DVD, so I'd rather get it right the first time. I read the documentation, but I?ve still got questions. Like: should pathnames have quotation marks surrounding them? Do I need to specify every option, or can I leave some out of the LAUNCHELF.CNF file and let it use default values? Probably the most helpful thing would be if some kind soul would post the LAUNCHELF.CNF that they use, and I can figure it out from there.

Thanks for your help!

[dlanor]

Hi All,

I'm going to burn uLaunchELF to a DVD, to make a DVD with some ELFs I'd like to boot. The problem is, I have no idea what format the LAUNCHELF.CNF file should be in. I'm going to burn the LAUNCHELF.CNF to the DVD, so I'd rather get it right the first time.
I'm not sure I understand you correctly here. You want to burn it to a DVD, even though you've never used it ?!? (As you have no CNF...?!?) Or maybe you do have a CNF but lack the means to transfer it to a PC. (No Network Adapter ?)

Well, that's your lookout, but in any case I recommend using the program quite a bit before burning a CNF to CD/DVD. Otherwise you'll be wasting discs needlessly.

I read the documentation, but I?ve still got questions. Like: should pathnames have quotation marks surrounding them?
No, never.

Do I need to specify every option, or can I leave some out of the LAUNCHELF.CNF file and let it use default values?
You have to specify every choice. There are no keywords in these files, so the only way for the software to identify each option is by counting the lines. This means that if you skip one then all the rest will be misinterpreted...

Not very friendly for human editing, I know, but that's because it never was intended for human editing in the first place. We may change this in some future version, by adding keywords to each option to allow proper parsing, but that is not yet implemented.

Probably the most helpful thing would be if some kind soul would post the LAUNCHELF.CNF that they use, and I can figure it out from there.
Ok, so I'm attaching a ZIP containing the set of 2 CNF files I normally have in my mc0:/SYS-CONF/ folder, for use when booting from HDD.

Some info about those CNF files:
The screen offset is specific to my TV and might not suit yours.
Since I boot from HDD I have DISC CONTROL set to OFF.
I always use RESET IOP: ON (I recommend it for you too)
I always use original (japanese) key mapping, O:OK X:Cancel

Best regards: dlanor

[zzthex]

Thanks dlanor! You are teh awesome!

As for why I wanted to know all of this:

I can only boot via swap magic, I have no way of getting a file from the ps2 to the PC, and I'm going to make different discs with different apps, so each disc needs its own config.

I probably should have mentioned all of that in my post, so thanks for replying anyways.

[Slam-Tilt]

E P / Dlanor, how do you guys feels about changing/extending the .cnf in future versions (but obviously keeping uLE backwardsly compatible) ? I have a bunch of ideas I'd like to implement that would benefit from having vaues stored in the .cnf, but obviously we can't just keep adding lines to the existing one.

Obviously in the past you've wanted to stay as close to the offical LE as possible, but now that is dead I guess you have more scope to make big changes ?

What I'm thinking of is an improved menu system that allows options NOT to be linked to buttons, sub menus, and alternative text to display rather than the Elf name. Perhaps the best move would be for me to use a new "menu.elf" and fall back on the values in launchelf.cnf if it's not present.

BTW, That other thing I'm working on hasn't been forgotten, I just haven't had time to doing any coding for a couple of weeks. This Friday is set aside as PS2 coding night :)

[dlanor]

E P / Dlanor, how do you guys feels about changing/extending the .cnf in future versions
That has been a plan of mine for a very long time, mainly to add keyword tokens for all kinds of entries in the CNF, so that we no longer have to rely on the line order to recognize different options.

(but obviously keeping uLE backwardsly compatible) ?
No problem. The first keyword added would be the only one whose position in the file is locked. It would have to be the first option in the file, and would specify the LaunchELF version. Any CNF file not having that keyword would be assumed to have the old format, and would be interpreted accordingly. Resaving such a CNF would thus convert it to the new format.

I have a bunch of ideas I'd like to implement that would benefit from having vaues stored in the .cnf,
Sort of like DOS environment variables, or even the Windows registry, right?
Yes, I too have considered that possibility, and it could be useful.
Especially if combined with a command line interpreter of some kind, for batch jobs. (Another old plan of mine that's been kept 'on ice'.)

but obviously we can't just keep adding lines to the existing one.
Not with the present format, but with a tokenized format there would be no problem.

Obviously in the past you've wanted to stay as close to the offical LE as possible, but now that is dead I guess you have more scope to make big changes ?
True, but even if it were still developed that would not have to stop us. It would just be more difficult to remain compatible with two different CNF formats, each developing in different ways. Fortunately we don't have to :).

What I'm thinking of is an improved menu system that allows options NOT to be linked to buttons, sub menus, and alternative text to display rather than the Elf name. Perhaps the best move would be for me to use a new "menu.elf" and fall back on the values in launchelf.cnf if it's not present.
I see no problem with any such additions to LAUNCHELF.CNF, as long as we assume they are made AFTER switching to a tokenized format.

BTW, That other thing I'm working on hasn't been forgotten, I just haven't had time to doing any coding for a couple of weeks. This Friday is set aside as PS2 coding night :)
Good! I'm looking forward to trying it, so I hope one night will do the trick.

Best regards: dlanor

[E P]

E P / Dlanor, how do you guys feels about changing/extending the .cnf in future versions (but obviously keeping uLE backwardsly compatible) ? I have a bunch of ideas I'd like to implement that would benefit from having vaues stored in the .cnf, but obviously we can't just keep adding lines to the existing one.
It's ok with me. Dlanor has told me before that if we want to add more things to the current setup, it will only become a hindrance to further additions.

Obviously in the past you've wanted to stay as close to the offical LE as possible, but now that is dead I guess you have more scope to make big changes ?
Yes, but now that the original author has given us his blessing, I doubt that it matters anymore. The only issue I can foresee is problems with those that use both versions of LaunchELF and expect to use the same CNF.

What I'm thinking of is an improved menu system that allows options NOT to be linked to buttons, sub menus, and alternative text to display rather than the Elf name. Perhaps the best move would be for me to use a new "menu.elf" and fall back on the values in launchelf.cnf if it's not present.
Many users have wanted the ability to name the apps text in the CNF rather than renaming the ELF's name. Perhaps the menus could also be changed somewhat to better organize everything.

BTW, That other thing I'm working on hasn't been forgotten, I just haven't had time to doing any coding for a couple of weeks. This Friday is set aside as PS2 coding night :)
Good to hear. I have been playing too much with ps2ftpd as of late.

[Slam-Tilt]

It sounds like were all thinking very much along the same lines, which is good.

Once I've got the other thing working properly (hopefully Friday), I'll give the menu thing some thought. As it really requires no PS2 HW knowledge it's probably a good one for me to tackle :)

[ivc]

What I'm thinking of is an improved menu system that allows options NOT to be linked to buttons, sub menus, and alternative text to display rather than the Elf name.
Displaying a custom text instead of the elf name would be perfect, ps2keylauncher is using that approach but it's not updated anymore.

It also would make uLaunchELF a bit more like a dashboard or main system menu with all the essential tools at your fingertips.

Keep it up :)

Edit: To keep this thread consistent, I noticed that the launchelf.cnf format is explained in the uLaunchELF documentation (http://www.ps2newz.net/forums/showthread.php?t=40179).

[Slam-Tilt]

As mentioned in the main uLE thread, the existing CNF format is very limiting, so I want to look at replacing it with something better (obviously with backwards compatability so uLE can still read old CNFs).

So what are people thoughts. I was thinking along the lines of an windows style .INI file with sections marked with square brackets and indetifier=value lines within each section. Obviously we'd need some kind of easy way of telling which version of uLE the CNF is designed for and I'd also like it to support c style comments.

e.g.



[Header]
uleVersion=3.1x

[Colors]
//Default Color Values
color1.r=034
color1.g=034
color1.b=034

color2.r=060
color2.g=000
color2.b=000

[Menu]
Level1.Header=Main Menu

Level1.Option1.Text=PS2Link
Level1.Option1.Button=Triangle
Level1.Option1.Elf=mc0:/BEDATA-SYSTEM/PS2LINK.ELF

Level1.Option2.Text=Emulators
Level1.Option2.Button=None
Level1.Option2.Elf=None
Level1.Option2.MenuLink=Level2

Level2.Header=Emulators

Level2.Option1.Text=Genesis / MegaDrive
Level2.Option1.Button=Square
Level2.Option1.Elf=hdd0:/+Homebrew/Emulators/PGEN.ELF

[Modules]
// Modules to load a startup
AutoLoadPS2NET=FALSE
AutoLoadPS2Disk=FALSE

[Misc]
ResetIOP=True
StopDisk=False



(Don't get excited about the options you see in there, they are just examples.)

Can anyone think of a better way ? Or something that this format can't cope with ?

[dlanor]

As mentioned in the main uLE thread, the existing CNF format is very limiting, so I want to look at replacing it with something better (obviously with backwards compatability so uLE can still read old CNFs).
Yes, I agree completely.

So what are people thoughts. I was thinking along the lines of an windows style .INI file with sections marked with square brackets and indetifier=value lines within each section. Obviously we'd need some kind of easy way of telling which version of uLE the CNF is designed for and I'd also like it to support c style comments.
The precise syntax is not really important. The important thing is that we use something that can fill our needs, and that we use it consistently. But even with that in mind it seems like a fairly good idea to use the '.INI' style, since that has stood the test of time for quite some years now.

----- snip ----- re: example of future CNF contents
(Don't get excited about the options you see in there, they are just examples.)
Yes, of course. The only definite 'must-have' is that the very first entry should be a header of some kind allowing quick recognition of the new CNF style.

Can anyone think of a better way ?
Let's rephrase that, as some people will always feel that the ways they thought of themselves are better... ;)

Can anyone think of ways that would be so much better that they're worth arguing over, even if that delays implementation ? ;)

Or something that this format can't cope with ?
Well, we can always dream up stuff unsuitable for direct inclusion in text-based CNF files. Any type of large-size binary data blocks, for example, as might be wanted for GUI features like icons etc.

But that is no reason to rule against text-based CNF files, but merely cause to look over alternative methods of storing such data. The obvious solution is to store any unsuitable data in separate binary files, and simply refer to them in the CNF.

Best regards: dlanor