[Soulstorm]

POST LAST EDITED: April 09, 2007

I changed the post so that users do not have to search the entire thread to find out what they are looking for.

Well, I thought I might as well make a new post in this old thread to notify about the changes that have happened in the application.

The application has reached 1.1 status, and it's available here. Changelog is available here, and the readme is available online here.

I strongly urge everyone to download the newest version. This is no more a beta. It has tons of bug fixes, more comprehensive documentation, updates checking, improved mod support, and many more things that I am really bored to mention here.

Perhaps the greatest addition is the "Check for Updates" option, which uses Sparkle for OS X. It's a nice feature, but I have made some changes that may break compatibility with the FS2_Open Installer. If that is the case, please pm me or send me an e-mail.

I strongly recommend you use this application instead of messing with the .cfg file, since the cfg file may give you a lot of headaches.

Once more, get the application here.

HERE IS A SCREENSHOT

Please read the instructions! And report any bugs in the links provided with the app!

[Hazaanko]

Nifty.  Should save some hassle in bug testing.  Nice work, man!  Hats off to yeh.

[Bobboau]

there is suposedly some way to comunicate with FSO to get a detailed description of all comand line options, this is how the current generation of win32 launchers works, I don't know if you are useing this, or if you just looked everything up, but if you didn't know that maybe you can use that.

[WMCoolmon]

It's "-get_flags", you can find the file format code by doing a search for get_flags_arg in cmdline\cmdline.cpp

However this is getting somewhat disorganized...by my count, this makes at least 4 separate launcher-style programs for the three supported platforms, along with the several methods of FS2_Open install. And no centralized download source or listing for any of them.

[Soulstorm]

It's "-get_flags", you can find the file format code by doing a search for get_flags_arg in cmdline\cmdline.cpp

I downloaded the source and found -get_flags. But I have no idea how can I use it. If someone could give me a hand, and explain how I could access the results of this command line argument using C++ (or C, it's the same for me), I could very easily use that for the development of the Command Line Organizer.

WMCoolmon, seems you have been involved with the source. Have you any idea how can I communicate with FSO to receive the info produced by the -get_flags command line argument?

[karajorma]

From what I can see from a brief look at the code the launcher runs FS2_Open with the -get_flags option. This runs the game and creates a file called flags.lch. The game then exits. The launcher then reads this file to determine which flags exists and then deletes the file.

Take a look at the ConstructFlagList() function here to see how the windows version deals with that file.

[Soulstorm]

From what I can see from a brief look at the code the launcher runs FS2_Open with the -get_flags option. This runs the game and creates a file called flags.lch. The game then exits. The launcher then reads this file to determine which flags exists and then deletes the file.

Take a look at the ConstructFlagList() function here to see how the windows version deals with that file.

Got it. All I have to do every time is to run FS2_Open with the -get_flags option. When the application quits, I will read the produced .lch file and modify the menus and buttons to use that. The current version of the Organizer is built on static menus. That means that I simply have read the freespace wiki and implemented all the actions inside. I was careful to program the application in a way that it is highly maintainable and revisable (since I wanted to update it each time a new beta comes out with changes to the command line).

Using the .lch file means that the app will always be up to date with the most current settings. However, I think I won't use the parsing methods that the windows launcher uses for the file. Using those means ignoring the powerful methods described by the Foundation framework.

In a couple of days, when I have the time I will upload a small update of the Organizer, which will add options for screen resolution and color bits. I almost have it ready. However, the .lch file means writing a lot of code, especially since I will want to find a new method for parsing the file using Objective-C. I am now trying to find the pattern in which the file is generated, so that I can finally begin to write code.

WMCoolmon, the application is NOT official and supported by any of the fs2_open staff. I took the plunge to write the application on my own just for fun, and because I caught myself using many times the command-line file. The file is uploaded into my personal webspace that I have been given from my ISP. The only relationship I have with the fs2_open is that I had laid my hands on the very first betas for OS X (years ago) and I have been one of the first people to have managed to do a full installation of FS2_Open on OS X. That's why I have made many posts with instructions in various places explaining things. I'm just a die-hard fan. That's why some things are indeed disorganized. When people with no particular involvement in the development make programs for an application (like me), that means confusion among other things that are not necessarily bad. I just wanted to have a GUI command line program for OS X, that's all.

[WMCoolmon]

Obviously discouraging personal developers would be contrary to useful to FS2Open. But I fear the same sort of problem that's plagued Linux, where you have several programs that do the same thing, each with its own merits, all continuing independently under the guise of "choice". EG in the case of music players, one might play OGG files but crash often, another might be rock-solid but only play .mid and .wav files, another plays OGG files but isn't supported for the platform you're using, and the developer lost interest before they ever released the source. Another implements a full media library, but uses outdated and extremely slow and buggy code for all types of files.

In the end if all developers had pooled their resources, they could have made one great program. But instead each chose to focus on a different aspect; versatility, minimalism, functionality, or on one particular feature. If you'd had the first guy making everything crossplatform, the next guy optimizing everything, the third guy writing the basic file loading library, and the last guy writing the library interface, you might've had a fully-featured, robust, crossplatform program. But because they all chose to focus on their particular goal, none of the programs are particularly usable.

(This is only an example; I haven't used Linux media players extensively for quite awhile, and they weren't that bad even back then. But they make a good example. )

In the case of fs2_open, this is made even worse because nobody has bothered to make centralized download lists for many of the applications and packages and campaigns related to fs2_open. So even if a choice exists, somebody finding one particular program isn't going to realize this. (In the above example, if the minimalist MIDI/WAVE player was the only result of a google search for 'media player', one might erroneously conclude that there was no OGG or media library in existence under Linux.)

[Soulstorm]

I am not discouraged by any means. How can anyone who is doing something for fun be discouraged?

I haven't been able to find any launcher for OS X. That's why I thought I should make something that fills this gap. Unlike any other devs that you may have in mind, I am always trying to hear what other are saying about the way I should organize and make my application, because: 1)I am 20 years old. How can a 20-years old person surpass the experience of older people? 2)Because of all the things you described above.

