[chief1983]

I have to agree with Kara, I'd have rather not seen it have to be built for every mod, and use a config instead.  It can only get harder to maintain as more mods get released, SoL will be out eventually, DaB is working on a micro machines mod, SWC will eventually be out, TAP, etc...

[Havner]

I have to agree with Kara, I'd have rather not seen it have to be built for every mod, and use a config instead.  It can only get harder to maintain as more mods get released, SoL will be out eventually, DaB is working on a micro machines mod, SWC will eventually be out, TAP, etc...

Ok, so you got a situation where you have all those 10 total conversions installed on your system and want to have a launcher in PATH dir. What would be config files of those? Every single launcher would have to have different config file so still they would have to be build for a specific mod. Just take look at my sources and see how conversions are handled now. I consider it clearer. And like I wrote before, adding new one is few seconds of work.

When a new conversion will be out, I'll add it, thats really no problem. And having a launcher with another config file and few images would be a pain for windows. And it has to be another config file then launcher6.ini cause for Linux, when launcher is not in game dir it wont even be able to find launcher6 yet without knowing the gamedir.

You want me to implement it? I can, but tell me specifically how you see it (both cases, launcher in game dir using current dir for gamedir and launcher in PATH which has to find <different> config file for every game). For me redistribution of that would be pain and for the second case it'd still have to be recompiled for every TC separately.

[chief1983]

The config file would have to be edited, but the launcher would be the same, that's the point.  Launcher would be in game dir, yes.  Sure there's more than one copy, but they're all the same exe so I don't see how that's any more complicated.  Just look for one config file and go from there, so you only have one build, etc.  Just sounds easier to me.

[Havner]

The config file would have to be edited, but the launcher would be the same, that's the point.  Launcher would be in game dir, yes.  Sure there's more than one copy, but they're all the same exe so I don't see how that's any more complicated.  Just look for one config file and go from there, so you only have one build, etc.  Just sounds easier to me.

When you think the windows way, yes, you're completely right. The point is its not only for windows. Running launcher from the game dir under Linux is strange, its not the way programs are usually written, they are run from PATH dir. I mentioned all of this in previous post. So the launcher doesn't have to be in game dir, but still it has to find the game. Thats the case I'm talking about. And your solution complicates things in this case giving nothing in return (the launcher would have to be recompiled for every TC anyway).

Like I said, if you're really for this solution I can do it, just there would have to be some agreement on how it'd look like. I'd really like Taylor to post his opinion on this.

[chief1983]

Then each launcher should be named differently, so as not to conflict with similar entries in the PATH variable.  Although I don't normally hear of people launching a game from the commandline via something set in your PATH variable.  To my knowledge, when you install fso on linux or mac, the binaries still all reside in the folder, they don't go to some location that had been specified in the path.  If you wanted to put the launcher in the path, separate from where the games are installed, I can see how that would be an issue, but I don't think that's anything anyone does.  If you wanted to put each game's directory in the PATH var, you could have each launcher named something different, but don't most linux advocates recommend not relying on PATH anyway, and using full paths to launch a program?  Maybe that's only when executing operations as root, I'm not sure.  So I'm starting to see how it might be an issue, I just think there are better ways around it.  Relying on PATH to run the launcher seems like a bad idea to me.  I say run it directly or make a shortcut on your desktop environment.

[Havner]

Then each launcher should be named differently, so as not to conflict with similar entries in the PATH variable. 

Of course it is, you didn't even check it, did you?

Although I don't normally hear of people launching a game from the commandline via something set in your PATH variable.  To my knowledge, when you install fso on linux or mac, the binaries still all reside in the folder, they don't go to some location that had been specified in the path.  If you wanted to put the launcher in the path, separate from where the games are installed, I can see how that would be an issue, but I don't think that's anything anyone does. 

For fs2 you can't tell because there is no coherent install method. For btrl yes, they are put in PATH dir and that's for the whole btrl_demo (or fs2_open) script is for, to find the game dir when it's not being run from it.

If you wanted to put each game's directory in the PATH var, you could have each launcher named something different, but don't most linux advocates recommend not relying on PATH anyway, and using full paths to launch a program?

Erm? You dont put game dirs to PATH var, you put some script/bin to a dir thats already in a PATH. You still seem to think the windows way. And the thing about linux advocates, totally not true. You can't even say about recommending or not recommending. Its just done this way, since years, since the begining.

Maybe that's only when executing operations as root, I'm not sure.  So I'm starting to see how it might be an issue, I just think there are better ways around it.  Relying on PATH to run the launcher seems like a bad idea to me.  I say run it directly or make a shortcut on your desktop environment.

You can't think about relaying or not on PATH, ist just the way things are done, they way things work, on the most basic level.

[karajorma]

