2021-12-08 19:40 EST


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002119FSSCPPlatform-Engine interactionpublic2021-01-09 04:29
Reporterchief1983 
Assigned Tochief1983 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0002119: Add support for moving the engine outside of the game data folder
DescriptionThere really isn't a reason the engine needs to be located in the same folder as the game's data. This would help out with packaging the system on Linux as the engine could essentially be a dependency of the game data, and multiple versions of the engine could be properly installed in the bin folder. Similar usefulness would be found on Windows as the Installer/Launcher could simply acquire necessary copies of the engine and store them in a /bin/ folder, and then tell the engine where the game data is at runtime. This data should therefore probably be stored in the unified config file mentioned in 0002118.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0011773

taylor (administrator)

I don't agree with this. On Linux in particular game binaries are installed with the data and then a link or shell script is but in a /bin directory to start it. This is the generally accepted practice with such things.

I also don't see a good reason to allow such a thing in the first place. Multiple versions of the engine can be easily installed without it; it goes against established packaging rules for such applications; it requires that a Launcher or other special configuration be done before being about the play a game thereby limiting future capabilities.

~0011778

chief1983 (administrator)

Installing the engine as a dependency of the game goes against typical packaging? Seems like it would fit in fine to me.

~0011780

taylor (administrator)

No, I'm saying that the engine is a fundamental part of a distributed game and as such you shouldn't separate the two. The game is nothing without the engine and the engine is nothing without the game. There is no reason to handle them separately.

Different TCs can and will use different engine versions so this would only cause problems. It also negatively impacts the preference of system versus local installs.

~0011781

chief1983 (administrator)

The same could be said for any library ever depended on by an application, yet they're always separate on Linux especially.

So what does an install of multiple TCs on Linux currently look like, and what kind of issues are there with it? How does the config data work with different exes in different install paths for different games?

~0011844

iss_mneur (developer)

Currently FSO on windows requests it's binary's location and then changes its working directory to that location. On SCP_UNIX platforms FSO does not do this and thus carries on with its inherited current working directory.

As such, chief1983 has running the game from outside the game data folder been attempted on linux? If so, what breaks? I unfortunately do not have a SCP_UNIX machine that will run FSO, so I cannot test this out.

To get this to work on windows it should be as simple as removing the change directory code from the binary to allow for this to work.

~0012931

niffiwan (developer)

Last edited: 2011-11-06 21:49

FYI - this is what you get when you run FSO on Linux from outside the game data folder:

ERROR: " Web cursor bitmap not found. This is most likely due to one of three reasons: 1) You're running FreeSpace Open from somewhere other than your FreeSpace 2 folder; 2) You've somehow corrupted your FreeSpace 2 installation, e.g. by modifying or removing the retail VP files; 3) You haven't installed FreeSpace 2 at all. (Note that installing FreeSpace Open does NOT remove the need for a FreeSpace 2 installation.) Number 1 can be fixed by simply moving the FreeSpace Open executable file to the FreeSpace 2 folder. Numbers 2 and 3 can be fixed by installing or reinstalling FreeSpace 2." at graphics/2d.cpp:621
AL lib: ALc.c:1879: exit(): closing 1 Device
AL lib: ALc.c:1808: alcCloseDevice(): destroying 1 Context(s)
Inconsistency detected by ld.so: dl-close.c: 731: _dl_close: Assertion `map->l_init_called' failed!

~0012932

chief1983 (administrator)

Yup. Would like to be able to have a way to tell the binary where the game data folder is, some sort of config setting or command line option, instead of just always assuming the root directory.

~0012933

iss_mneur (developer)

I don't think that is necessary. What niffiwan just noted is that on SCP_UNIX fso uses the current working directory as its data dir which is just fine for what this bug it looking for (use a shell script to change to directory that the data is in and just go from there).

~0012934

niffiwan (developer)

Last edited: 2011-11-06 21:50

So if we assume we have a some packages (.deb or .rpm) like:

fso-3.6.14 (fs2_open_3.6.14 in /usr/share/games/freespace2)
fso-retail (*.vp in /usr/share/games/freespace2)
fso-mediavp-3.6.12 (mediavps_3612 in /usr/share/games/freespace2)

then the fso-3.6.14 package would also contain a script, (e.g.) /usr/bin/freespace2, which looked something like:

#!/bin/sh
cd /usr/share/games/freespace2
./fs2_open_3.6.14

When 3.7.0 was released, you'd have a new package called (e.g.) fso-3.7.0 and the script would look like:

#!/bin/sh
cd /usr/share/games/freespace2
./fs2_open_3.7.0

~0012936

chief1983 (administrator)

I'm not so worried about shell scripts as I am about wxLauncher being able to say, here's the binaries in one folder, here's the game data that I'm supposed to make work with one of those binaries, make it happen. If you're saying that could already be done without changing the FSO source, then great.

~0012937

iss_mneur (developer)

Yes, what niffwan's report implies is that the FSO source does not need to be changed for SCP_UNIX based builds to fix this bug.

However, for windows builds we will need to provide a commandline flag (so that we don't break the other launchers) that will disable the FSO behaviour that is causing us problems.

~0017055

MjnMixael (manager)

This feature was added in the last few years and works as expected.
+Notes

-Issue History
Date Modified Username Field Change
2010-02-10 12:05 chief1983 New Issue
2010-03-13 20:46 taylor Note Added: 0011773
2010-03-15 11:45 chief1983 Note Added: 0011778
2010-03-15 12:35 taylor Note Added: 0011780
2010-03-15 12:43 chief1983 Note Added: 0011781
2010-03-30 13:50 iss_mneur Note Added: 0011844
2011-11-05 23:09 niffiwan Note Added: 0012931
2011-11-05 23:10 niffiwan Note Edited: 0012931
2011-11-06 11:33 chief1983 Note Added: 0012932
2011-11-06 12:20 iss_mneur Note Added: 0012933
2011-11-06 21:47 niffiwan Note Added: 0012934
2011-11-06 21:49 niffiwan Note Edited: 0012931
2011-11-06 21:50 niffiwan Note Edited: 0012934
2011-11-07 11:43 chief1983 Note Added: 0012936
2011-11-07 21:01 iss_mneur Note Added: 0012937
2012-04-03 09:51 Echelon9 Severity block => feature
2021-01-09 04:29 MjnMixael Assigned To => chief1983
2021-01-09 04:29 MjnMixael Status new => closed
2021-01-09 04:29 MjnMixael Resolution open => fixed
2021-01-09 04:29 MjnMixael Note Added: 0017055
+Issue History