[UbuntuFS2]

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.

[Bobboau]

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.

[chief1983]

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.  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.

[UbuntuFS2]

I would like to know, what is the license of the source code ? And the new media VPs ? And the old ones ?

[The E]

SCP Source License is

Code: [Select]

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.

[chief1983]

We may as well slap a BSD license on those then, just so we have something.

[The E]

CC-BY-NC (CC-BY-NC-SA if we're feeling trollish) would be better.

[chief1983]

I would suggest just CC-BY, or just CC with no restrictions, if we went that route.

[The E]

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.

[chief1983]

I thought the idea was to be more open than the SCP license as it's annoyingly restricting.

[The E]

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.

[bash]

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

[chief1983]

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.

[Iss Mneur]

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.  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).

[Bobboau]

would it not be possible to use a symbolic link to mount an exsisting FSO directory somewhere more Linux friendly?

[Topgun]

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.

[Bobboau]

I just want to make sure, dual boot compatibility is a priority, right?

[UbuntuFS2]

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).

[The E]

Why not use YAL or wxLauncher?

[Topgun]

I just want to make sure, dual boot compatibility is a priority, right?

for me it is.