Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: UbuntuFS2 on September 07, 2010, 08:49:15 am
-
Hi,
I have a project to make DEB packages for Ubuntu with FS2 SCP...
I have a couple of questions before I start anything :
1) Has anybody tried to run the game from "/usr/games", with the data placed in "/usr/share/games" ?
What options should i compile the game with to test this configuration ?
2) How could we include free data in the source tree to make packaging easy ?
3) We need an easy way to get nonfree data from the CDs to make an easy install on Linux...
Thanks for your answers.
-
also keep in mind most players are going to have dual boot systems and thus will have all the non-free files on an existing partition. so an option to select the installed directory might be good to have.
-
Putting the data and the game binary in different locations is something I filed a Mantis issue for, and that we are getting close to being able to support. #2119 (http://scp.indiegames.us/mantis/view.php?id=2119). Feel free to add any comments if you want. I don't think it's an insurmountable task, and would just make the engine a little more robust to support this. It will probably need to be done for one, for the new wxLauncher to manage multiple versions of the binaries in a clean manner. Unfortunately, it's not coded in to support this yet, but if you're interested in looking at that area of the code, let me know.
-
I would like to know, what is the license of the source code ? And the new media VPs ? And the old ones ?
-
SCP Source License is
Copyright (C) Volition, Inc. 1999. All rights reserved.
All source code herein is the property of Volition, Inc. You may not sell
or otherwise commercially exploit the source or things you created based
on the source.
MediaVPs are not under any license whatsoever.
-
We may as well slap a BSD license on those then, just so we have something.
-
CC-BY-NC (CC-BY-NC-SA if we're feeling trollish) would be better.
-
I would suggest just CC-BY, or just CC with no restrictions, if we went that route.
-
CC-BY would be what we've sort of used in the past. I'd like to use CC-BY-NC just because it matches the "SCP License" more closely.
-
I thought the idea was to be more open than the SCP license as it's annoyingly restricting.
-
IMHO, Attribution (if only in the form of "<ASSET> taken from the MediaVPs") is non-negotiable. "No commercial use" is something FSU needs to debate, but again, I personally would prefer to have the clause.
-
2) How could we include free data in the source tree to make packaging easy ?
3) We need an easy way to get nonfree data from the CDs to make an easy install on Linux...
The answers to both questions would probably be: postinst + debconf
This allows you easily to download mediavps or have users insert and/or specify cdrom disks or whatever.
Cheers
-
It would currently be possible to automate the extraction process from several sources, including the retail discs and the GOG download. But at least the GOG one would depend on Wine, as the only extractor I'm aware of for that type of archive exe only works on Windows. So possible, but a PITA right now.
-
It would currently be possible to automate the extraction process from several sources, including the retail discs and the GOG download. But at least the GOG one would depend on Wine, as the only extractor I'm aware of for that type of archive exe only works on Windows. So possible, but a PITA right now.
I thought 7-zip could open the GOG installer file for file extraction?
CC-BY would be what we've sort of used in the past. I'd like to use CC-BY-NC just because it matches the "SCP License" more closely.
We have to keep in mind FSU is based on an existing IP that we don't have any control over so the NC thing may be a requirement no matter what we do.
Putting the data and the game binary in different locations is something I filed a Mantis issue for, and that we are getting close to being able to support. #2119 (http://scp.indiegames.us/mantis/view.php?id=2119). Feel free to add any comments if you want. I don't think it's an insurmountable task, and would just make the engine a little more robust to support this. It will probably need to be done for one, for the new wxLauncher to manage multiple versions of the binaries in a clean manner. Unfortunately, it's not coded in to support this yet, but if you're interested in looking at that area of the code, let me know.
Regarding running FSO outside of the game data directory. As I noted in the bug report, the SCP_UNIX versions of FSO (Linux and OSX) do not have the restriction to be physically in the game data directory. For SCP_UNIX platforms you only need to have the current working directory set to the game directory (that is, using your shell cd to the game directory).
As for why FSO behaves this way on Windows only, I don't know why specifically. But based on the fact that the win32 launcher does not understand how to change directories (the win32 launcher also assumes that it is in the game data directory and that the binaries are in the same directory as it). Also, unless you set the "start in" field of the shortcut on windows, windows will set the current working directory to be the location of the shortcut (that is, the desktop or the start menu folder).
As for on SCP_UNIX, at this point the only reason that you cannot put the binary and the game data into different folders is entirely restrictions of the launchers on Linux and OSX. wxLauncher is more that capable of supporting this (in fact, it does this to extract the flag file, but I digress), but currently it assumes that the binaries are in the game data directory and only in the game data directory.
As for fixing this concern on windows, it is something I have been working on as part of my "Launcher/Platform/FSO interoperability work". The biggest issue is backward compatibility with older launchers (if only because wxLauncher is not ready for prime time as of yet) and older binaries that have this hard coded restriction (on windows only).
-
would it not be possible to use a symbolic link to mount an exsisting FSO directory somewhere more Linux friendly?
-
would it not be possible to use a symbolic link to mount an exsisting FSO directory somewhere more Linux friendly?
you would have to link the whole data folder, which seems silly to me, I would rather bind it.
-
I just want to make sure, dual boot compatibility is a priority, right?
-
So, for the first version of our debs, here's what we are doing.
There are 5 deb packages:
- fs2open (the game engine + depends on the other packages to get them all installed),
- fs2open-data (basic VPs from the FS2 Upgrade Project),
- fs2open-data-extra (MV_Advanced, MV_RadarIcons ...),
- fs2open-data-nonfree (this does not contain data from Volition, but the other packages depend on it, and it uses debconf to extract nonfree data from retail CDs, or retail installation, or Good Old Games version),
- fs2open-tools, with our custom very simple launcher (basically, 2 buttons : play, select mod, will add some basic configuration then).
-
Why not use YAL or wxLauncher?
-
I just want to make sure, dual boot compatibility is a priority, right?
for me it is.
-
We are thinking about dual-boot compatibility, but for now we are only including a script which asks for the retail data while installing the deb packages, giving the choice to import it from the game CDs, Good Old Game, or another place including a Windows installation.
About the launcher, i first thought about YAL, but according to the coder, we need to add Ubuntu specific things, so he is creating a light launcher which fits more to our needs.
-
About the launcher, i first thinked about YAL, but according to the coder, we need to add Ubuntu specific things, so he is creating a light launcher which fits more to our needs.
Ubuntu specific things?
-
About the launcher, i first thinked about YAL, but according to the coder, we need to add Ubuntu specific things, so he is creating a light launcher which fits more to our needs.
Ubuntu specific things?
probably libs that ubuntu comes with.
-
Libs aren't very platform specific. I would definitely keep an eye on the wxLauncher though, I'm not sure how far it is from being Linux usable yet.
-
it would probably be more accurate to say debian specific things.
which makes since seeing how this is a .deb package
-
it would probably be more accurate to say debian specific things.
which makes since seeing how this is a .deb package
Debian and ubuntu are not package compatible. they use the same file type but ubuntu uses different libraries than Debian, so most packages won't install them right.
-
Libs aren't very platform specific. I would definitely keep an eye on the wxLauncher though, I'm not sure how far it is from being Linux usable yet.
Version 0.8.0 is linux usable. That is why it has .deb (built on Ubuntu) installer available (which is apparently x64 only, yet nobody noticed until a few days ago). If you are having problems with it on linux please let me know.
If UbuntuFS2 wants, I can create a 32-bit version of the wxLauncher .deb and put it on wxLauncher's download site.
That being said, right now, wxLauncher is not necessarily the most user friendly launcher at this time.
-
We have mainly 3 reasons to code a new launcher :
-we prefer native GTK,
-we want something really simple (a menu to select, add or remove a mod, 2 buttons, play and configure (a pop up to set options for high or low end computer end), and the presentation of the mod),
-we need to integrate it with debconf, a debian specific configuration tool wich is triggered by the installation of the game, that we use to retrieve proprietary data from retail disks or another place.
It seems that the game still needs to be in the same directory as game data (data and mediavps). It caused some trouble to the packager.
Could this be fixed in 3.6.13 ? (And could the patch be backported to 3.6.12 ?)
The packages for the engine and the free data are now ok, and the package for the non free data installer is on the way !
I'll give you the PPA when there is a first version of all packages (probably 2 days from now).
-
-we want something really simple (a menu to select, add or remove a mod, 2 buttons, play and configure (a pop up to set options for high or low end computer end), and the presentation of the mod),
Personally, I'd like to have more in-depth configuration options than that.
Also, wxLauncher is supposed to become the official FSO Launcher in the future. We would prefer people to use it, as it is planned to incorporate functionality from Turey's installer.
It seems that the game still needs to be in the same directory as game data (data and mediavps). It caused some trouble to the packager.
Could this be fixed in 3.6.13 ? (And could the patch be backported to 3.6.12 ?)
We don't do backporting. As for fixing this, we'll have to look into it.
-
We haven't done backporting before, although I'm not against it as a rule. Dunno how anyone else feels about it.
-
It seems that the game still needs to be in the same directory as game data (data and mediavps). It caused some trouble to the packager.
Could this be fixed in 3.6.13 ? (And could the patch be backported to 3.6.12 ?)
Have you actually tried separating them? The documenation says that you can't, but in my searching the code, on *nix platforms, FSO should be fine having the binary separate from the game data.
The reason that the documenation says that is because most of our documenation was written by Windows developers (where you infact cannot separte the engine binary and the game data) and our current launchers (wxLauncher included, for now anyway) make the assumption that they are in the same directory.
-
The packager told me he solved the problem using links.
About wxLauncher, we don't need its install and update functionnalities, now we have a Ubuntu repository, fs2 open updates are synchronized with system ones. We also have a template to make mod packages for Ubuntu, it will be easy to maintain the repository.
Turey's installer, or the new wxLauncher are not made to be used as superuser, so it's more complicated to make multi-user installations of the game.
I think wxLauncher is a good thing for Windows and Mac OS X users, but it is redundant with Ubuntu package management.
And, as many people need to install retail data while installing the game, we wanted to unify the installation (free data from our repository, proprietary data from CDs or wherever else) with the tools given by our platform (debconf).
@The E: We will add more configuration options, but our goal is to make a very simple launcher, with the possibility to set advanced options by setting flags, for advanced users.
-
The packager told me he solved the problem using links.
About wxLauncher, we don't need its install and update functionnalities, now we have a Ubuntu repository, fs2 open updates are synchronized with system ones. We also have a template to make mod packages for Ubuntu, it will be easy to maintain the repository.
Turey's installer, or the new wxLauncher are not made to be used as superuser, so it's more complicated to make multi-user installations of the game.
How easy to maintain will this repository be? Who will maintain it? Who is "we"?
You see, as awesome as this is, I'd still like to know who we're dealing with here, and what your plans are. I mean, if we can build a mod deployment architecture using something like debconf, and if we could extend it so that it can be used on Windows and MacOS, that would help us immensely. Maintaining several separate pipelines for mod installation is a recipe for disaster IMHO.
I think wxLauncher is a good thing for Windows and Mac OS X users, but it is redundant with Ubuntu package management.
It's a good thing period. You see, one of its planned features is to make error reporting easier for support cases. Which is one thing I am really looking forward to.
@The E: We will add more configuration options, but our goal is to make a very simple launcher, with the possibility to set advanced options by setting flags, for advanced users.
You know, that's harder than it looks. You need to parse the binary blob the exe writes when started with the "-get_flags" option to get all arguments supported by the exe. In addition, you need support for setting the values for the various graphical settings that need numeric arguments.
-
Yes, having some sort of support for the official launcher even on a Linux system is strongly recommended. That said, it will be great to finally have a dedicated package maintainer for one of the most popular desktop Linux distributions currently available. There is probably a way to integrate the launcher's install functionality with Ubuntu's own even, but IssMneur and kkmic would have to look into that. Foregoing inclusion of the wxLauncher is going to become an increasingly troublesome proposition as it gains utility through its development though. The endgame is to have something like a Steam system of mod and engine management, but without all the stuff people hate about Steam (before the mere mention of it starts a flame war). It will be silly to try to duplicate that kind of functionality through Ubuntu's own package manager without the wxLauncher. That said, that functionality is still a ways off, as in on the drawing board, so whatever helps the most Ubuntu users get into FSO right now, can't be a bad thing, as long as the future changes are kept in mind. At one point it likely won't be a simple update. We also don't have terribly good documentation about what mods work with what engine/MediaVPs/etc, and trying to install multiple engine versions currently could be very difficult. Definitely not trying to turn you off, but I just want you to know what some of the speedbumps look like before you run into them.
-
The packager told me he solved the problem using links.
I would not advise you to use symlinks, they can always be problematic on multi-platform software packages. A better approach would be using quilt.
As for the launcher, you should probably consider working with wxlauncher upstream to make it support your wishes, eg support multiple widget toolkits or make features configurable for various platforms.
-
Turey's installer, or the new wxLauncher are not made to be used as superuser, so it's more complicated to make multi-user installations of the game.
What do you mean. What is wxLauncher lacking that makes it more complicated for multi-user installations? Most of the issues that I see with multi-user installations are actually caused by FSO and it windows legacy.
@The E: We will add more configuration options, but our goal is to make a very simple launcher, with the possibility to set advanced options by setting flags, for advanced users.
You know, that's harder than it looks. You need to parse the binary blob the exe writes when started with the "-get_flags" option to get all arguments supported by the exe. In addition, you need support for setting the values for the various graphical settings that need numeric arguments.
You got that right. As part of writing wxLauncher I have written up a wiki article (which lives on wxLauncher's wiki at this point) that enumerates how everything works and what FSO is expecting from the a launcher. http://code.google.com/p/wxlauncher/wiki/FS2OpenLauncherCommunication (http://code.google.com/p/wxlauncher/wiki/FS2OpenLauncherCommunication)
That said, that functionality is still a ways off, as in on the drawing board, so whatever helps the most Ubuntu users get into FSO right now, can't be a bad thing, as long as the future changes are kept in mind. At one point it likely won't be a simple update.
Well, as long as the packages follow the FSO -mod guidelines (they are on the FreeSpace wiki) and/or the manual mod installation guidelines, upgrading to wxLauncher shouldn't be a problem. Though the Ubuntu package manager may have some problems with it.
-
1) Has anybody tried to run the game from "/usr/games", with the data placed in "/usr/share/games" ?
What options should i compile the game with to test this configuration ?
A while ago, I made .deb packages for the FotG project, including the game engine. How I got around the problem of the game engine needing to be in the same directory was a simple script fs2_open, installed in /usr/bin, that would check to see if the directory already had a copy of fs2_open. If needed, it would copy the appropriate engine from either /usr/bin/fs2_open_r or /usb/bin/fs2_open_d to current directory as fs2_open, run the game with some decent flags, then remove the fs2_open from $CWD (if it wasn't there before).
Keep in mind, this has a bit of a security flaw in it.
However, you could package the game with a symlink to the binary, and a wrapper script to cd to that directory, and run the included binary. The gui launcher would just run that script.
-
1) Has anybody tried to run the game from "/usr/games", with the data placed in "/usr/share/games" ?
Not as far as I know. Keep in mind that FSO does require current working directory of the binary to be the game data directory.
What options should i compile the game with to test this configuration ?
The only prerequisite at this point is you have to be compiling in a SCP_UNIX system (Linux or OSX). Use inferno becuase there is no reason not to at this point. I would suggest a debug build while you are trying it out so that you will actually see any complaints or issues that FSO does actually have about this situation, if any.
A while ago, I made .deb packages for the FotG project, including the game engine. How I got around the problem of the game engine needing to be in the same directory was a simple script fs2_open, installed in /usr/bin, that would check to see if the directory already had a copy of fs2_open. If needed, it would copy the appropriate engine from either /usr/bin/fs2_open_r or /usb/bin/fs2_open_d to current directory as fs2_open, run the game with some decent flags, then remove the fs2_open from $CWD (if it wasn't there before).
Keep in mind, this has a bit of a security flaw in it.
However, you could package the game with a symlink to the binary, and a wrapper script to cd to that directory, and run the included binary. The gui launcher would just run that script.
That is a lot more complex than it needs to be. The binary (on SCP_UNIX systems only) does not care if the data is in the same directory as the binary, just that the current working directory you are running the binary in is the game data directory.
For example. If you put the game data in /usr/share/games/FotG and the binary at /usr/bin/fs2_open_3_6_12_INF_d (or however the binary is named on linux). All you would need to do is:
$ cd /usr/share/games/FotG
$ /usr/bin/fs2_open_3_6_12_INF_d <any flags that you need beyond what is in /usr/share/games/FotG/data/cmdline_fso.cfg and ~/.fs2_open/data/cmdline_fso.cfg>
this means that if you want to make a script to allow the user to run the game without running the launcher first the script simply needs to be:
#!/bin/env bash
cd /usr/share/games/FotG
/usr/bin/fs2_open_3_6_12_INF_d <any flags that you need beyond what is in /usr/share/games/FotG/data/cmdline_fso.cfg and ~/.fs2_open/data/cmdline_fso.cfg>
Obviously, this would not support updating the binary very well, but that is what the launcher is for. The only real issue with this configuration is that the launcher's, wxLauncher included assume that the game data and the binaries are in the same folder, but in wxLauncher's case, that is simply a minor code change away.
-
I'd love to see some working packages, even though I'm a Debian user myself. I haven't been active for the last few years due to not having a proper GPU to play FS on, and a rather-full time BSc degree taking a lot of time. I've been lurking for the past few months though, and here are some questions/remarks:
How DFSG (Debian free-software guidelines) compatible does Ubuntu want to be? The whole NC bit is incompatible with GPL code, and I'm not sure if Ubuntu likes that kind of code in the repos. I'm sure that Debian packages based on this source are stuck in non-free, and need seperate licenses and all. How problematic is this for Ubuntu?
Aside from that, I'd like to join the rest in recommending the use of a standard launcher, and not making your own Ubuntu-specific one, especially for bugreports. I assume that the package maintainers would prefer to file as much upstream as possible, and I guess upstream would really like everyone using the same launcher...
-
I'll give you the PPA when there is a first version of all packages (probably 2 days from now).
So... how long are those two days gonna be? :D
-
1) Has anybody tried to run the game from "/usr/games", with the data placed in "/usr/share/games" ?
Not as far as I know. Keep in mind that FSO does require current working directory of the binary to be the game data directory.
There are enumerable ways to solve this, not sure which is best. Attached is a small(2 line) patch that has fs2_open change the working directory to whatever the env. variable FS2_DATA_DIR is pointing to.
[attachment deleted by admin]
-
There are enumerable ways to solve this, not sure which is best. Attached is a small(2 line) patch that has fs2_open change the working directory to whatever the env. variable FS2_DATA_DIR is pointing to.
Yes, have the caller change directory to the game data directory before calling the binary. This is what wxLauncher does on linux.
That being said, if we go this route, we should have FSO log that is it is changing dirs (and the directory that it is changing to) so that the support ninjas can tell what is going on. Also, IIRC (I don't have the code in front of me) logging would have already started, which means that the log file is being written to the old working directory.
-
So chdir, then write the working dir to the log file once it's created.
-
Well. guess this was just someone blowing a lot of steam again, huh?
Has anyone heard anything about how this project is progressing?
-
Well, pretty old thread, isn't it.
Now there are DEB packages available for wxlauncher and freespace2 engine, respectively:
http://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=freespace2&searchon=names
The engine is installed to /usr/games and needs to be copied to the main FS2 folder. 64bit users need to be sure to run
sudo apt-get install libasound2:i386 libasyncns0:i386 libavahi-client-dev:i386 libc6:i386 libcaca0:i386 libdbus-1-3:i386 libflac8:i386 libgcc1:i386 libglu1-mesa:i386 libjansson4:i386 libjpeg-turbo8:i386 libjson-c2:i386 liblua5.1-0:i386 libncursesw5:i386 libogg0:i386 libopenal1:i386 libpng12-0:i386 libpulse0:i386 libpulse-dev:i386 libsdl1.2debian:i386 libsdl1.2-dev:i386 libslang2:i386 libsndfile1:i386 libstdc++6:i386 libtheora0:i386 libtinfo5:i386 libvorbis0a:i386 libvorbisenc2:i386 libvorbisfile3:i386 libwrap0:i386 libx11-6:i386 libxau6:i386 libxcb1:i386 libxdmcp6:i386 libxext6:i386 zlib1g:i386
32bit users:
sudo apt-get install libjansson4 liblua5.1-0 libopenal1 libsdl1.2debian libsdl1.2-dev
-
Just be aware that it's 3.7.0. Given the way distros work, a PPA would probably suit FSO best, i.e. to be more up to date. The only issue being, I couldn't figure out how to config a PPA to build for multiple Ubuntu versions (I really prefer rpm spec files to all the malarkey you need to build a deb! :))
-
From wiley on its 3.7.2. Even wxlauncher is 0.10.1 in xenial. But you are right, a PPA (from hard-light.net?!) would be the best solution.
-
If it needs to be hosted, we could figure that out I'm pretty sure.
-
From wiley on its 3.7.2. Even wxlauncher is 0.10.1 in xenial. But you are right, a PPA (from hard-light.net?!) would be the best solution.
I missed that, it's very cool that the debian maintainer is staying up to date, hurrah for Dmitry Smirnov :)
-
From wiley on its 3.7.2. Even wxlauncher is 0.10.1 in xenial. But you are right, a PPA (from hard-light.net?!) would be the best solution.
I missed that, it's very cool that the debian maintainer is staying up to date, hurrah for Dmitry Smirnov :)
Yes, Dmitry has been very helpful with getting wxLauncher into Debian in a very timely manner.
-
Is this thread itself still warranting a sticky? It doesn't actually have much useful info until page three, and if the packages are being maintained externally to this thread I don't see much purpose here.
-
nah, unsticky it