Ok, so you got a situation where you have all those 10 total conversions installed on your system and want to have a launcher in PATH dir. What would be config files of those? Every single launcher would have to have different config file so still they would have to be build for a specific mod. Just take look at my sources and see how conversions are handled now. I consider it clearer. And like I wrote before, adding new one is few seconds of work.

Let me give you a counter scenario. 3.6.10 is out. We're ready to release. Someone points out that there is a typo in the welcome tab. Now you have to rebuild all 10 builds again just to fix a typo. Suppose Mantis changes servers, again you have to rebuild.

The advantage of using a configuration file is that anyone can change them. You don't have to be a coder, you don't have to have the ability to compile, you don't even have to have the operating system you're writing the config file for. You simply need a text editor.

[Havner]

Let me give you a counter scenario. 3.6.10 is out. We're ready to release. Someone points out that there is a typo in the welcome tab. Now you have to rebuild all 10 builds again just to fix a typo. Suppose Mantis changes servers, again you have to rebuild.

The advantage of using a configuration file is that anyone can change them. You don't have to be a coder, you don't have to have the ability to compile, you don't even have to have the operating system you're writing the config file for. You simply need a text editor.

You released 3.6.10, and there was some major bug that was caused by a simple typo in a code. Somehow you don't expect people to fix it by a text editor. Launcher (any launcher in the case you described) would be considered as a part of release. Why should it be different? (Not mentioning that a Welcome tab text is written since a long time and doesn't seem to be changed that often).

Completely on the other hand, I just wrote an alternative launcher, was trying to be helpful (at least for the minority of Linux guys like me that might be outthere somewhere), noone ever said that this would ever be considered as a part of the official release and I never asked for that. Additionally I _completely_ get your arguments. Its just that you seem not get mine. I wrote (at least twice) that I CAN do it the way you want, heck at some point you even can do it yourself if I'll ever get that stuborn (it's GPL after all). But for that to be done I'd like to have some consensus of how it would look like (with consideration of _my_ arguments). So please, instead of nagging me for it lets just merithorically think what to do to make it the way that both sides would be happy. I've got an idea for that but it can be hard without first knowing how MAC port would look like first. I still kinda can't do it yet. I'm still waiting for my MAC to be shipped (yes, MACs are not that popular in Poland, and somehow I dont want to play with hackintosh again).

EDIT: Aditionally I'd be really grateful if (for the sake of having this launcher better) some SCP developer (even You Karajorma) could replay to the topic about d3d registry I've made in the parent forum. Without it I'm going blind and that would be a worse thing that having or not having any config file for the launcher itself.

[WMCoolmon]

Isn't there a way to get the absolute path of the executable, so you could just cd over to that dir, check for the config file, and then cd back to the initial CWD?

Or perhaps the config file should be read from the same directory as the target fs2_open executable. That way, if you accidentally select a BTRL executable when you meant to select a WCS, the wrong graphic will clue you in on the mistake.

At the very least, having a config file would save some effort when a new Launcher update comes out. And it'd be nice to have a crossplatform 'official' launcher.

[Havner]

Isn't there a way to get the absolute path of the executable, so you could just cd over to that dir, check for the config file, and then cd back to the initial CWD?

Thats the whole point. I'll sum up what I came with so far and about what's been mentioned in this thread.

Lets think windows way. Launcher binary is inside gamedir and is always run from that dir (even when its not, the current dir is set to game dir with .lnk). So its not problem. It reads _one_ config file, preferably launcher6.ini with new section (not to multiply config files) and it gets apropriate entries from it.

