Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: Havner on April 07, 2008, 02:53:35 pm
-
OUTDATED, new release here: http://www.hard-light.net/forums/index.php?topic=68413.0
===========================================================
svn://vega.livecd.pl/yal/trunk
----------------------------------------
Yes, I know there is going to be new portable launcher for 3.7 and I know about old Linux GTK based but it wasn't portable, had less functionality and the download seems to be lost.
In general it drove me crazy that we don't have anything nice for Linux now. So I started to write a new launcher with two assumptions:
- copy look&feel&functionality from the windows one
- make it as much portable as possible
(using QT4, splitting non-portable code to platform specific files, etc), this way maybe one day (if 3.7 will get delayed) we could have one coherent 3.6.x launcher for all platforms with one code base (but still much remains to achieve that).
This is the first public version. For now it works only on Linux (though I think it should run on Mac OS X with minor changes), and only first 3 tabs (Welcome/Features/MOD) are implemented, but still it allows Linux people to select flags/mods in convienient way, no more command line or editing cmdline_fso.cfg by hand.
Enjoy :-) and make sure to read README.
If someone would like to help with its development (f.e rewriting some windows specific things when I'll make GUI for the rest of the tabs) send me a note.
(http://vega.livecd.pl/~havner/yal/old/windows-screenshots/btrl_welcome.png)(http://vega.livecd.pl/~havner/yal/old/windows-screenshots/btrl_features.png)(http://vega.livecd.pl/~havner/yal/old/linux-screenshots/fs2_open_main.png)(http://vega.livecd.pl/~havner/yal/old/linux-screenshots/fs2_open_mod_cardinalspear.png)(http://vega.livecd.pl/~havner/yal/old/linux-screenshots/btrl_main.png)(http://vega.livecd.pl/~havner/yal/old/linux-screenshots/btrl_features.png)
More screenshots:
http://vega.livecd.pl/~havner/yal
Yet Another Launcher.
FreeSpace 2 portable launcher.
1. Linux
Before you start you need to let the launcher know where your game is
located. This is hardcoded compile time. This way we can have the
launcher anywhere we want, f.e. in some bin/ dir and it will still work.
To do this edit src/unix/FilePaths_unix.cpp and modify GAMEDIR define.
You can uncomment the top most GAMEDIR define as well. In such case the
launcher will behave like windows one, it assumes that game is in its
current run directory and ignore any compile time paths.
If you want to have browser functionality you need to define BROWSERCMD
in src/unix/System_unix.cpp. You can leave as it is now and f.e. make
some browser script like I do and put it inside PATH dir:
#!/bin/sh
exec firefox "@"
Launcher requires QT4. Probably 4.2 or even 4.3 (I think I did use
some 4.2 functions, maybe even 4.3).
If you want to compile launcher for another game edit your yal.pro file
and ucomment _one_ of the CONFIG lines at the top of it.
To compile type:
./autogen.sh
make
If everything went fine you should have fs2_open/btrl_demo/tbp/wcsaga
binary in the current dir. Put it anywhere you want (if you compiled
with hardcoded GAMEDIR). To the game dir, to some bin/ dir included in your
PATH. You can rename it as well.
Make sure you DON'T have GAMEDIR/data/cmdline_fso.cfg file. FS2_open
merges flags from system wide and user wide files so if you do have
one all flags from it will be forced and yal won't reflect this in
features tab. Handling this is in TODO.
3. Windows
Yal for windows is distributed in binary form.
Put the appriopriate launcher to game dir and run from there.
You can put all the dll's to some System32 windows dir or just keep them
in current dir.
If you want to recompile windows version you need MinGW and GPL version
of QT. Basically its done the same way as for Linux: qmake; make;
3. MacOSX
Coming soon...
4. Common
For now launcher uses the following files:
1. ~/.fs2_open/launcher6.ini
2. ~/.fs2_open/data/cmdline_fso.cfg
3. GAMEDIR/MOD/mod.ini
4. TEMPDIR/flags.lch
ad 1. This file is read on start if it exist. If it contains proper
exe_filepath the latter is executed inside temporary dir and flags
are read from flags.lch (ad 4).
ad 2. If launcher6.ini does not exist or does not contain game_flags or
they are empty there is an attempt to read cmdline_fso.cfg to fill
initiall flags.
ad 3. This file is read from inside the active_mod dir or any other dir
selected using GUI. Including game root dir used when actual mod name
is empty.
yal-0.1.3
- windows version of launcher
- better unix/win code separation
- cosmetics
yal-0.1.2
- small bugfixes
- seperate resource files and target names for all launchers
- GAMEDIR can be current dir to behave like windows launcher
- new Select MOD dialog window
yal-0.1.1
- small bugfixes
- project file included
yal-0.1
- Initial release
For full changelog see 'svn log'.
-
:jaw:
This is awesome! Keep it up!
-
Damn sexy.
Thanks for choosing QT
EDIT
Hey, what are the dependencies for this?
-
Hey, what are the dependencies for this?
Dependencies in term of libs? QtGui and QtCore. Later there will be SDL and OpenAL for some HW detection. For now if you have QT >= 4.2 you should be fine.
-
I'm getting an error when I try to compile this
root@ursa-desktop:/home/ursa/Desktop/yal-0.1/yal-0.1# make
g++ -c -pipe -Wall -W -O2 -D_REENTRANT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_TABLET_SUPPORT -I/usr/share/qt3/mkspecs/default -I. -I. -Isrc -Isrc/gui -I/usr/include/qt3 -o IniParser.o src/IniParser.cpp
In file included from src/IniParser.cpp:1:
src/IniParser.h:4:18: error: QtCore: No such file or directory
In file included from src/IniParser.cpp:1:
src/IniParser.h:8: error: ‘QString’ does not name a type
src/IniParser.h:9: error: ‘QString’ does not name a type
src/IniParser.h:19: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.h:19: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.h:20: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.h:20: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.h:22: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.h:22: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.h:23: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.h:23: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.h:24: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.h:24: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.h:25: error: ‘QString’ does not name a type
src/IniParser.h:28: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.h:28: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.h:31: error: ISO C++ forbids declaration of ‘QList’ with no type
src/IniParser.h:31: error: expected ‘;’ before ‘<’ token
src/IniParser.cpp:15: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.cpp:15: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.cpp: In member function ‘bool IniParser::loadIni(int)’:
src/IniParser.cpp:17: error: ‘list’ was not declared in this scope
src/IniParser.cpp:19: error: ‘QFile’ was not declared in this scope
src/IniParser.cpp:19: error: expected `;' before ‘file’
src/IniParser.cpp:20: error: expected `;' before ‘section’
src/IniParser.cpp:20: warning: statement has no effect
src/IniParser.cpp:22: error: ‘file’ was not declared in this scope
src/IniParser.cpp:22: error: ‘QIODevice’ has not been declared
src/IniParser.cpp:25: error: ‘file’ was not declared in this scope
src/IniParser.cpp:27: error: expected `;' before ‘line’
src/IniParser.cpp:27: warning: statement has no effect
src/IniParser.cpp:30: error: ‘line’ was not declared in this scope
src/IniParser.cpp:34: error: ‘line’ was not declared in this scope
src/IniParser.cpp:37: error: ‘section’ was not declared in this scope
src/IniParser.cpp:44: error: ‘section’ was not declared in this scope
src/IniParser.cpp:48: error: ‘line’ was not declared in this scope
src/IniParser.cpp:50: error: ‘line’ was not declared in this scope
src/IniParser.cpp:53: error: expected `;' before ‘key’
src/IniParser.cpp:53: warning: statement has no effect
src/IniParser.cpp:54: error: ‘key’ was not declared in this scope
src/IniParser.cpp:54: error: ‘section’ was not declared in this scope
src/IniParser.cpp:57: error: ‘val’ was not declared in this scope
src/IniParser.cpp:61: error: ‘file’ was not declared in this scope
src/IniParser.cpp: At global scope:
src/IniParser.cpp:74: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.cpp:74: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.cpp: In member function ‘bool IniParser::dumpIni(int)’:
src/IniParser.cpp:77: error: ‘list’ was not declared in this scope
src/IniParser.cpp:80: error: ‘QFile’ was not declared in this scope
src/IniParser.cpp:80: error: expected `;' before ‘file’
src/IniParser.cpp:81: error: expected `;' before ‘section’
src/IniParser.cpp:81: warning: statement has no effect
src/IniParser.cpp:83: error: ‘file’ was not declared in this scope
src/IniParser.cpp:83: error: ‘QIODevice’ has not been declared
src/IniParser.cpp:86: error: ‘QTextStream’ was not declared in this scope
src/IniParser.cpp:86: error: expected `;' before ‘out’
src/IniParser.cpp:88: error: ‘list’ was not declared in this scope
src/IniParser.cpp:90: error: ‘section’ was not declared in this scope
src/IniParser.cpp:93: error: ‘lastSection’ was not declared in this scope
src/IniParser.cpp:94: error: ‘out’ was not declared in this scope
src/IniParser.cpp:94: error: ‘endl’ was not declared in this scope
src/IniParser.cpp:100: error: ‘out’ was not declared in this scope
src/IniParser.cpp:100: error: ‘endl’ was not declared in this scope
src/IniParser.cpp:103: error: ‘file’ was not declared in this scope
src/IniParser.cpp: At global scope:
src/IniParser.cpp:112: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.cpp:112: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.cpp: In member function ‘bool IniParser::addEntry(int)’:
src/IniParser.cpp:115: error: ‘key’ was not declared in this scope
src/IniParser.cpp:118: error: expected `;' before ‘keySection’
src/IniParser.cpp:118: warning: statement has no effect
src/IniParser.cpp:119: error: ‘keySection’ was not declared in this scope
src/IniParser.cpp:119: error: ‘key’ was not declared in this scope
src/IniParser.cpp:123: error: ‘list’ was not declared in this scope
src/IniParser.cpp:131: error: ‘section’ was not declared in this scope
src/IniParser.cpp:134: error: ‘lastSection’ was not declared in this scope
src/IniParser.cpp:138: error: ‘lastSection’ was not declared in this scope
src/IniParser.cpp:149: error: ‘struct IniEntry’ has no member named ‘key’
src/IniParser.cpp:150: error: ‘struct IniEntry’ has no member named ‘val’
src/IniParser.cpp:150: error: ‘val’ was not declared in this scope
src/IniParser.cpp:151: error: ‘dumpable’ was not declared in this scope
src/IniParser.cpp:153: error: ‘list’ was not declared in this scope
src/IniParser.cpp: At global scope:
src/IniParser.cpp:162: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.cpp:162: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.cpp: In member function ‘bool IniParser::modEntry(int)’:
src/IniParser.cpp:164: error: ‘list’ was not declared in this scope
src/IniParser.cpp:165: error: ‘key’ was not declared in this scope
src/IniParser.cpp:166: error: ‘val’ was not declared in this scope
src/IniParser.cpp: At global scope:
src/IniParser.cpp:162: warning: unused parameter ‘QString’
src/IniParser.cpp:177: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.cpp:177: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.cpp: In member function ‘bool IniParser::delEntry(int)’:
src/IniParser.cpp:179: error: ‘list’ was not declared in this scope
src/IniParser.cpp:180: error: ‘key’ was not declared in this scope
src/IniParser.cpp: At global scope:
src/IniParser.cpp:177: warning: unused parameter ‘QString’
src/IniParser.cpp:192: error: ‘QString’ does not name a type
src/IniParser.cpp: In member function ‘void IniParser::setDumpable(bool)’:
src/IniParser.cpp:206: error: ‘list’ was not declared in this scope
src/IniParser.cpp: At global scope:
src/IniParser.cpp:214: error: expected ‘,’ or ‘...’ before ‘&’ token
src/IniParser.cpp:214: error: ISO C++ forbids declaration of ‘QString’ with no type
src/IniParser.cpp: In member function ‘bool IniParser::setDumpable(int)’:
src/IniParser.cpp:216: error: ‘list’ was not declared in this scope
src/IniParser.cpp:217: error: ‘key’ was not declared in this scope
src/IniParser.cpp:218: error: ‘dumpable’ was not declared in this scope
src/IniParser.cpp: At global scope:
src/IniParser.cpp:214: warning: unused parameter ‘QString’
make: *** [IniParser.o] Error 1
I'm using Ubuntu Hardy
-
I'm getting an error when I try to compile this
root@ursa-desktop:/home/ursa/Desktop/yal-0.1/yal-0.1# make
g++ -c -pipe -Wall -W -O2 -D_REENTRANT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_TABLET_SUPPORT -I/usr/share/qt3/mkspecs/default -I. -I. -Isrc -Isrc/gui -I/usr/include/qt3 -o IniParser.o src/IniParser.cpp
/usr/share/qt3/mkspecs/default
^^^^^^^^^^^^^^^^^^^
Your system tries to compile it using QT3, this wont work. Make sure you got QT4 installed. I think the package should be named 'libqt4-dev'.
Get yal-0.1.1 (it includes generated project file) and run 'qmake-qt4' instead of ./autogen.sh
If this wont work you might need to select your actual QT version to QT4 using alternatives system (I see ubuntu uses it for QT).
-
Much obliged
-
Awesome! I'll test it when I install Linux.
-
Awesome! I'll test it when I install Linux.
Nice to see some polish blood :-)
-
Update: Windows version released. MacOSX next.
Then I'm going to implement graph/sound detection and setting (SDL/OpenAL).
-
I hope you've implemented the graphics on the welcome screen as bitmaps loaded from disk (as with the Mod image) rather than having to include them at compile time.
Apart from that :yes:
-
I hope you've implemented the graphics on the welcome screen as bitmaps loaded from disk (as with the Mod image) rather than having to include them at compile time.
No, they are compiled as resource inside binary. Why shouldn't be they? Copyright issues? Windows launcher got them included as well.
-
I personally don't like how you used buttons. I prefer the tabs, myself.
-
I personally don't like how you used buttons. I prefer the tabs, myself.
Thats because I didn't manage to wrap tabs in QT. You'd have to scroll one line of them left<>right which was even worse. I'll get back to that at some point. For now its just cosmetics.
-
No, they are compiled as resource inside binary. Why shouldn't be they? Copyright issues? Windows launcher got them included as well.
Just cause the Windows launcher made a bad choice doesn't mean you have to copy it. :p
Ideally the Welcome text, the URLs the buttons go to and the images should all be controlled from an ini file same as they are for the mod tab. That way TBP, Wing Commander and BtRL aren't forced to recompile for Linux, Windows and Mac OS X just cause they want the launcher to take people to their readme, etc
-
Ideally the Welcome text, the URLs the buttons go to and the images should all be controlled from an ini file same as they are for the mod tab. That way TBP, Wing Commander and BtRL aren't forced to recompile for Linux, Windows and Mac OS X just cause they want the launcher to take people to their readme, etc
I made launchers for all 4 games (FS2, BTRL, WC, TBP). They are selected by CONFIG var in project file. In case that wont be enough its just a few secs to add another game. Making config file for graphics/readme etc would be very easy. The thing I dont like about it is that you have to put those files (config and graphics) somewhere making it harder to install/distribute for people. Anyway, if there will be a need for the solution you described I'll make it so :-). For now its not that important IMO. There are I think two or three more total conversion but the ones mentioned before and none of those is released afair (correct me if I'm wrong, I'll add any other game thats already released).
-
has anyone managed to do this on ubuntu,im using ubuntu studio and am stupid so if some one could give me a step by step guide id be so happy ........;
-
has anyone managed to do this on ubuntu,im using ubuntu studio and am stupid so if some one could give me a step by step guide id be so happy ........;
Ok, this is blind, I dont have Ubuntu. But if it will fail just paste me the output.
Unpack tgz to some dir.
Open src/unix/System_unix.cpp and edit BROWSERCMD (described in README)
Open src/unix/FilePaths_unix.cpp and edit GAMEDIR for the game you're interested in.
Open Terminal:
Enter the dir you've unpacked tgz to (you need to be in a dir with yal.pro file)
$ sudo apt-get install libqt4-dev
$ qmake-qt4
or
$ qmake-qt4 "CONFIG+=btrl"
or
$ qmake-qt4 "CONFIG+=tbp"
or
$ qmake-qt4 "CONFIG+=wcsaga"
then:
$ make
-
use qmake-qt4 instead of make, make will give you errors if you have a qt 3 dev package about
-
use qmake-qt4 instead of make, make will give you errors if you have a qt 3 dev package about
You mean qmake-qt4 instead of qmake, not make. You can't use any qmake instead of make, those give totally different functionality. qmake* generates Makefile which make uses next.
-
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...
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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...
-
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.
-
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)
-
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. :D
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]
-
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.
-
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.
-
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 :yes:
-
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.
-
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.
-
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.
-
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 :yes:
-
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.
-
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 ¶ms, 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()
-
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.
-
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. :rolleyes: :p
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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:
[multimod]
primarylist =
secondarylist = fsport,mediavps
The mod.ini in the fsport directory says:
[multimod]
primarylist = fsport-mediavps;
secondarylist = mediavps;
When I select the fsport-mediavps mod in the yal, it will use
-mod fsport,fsport-mediavps
which means that the mediavps mod is missing.
When I select the fsport mod, yal uses
-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
-mod fsport-mediavps,fsport,mediavps[/fsport]
-
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.
-
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.
-
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:
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.
-
Just put everything in one 'fsfport' directory and modify mod.ini to include only 'mediavps' dir.
-
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.
-
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.
-
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).
-
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.
-
At least, after changing back to the original layout, which is, as far as I understand, also suggested in the
release thread, *and* after changing "secondarylist" to "secondrylist" in the mod.ini files, yal now uses the
correct mod options when I choose the fsport-mediavps mod, which ist
-mod fsport-mediavps,fsport,mediavps
So it seems the main problem was secondarylist vs. secondrylist. When I select the fsport mod, yal uses
-mod fsport,fsport-mediavps,mediavps
I honestly don't know if this is desired or not, and from how I understand chief1983, the fsport mod.ini file
shouldn't refer to mediavps and fsport-mediavps at all, because it is supposed to give you the Free Space port
without any additional vps. But I guess that is something for the fsport crew to decide on.
-
I just downloaded FSPort last night. Playing FSPort can utilize anywhere from 1 to 3 folders, fsport, fsportmvps, and mediavps. To play with retail graphics and no other enhancements, just select the fsport. The mod.ini in the fsport directory should have no primary or secondary list variables defined. Although it seems someone left some semicolons out of the file I downloaded, since I think every line should end in one except for the [] tags. Either way, the mod.ini I downloaded with the fsport last night in the core file is this:
[launcher]
modname = The Freespace Port 3.1
image255x112 = fsport.bmp;
infotext = A fourteen-year war between the Terran and Vasudan species leads into something far more sinister. This is the story of the Great War.;
website = http://fsport.hard-light.net/;
forum = http://www.hard-light.net/forums/index.php/board,39.0.html;
[multimod]
primarylist =
secondarylist =
It should not require any other mods to play it by itself. To use it with the fsport mediavps and the fs2 mediavps, you would extract the fsport mediavp file to its own directory, fsportmvp, and select it as a mod. It includes both the fsport and the mediavps directories in its secondary list, as you have it set up to do. But you somehow seem to have a differently set up fsport mod.ini than I do, unless it changed between the times we downloaded it I don't know how that would have happened. The FSPort MediaVPs were designed to be installed as a separate mod from the rest of the port, although I don't think the release notes made this very clear, and it seems you were setting it up that way. But having includes of mods in the fsport folder was backwards and it wasn't set up to be installed in that manner. If you put the port mediavps in their own mod folder and use it as a mod with its mod.ini it should take precedence over the low detail data in the port itself (it did for me just last night).
Edit: Ah yes, secondrylist. Forgot about that. Just for clarity, here's my fsportmvp folder's mod.ini:
[launcher]
modname = The FSPort Media VP
image255x112 = fsportmvp.bmp;
infotext = Freespace Port Media VPs. Requires FSPort 3.1 and Media VPs 3.6.10. ;
website = http://fsport.hard-light.net/;
forum = http://www.hard-light.net/forums/index.php/board,170.0.html;
[multimod]
primarylist =
secondrylist = fsport,mediavps
-
Well, looks like you got a different fsport mod.ini than I got. Maybe something was changed after you
downloaded the archives after all. Maybe you can compare the md5 checksum of fsport3_1.zip with mine, which
is
28c9e2c65a48e836872db8876227638b fsport3_1.zip
Also, it seems the name of the fsport mv folder was changed from fsportmv to fsport-mediavps, see
http://www.hard-light.net/forums/index.php/topic,58357.msg1178255.html#msg1178255 (http://www.hard-light.net/forums/index.php/topic,58357.msg1178255.html#msg1178255).
And, at last, my fsport mod.ini file, which is different from yours, also breaks the Windows launcher, as I get
the same error that is reported in these two messages:
http://www.hard-light.net/forums/index.php/topic,58357.msg1178208.html#msg1178208 (http://www.hard-light.net/forums/index.php/topic,58357.msg1178208.html#msg1178208)
http://www.hard-light.net/forums/index.php/topic,58357.msg1178251.html#msg1178251 (http://www.hard-light.net/forums/index.php/topic,58357.msg1178251.html#msg1178251)
Using your mod.ini works as expected, and as I already wrote, the fsport-mediavps mod.ini works as well,
after changing "secondarylist" to "secondrylist". By the way, I just checked with the windows loader, and
it does understand "secondardlist", so adding support for this to yal as Havner proposed would be good,
for compatibility.
-
And just for the sake of completeness, the problem in the windows loader seems to come from the dash in
fsport-mediavps (see http://www.hard-light.net/forums/index.php/topic,58357.msg1178396.html#msg1178396 (http://www.hard-light.net/forums/index.php/topic,58357.msg1178396.html#msg1178396)).
Looks like yal is a little more robust in this regard and does not suffer from the same problem, it just passes a mod name with a dash in it to the game the right way.
-
Ok. I'm surprised your mediavps mod.ini had secondarylist, mine had secondrylist too. Unless someone has swapped out two different VPs I don't know why this would have happened. From the looks of it, you'd have been less confused had you grabbed them a couple hours after release last night. *sigh*
Edit: Yup it looks like someone tried to clean up the mod.ini in the port mediavps file too, it has all the missing semicolons now but they did in fact change the spelling of secondary, which as you've seen breaks YAL apparently. Time to update that source code I think.
-
I checked again, this time with the fsport mod.ini that came with my fsport3_1.zip, but after changing fsport-mediavps to
fsportmvps, so that it reads:
[multimod]
primarylist = fsportmvps;
secondrylist = mediavps;
Using that in the Windows launcher works, but the result is different from what yal uses. The windows launcher interprets this as:
-mod fsportmvps,fsport,mediavps
I wrote my own xyz/mod.ini, which uses:
[multimod]
primarylist = abc,zzz;
secondarylist = def,ggg;
This results in
-mod abc,zzz,xyz,def,ggg
So the Windows launcher, which as far as I can see is the only authority so far on how the mod.ini file needs to be interpreted, puts the mods from "primarylist" at the beginning of the list, then adds the selected mod, and then adds the secondrylist mods. This is different from yal, which puts the selected mod first, then primarylist, then secondrylist. Maybe yal should change it's behaviour in this regard (and *maybe* the way mod.ini is to be interpretated should be standardized some way, e.g. in the Wiki, by someone or several someones who have the authority to do so). Well, anyway, it looks like I found the answers to all my questions, thanks a lot *g*
-
Ok, so to sum up from this thread for yal:
1. add secondarylist to the accepted keywords next to secondrylist
2. order: pimarylist,modname,secondarylist
The problems you first hit where caused by the sum of the above, right?
-
Yes. From that, and from one of the mod.ini files referering to other mods, where it should not use them. But that is of course not yal's problem.
-
Yup! Thanks Havner.
Also, after rereading the vast majority of this thread, I realize I kind of sounded like an ignorant dick. Sorry I so completely failed to grasp the whole problem with the config dirs, I'm just now wondering what's going to happen when I start trying to run both the SWC standalone test build and regular FS2 on my Mac I just got set up. I'm guessing they're still going to collide config dirs.
-
chief1983: Don't worry. I have several years of Usenet experience, so I am not very sensitive in this regard anymore :lol:
Anyway, I have another suggestion for yal. It shows a field with the selected mod's name
next to the buttons "Select Mod" and "No Mod". Currently, yal shows the name of the
mod folder. The mod.ini file however has a "modname" field. From the blueplanet mod.ini:
# modname: Display name only, so you can have spaces instead of underscores for multi word MOD's
modname = Blue Planet;
Maybe yal could make use of this to display the mod name.
-
I suppose it could :nod:
-
And yet another suggestion. The website and forum entries in the mod.ini file are optional. When they are
empty, klicking on the website and forum buttons in yal does nothing. Maybe when they do nothing anyway,
they should be deactivated or greyed out, so the user knows that they won't do anything for this mod, instead
of wondering why the browser does not pop up.
-
... and maybe a tool tip for the two buttons, or some other kind of display showing the URL that will be opened before you click on it?
-
I believe I found another bug in yal. I used the custom flags field to apply the settings that are recommended in the mediavps 3.10 release thread, namely:
-ambient_factor 35 -ogl_spec 20 -spec_exp 15 -spec_point 1.2 -spec_static 1.5 -spec_tube 1.5
After applying the settings, ~/.fs2_open/launcher6.ini shows this line:
game_flags = [other flags] -ambient_factor 35 -ogl_spec 20 -spec_exp 15 -spec_point 1.2 -spec_static 1.5 -spec_tube 1.5;
However, when I quit yal and restart it, the settings in the custom flags field show:
-ambient_factor 35 -ogl_spec 20 -spec_exp 15 -spec_point 1.2 -spec_static -spec_tube 1.5
Please note how the numeric value for -spec_static is missing. launcher6.ini still has the value, so it seems
that yal somehow parses it's configuration file the wrong way.
-
Noted, thanks. I'll get to all of this soon.
-
Did you modify yal somehow bypassing svn? I have the impression that there have been some changes, e.g.
yal now uses "primarylist" correctly. However, svn log shows
r105 | havner | 2008-05-24 03:21:17 +0200
as the latest commit :wtf:
-
Perhaps trunk was already fixed before but the 0.1.3 tag was always broken?
-
Did you modify yal somehow bypassing svn? I have the impression that there have been some changes, e.g.
yal now uses "primarylist" correctly. However, svn log shows
r105 | havner | 2008-05-24 03:21:17 +0200
as the latest commit :wtf:
Bypass? No. What version are you talking about? From what I see in the code 0.1.3 did that wrong treating all mods (primary + secondary as one list). But in trunk it seems to be fixed. So I must have done that long time ago just made no release with that fix. Compile trunk then and you should be ok with that.
-
I thought I was using trunk when I found that problem with primarylist, but maybe I was wrong and using some older version instead. Nevermind.
-
r106 | havner | 2009-01-10 11:51:50 +0100 (Sat, 10 Jan 2009) | 4 lines
- display full mod name in mod tab (launcher:modname)
- allow secondarylist along with secondry list
- fixed a bug where a field could disappear in custom_flags
Most needed bug fixes for now.
I'll try to sit down to cleaning some of the code and going further with implementing other tabs (along with your sugestions, grey buttons, tooltips, etc)
For now Smurd please check if it behaves correctly.
-
The things you changed are working now. Thanks a lot!
-
I did work a little on it. Mainly cleaning and code level improvements but implemented other things you were suggesting here (point me if I forgot something). Fixed few bugs. Made it read mod/settings.ini on start (but only non custom flags from it to avoid duplicating of custom ones on mod load) etc...
Check it if you got a second. I'll hopefully try to do video tab this weekend and release something.
Note: there are more then one .pro files in trunk, so if you run qmake you may need to specific which one you want ( qmake yal.pro or just run ./build-all.sh)
-
The greyed-out link buttons work as supposed. I do however not see any tool tips.
-
They definitely work for me. They're added for every link/browser button. Both, FS2 (readme, forums, report bug) and actual mod (website, forum). They don't appear when you hover a mouse for 2-3 secs?
-
I get this:
bash-3.1# ./autogen.sh
yal.pro:29: Unknown test function: CONFIG
You can run 'make' now.
Of course, if I run make I get this:
bash-3.1# make
make: *** No targets specified and no makefile found. Stop.
YAL version 0.1.3, unmodified except for the GAMEDIR setting in the FilePaths_unix.cpp.
Any suggestions?
-
First of all use trunk, it's much updated then 0.1.3. You don't need to set GAMEDIR anymore, it's described in readme how to properly set it up.
To get it run:
svn co svn://vega.livecd.pl/yal/trunk
About CONFIG error to be honest I have no idea other then maybe you're running qmake from QT3.
Check trunk, updated autogen.sh tries to check if the QT version in use is sufficient.
Paste me output of that if it fails.
-
Hmm... I will try the SVN version when I'll get back, probably on Monday.
As for which version of QT I'm using... I've installed QT4 on my system a while ago (Slackware 12.2), and I think I've kept the existing QT3 version. I can check that on Monday too :)
If I have the two versions installed, what should I use instead of qmake?
LE: I took a look at the "new" autogen.sh, looks like it is able to use the proper QT version. I'll check it out on Monday :D
-
If you got both QT versions installed you may try qmake4 f.e. Or maybe slackware just holds it in separate directory. I don't know how it's solved there but grepping QT4 package file list for 'qmake' will tell you the truth :-) Anyway it has to be somewhere.
-
There might be a tool to set the active version in the environment too.
-
QT4 qmake (qmake-qt4 on my system) did the trick. The launcher compiled without a problem.
I'll check out the svn version now.
So far the application looks nice. Thanks
LE:
I checked out the svn version (revision 118) and when I executed the autogen.sh script, got this:
bash-3.1# ./autogen.sh
Usage: /usr/bin/qmake-qt4 [mode] [options] [files]
QMake has two modes, one mode for generating project files based on
some heuristics, and the other for generating makefiles. Normally you
shouldn't need to specify a mode, as makefile generation is the default
mode for qmake, but you may use this to test qmake on an existing project
(below are detailed usage instructions for qmake-qt4)Same result when I run qmake-qt4 by hand.
QT4 version:
bash-3.1# qmake-qt4 -v
QMake version 2.01a
Using Qt version 4.4.3 in /usr/lib/qt-4.4.3/lib
Any suggestions? :)
-
Hi,
I've had a few free minutes to have a quick look through the code.
In System_win.cpp (I'm not that familiar with this stuff on other platforms), you've use CreateProcess to create a process, however you haven't released your handles after you exit the loop. (See MSDN (http://msdn.microsoft.com/en-us/library/ms684873(VS.85).aspx))
You should probably use WaitForSingleObject (http://msdn.microsoft.com/en-us/library/ms687032(VS.85).aspx) instead of the loop.
Launcher itself looks good!
Will see what I can find about wrapping tabs in Qt.
-
Thanks, will have a look when I get back home. Me on the other side have little experience in winapi :-) This was partly copy pasted from current windows launcher.
-
1) Ouch.
2) How can I help out?
EDIT: Maybe instead of tabs, you could have a tree control down the left hand side to select options
-
If you want to have browser functionality you need to define BROWSERCMD
in src/unix/System_unix.cpp.
Do you know about xdg-open? http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html
-
When will we have the OSX version?
-
Well, there's already Soulstorm's launcher, or are you hoping to get one that works on every platform?
-
There is an intent to start work on a new installer/launcher after 3.6.10 has been released.
-
When will we have the OSX version?
As soon as someone with OSX and very basic programming skill with sit to it. I had plans to get some OSX machine (or even isntall hackintosh one more time) but for now I don't have possibility to do that.
Code requires two/three simple functions to be written and there is no reason why it wouldn't work on OSX.
-
You tell me how to do it, I'll do it, but remember that my programming skill are almost 0...
I can just compile, make and make install. Oh, yes, I can run too :P
My computer is a MacMini G4 with OSX 10.4.11, if you need the info.
-
On OS X it's more like 'xcodebuild --project FS2_Open.xcodeproj --configuration Release clean build', but you get the idea.
-
There is nothing i can tell you about what needs to be done. You need to know yourself how to do that, if I knew (or at least had OSX to experiment) i wouldn't ask for help :-)
Basically there are few simple OS specific functions to be written. Get latest svn and look in trunk/src/macx. They should be self explanatory when comparing to win/linux implementation.
About build system I'm pretty sure qmake will handle it automatically.
-
I personally don't like how you used buttons. I prefer the tabs, myself.
Thats because I didn't manage to wrap tabs in QT. You'd have to scroll one line of them left<>right which was even worse. I'll get back to that at some point. For now its just cosmetics.
It's argued that they are a bad idea usability-wise... people hate multirow tabs as they hate Comic Sans. Not even the KDE equivalent supports this.
There are bugs opened about this, you could vote for them...
-
Well, that means that I should stop rewriting Luncher 4 for OS X?
If you would like, I could do some work for this Launcher on OS X... Notify me if you want to.
-
Honestly, it's a race to the finish line at this point. Preferably a cross platform launcher that works would be ideal, but people have to use what they can get in the meantime and there's no guarantee the best solution will be seen in the near future.
-
If you would like, I could do some work for this Launcher on OS X... Notify me if you want to.
Well, the OS X specific parts need an OS X user to test them. I suppose that's what Havner would most want from you right now.
It's really easy if you know OS X and have a machine to test:
* FilePaths_macx.cpp
- bool initialize( const QString& );
Sets QString m_qstrGameDir to the game directory. Probably just the dirname() of the parameter.
- QString getConfigDir();
Returns a dir where config files will be stored. Probably the same that fs2_open uses.
- QString getTempDir();
Returns a dir with write permission so fs2_open's -get_flags works. Probably just QDir::tempPath().
* System_macx.cpp
- static bool run( const QString&, const QStringList& = QStringList(), bool = false );
Run the game with the given parameters
- static bool runBrowser( const QString& );
Open the URL from the parameter with an Internet browser
- static int mSleep( int );
Just sleep.
- static QSize getSize();
Returns the window size.
Probably all of them can be just copied from System_unix.cpp.
-
Probably all of them can be just copied from System_unix.cpp.
I suppose they can't. Take into consideration that application on OSX is an .app dir. I have no idea how's that related to data dir. Binary itself is hidden somewhere inside this .app, I don't know whether your current dir when you run this .app is inside binary dir, inside .app dir or somwhere else. Same with config dir. AFAIR fs2_open holds it somewhere else then ~/.fs2_open.
So basically you can't copy that from System_unix but a person with basic knowledge how that work on OSX should be able to do that without any problems. If any of you is eager to do that be my guest, would be nice to run this launcher on OSX.
Answering Soulstorm's question, no I don't want you to stop developing anything if you feel that's needed. On the other hand if you feel you're doing the same work and would like to help here you're more then welcome.
-
Yes, I am willing to help.
Also, I haven't been around for some time, and I also haven't taken a look at this Launcher to see differences and similarities in functionality, so I can't tell you if 2 Launchers are needed. Right now, I am willing to begin writing Launcher 4, which will be a complete overhaul from 3, and I also want it to use Core Animation in order to make the UI more appealing to the end user. Objective C offers a great level of abstraction, and sometimes that is needed.
So, what do I do to help? Must I download a binary? Or take a brief look at the source? This program is Qt based, right? Please pm me if you are interested in me helping with anything regarding the new Launcher.
-
We're very utilitarian in this community. I can tell you we don't need core animations (unnecessary animations would make it worse). Just make it a good utility launcher and that's what everyone wants at heart.
-
I wouldn't speak for the whole community, Mac users are notorious for expecting a pretty UI, even if the same doesn't apply to the community as a whole. If it improves the user experience then go for it.
-
Can someone help me getting this working on Kubuntu 9.04?
I've played this on XP before but I thought I'd try to get it going on Linux as well
I get these errors:
make -f Makefile.Release
make[1]: Entering directory `/home/agent24/Desktop/yal-0.1.3'
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -Isrc -Isrc/gui -Irelease -o release/FilePaths.o src/FilePaths.cpp
make[1]: g++: Command not found
make[1]: *** [release/FilePaths.o] Error 127
make[1]: Leaving directory `/home/agent24/Desktop/yal-0.1.3'
make: *** [release] Error 2
-
The error seems pretty self explanatory to me, it can't find g++ so there's something wrong with your build environment. Either it's not installed or it's not in your path.
-
Exactly as chief said. Besides if you want to use it take SVN version, much more usable.
-
Thanks but I have no idea how to get SVN or what g++ is or what to install to get it...
-
Use synaptic to install the build-essential and qt-make packages.
-
Also install subversion, create some dir and inside it in terminal run:
$ svn co svn://vega.livecd.pl/yal/trunk
-
I have decided to take a look at the Launcher, so I downloaded from the latest trunk at the SVN. I installed QT 4.5 on Leopard, and I opened the "yal.pro" file. When building, I received 12 warnings and 4 errors from the debugger. Note that I have Leopard.
In Snow Leopard, I receive 250 warnings and 46 errors, and I take it this is a Qt incompatibility with Snow Leopard.
This is what I am getting in Leopard 10.5.8:
/Users/soulstorm/programming/Active Projects (Controlled)/FS2_QT/trunk/src/macx/FilePaths_macx.cpp:3: error: prototype for 'bool FilePaths::initialize()' does not match any in class 'FilePaths'
/Users/soulstorm/programming/Active Projects (Controlled)/FS2_QT/trunk/src/macx/FilePaths_macx.cpp:3: error: prototype for 'bool FilePaths::initialize()' does not match any in class 'FilePaths'
/Users/soulstorm/programming/Active Projects (Controlled)/FS2_QT/trunk/src/macx/FilePaths_macx.cpp:3: error: prototype for 'bool FilePaths::initialize()' does not match any in class 'FilePaths'
/Users/soulstorm/programming/Active Projects (Controlled)/FS2_QT/trunk/src/macx/FilePaths_macx.cpp:3: error: prototype for 'bool FilePaths::initialize()' does not match any in class 'FilePaths'
I guess that you need help with the OS X side of the Launcher? Or I did something really wrong with this one? I would really like to help with Qt, and I intend to get to know it better, since I need to do some cross platform work in some projects.
-
Exactly, the errors you pasted show unimplemented functions that need to be done for OSX. Just look what they are in linux/win version, they are QT independant, just some simple functions for finding files and a little bit more complicated for running processes.
-
I will try. I intend to get involved with Qt, and when I learn to do some basic stuff, this Launcher is the first one I will look into, in order to establish support for OS X.
If I may ask, is distributing the compiled application with Qt allowed? Or must anyone who wants to use the Launcher must download the source and compile it?
EDIT: Oh, and... if anyone doesn't have the Qt framework installed, can he/she use the precompiled binary?
-
If I may ask, is distributing the compiled application with Qt allowed? Or must anyone who wants to use the Launcher must download the source and compile it?
You can distribute the precompiled binary but if it's compiled from modified source you need to give the modified source as well if someone asks you (GPL)
EDIT: Oh, and... if anyone doesn't have the Qt framework installed, can he/she use the precompiled binary?
Normally no, there are few ways to workaround that:
1. Statically link
2. Include libs together with binary (more of a windows way)
3. Include framework within .app dir (osx way, don't know whether that's possible but something like this should be)
-
Is this the latest launcher?