Help needed with an account

[spara]

Bugger. It was probably an old list from an old installation that came to haunt. In short, I can't get the in game manager to show anything. Here's what I have done:

1. Downloaded OoliteInstall-1.91.0.7617-240614-f930b3a-linux-dev-x86_64.run from github
2. Installed it system wide
3. Executed oolite and crash due to a too new library
4. Downgraded lib-file and Oolite runs
5. Tried to update expansion list from the game and it gives an empty list
6. Edited the oolite.plist preferences file by adding the address from wiki and the list is still empty

This pops into the log-file, when I choose "Download expansion list":

Code: Select all

14:24:29.356 [exception]: ***** Exception checking controls [pollDemoControls]: NSInvalidArgumentException : NSTask - no launch path set

[another_commander]

Can we see the preferences file after your edit?

[spara]

Sure

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>debug-settings-override</key>
    <dict>
    </dict>
    <key>display_height</key>
    <integer>1440</integer>
    <key>display_refresh</key>
    <integer>0</integer>
    <key>display_width</key>
    <integer>2560</integer>
    <key>fullscreen</key>
    <false/>
    <key>gamma-value</key>
    <real>1</real>
    <key>oxz-index-url</key>
    <string>http://addons.oolite.space/api/1.0/overview</string>
    <key>volume_control</key>
    <real>0.5</real>
    <key>window_height</key>
    <integer>808</integer>
    <key>window_width</key>
    <integer>1280</integer>
</dict>
</plist>

[another_commander]

Looks malformed to me. Try adding an "oolite" and an NSGlobalDomain section like this:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSGlobalDomain</key>
    <dict>
    </dict>
    <key>oolite</key>
    <dict>
        <key>debug-settings-override</key>
        <dict>
        </dict>
        <key>display_height</key>
        <integer>1440</integer>
        <key>display_refresh</key>
        <integer>0</integer>
        <key>display_width</key>
        <integer>2560</integer>
        <key>fullscreen</key>
        <false/>
        <key>gamma-value</key>
        <real>1</real>
        <key>oxz-index-url</key>
        <string>http://addons.oolite.space/api/1.0/overview</string>
        <key>volume_control</key>
        <real>0.5</real>
        <key>window_height</key>
        <integer>808</integer>
        <key>window_width</key>
        <integer>1280</integer>
    </dict>
</dict>
</plist>

[spara]

No dice. The same exception in the log. Maybe it's just some Linux thingy, a missing library, wrong execution rights somewhere or something. Who knows I'll look into the external solution.

[spara]

Got the OoliteStarter working. Guess that's the tool for expansions now. Looking nice.

[MrFlibble]

Just checked with a virgin Linux box (LinuxMint).

TLDR;
Fresh (local/home) install:
apt install libgnustep-base1.28 # to fix the silent crash (see below)
For the DM, make sure you're using the newest pre-release of Oolite.

Both the normal and dev version from releases, (more specifically the latest from that page 1.91.0.7617-240614-f930b3a) had the links already set right for DM. In game, select update expansion list, and voila, more than 700 to choose from.

Between (local) installs I zapped ~/.Oolite and ~/GNUstep to clear out state.

Please verify version spara. Something's amiss if the links were wrong. edit: Just saw your post. I see you've certainly got the right version. I confess I didn't try system-wide install just now. Maybe you still had stuff lurking in $HOME/GNUstep from an old install, which would likely not be overwritten by a system-wide install.

Wordy bit, from old eyes taking a new look at an old problem:

If missing libgnustep-base1.28, Oolite just gives a crashed/singularity popup which gives no clue about the issue. In the absence of that package, there's no log in ~/.Oolite/Logs.

Only when launched from a terminal does the issue reveal itself*. That's not trivial for a less technical user, as the executable is not in the path. For me (and likely for all who do a Home install) it was at ~/GNUstep/Applications/Oolite/oolite but if not, to find the path to it, right click the launcher and select 'edit', or look at the desktop file in ~/.local/share/applications.

* (or maybe digging X logs?)

Perhaps that should have a meaningful human-readable error message in the 'singularity' crash popup.

I wonder how many have fallen silently at these hurdles!

[spara]

Just for the fun of it, I deleted the installation, went through the GNUStep folder and at least tried to delete everything Oolite related. Then proceeded to make a home install and the result is the same:

Code: Select all

16:11:55.579 [exception]: ***** Exception checking controls [pollDemoControls]: NSInvalidArgumentException : NSTask - no launch path set

It must be something missing, a wrong version or wrong access rights somewhere in my Debian installation. The installation is something like 5 years old, but it has been kept at "testing" all the time. With an occasional tweak here and there when for example virtualbox does not play nicely with some new lib or the old Oolite debug wanting an old twisted version and so on.

For now, I think I'll settle with the OoliteStarter, it seems to do the job and is quite pleasant to use. Shame though, if someone else has this kind of trouble getting the game running. I would love to see some feedback from the manager instead of just an empty list when error occurs. Then again, this is not that out of the ordinary when using Debian testing. I'm quite sure Windows installations work just fine.

[hiran]

Wordy bit, from old eyes taking a new look at an old problem:

