[Soulstorm]

Soulstorm: If you want to help just look into SVN and try to compile this on OSX. There are 2 static classes where you might need to reimplement some native OSX funtions, but that shouldn't be too much work (FilePaths and System). The rest is 100% portable. I still can't do it myself cause I don't have a MAC yet.

I will do that. I will update my own Launcher due to a feature request, and then I will look into compiling your Launcher with Qt and performing necessary changes (if any). I will post back when I do this.

[Havner]

I will do that. I will update my own Launcher due to a feature request, and then I will look into compiling your Launcher with Qt and performing necessary changes (if any). I will post back when I do this.

There will be for sure, cause the non-portable code is separated in arch by dirs. And OSX one is empty. I'll prepare some teplate for you (function declarations, project file, etc).

EDIT: Done, qmake project file "should" be ok. For the source look into src/macx dir. For an example of what to expect look into src/win, src/unix.

Functions you'd need to implement:

// returns dir where game executable and "data" dir exist (here's the problem as I dont know whether fs2 data is bundled in .app in OSX or not, never seen it in my life. if it is bundled then this will require some redesign
QString FilePaths::getGameDir()
// returns config dir (f.e. ~/.fs2_open on linux)
QString FilePaths::getConfigDir()
// returns any writeable dir (flags.lch will be written to it)
QString FilePaths::getTempDir()

// runs the command with parameters and eventually waits for the command to finish
bool System::run(const QString &exec, const QStringList &params, bool waitForEnd)
// self explanatory
bool System::runBrowser(const QString &url)
// miliseconds sleep
int System::mSleep(int msec)
// i think you can leave the following as it is
QSize System::getSize()

[WMCoolmon]

Java would be my choice for a Launcher, since it reduces the number of platforms (and compilers) that it has to compile under, and speed isn't an issue here so it wouldn't pose a problem.

However, Qt is more or less as portable for our purposes, and there's no reason why the OS-specific stuff can't go in #defines. The most important thing is that there's somebody willing to support and continue to improve on the Launcher, when needed.

[karajorma]

The problem with Java is that you basically have to make an executable version for Windows users or you start getting complaints that you've given them nothing but a folder full of .class files.

For that reason I kinda prefer QT as it prevents the end user getting hold of the "wrong" version like we've occasionally seen with Turey's installer.

[Soulstorm]

Thanks a lot, although I won't do it now, I will get involved with it when I have the time. If I am not mistaken, I must download the Qt version and install it? Isn't Qt a commercial project? Or it is free for Open Source projects? I remember using it long ago.

Well, I will definitely have a look at it. It is also a good chance to get involved with cross-platform GUIs.

Well, if people here find that version better than mine with more functionality, I won't have any problem to withdraw my version, or at least continue improving it as a side-project.

[Mars]

Haavard Nord and Eirik Chambe-Eng (the original developers of Qt and the CEO and President of Trolltech respectively) began development of "Qt" in 1991, three years before the company was incorporated as Quasar Technologies, then changed the name to Troll Tech, and then to Trolltech.

The toolkit was called Qt because the letter Q looked appealing in Haavard's Emacs font, and "t" was inspired by Xt, the X toolkit.[12]

Controversy erupted around 1998 when it became clear that KDE was going to become one of the leading desktop environments for Linux. As KDE was based on Qt, many people in the free software movement worried that an essential piece of one of their major operating systems would be proprietary.

This gave rise to two efforts: the Harmony toolkit, which sought to duplicate the Qt Toolkit under a free software license, and the GNOME desktop, which intended to supplant KDE entirely. The GNOME Desktop uses the GTK+ toolkit, which was originally written for the GIMP, and primarily uses the C programming language.

Until version 1.45, source code for Qt was released under the FreeQt license — which was viewed as not compliant with the open source principle by the Open Source Initiative and the free software definition by Free Software Foundation, because while the source was available it did not allow the redistribution of modified versions. With the release of version 2.0 of the toolkit, the license was changed to the Q Public License (QPL), a free software license but one regarded by the Free Software Foundation as incompatible with the GPL. Compromises were sought between KDE and Trolltech whereby Qt would not be able to fall under a more restrictive license than the QPL, even if Trolltech was bought out or went bankrupt. This led to the creation of the KDE Free Qt foundation, which guarantees that Qt would fall under a BSD-style license should no free software/open source version of Qt be released during 12 months.

The first two versions of Qt had only two flavours: Qt/X11 for Unix and Qt/Windows for the Windows platform. The Windows platform was only available under the proprietary license which meant free/open source applications written in Qt for X11 could not be ported to Windows without purchasing the QPL edition. In the end of 2001, Trolltech released Qt 3.0 which added support for the Mac OS X platform. The Mac OS X support was available only in the proprietary license, until June 2003, where Trolltech released Qt 3.2 with Mac OS X support available under the GPL.

