[Soulstorm]

I managed to read the .lch file and import all the data needed. The dynamic menus are ready, file loading works like a charm etc. But iI stumbled into a very important detail:

I will need to call the actual FS2_Open executable, let it create the .lch file, and then load that file, right? I have some questions.

1)In terminal, I found that when I call the actual executable with the -get_flags argument, it produces the .lch file inside my home directory without having to mess with the command line file. But if I give in the command line file the -get_flags argument, the .lch file is produced into my startup disk. Why is that?
2)In C++ I am having problems with the 'system' command. Supposedly I have a string (an STL string I mean) containing the path to the executable. I want to produce this command in order to work:

Code: [Select]

"/GAMES/FreeSpace2/FS2_Open 3.6.9.app/Contents/MacOS/FS2_Open" -get_flagsBut I really can't do it. My code is:

Code: [Select]

string s([[openPanel filename]cString]);
s = '\"' + s + "/Contents/MacOS/FS2_Open\" -get_flags";
system(s.c_str());Which does not work (actually, that line does nothing at all). But the same string, when given in the terminal, works. Taylor, what do you use to produce the flag.lch file in OS X without having to mess with the command line file?

[taylor]

1)In terminal, I found that when I call the actual executable with the -get_flags argument, it produces the .lch file inside my home directory without having to mess with the command line file. But if I give in the command line file the -get_flags argument, the .lch file is produced into my startup disk. Why is that?

The .lch file is created without a path, which means that it will go into the working/current directory.  When run through Finder, the currently directory is always your startup disk (I think, technically it's "/").

You could have your code change the current directory (to something like ${HOME}), then run with the command line argument, read the file contents into memory, and delete the file.  That should also get you around any permissions/security issues as well.

2)In C++ I am having problems with the 'system' command. Supposedly I have a string (an STL string I mean) containing the path to the executable. I want to produce this command in order to work:

<snip>

Which does not work (actually, that line does nothing at all). But the same string, when given in the terminal, works.

Have you verified that the actual result of "s" is what the string that you intended?  What is the return value of the system() call?

[Soulstorm]

Thanks taylor, the advice with the permissions was useful, since I hadn't though about it.

But actually, I found out that it is an Xcode problem. When ran from the Finder, the application works as expected. But when ran from the Xcode's 'buid and run' option, it doesn't handle the file paths correctly. Actually, the -get_flags file was indeed produced, only that it was produced inside the folder with the executable. This shouldn't happen especially since I had given commands to use the user's home directory as the current working directory. The solution was to give the commands another way. I have written the same commands in Objective C and they worked, even from the Xcode. Problem solved.