If missing libgnustep-base1.28, Oolite just gives a crashed/singularity popup which gives no clue about the issue. In the absence of that package, there's no log in ~/.Oolite/Logs.

Only when launched from a terminal does the issue reveal itself*. That's not trivial for a less technical user, as the executable is not in the path. For me (and likely for all who do a Home install) it was at ~/GNUstep/Applications/Oolite/oolite but if not, to find the path to it, right click the launcher and select 'edit', or look at the desktop file in ~/.local/share/applications.

* (or maybe digging X logs?)

Perhaps that should have a meaningful human-readable error message in the 'singularity' crash popup.

I wonder how many have fallen silently at these hurdles!

I added the popup message so graphical users get some message at all. It is so generic that the reason is unknown. At least you know 'hope and wait' will not solve it.

viewtopic.php?t=21405

But if you know ways to enrich the messages do not hold back.

[spara]

Can't just let this be . I tried with the old 1.90, set the "oxz-index-url" to "https://addons.oolite.space/api/1.0/overview" (and also to http://addons.oolite.space/api/1.0/overview) and I get a 404 page into Oolite-download.plist. If I put the address into a browser, I get the list. Any idea what could be causing this? Maybe it's the same with 1.91?

[another_commander]

Are you absolutely sure you are changing the prefs file at the right location? I mean, the 404 error would be what you would get with 1.90 if you didn't edit anything.

[spara]

Now we're talking. Right you are. Found the correct one. And now it works. I think 1.91 creates an oolite.plist file into Defaults directory, and 1.90 uses .GNUstepDefaults file. I was editing the wrong file. Thanks. Got the 1.90 working. 1.91 still throws the same exception, so no help there.

[MrFlibble]

But if you know ways to enrich the messages do not hold back.

Know, not directly. Pointers I can do.

To reset, I "apt autopurge 'that library'" (not installed by default on LinuxMint), blast the relevant Oolite files, and change my metaphorical shoes.

Joe Sixpack eagerly installs Oolite, launches the game from the apps menu, then gasps with disappointment as a popup vaguely hints:-

Oolite died in a singularity with exit code 127. For troubleshooting check console and log output.

Logs: "Where?", says Joe. There's no hint in the popup of what log to check. Helpdesk here rattles keys at an xterm: ls -al ~/.Oolite : Nope, only .oolite-run exists. So, no 'usual' log dir yet! ( I know right?, tail ~/.xsession-errors, but I'm pretending to be a low-paid helpdesk! )

Console output: Finding the executable to run it in a terminal would be far from simple for them. Knowing so to do... unlikely.

By this point, average Joe has a few hundred megs less storage, and has likely lost interest.

Were the prospective commander to persist, and manage to launch it from a terminal they'd of course get the vital, searchable clue which can be copy/pasted into a web search:

Code: Select all

$ GNUstep/Applications/Oolite/oolite
./oolite.app/oolite: error while loading shared libraries: libgnustep-base.so.1.28: 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.

Rather than the opaque "exit code 127", perhaps a more helpful human readable code in the popup like:-

error while loading shared libraries: libgnustep-base.so.1.28: cannot open shared object file.
Please see http://$wiki/$article for a proper clue.

I didn't dive into the source to check, perhaps 127 covers a range of ills, but since the terminal output is informative, I'd hope the popup could be specific too. If a wiki page describes this issue, then the console message should also mention it.

Could the console messages be mirrored in the popup?

[hiran]

Are you absolutely sure you are changing the prefs file at the right location? I mean, the 404 error would be what you would get with 1.90 if you didn't edit anything.

Umm just to be precise:
The 404 does happen on the old URL but is not guaranteed to happen.

Remember we gave up the old domain and someone else owns it now. It this someone else is now in control whether a request to his website is answered at all, not to talk of the response content.

We know the old domain was used to distribute malware. A somewhat desperate attack vector could be to offer nice addons that - when downloaded - turn out to be something else. Unlikely give the effort and prospective success but nevertheless...

[hiran]

Were the prospective commander to persist, and manage to launch it from a terminal they'd of course get the vital, searchable clue which can be copy/pasted into a web search:

Code: Select all

$ GNUstep/Applications/Oolite/oolite
./oolite.app/oolite: error while loading shared libraries: libgnustep-base.so.1.28: 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.

Rather than the opaque "exit code 127", perhaps a more helpful human readable code in the popup like:-

error while loading shared libraries: libgnustep-base.so.1.28: cannot open shared object file.
Please see http://$wiki/$article for a proper clue.

I didn't dive into the source to check, perhaps 127 covers a range of ills, but since the terminal output is informative, I'd hope the popup could be specific too. If a wiki page describes this issue, then the console message should also mention it.

Could the console messages be mirrored in the popup?

First, code 127 can mean a plethora of reasons. Basically it means the executable you tried to launch could not be launched. Not having the correct version of libgnustep is one of them. Not having another shared lib would also yield 127, and having an arm64 binary on an x86 platform would likely yield the same.
So it is required to look at stdout/stderr.

Then look at the process structure:
There is the oolite executable, run by a wrapper to set LD_LIBRARY_PATH, which again is run by a wrapper to display error on failure. When wiretapping stdout/stderr we need to grab the content while not blocking it from other users to be able to forward it into the UI. The UI is capable of more.