Linux way. We want to have a launcher either in PATH dir or gamedir, and it has to work. The thing is that when it's not in game dir it has to find it somehow. Aditionally it has to find your local configuration directory for the game (f.e. ~/.fs2_open or ~/.btrl_demo) not to break multi user eviroment fs2 already supports. The simplest and most reliable way (as well as the most painful for end user and fs2 ts's distributors) would be to put a config file in homedir. The whole drawback is that for every TC it'd have to be a different config file, otherwise their names would conflict. It also implies that for every TC it would have to be recompiled to know which config file to read. Another drawback is that we'd have to split windows launcher6.ini in two files, one with current options, the other one with a path to gamedir. So it breaks windows assumption about one config file above . That's the whole point I dont like this solution.
And I can't come up with anything that would fix it.
In fs2 (or btrl in this case as its the only one I've run from .sh install) the game is put in some dir. The script that runs the game is put in gamedir and symlink to it is put in PATH. The script runs from PATH but knowing that it's a symlink it is able to find gamedir from symlink value (dirname()). And it has ~/.fs2_open dir hard compiled in it.
Let's assume I'd want to do the same for launcher. I put it in gamedir, make a symlink to it in PATH. Launcher would get the gamedir from statting the symlink value of argv[0]. But what about homeconfig dir? How to find that? Only two options comes to my mind: 1. hard compile it which would mean we still have to recompile the launcher for every TC, 2. get basename() of game dir, add a dot in front and hope a user didn't rename the dir the game was installed into. Other option would be to scan fs2 binary to get a config dir it was compiled with (the same way we scan for possible args). The thing is that fs2 can't do that now, it would have to be added.

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.

Or perhaps the config file should be read from the same directory as the target fs2_open executable. That way, if you accidentally select a BTRL executable when you meant to select a WCS, the wrong graphic will clue you in on the mistake.

I dont know if I get you correctly on this one, but I think that should be obvious. Thats the whole point of it, to have all possible TC's installed and they coexist with eachother.

And it'd be nice to have a crossplatform 'official' launcher.

Thank you...

[chief1983]

Ok, why not have one config file, with a global launcher, and the config file itself is broken up into a section for each mod?  Then to add a mod, you just copy and paste a section and change the identifier to the new mod, and go from there.  Then you'd have a dropdown list or something in the launcher to pick which mod maybe.

[WMCoolmon]

How about breaking the config file into two versions - a soft config and a hard config. The hard config ships with the TC, and can safely stay with the binaries as it contains all the per-TC data that's supposed to never change, except when the TC is installed. Thus it can safely sit with the application under Linux/OS X.

The hard config contains name, graphic, website for the package, as well as a unique config (UID) name. For 3.6.10 this config file is made official in that it's also read by the executable to determine where the fs2_open executable will search for config files. That way you can run multiple fs2_open-based TCs on the same user account with different resolution settings and so on. Also stores mod-specific launcher flags (although I still think those should be eliminated entirely).

The soft config file is launcher-only, and is stored in ~/.fs2_open/UID/. It contains the current executable, flags, joystick, and all the other good things that the launcher has to deal with.

Under Windows, my understanding was that the config data was going to be moved to Documents and Settings at some point in the near future, so same deal would work there.

Under Linux, presumably the hard config would be stored with the .app and the soft config would go in Users.

Using the symlink and shortcut methods for Linux and Windows respectively, the launcher could always find the hard config which would redirect it to the soft config, which would redirect the Launcher to the game executable. Not sure how that would work in OS X, so I can't take that into account. My suspicion is that you'd have to package the Launcher in with the executable and VPs for a TC to work properly, but that's not too bad. It makes more sense with the Mac design schema to only have one thing to double-click on for one program. (Dunno how you would handle FRED in that case...maybe with another Launcher button)

[karajorma]

You released 3.6.10, and there was some major bug that was caused by a simple typo in a code. Somehow you don't expect people to fix it by a text editor. Launcher (any launcher in the case you described) would be considered as a part of release. Why should it be different? (Not mentioning that a Welcome tab text is written since a long time and doesn't seem to be changed that often).

But I only have to recompile once!. I can then distribute the executable with all the TCs. That's not the same thing as having to recompile 10 times and distribute. And the reason why the launcher text doesn't change is precisely because it requires a recompile to do it and I'm the only person who has bothered (at least with a released version).

The real issue though is that not every TC has a Linux or Mac OS X coder. Which means that they'd have to find you or Taylor to build the launcher for them. Hell many of them don't even have a Windows coder.

A big trend in the SCP is moving hardcoded options into tables so that developers can get at them. This is just more of the same.

Completely on the other hand, I just wrote an alternative launcher, was trying to be helpful (at least for the minority of Linux guys like me that might be outthere somewhere), noone ever said that this would ever be considered as a part of the official release and I never asked for that.

If something is useful it has a habit of becoming official or at least semi-official. A good example of this is Turey's installer. I simply want to get rid of potential problems before I end up having to support them.

Additionally I _completely_ get your arguments. Its just that you seem not get mine.

Actually I do. It's just that it seemed like were were at the explain why it should be done rather than brainstorm on how stage to me.

WMC has presented an explanation along the lines of what I was thinking of. There are some differences but I like his way better.

EDIT: Aditionally I'd be really grateful if (for the sake of having this launcher better) some SCP developer (even You Karajorma) could replay to the topic about d3d registry I've made in the parent forum. Without it I'm going blind and that would be a worse thing that having or not having any config file for the launcher itself.

I'll take a look at it. Although 3.6.9 official does use that stuff so unless you're planning to make your launcher only support 3.6.10+ you might need to set it.
[/quote]

[Havner]

But I only have to recompile once!. I can then distribute the executable with all the TCs. That's not the same thing as having to recompile 10 times and distribute. And the reason why the launcher text doesn't change is precisely because it requires a recompile to do it and I'm the only person who has bothered (at least with a released version).

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.