Actually, the many-programs-with-little-functionality problem is a problem that concerns software in all platforms, even OS X and windows. As far as FS2_Open is concerned, I know the problem, that's why I have made these posts in many forums, to gather all information into one post.

Anyway, if I seem to be intimidated by the project, I will give the source code, for anyone else to continue this little application. And if someone comes up with a better solution, I will stop the project, since there will be no need in continuing it. I'm sure there are better coders in here than me.   

[karajorma]

@WMC :  As far as I'm aware we currently have the windows SCP launcher, Mac OS X launcher from this thread and the Linux one from here. Unless you're counting the retail launcher or I've missed one I don't see how you're counting 4 launchers.

As long as we don't get anyone new coming along and making something we basically have what we need. We can simply get behind these guys, get them to upload their code to CVS and then we're done.

[WMCoolmon]

I'm actually counting the one that Taylor's working on as well.

[karajorma]

Well we're not seeing that one for a year. These are basically stopgaps until that one comes out.

[Soulstorm]

Taylor is very busy working on other things on FS2_Open atm. He stated that he would release a launcher for OS X, but that was a long time ago.

NEW RELEASE

NOTABLE CHANGES:
--Moved from Obj-C to Obj-C++ (parsing in Cocoa is really difficult an requires a lot of code)
--Implemented options for changing screen resolutions.
--Application will load the existing resolutions from the default location.

BUG FIXES
--No longer will the application crash if it doesn't find the default folders in the user's library
--No longer will the application create a zero kbyte file if no command line arguments are selected by the user. Previously, that happened occasionally, and when the application tried to load data from that file, it crashed.
--The application will create the default necessary structure of files inside the user's library. That means that it is no longer necessary to have ran the FS2_Open application at least once. If the default files are not found in place, the application will create the basic structure of the folders and the 2 files it needs to process, and it will fill the fs2_open.ini file with default options.
--Code enhancements (although you may not be able to notice that).