In 2002 members of the KDE on Cygwin project began porting the GPL licensed Qt/X11 code base to Windows[13]. This was in response to Trolltech's refusal to license Qt/Windows under the GPL on the grounds that Windows was not a free software/open source platform[14][15]. The project achieved reasonable success although it never reached production quality.

This was resolved when Trolltech released Qt/Windows 4 under the GPL in June 2005. Qt 4 now supports the same set of platforms in the free software/open source editions as in the proprietary edition, so it is now possible to create GPL-licensed free/open source applications using Qt on all supported platforms.

[Soulstorm]

Mac? I have no slightest idea. I basically know how .app dirs work. But I dont know whether launcher should be completely another .app, or it should be boundled together with game .app. Tbh I like the latter most. It would solve everything as AFAIR there are some functions to get resources or paths from the .app you run binary from. Still, I dont know what about local config files, I need to check how current fs2 works with that, where it puts them.

I can explain that. At least I can explain how my Launcher works.

The OS X Launcher as it is now includes support for multiple standalone applications. The user may add as many standalone mods at he/she wants in the list of the Launcher. After selecting the location of the mod's application, the program searches the user's Library, and finds all folders which contain valid configuration files and asks the user what is the appropriate folder for the application.

That enables the user to either have a separate configuration file for each mod, either to have one configuration file for each standalone mod!

The Launcher's GUI is almost completely dynamic, and configures itself based on what mods have been added into the Launcher's database. Adding a mod is a matter of 2 clicks.

The Launcher finds the actual executable of the application by peeking inside the bundled .app and finding the info.plist file. It then Launches the application.

So far, that is my approach. I will upload the new source as an example (I updated it today) so that you have an example on how to work on the Launcher.

I haven't used the windows version of the Launcher, and I don't know if it supports multiple standalone mods, but if a Launcher comes out for OS X, I think it would be nice not to abandon this feature. The good news is that in OS X it is possible to do such a thing, as all standalone applications put their configuration files into the user's Library.

[mr.pancakes]

I'm a little bit confused on how to even go about 'making' this into a launcher.  I'm not as seasoned in using linux as the rest of you.  All I do know is that I'm able to unpack the file (make it into a folder on my desktop with stuff in it).

I have really no idea where to go from there to make this work.  If anyone could give me a step by step for 'dummies' on how to do this, I'd really appreciate it.

[Havner]

EDIT: Ok, I've read WMC's post once more and found a thing I missed first time. FS2 binary uses hard config file as well to see which home config dir it should use. This is much better then above (another cmd line flag). I suppose that if it wont find it it assumes HOME/.fs2_open (or any other thing on other platforms, where launcher would assume the same). So if devs would agree on that please implement it in SVN, so I could move one. Additionally I'd like dev to speak on hard config file name and its content. (still launcher6.ini with additional section? this could be good as TC could provide defaults for flags f.e.).

This way we really could have one fs2 and one launcher binary for all the TC's.

Is it really once? As far as I can tell Linux got only two official releases, FS2 and BTRL. Each of them has different home config dir (~/.fs2_open and ~/.btrl_demo) and they are hardcoded. WCS and TBP doesn't have any, but I made compilations of them for myself and hardcoded their dirs as well (~/.tbp, ~/.wcsaga). So the binaries differ in the same way launcher one would.

Taylor has mentioned removing that problem in 3.6.10 IIRC. I'll have to wait and see how he's doing it though since I don't remember the details.

Karajorma, WMCoolmon, any news on this issue?

[S-99]

I can explain that. At least I can explain how my Launcher works.

The OS X Launcher as it is now includes support for multiple standalone applications. The user may add as many standalone mods at he/she wants in the list of the Launcher. After selecting the location of the mod's application, the program searches the user's Library, and finds all folders which contain valid configuration files and asks the user what is the appropriate folder for the application.

That enables the user to either have a separate configuration file for each mod, either to have one configuration file for each standalone mod!

The Launcher's GUI is almost completely dynamic, and configures itself based on what mods have been added into the Launcher's database. Adding a mod is a matter of 2 clicks.

The Launcher finds the actual executable of the application by peeking inside the bundled .app and finding the info.plist file. It then Launches the application.

So far, that is my approach. I will upload the new source as an example (I updated it today) so that you have an example on how to work on the Launcher.

I haven't used the windows version of the Launcher, and I don't know if it supports multiple standalone mods, but if a Launcher comes out for OS X, I think it would be nice not to abandon this feature. The good news is that in OS X it is possible to do such a thing, as all standalone applications put their configuration files into the user's Library.

OMG that's over the top and a little unnecessary. Because i guess everyone wants to load a mod in a different resolution, color depth, and texture detail than the last one they played? It's my experience that most mods are just as graphically intensive as fs2 open with the media vp's.

Plz keep on keepin' on with turning your fs2 open installation into your next operating system.