A big trend in the SCP is moving hardcoded options into tables so that developers can get at them. This is just more of the same.

Then please, make me an option that would give me current binary home config dir :-)

WMC has presented an explanation along the lines of what I was thinking of. There are some differences but I like his way better.

I get the idea of WMC, the thing is its impossible to be done now with current SCP. The reason is above. Every TC (fs2/btrl at least) got different home config dir and putting configs of btrl to ~/.fs2_open wouldn't be the best option IMO. More about it below.

I'll take a look at it. Although 3.6.9 official does use that stuff so unless you're planning to make your launcher only support 3.6.10+ you might need to set it.

Let's just say I'm planning on making it OGL only. It would still work on pre 3.6.10 (as long as we dont complicate the following too much).

So going back to topic. My proposition is following: I get developing it further as it is now until we can solve the following:
1. Launcher is in game dir. Lets assume I will be able to find the gamedir statting symlink somehow.
2. Launcher has two config files (hard/soft). One per TC (in game dir), one per user (in home config dir).
3. Launcher has to be able to find home config dir. And this is to be taken care of by SCP developers somehow. Like I wrote above for now every TC gets another home config dir. Every TC should have different place to store its config files IMO (for diffent mods, for different flags etc, f.e. -tbp). For the above reasons let's change the UID thing into home config dir value stored in hard config. Then its possible. But this could lead to breaking the launcher by breaking its config (or making the launcher not working at all by removing the hard config file) and I dont like it. The easiest way IMO would be to give SCP a cmd line switch that would return current binary home config dir. If I run onto a binary that doesn't (pre 3.6.10) I assume its ~/.fs2_open. This way launcher doesn't need hard config file provided at all to work (in a limited way of course, without welcome text etc, but still). Comments?

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.

[karajorma]

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.

[S-99]

Personally i've always just installed wine, then the windows openal driver, and then run the windows launcher in linux and use it to configure fs-scp and then run the linux binary. You can do everything with the windows launcher in linux that you want except for switching the resolution and color depth. That takes place in a different spot in linux. This is another way for linux users to get by

[Soulstorm]

Well, can I say something here?

I made the original FS2_Open Launcher for OS X some years ago. It is very interesting to see more people are attempting to make something different in that area, if they think there is something I may have missed.

If you want help porting to OS X, I would be glad to help. I would also be glad to see what features I may have missed that could be included in another Launcher. If you want any help, don't hesitate to contact me.

[S-99]

Why not port the osx launcher to linux? Osx is a unix derivative like linux is. I know it's not as simple as that. But, it would make porting easier than say windows to linux. Like i said just use the windows launcher in linux until the linux launcher comes out. Really a cross platform launcher should be made. The fs-installer is cross platform through java, and does wonderfully. Why  not a java based launcher that can also be cross platform? An aspect of fs2 is already cross platform for installing on all platforms with the correct binaries for each platform. Why not follow suit with a cross platform launcher?

i mean so far it's like this. It's easy to install on any platform. But, if you're linux or osx, then you're in a different world for how the game gets configured on either os besides windows (it's harder). Really the only thing the launcher does is put together a config file fs scp sees and executes your preferred settings as desired by the user. It's one of the main reasons why i haven't had any trouble in using the windows launcher in linux (except that in linux the resolution control for the game is in the home directory).

I'm not saying hop to it. It's just something that once i thought about that we have a cross platform installer and after that it adds up to sort of an awkward situation after installation has finished.

[Havner]

Why not port the osx launcher to linux? Osx is a unix derivative like linux is. I know it's not as simple as that. But, it would make porting easier than say windows to linux. Like i said just use the windows launcher in linux until the linux launcher comes out. Really a cross platform launcher should be made. The fs-installer is cross platform through java, and does wonderfully. Why  not a java based launcher that can also be cross platform? An aspect of fs2 is already cross platform for installing on all platforms with the correct binaries for each platform. Why not follow suit with a cross platform launcher?

Porting OSX (cocoa) applications to Linux is exactly the same as porting native windows applications to Linux. Those are completely different APIs and the fact that OSX is unix deritarive has nothing to do with the gui.

And about portable launcher the one I wrote IS portable, that was the whole point. It's written in QT, portable GUI lib, and making OSX compilation is very little problem. You dont need java for that.

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.

[S-99]

I understand with using qt. Qt4 can be used on osx, linux, and windows (unrelated but reminds that kde programs can finally be ported to windows because of qt4 and the way the licensing it has permits it...like i said, unrelated i just got reminded of it). That may very well lead to a cross platform launcher. I was just citing java as an example of what's already been done for cross platform around here. I know osx and linux are unix derivatives of course as well as you know, but i also said it's not as easy as that also. Of which you have also showed me the reasons. But, i also wasn't really thinking of the gui. Qt should be great