Enjoy!

EDIT: I forgot to give you the download link. Sorry for that. Actually, it's the same as the old one.

[Soulstorm]

Sorry for the double post.

I have been trying to get involved with the .lch file. The fact is that I have been trying to find the characters that separate each command line. Although phenomenally we have a plain straight-through string, I know that there are hidden characters. I know that because when I try run the write-cursor one letter at a time, it always get stuck into some points and refuse to get going until I hit the right arrow many times.

Since I haven't been able to find out what those characters are, I can't write any code. So, I approached the problem the other way. I looked into the FS2_Open source, and into the Launcher source, and I haven't fully understood what is going on yet, but I will. One thing that disturbs me, though is that although C++ is used for both programs, plain C functions are used for file i/o. I haven't used those functions extensively (I always did file i/o in C++, and I really love the way it works), so I may need to consult a book or two in order to find out what to do (I learnt C++ with no C background). Another thing that disturbs me is that I can't open the whole project in Xcode, especially in the case of Launcher (since many platform-specific functions are not supported by OS X). That renders finding strings and method definitions and declarations pretty hard. I rely on spotlight for that problem atm.

If I end up figuring out what to do, I will rewrite the Organizer, to use dynamic menus, buttons, etc. Again, any info or help would be appreciated. And please, can anyone verify if the version I have given here works as expected? Are there any errors?

[taylor]

Can you post the code that you are using to read the .lch file?

There aren't any special characters though, it just sounds like you aren't reading the struct info in correctly.

[Soulstorm]

I haven't written any code for the .lch file yet yet. I don't have much time for programming these days (I have my exams in the university coming up). I will look at it, though. 

One point I should mention though, at first I tried NOT to use the struct info, but just simply parse the file, using a way on my own. Later on, I found out that this wasn't possible. So, it seems I will use some code from the Launcher and the FS2_Open source, although I haven't had the time to figure out how yet. Just need to look at these plain C books for C i/o again

[taylor]

Yeah, you'll deffinitely have to read in the entire struct.  As far as the C file i/o goes, you should be able to get the info you need by opening up Terminal app and doing a man fopen, man fwrite, and man fclose.  Those should be the only three functions that you need to read the file contents.

Other than that I think that the only thing to remember, or a least keep in mind, is that the .lch file is the only thing in the game which uses host endian ordering.  So you won't have to worry about byte swapping or anything, since it will be in native order for each machine that uses it.  That's why it's important to delete the file after you have read in it's contents.

[Soulstorm]

Taylor, thanks for all your help. Using C++, I managed to correctly parse the .lch file and load all of its contents and store it into a container, with all their info.

However, now comes the difficult part: Making those dynamic menus into my application. That will be tough, since the application as it is now, uses statically created menus. One thing I need to know though. Is there any way I can see from the .lch file which command line arguments accept an argument and which of these are just on-off switches?

[taylor]

However, now comes the difficult part: Making those dynamic menus into my application. That will be tough, since the application as it is now, uses statically created menus. One thing I need to know though. Is there any way I can see from the .lch file which command line arguments accept an argument and which of these are just on-off switches?

Anything in the .lch file is an on-off switch.  The format of the .lch, unfortunately, doesn't support arguments so we just don't put any commands which require an argument in that file.  This will be fixed with the new cross-platform launcher that I'm working on though (but won't show up officially until late this year or early next year, and won't support current builds).

Anything that uses an argument you will have to handle statically.  We don't tend to change those nearly as often as the on-off ones though, so they should be easier to deal with statically than the on-off switches would be.

[Soulstorm]

That's good news. No, really. I hate messing with NSMatrix too much when creating dynamic interfaces. Anyway, I have now a general idea of what I must do, thanks a lot for your help. I don't know how much time this will take me though, since I have the exams in the university this month, and unfortunately, none of the lessons I will be examined involves programming (so that I could fool myself of doing work that will improve my programming skills that are needed for the lesson )...