I finished nearly every thing I wanted to do. I had to implement preferences support (a file named "com.soulstorm.FS2_Open cmdline.plist" in the Preferences folder which lies into the current user's Library) mess with the terminal a bit, but I have done it.

The only thing that I don't know yet is wether it will work on other machines. What happens if the FS2_Open application won't be able to produce the flag file before the FS2_Open Command Line Organizer asks for it in the user directory? I have ran extensive tests on my machine, but that is a G5. So, the application will need some testing by other people before I consider to remove the old version. I will upload it one of these days, when I wrap up the source code a bit and add some error handling.

[taylor]

The only thing that I don't know yet is wether it will work on other machines. What happens if the FS2_Open application won't be able to produce the flag file before the FS2_Open Command Line Organizer asks for it in the user directory?

It really shouldn't be an issue.  The system() command won't return until the shell exits (so that it can get a return value) which means that unless you did some rather complex things to make it work asynchronously, the .lch file will always exist when you go to read it, regardless of how fast or slow the machine is.  But, it would be a good idea to test for the .lch before you really try to operate on it.  I'm not sure if you are using fopen() to grab the file, but if you are then just check that it's return value is not NULL, and if it is then handle that case occordingly.


And one thing that I don't really see in the screenshots, does it handle mods at all?  That is still one thing that's pretty annoying, since you have to manually edit cmdline_fso.cfg in order to switch between mods.  Having the ability to change all of that in a GUI would facilitate more (and far easier) use of the various mods that are available (like FSPort, Derelict, Sync, Transend, etc.).

[Soulstorm]

NEW RELEASE (BETA!)

New version offers a number of changes and introduces new bugs!

NOTABLE CHANGES:
--Ability to launch FS2_Open though the application (warning: You must 'save the changes to file' first!)
--Dynamic menus. Now the application will load the available command line arguments from the FS2_Open application

NOTES
Due to the second 'notable change', I had to implement some things, such as the text field that holds the application location into the HD. The first time the application opens, it asks for the location of FS2_Open into the HD. It keeps that location into the preferences. The preferences file is named "com.soulstorm.fs2_open cmdline 2.plist" and resides into the Preferences folder inside the current user's Library. You may want to delete it if something goes wrong and need to reset the application.

You will have the ability to change the default location of the FS2_Open application at a later stage. When you do that, you will be prompted to restart the application. That is due to a terrible bug that I hadn't had the time to fix, and concerns the loading of dynamic menus. By restarting the application, you are avoiding this.

TO BE FIXED:
--The restart after the change of the application path. It will be removed.
--Custom mod support will be improved.
--Bugs will be fixed.
--Maybe loading of custom flags.lch files will be implemented.
--Tooltips will be implemented at a later stage.
--The whole appearance of the application will be improved

Get the application here.

Guys, please note that I really need some testers to verify which parts of the application work and which of these don't I would appreciate ANY feedback, since I have only tested the application into my G5. Notably I want someone to answer these questions:
--Do all the command line arguments show up correctly?
--Does the application crash unexpectedly?
--Does it write to the files every command line argument as it should?
--Does it load the mod it was supposed to load?

And one thing that I don't really see in the screenshots, does it handle mods at all?  That is still one thing that's pretty annoying, since you have to manually edit cmdline_fso.cfg in order to switch between mods.  Having the ability to change all of that in a GUI would facilitate more (and far easier) use of the various mods that are available (like FSPort, Derelict, Sync, Transend, etc.).

taylor, the only thing I have been able to do is to implement a text field to represent the '-mod' command line argument. You can see that on the picture. I know that this may not be enough. I have an idea of what can I do to make it better (scan the FS2_Open folder for mods and represent their names into a contextual menu) but that I will look into it at a later stage. To be honest, though, the -mod support should work correctly (why shouldn't it? it only adds the -mod argument into the command line file) although I hadn't had the time to test it using any mods. Can anyone verify if it works correctly?

I am expecting feedback into this one. If you have any problems using this beta, you can switch back to the old stable version I gave you earlier on this thread. The two applications will work fine with each other.

[attachment deleted by admin]

[Soulstorm]

So, anyone with any opinion yet? Does it work?

I have the newest version ready, just waiting on anyone to tell me wether this app works as it is now or if it needs any enhancements or bug fixes. That way I can ensure that the newest version works correctly. Taylor, do mods work with the application? Have you tried it?

[taylor]

Taylor, do mods work with the application? Have you tried it?

Not sure, haven't tried it out myself yet.  It's on my list of things to do this weekend though, so I'll let you know how it works out for me in another couple of days.

[Soulstorm]

Thanks. Although the most important version is the new one. I hope I will upload it tomorrow.

One of the most useful things is that it can load external .lch files and load flags form that. Another thing I have added is the ability to change the applications and reload the menus without having to restart the application. Startup time should be improved too. Some bugs have been fixed (erros that would happen if the user did something wrong).

I will try to finish that thing by tomorrow by correcting some minor but annoying problems, and I will post it here.

[Soulstorm]

NEW BETA

In looks, it's the same as the old one. But here's what is implemented in this version.
--Removed the restarting of the application after the FS2_Open application path was changed.
--Fixed some bugs.
--Added the option to load custom .lch files. Note though, that if you load the custom .lch file, the next time the Organizer launches, it will NOT LOAD THE CUSTOM FILE! Loading will again be done from the FS2_Open executable whose path is set by you in the appropriate field.
--Added the option to disable all options with a simple click (it's on the menu).
--Tooltips were implemented. They will be loaded from the flags.lch file.

Note that even if this version is more stable than the last one, there may still be problems. If you encounter any bug, or have any recommendation, please tell me so.

[attachment deleted by admin]

[Soulstorm]

Anyone with any report? Does it work as expected? (sorry for the triple post)

[karajorma]

That's okay. It's a point worth mentioning.

I'll see if anyone on the BtRL team is going to be testing stuff on the mac and point them over here if they are.

[chief1983]

I verified that Turey's installer works with Mac OS X a while back, you might want to see about getting this launcher included with the OS X binaries that his installer currently grabs, once he starts working on it again.

[Turey]

I verified that Turey's installer works with Mac OS X a while back, you might want to see about getting this launcher included with the OS X binaries that his installer currently grabs, once he starts working on it again.

I'm always open to new files to include. He can submit his launcher just like a mod. Just follow the information on this page.

[Soulstorm]

I'm always open to new files to include. He can submit his launcher just like a mod. Just follow the information on this page.

OK. I will check it tomorrow. There are some thing I want to implement, but actually, with a first look, I can update the application just by replacing the old binary with the new one without notice, right?

I have been receiving some feedback from another forum... It would be nice if I added a feature that would tell when the last update to the cmdline_fso.cfg file happened. Taylor, is there any way I can write any data to this file without being parsed by FS2_Open? (for example, by adding a '//' at the beginning of the line should tell the FS2_Open to not parse this line). If not, then I think I will have to use the Finder's own method for viewing modification dates.

I am hearing that the application works well at the moment, although at some point I am going to sit down and do some major changes. But that will happen after I finish the exams (I don't know if someone knows what happens with the current educational institutes here in Greece the last 2 months, but I can assure you things are pretty messed up)!

Turey, I will give you the application tomorrow in .zip format, with the txt file you are describing. I have also solved the problem of a permanent file host long ago (the same server as my website, actually). After that, need I notify you for every update I make to my application or is this handled somehow by your application?

[chief1983]

Yup, just swap out the hosted file, and when he runs an update it should notice that the file size has changed and offer to update it.  I'm thinking that's how he currently has it working anyway.

[Turey]

OK. I will check it tomorrow. There are some thing I want to implement, but actually, with a first look, I can update the application just by replacing the old binary with the new one without notice, right?

Pretty much. All you'll have to change is the VERSION string in the text file.

Turey, I will give you the application tomorrow in .zip format, with the txt file you are describing. I have also solved the problem of a permanent file host long ago (the same server as my website, actually). After that, need I notify you for every update I make to my application or is this handled somehow by your application?

If you're just zipping up a .dmg file, you can just use the plain .dmg file instead.

To update, simply change the VERSION string in your text file. No need to notify me.

[Soulstorm]

OK. I will check it tomorrow. There are some thing I want to implement, but actually, with a first look, I can update the application just by replacing the old binary with the new one without notice, right?

Pretty much. All you'll have to change is the VERSION string in the text file.

Turey, I will give you the application tomorrow in .zip format, with the txt file you are describing. I have also solved the problem of a permanent file host long ago (the same server as my website, actually). After that, need I notify you for every update I make to my application or is this handled somehow by your application?

If you're just zipping up a .dmg file, you can just use the plain .dmg file instead.

To update, simply change the VERSION string in your text file. No need to notify me.

I think we are all set, now that you have the proper .txt file and the file uploaded into a permanent server. I hope you take the time to notify me if and when the file will be included.

[Soulstorm]

new beta. Changed the first post so that users do not have to search the entire topic.

[Soulstorm]

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.

[Turey]

What's Sparkle? The site seems to be down, and the Wikipedia article is useless...