OpenXcom Forum
OpenXcom => Troubleshooting => Topic started by: Arthanor on October 10, 2014, 04:52:59 am
-
After playing with 1.0 for a while (which worked flawlessly), I have finally given in and decided to go the next step: Use the "nightly" version. Of course, there is no such thing on Linux, so it means downloading the code and compiling.
I installed all the dependencies first and then followed the instructions from https://www.ufopaedia.org/index.php?title=Compiling_with_Make_%28OpenXcom%29 (https://www.ufopaedia.org/index.php?title=Compiling_with_Make_%28OpenXcom%29). Everything compiled :D
The game actually loads (and loads all mods I ask it too) and accesses the data and user folders from my 1.0 install (presumably, since it knows of all the mods and when I disabled them in the compiled version, they were disabled in the 1.0 install too. (I kept every mod off for now, to not complicate things)
When I click "New Battle", I get as far as the red/orange screen with the terror mission description, click OK and crash to desktop instead going to the pre-mission inventory screen. If I want to start a new game, I get to pick the difficulty and then crash to desktop before the geoscape.
Launching OpenXCom from a terminal, I got some extra info. 14 instances of:
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: error: Unable to open file "/usr/share/sounds/sf2/FluidR3_GM.sf2"
fluidsynth: error: Couldn't load soundfont file
fluidsynth: error: Failed to load SoundFont "/usr/share/sounds/sf2/FluidR3_GM.sf2"
followed by:
Segmentation fault
I looked into that folder and, although it exists, there is no file named FluidR3_GM.sf2 in there. Is that something I am supposed to have from some other installation? I have no idea where to get that, or why it is needed for the nightly but not 1.0..
Thank you in advance to anyone willing to help!
-
a short search resultes in a package called "fluid-soundfont-gm" that has the missing file
no idea if that helps
-
Thanks for the search :)
It did have an effect, but unfortunately I can't say it was positive!
Now I only get the message "Failed to pin" line, so fewer errors, but they occur as soon as I launch the game, so I don't even make it to the intro. It takes forever too (to the point where I've had to restart the computer since nothing was responding anymore).
Looking at the errors, I searched for fluidsynth and installed that too, but no effect. Redownloading the code and compiling after all the installs also did not change anything either. And trying it now, my 1.0 install doesn't work anymore either :'(
-
Well, I purged the two new packages from my computer and the 1.0 install seems to work again :D (Tested Geoscape and Battlescape briefly).
I kept a copy of the missing file and put it back in the folder after the packages were uninstalled to see what would happen. It wasn't pretty!
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: error: Out of memory
fluidsynth: error: Failed to load SoundFont "/usr/share/sounds/sf2/FluidR3_GM.sf2"
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: error: Out of memory
fluidsynth: error: Failed to load SoundFont "/usr/share/sounds/sf2/FluidR3_GM.sf2"
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: error: Out of memory
fluidsynth: error: Failed to load SoundFont "/usr/share/sounds/sf2/FluidR3_GM.sf2"
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
Killed
Not sure where to go from here, beyond staying with 1.0.. :/
-
If the problem is with fluidsynth, I'd suggest getting one of the music replacement packs. I've been running that way on Linux for quite some time with no issues.
-
Oh? You mean one of the mods with different sounds? hum.. I already have one, but that might be something to look into more.
I have noticed that even though it runs fine, my installation of 1.0 also gives all the warnings about the same missing file. When I start it from the command line, I get the whole series of:
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: error: Unable to open file "/usr/share/sounds/sf2/FluidR3_GM.sf2"
fluidsynth: error: Couldn't load soundfont file
fluidsynth: error: Failed to load SoundFont "/usr/share/sounds/sf2/FluidR3_GM.sf2"
Followed by:
libpng warning: Out of place iCCP chunk
But everything runs fine and I've never had it crash on me (except for those crashes I create myself...).
So I am lead to believe that I can ignore the message that the nightly gives me since they are the same. Now why the game would crash upon going to the geoscape for a new campaign or to the inventory screen for a new battle, or loading any save.. I still don't know :/
-
Hi Arthanor
I'm having the game crashing issue when compiling from source in linux, not having any of those fluidsynth issues though.
I've found the following going back through the nightly builds:
Last working build (no crash):
647c3e5 - Pkrcel, Tue Aug 19 23:55:22 2014 +0200 : Moved "Discovered Techs" load before "Bases" loading to allow for PsiStringEval true upon loading a new game.
Noah's flood (entire planet under water):
3dd9bba - Daniel, Wed Aug 20 00:11:37 2014 +0100 : Merge pull request #928 from FalkoOXC/updatequickarmorselect
to
660503d - Warboy, Sun Aug 24 15:27:03 2014 +1000 : add comments.
Game crashes on trying to start a new game:
30dd33c - SupSuper, Thu Aug 28 02:08:22 2014 +0100 : Externalizing globe markers.
I haven't looked at the code in detail yet, but hopefully that'll be helpful. I suspect that it's got something to do with Terror From the Deep stuff... perhaps to get the latest build working we need to install stuff from the second game?
Basically, if you want to go to the last working nightly build then use git checkout 647c3e5. Compiling that and running it works for me. When I have time I'll try look into what's causing the crash.
Hope this helps
Update:
After taking a look it seems that we're missing a file called GlobeMarkers. I've logged a bug report here: https://openxcom.org/bugs/openxcom/issues/841
Slaveboy
-
Thanks a lot for the info!
As I wrote above, the fluidsynth errors are something else entirely. I get them with 1.0 even though it runs fine.
Your assessment of missing a file sounds right. I get the same behaviour out of my compiled version as when I try to use a resource that's not there while modding. And it being related to the globe would make sense since it crashes when you go pick your first base location in a new game. I would expect that the save architecture is slightly different as well, which could be why it saves when loading stuff. (Not sure about the impact on New Battle though, as that's not related to the globe).
I'll give it a try tonight to see how it goes! Thanks again!
-
Turns out that the problem was caused by me installing the game (using sudo apt-get install openxcom) and playing it before trying to set up compilation.
When I compiled the code, on starting up it looked for the data folder and found it where it had been installed to (~/.local/share/openxcom/data) instead of looking in the local bin/data directory (~/sandbox/OpenXcom/build/bin/data). The former did not have the Resources directory (among other things) and I hadn't copied the base xcom directories (GEODATA, GEOGRAPH, MAPS, ROUTES, SOUND, TERRAIN, UFOGRAPH, UFOINTRO, UNITS) into the latter.
The solution was to uninstall the openxcom with "sudo apt-get purge openxcom", then manually remove the ~/.local/share/openxcom and ~/.config/openxcom directories (warning, will lose your save games etc. that way) and then copy the base xcom directories into ~/sandbox/OpenXcom/build/bin/data/
Slaveboy
-
That's weird.. I haven't had time to try again, but my OpenXCom 1.0 installation uses the .data and .config folders, so those are full of everything needed by the game. I know that the version I compiled also tried to access those folders and succeeded (it read the config file and loaded all the mods I have when I first launched it, finding all the resources fine).
I'll give that a try any ways, since what you describe is similar to my situation: Install and play 1.0 before trying the nightly and failing.
Or maybe since it finds the data in the general folder, it stops looking elsewhere and thus doesn't find new data that was downloaded with the nightly and resides in its own directory? That could make sense, I think. (I know the game looks for the "global" folders and only looks in its directory if that fails)
Thanks for all the info! Now I just have to find the time to try..
-
just for reference, let me chronicle the steps I took to get my current working install. I get the feeling it is slightly different from what you are describing. The steps here keep the running installation separate from the source directory so I can install mods and not mess up the source code tree.
- git clone git@github.com:SupSuper/OpenXcom.git openxcom
- {copy XCOM1 assets into openxcom/bin/data}
- mkdir openxcom/build
- cd openxcom/build
- cmake ..
- ccmake ..
- {set CMAKE_BUILD_TYPE to Release (or Debug if you want useful stack traces)}
- {set CMAKE_INSTALL_PREFIX to /home/yourusername/bin/OpenXcom (or whatever)}
- {configure, generate, and exit}
- make -j3
- make install
Then I have a small executable script in my $HOME/bin directory (which is in my path) named openxcom with the contents:
#!/bin/sh
"$HOME/bin/OpenXcom/bin/openxcom" -data "$HOME/bin/OpenXcom/share/openxcom/data"
Then I install any mods I want in $HOME/bin/OpenXcom/share/openxcom/data and play play play
-
This is awesome! Thanks Myk!
Any chance you could add this setup to the wiki page? Possibly here: https://www.ufopaedia.org/index.php?title=Compiling_with_CMake_%28OpenXcom%29
It seems to be working perfectly. Only question I have is that I notice that when I launch the game (using the ~/bin/openxcom script), I get this added to the openxcom.log file:
[23-10-2014 10:28:12] [WARN] Unknown option: home/brian/bin/openxcom/share/openxcom/data
Any idea why that is? It doesn't seem to affect anything.
Thanks
-
That worked!! I really wish I could buy you a beer :D
I think one of the main trick is to not let OpenXCom access the "default linux" data folder, but instead force it to access the data folder that's specific to the new installation.
Using your method, when I ran just "$HOME/bin/OpenXcom/bin/openxcom", I got the same crashes as I used to have before: As soon as your load a game, start a campaign or start a new battle.
When I run it while specifying the data folder, it works flawlessly. This seems to indicate that bslaveboy was right saying that we were missing a file. It's not really a bug (since it actually does come in the installation), but it's "feature" of looking first in the default folder, which for me was full of stuff from 1.0 and missing other needed things.
Edit: So I just realized that the -data option seems to add to the search path for data, it doesn't overwrite the other ones. Indeed, my "$HOME/bin/OpenXcom/share/openxcom/data" folder is pretty much empty.
One of the unfortunate side effects is that the game doesn't use up to date language files, so I get "STR_BLA_BLA" in game sometimes. It happens since the game finds the language file in the default directory: "/usr/share/openxcom/data/", but that one I got with 1.0, for which features like menus in manufactoring were absent (so I see STR_ALL_ITEMS instead of "All Items").
One fix, I guess, is to remove the offending folders from the default path and only keep things like mods there, while making sure each installation has all it needs in its local data folder.
-
Any chance you could add this setup to the wiki page?
done: https://www.ufopaedia.org/index.php?title=Compiling_with_CMake_%28OpenXcom%29#End-to-end_example
It seems to be working perfectly. Only question I have is that I notice that when I launch the game (using the ~/bin/openxcom script), I get this added to the openxcom.log file:
[23-10-2014 10:28:12] [WARN] Unknown option: home/brian/bin/openxcom/share/openxcom/data
yeah, that is an artifact from the commandline parsing. it's harmless, but I'll put it on my list of things to look into and clean up.
Edit: So I just realized that the -data option seems to add to the search path for data, it doesn't overwrite the other ones. Indeed, my "$HOME/bin/OpenXcom/share/openxcom/data" folder is pretty much empty.
One of the unfortunate side effects is that the game doesn't use up to date language files, so I get "STR_BLA_BLA" in game sometimes. It happens since the game finds the language file in the default directory: "/usr/share/openxcom/data/", but that one I got with 1.0, for which features like menus in manufactoring were absent (so I see STR_ALL_ITEMS instead of "All Items").
One fix, I guess, is to remove the offending folders from the default path and only keep things like mods there, while making sure each installation has all it needs in its local data folder.
Thank you for figuring this out -- I had never run into these issues since I had never installed anything at the system level. I added a note to the wiki that says to ensure a system-level OpenXcom is not installed when using this method to build and run nightly versions.
-
Thanks for all the work! Now the little newbies of the future will have a much easier time :D
(Maybe a note regarding debugging slowing down the game significantly, so people don't make my mistake ;) Assuming that's the mistake, I'm reinstalling now.)
-
Thanks Myk!
Really appreciative of your help... now if I could just find some time to play and try my hand at mods. :)
-
(Maybe a note regarding debugging slowing down the game significantly, so people don't make my mistake [...])
Good idea. added.
-
One extra note for the future:
When you run: "ccmake ..", there is a "DATADIR" field, where you can define your data directory. Doing that may circumvent the need for the "- data [...]" part of the command line call.
-
good idea -- I'll have to test that out and add a note