Oolite Bulletins

Apologies in advance if I'm breaking any board rules to do with formatting my post as I rarely do this and any pointers would be great. I've tried to put as much info as I can muster here, hopefully to make it easier to diagnose the problem.

I'm running Gnustep Ooliite latest build from your website: oolite-1.86.linux-x86_64.run (101mb) after installing the Synaptic version which is pretty dated so I purged it to start a fresh install.
I'm running Linux Mint 17.3 KDE 64bit, Cpu: AMD FX-8370 Eight-Core, Ram: Kingston 8g, Mobo: Asus 970 pro gaming aura, Video: GM107 [GeForce GTX 750 Ti], Audio: SBx00 Azalia (Intel HDA), HDD: various + usb webcam
^as reported from $ lshw --short

1st Initial run worked from the menu launcher except for no sound. Found this board and tried:

me@somepc:~/GNUstep/Applications/Oolite > ./oolite --nosplash

It seems that your operating system does not have a valid timezone name
configured and is using an abbreviation instead. By comparing timezone
file data it is has been possible to find the actual timezone used, but
doing that is a slow process.

You can avoid slowness of this time zone detecting approach
by setting the environment variable TZ='NZ'
Or You can override the timezone name by setting the 'Local Time Zone'
NSUserDefault via the 'defaults' command line utility, a Preferences
application, or some other utility.
eg "defaults write NSGlobalDomain 'Local Time Zone' 'NZ'"

AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
AL lib: (EE) alcOpenDevice: Option 'format' is deprecated, please use 'channels' and 'sample-type'
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/hwC0D0
AL lib: (EE) alsa_open_playback: Could not open playback device '/dev/snd/hwC0D0': No such file or directory
AL lib: (EE) alcOpenDevice: Option 'format' is deprecated, please use 'channels' and 'sample-type'
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/hwC0D0
AL lib: (EE) alsa_open_playback: Could not open playback device '/dev/snd/hwC0D0': No such file or directory
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
AL lib: (EE) alcOpenDevice: Option 'format' is deprecated, please use 'channels' and 'sample-type'
AL lib: (EE) alsa_open_playback: Could not open playback device '/dev/snd/hwC0D0': No such file or directory
19:05:04.248 [sound.initialization.error]: Failed to open default sound device

2nd I use .alsoftrc in my home folder as a workaround for alot of games that had sound issues, with good results.
.alsoftrc
[general]
layout_STEREO = fl=-30, fr=30
format = AL_FORMAT_STEREO16
cf_level = 0
sources = 256
frequency = 44100
period_size = 1024
periods = 4
stereodup = false
excludefx =
slots = 4
sends = 2
drivers = pulse,alsa,oss,dsound,winmm,wave,port,solaris

[alsa]
device = /dev/snd/hwC0D0 <<< see below
capture = /dev/snd/hwC0D0
mmap = true

[oss]
device = /dev/dsp
capture = /dev/dsp

[port]
device = -1

[solaris]
device = /dev/audio

[wave]
file =

<<< So I thought maybe if changing this line with every /dev/snd/ device listed below except seq & timer in turn might work.