The windows launcher is pretty uncomplicated. When you want to load a mod, you just have the launcher select a different mod. The windows launcher doesn't have a list for mods, when you want to load a new one, you just select that mod's directory and you're ready to play a different mod. And then the configuration for stuff like sound and resolution gets saved in one config file, not a config file per mod.

[Soulstorm]

OMG that's over the top and a little unnecessary. Because i guess everyone wants to load a mod in a different resolution, color depth, and texture detail than the last one they played? It's my experience that most mods are just as graphically intensive as fs2 open with the media vp's.

The windows launcher is pretty uncomplicated. When you want to load a mod, you just have the launcher select a different mod. The windows launcher doesn't have a list for mods, when you want to load a new one, you just select that mod's directory and you're ready to play a different mod. And then the configuration for stuff like sound and resolution gets saved in one config file, not a config file per mod.

Actually, setting up a new mod is a matter of 2 clicks. And then, you can select any mod you want from the launcher, without each time selecting a new directory. I prefer having all of my mods into a list, not search every time the directory of a mod. And each mod saves its configuration into the Library forlder of each user. The config file for each mod is created by the mod itself. The Launcher launcher only reads the config files for each mod, as intended to be by the developer of the mod.

[smurd]

Is anybody else having problems with the latest fsport release and yal? I installed the port as recommended, i.e. mv_fsport.vp and it's mod.ini to $fsdir/fsport-mediavps and the rest to $fsdir/fsport. The mod.ini in fsport-mediavps says:

Code: [Select]

[multimod]
primarylist  =
secondarylist = fsport,mediavps
The mod.ini in the fsport directory says:

Code: [Select]

[multimod]
primarylist  = fsport-mediavps;
secondarylist = mediavps;
When I select the fsport-mediavps mod in the yal, it will use

Code: [Select]

-mod fsport,fsport-mediavps
which means that the mediavps mod is missing.
When I select the fsport mod, yal uses

Code: [Select]

-mod fsport-mediavps
which means that most of the fsport data is no available (including the fsport campaingns in the campaign room).

The correct option for the fsport-mediavps mod should be

Code: [Select]

-mod fsport-mediavps,fsport,mediavps[/fsport]




[chief1983]

Why are you setting it up like that?  Leave the mod.ini in the fsport directory alone.  The intent was that you could play the port without the MediaVPs by selecting it as a mod, or with the mediavps by just selecting the fsport-mediavps as a mod.  Either way, it does sound like there might be a bug with a hyphen similar to the bug in the Windows launcher.  But you could just rename your port mediavps folder to fsportmvps to get around it for now.

[Havner]

I'll look into it. For now just simplify the dirs and mod.ini files as Chief suggested if you want to play with mediavps anyway.

[smurd]

Thanks for your quick answer, but the mod.ini in my fsport directory is the very one from fsport3_1.zip, I didn't change anything in it. I just extracted the zip file again just to make sure that nothing was mixed up. That one should go to the fsport directory, right? Well, here is the content list of both dirs, just to make sure my setup is not somehow broken:

Code: [Select]

fsport:
FS1OGGcutscenepack.vp
fsport3_1.vp
fsport.bmp
fsport-hi_res.vp
fsport-missions.vp
mod.ini
readme.txt
sparky_hi_fs1.vp
stu_fs1.vp
tango_fs1.vp
warble_fs1.vp

fsport-mediavps:
fsport-mediavps.bmp
mod.ini
mv_fsport.vp
Adding missing semicolons to fsport-mediavps/mod.ini doesn't change anything.

[Havner]

Just put everything in one 'fsfport' directory and modify mod.ini to include only 'mediavps' dir.

[smurd]

Well, yes, it does. By the way, I also noticed that the original mod.ini files from the archives
use "secondarylist" (see the additional A?), which yal ignores, opposed to "secondrylist", which is also used in
all my other mod.ini files, and which is regognized by yal. I leave it up to you if this is a bug in the mod.ini or
in yal, because I can't find documentation that explains the mod.ini format exactly enough. Thanks anyway for
your answer.

[Havner]

There is no documentation I'm aware of. I had problems as well implementing it, how should it be done, etc. The only thing is reference in windows launcher which appeared to have bugs as well. Secondrylist was intentional. Don't remember why I did it, but that was connected to windows launcher in some way. Adding the other as well won't be a problem.

[smurd]

It also looks like your suggestion does, after all, not quite like desired. I just noticed that, if I copy the
mv_fsport.vp file to the fsport directory, the ship models used in it are not displayed in the lab. Instead, the
standard models are used. It seems like the old ones take precedence over the better ones because of the
loading order. When I rename mv_fsport.vp to 0mv_fsport.vp, the high quality models are used, probably due
to the changed loading order (the fs2 log also shows the changed order of the vp files as they are found).

[Havner]

Yeah, you seem to be right about load order.

I'll be laying my hands on the newest fsport soon if time allows. I'll try to fix yal to behave better in this case.