View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002119 | FSSCP | Platform-Engine interaction | public | 2010-02-10 17:05 | 2021-01-09 09:29 |
| Reporter | chief1983 | Assigned To | chief1983 | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Summary | 0002119: Add support for moving the engine outside of the game data folder | ||||
| Description | There 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
Installing the engine as a dependency of the game goes against typical packaging? Seems like it would fit in fine to me. |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
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! |
|
|
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. |
|
|
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). |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
This feature was added in the last few years and works as expected. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-02-10 17:05 | chief1983 | New Issue | |
| 2010-03-14 01:46 | taylor | Note Added: 0011773 | |
| 2010-03-15 15:45 | chief1983 | Note Added: 0011778 | |
| 2010-03-15 16:35 | taylor | Note Added: 0011780 | |
| 2010-03-15 16:43 | chief1983 | Note Added: 0011781 | |
| 2010-03-30 17:50 | iss_mneur | Note Added: 0011844 | |
| 2011-11-06 03:09 | niffiwan | Note Added: 0012931 | |
| 2011-11-06 03:10 | niffiwan | Note Edited: 0012931 | |
| 2011-11-06 16:33 | chief1983 | Note Added: 0012932 | |
| 2011-11-06 17:20 | iss_mneur | Note Added: 0012933 | |
| 2011-11-07 02:47 | niffiwan | Note Added: 0012934 | |
| 2011-11-07 02:49 | niffiwan | Note Edited: 0012931 | |
| 2011-11-07 02:50 | niffiwan | Note Edited: 0012934 | |
| 2011-11-07 16:43 | chief1983 | Note Added: 0012936 | |
| 2011-11-08 02:01 | iss_mneur | Note Added: 0012937 | |
| 2012-04-03 13:51 | Echelon9 | Severity | block => feature |
| 2021-01-09 09:29 | MjnMixael | Assigned To | => chief1983 |
| 2021-01-09 09:29 | MjnMixael | Status | new => closed |
| 2021-01-09 09:29 | MjnMixael | Resolution | open => fixed |
| 2021-01-09 09:29 | MjnMixael | Note Added: 0017055 |