me@somepc: ls /dev/snd/*
/dev/snd/controlC0 /dev/snd/pcmC0D0c /dev/snd/pcmC1D7p
/dev/snd/controlC1 /dev/snd/pcmC0D0p /dev/snd/pcmC1D8p
/dev/snd/controlC2 /dev/snd/pcmC0D1p /dev/snd/pcmC2D0c
/dev/snd/hwC0D0 /dev/snd/pcmC0D2c /dev/snd/seq
/dev/snd/hwC1D0 /dev/snd/pcmC1D3p /dev/snd/timer

/dev/snd/by-id:
usb-046d_08d7-01

/dev/snd/by-path:
pci-0000:00:12.0-usb-0:4:1.1 pci-0000:00:14.2 pci-0000:01:00.1

Nope.
Looked at other alsa workarounds to no avail.

3rd :idea Tried disabling the lib folder as advised from another post on this board and got:

me@somepc~/GNUstep/Applications/Oolite > ./oolite --nosplash
./oolite.app/oolite: error while loading shared libraries: libgnustep-base.so.1.20: cannot open shared object file: No such file or directory

Erk. It looks like Oolite died with an error. When making an error
report, please copy + paste the log above into the report.

(Press Ctrl-C to continue)
^C

Put the folder back and then removed 'libopenal.so.1' and 'libSDL-1.2.so.0' each in turn & also together with the same initial result. I guess both files reside on my system (but they could be symlinked to other versions, I'm not sure) as the error message didn't change.

4th Try the 'padsp' trick (which I use on UT2004 in the 32bit version) with both 32 & 64 bit versions with no success either.

I feel like I'm ranting here, sorry . The game looks great and I would love to have the audio woking.
Tried a few things and no dice so maybe someone could help me please?
It might be something complex (hope not) or something real simple which I'm missing.

Any help would be appreciated & I thank you in advance ('-')

Welcome aboard, Commander! Hopefully, a penguinista will be along soon with some advice/ideas.

Thanks for welcoming me in. Yes I hope so too, would like to start playing this game as I got some Ice Pirates to track down
So if the Air Force contols an air space what does the Galcor control... Spaces' space

rustyshark wrote:

Apologies in advance if I'm breaking any board rules to do with formatting my post as I rarely do this and any pointers would be great. I've tried to put as much info as I can muster here, hopefully to make it easier to diagnose the problem.

No worries its pretty casual here.
Really a bummer, Oolite runs ok for me on Mint 17.3 Mate, at least the version I installed when I installed 17.3 last, I'll have to check that out.

rustyshark wrote:

me@somepc~/GNUstep/Applications/Oolite > ./oolite --nosplash
./oolite.app/oolite: error while loading shared libraries: libgnustep-base.so.1.20: cannot open shared object file: No such file or directory

I don't think this has anything to do with your sound problem, but is a bug of some kind that may to be affecting the latest versions of oolite.
I recently installed 18.3 and if I even try to do storm@knucklehead ~/GNUstep/Applications/Oolite-trunk/oolite.app $ ./oolite I get the same message, but if I run it from the icon in the start menu Oolite starts and runs fine including sound.
The version I compiled myself doesn't give that message and runs fine from terminal.

Could you try running the ./oolite command without the nosplash parameter to verify if this happens to you as well?

The only thing I can think of that you didn't mention is if you ran apt-get autoremove after purging oolite. I'm not sure it will help but it might be worth a try if you don't have any custom installations or compiled software.

As Stormrider says, we're pretty casual here - I'm in my pyjamas.

rustyshark wrote: ↑Mon Jan 01, 2018 7:13 am

... any pointers would be great.

If you highlight code snippets and hit the Code button (or the icode button for short inline snippets) it's clearer.

Yeah sorry forgot to mention I autoremoved after purging the Software Manager version, but just to make sure autoremoved again. Same results:
I've tried all possible start options, from the kicker menu, the wrapper script and with the --nosplash option, the last 2 from the console. Same result. Gahh!
Then I thought, wait a minute what if I remove '.alsoftrc' temporarily?
Holy cigar smokin' chipmunks Batman! We have audio! I love the autopilot music, classic.
Setting up a script to archive then delete '.alsoftrc' everytime Oolite runs, then upon exit extract it again for other software to use might be a good workaround.

Thanks everyone for the quick replies and happy hunting people.

I can now sprinkle space dust on my cornflakes instead of sugar

rustyshark wrote:

Setting up a script to archive then delete '.alsoftrc' everytime Oolite runs, then upon exit extract it again for other software to use might be a good workaround.

I am glad you got it working, I've been running the Trunk version of Oolite on mint systems for years and haven't ever really had any issues.
I think I'll start another thread about the libgnustep-base.so.1.20 error. I don't know if its expected behavior but I haven't noticed it before.

Cool!

rustyshark wrote: ↑Wed Jan 03, 2018 8:15 am

I can now sprinkle space dust on my cornflakes instead of sugar

A psychedelic breakfast, perhaps?

For what it's worth, when you execute oolite, you actually run a script which
it executes the Oolite/oolite.app/oolite-wrapper script which
it actually executes the Oolite/oolite.app/oolite binary.
The Oolite/oolite.app/oolite-wrapper script instructs the O/S to first look into Oolite/oolite-deps/lib folder, for any library requested by the Oolite/oolite.app/oolite binary, before looking into its system library folders. In that way we ensure Oolite portability and maintainability.
If the O/S does not find a library requested in the suggested folder, then it starts looking at its own system library folders.
If the requested library can still not be found, an error is triggered and the execution is aborted.

In the libgnustep-base.so.1.20 case, the O/S could not find it in either the Oolite/oolite-deps/lib folder (being deliberately obfuscated by rustyshark), or the system library folders (most probably having a higher version, if no libgnustep at all). Oolite is compiled to specifically look for this version.

Conclusion
Completely removing the Oolite/oolite-deps/lib folder will most probably lead to execution abort, due to For troubleshooting purposes only, sometimes we suggest to players with issues, to selectively "hide" specific "Oolite-packaged" libraries, just to check O/S compatibility. Most common (still rare, though) issues come with audio; actually I don't recall any other type of issue nagging the Oolite players.
This is why there is a specific section for troubleshooting audio issues in the Oolite/doc/README.TXT file.

Getafix wrote:

For what it's worth, when you execute oolite, you actually run a script which
it executes the Oolite/oolite.app/oolite-wrapper script which
it actually executes the Oolite/oolite.app/oolite binary.
The Oolite/oolite.app/oolite-wrapper script instructs the O/S to first look into Oolite/oolite-deps/lib folder, for any library requested by the Oolite/oolite.app/oolite binary, before looking into its system library folders. In that way we ensure Oolite portability and maintainability.
If the O/S does not find a library requested in the suggested folder, then it starts looking at its own system library folders.
If the requested library can still not be found, an error is triggered and the execution is aborted.

In the libgnustep-base.so.1.20 case, the O/S could not find it in either the Oolite/oolite-deps/lib folder (being deliberately obfuscated by rustyshark), or the system library folders (most probably having a higher version, if no libgnustep at all). Oolite is compiled to specifically look for this version.

Thanks for the clarification Getafix, I though it might be something like that. I am pretty sure I used to be able to run the oolite binary without invoking the oolite-wrapper, so I think Mint has recently updated libgnustep-base.so.1.20. I can.t even find a version of libgnustep-base.so in synaptic anymore so maybe its been included in libgnustep-base 1.24.
What threw me is that the version I compiled does run from the binary, but I never make-install. I just compile the code, rename the oolite folder that git creates, drop it in ~/GNUstep/Applications with the rest of my oolite versions, and create a custom launcher on my desktop that points to the binary.

Actually, if you build your own oolite binary, it will use your system's libraries.
This is most probably why you can execute oolite without the wrapper.

Getafix wrote:

This is most probably why you can execute oolite without the wrapper.

But I can't anymore with any pre-compiled version, only with my own compiled version.
Check this out. This indicates to me that the only places I've got libgnustep-base.so.1.20 is in oolites dev folders so my compiled version must be using one of the libgnustep-base.so versions that are in /usr/lib.
No big deal, just trying to wrap my head around runtime environments, thanks again for the input.

I think we are saying the same thing; it just me saying it in a direct english translation of greek!

Your own compilation is using your system's libraries. It doesn't matter if the pre-compiled Oolite libraries are there. Wrapper or no wrapper it will look for your system's libraries.

The pre-compiled Oolite, is compiled to use libgnustep.so.1.20, so if you don't use the wrapper, it will not find the library and will "gracefully" exit.

You can check out the shared libraries needed by an executable or a library itself as follows
(Note: objdump just dumps what the executable itself lists as libraries, while ldd goes further by following the graph backward, so that you can see what would be loaded by those libraries.)Try it with the pre-compiled and the own-compiled oolite executables and check-out the differences.

Cody, phsychadelic indeed! Om nom nom

Getafix, yes I saw the wrapper and the lib folder call and tried messing with that but no dice. But, it is good to know how things work for future trouble shooting. I've made a few lib folder workaround scripts for other apps/games with a moderate success rate, so more knowledge is more fun solving problems and getting things up and running. In my exitement/frustration I forgot to Oolite/doc/README.TXT, sorry yes your right so me bad can has remembory if fails, instructions read!

Stormrider, good info there. If I had more room on / I'd be all versions Oolite. Latest is working so I'm happy about that & with a swag of mods which are all working really well together. Modding rocks!

Now to stop getting blasted by blasted pirates.

Thanks everyone.