Detect and run modern installations

[hiran]

Is this manifest used by Oolite itself or only by external utilities? I can see it generated in the make postamble and wondered if Oolite reads values from it.

That I cannot tell. However the structure of the Resources folder is just like an OXP. While I can only guess this is on purpose within Oolite I can confirm that OoliteStarter is taking advantage of this similarity when indexing OXPs and treating Oolite just the same.

We could add DEPLOYMENT_RELEASE_CONFIGURATION which can be yes or no. Where it is no, it means that there is a Basic-debug.oxp. Alternatively, we could put the release type like dev or test.

I had been experimenting with including a text file OOLITE_VERSION.txt in the build that would contain:
OOLITE_VERSION=1.92.1.7794-260223-0e2a2d2
BUILDTIME=2026.02.23 20:24
DEPLOYMENT=no

The different build types used to have names. So one is "", one is "test", one is "debug". If you introduce a new word DEPLOYMENT you will continually have to explain why a 'no' would mean the debug OXP is contained. All the documentation we have so far uses these three identifiers.

I could then cat that file in the Linux startup script if the user supplies an argument "packageinfo" eg.

Code: Select all

> ./Oolite_test_1.92.1.7794-260223-0e2a2d2-x86_64.AppImage packageinfo
OOLITE_VERSION=1.92.1.7794-260223-0e2a2d2
BUILDTIME=2026.02.23 20:24
DEPLOYMENT=no

I could cat the manifest instead, but just want to check where it is used. For example, if it is not used by Obj C, it makes less sense to use a plist format.

That sounds very usable.

[another_commander]

Of course this solution is so much better than what we currently have yet still less capable than where we used to be with classic builds.

The full version used to be in 'version'. Why do we need to distinguish a short and a full version at all? Little impact you might not see: The code that parses manifest.plist treats Oolite just like any other expansion. The key 'version' is mandatory and 'version_full key' is not defined at https://wiki.alioth.net/index.php/Manifest.plist

Why the hesitation about showing the full version? It allows users to easily compare and see which of two builds is newer. This helps everybody when reporting bugs or debugging.

I put the version_full key for exclusive use by OoliteStarter. If you want it to completely replace the version key, that's fine by me. This manifest is not used by anything critical in the game itself so it's no big deal.

In the next few days I'll put up a pull request for this change. I will replace the contents of the version key with the full version and remove the version_full key completely. I have also added a new key named "deployment_build" which has a yes/no value. Again, this key is meant for exclusive use by OoliteStarter to allow it to distinguish debug builds from non-debug ones.

It will look like this:

Code: Select all

{
	title = "Oolite core";
	identifier = "org.oolite.oolite";
	
	version = "1.93.0.7775-260223-e400ac6";
	deployment_build = "no";
	required_oolite_version = "1.93";
	
	license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
	author = "Giles Williams, Jens Ayton and contributors";
	information_url = "https://oolite.space/";
}

Edit: The version string from the manifest does appear to be used for something after all. Excerpt from the log:

Code: Select all

22:49:53.601 [script.load.world.listAll]: Loaded 29 world scripts:
    AddOns.anon-script
    InsectPicsOnF7.anon-script 1.0
    No Mass Locks 0.1
    Oolite Equipment Control 1.93.0.7775-260223-e400ac6
    Oolite Ship Library 1.93.0.7775-260223-e400ac6
    oolite-cloaking-device 1.93.0.7775-260223-e400ac6
    oolite-constrictor-hunt 1.93.0.7775-260223-e400ac6
    oolite-contracts-cargo 1.93.0.7775-260223-e400ac6
    oolite-contracts-helpers 1.93.0.7775-260223-e400ac6
    oolite-contracts-parcels 1.93.0.7775-260223-e400ac6
    oolite-contracts-passengers 1.93.0.7775-260223-e400ac6
    oolite-libPriorityAI 1.93.0.7775-260223-e400ac6
    oolite-nova 1.93.0.7775-260223-e400ac6
    oolite-populator 1.93.0.7775-260223-e400ac6
    oolite-primable-equipment-register 1.93.0.7775-260223-e400ac6
    oolite-registership 1.93.0.7775-260223-e400ac6
    oolite-thargoid-plans 1.93.0.7775-260223-e400ac6
    oolite-trumbles 3.5
    oolite-tutorial 1.93.0.7775-260223-e400ac6
    Select-o-matic Crosshairs 1.0
    Spawn-ice_shader_asteroid 1.0.1
    System Features: Rings 2.1
    System Redux 0.8
    woot_attack.js 0.3

[hiran]

I put the version_full key for exclusive use by OoliteStarter. If you want it to completely replace the version key, that's fine by me. This manifest is not used by anything critical in the game itself so it's no big deal.

Thank you.

In the next few days I'll put up a pull request for this change. I will replace the contents of the version key with the full version and remove the version_full key completely. I have also added a new key named "deployment_build" which has a yes/no value. Again, this key is meant for exclusive use by OoliteStarter to allow it to distinguish debug builds from non-debug ones.

If that key is exclusively for OoliteStarter to distinguish if a build is a debug version, why not name it like this?
'deployment_build=no' sound very fuzzy in this respect.
'debug_console_support=yes' would be more usable - not just for OoliteStarter but anyone trying to debug stuff.

[another_commander]

If that key is exclusively for OoliteStarter to distinguish if a build is a debug version, why not name it like this?
'deployment_build=no' sound very fuzzy in this respect.
'debug_console_support=yes' would be more usable - not just for OoliteStarter but anyone trying to debug stuff.

'debug_console_support=yes' is a bit complicated to code around - will have to write some logic in the script creating the manifest to handle it. What can be done instead, which does not require any logic implementation, is to name it 'debug_functionality_disabled'=yes/no. This maps to the same yes/no value as 'deployment_build'=yes/no and still is pretty clear in what it means.

[hiran]

If that key is exclusively for OoliteStarter to distinguish if a build is a debug version, why not name it like this?
'deployment_build=no' sound very fuzzy in this respect.
'debug_console_support=yes' would be more usable - not just for OoliteStarter but anyone trying to debug stuff.

'debug_console_support=yes' is a bit complicated to code around - will have to write some logic in the script creating the manifest to handle it. What can be done instead, which does not require any logic implementation, is to name it 'debug_functionality_disabled'=yes/no. This maps to the same yes/no value as 'deployment_build'=yes/no and still is pretty clear in what it means.

I do not understand why, but it is ok. Let's do that.

[another_commander]

The branch version_full_inline is up and contains the version changes discussed previously. Can someone running Linux please test the artifacts generated here (scroll to the bottom of the page) and confirm that the version inlining works as expected? You should be able to see the full version string in the output of oolite -help and you should also see it in the Resources/manifest.plist file.

If all good we can proceed soon with a PR.

[Lone_Wolf]

I applied https://github.com/OoliteProject/oolite ... 07c00d235d on top of oolite trunk commit 11b667a .

Both Resources/manifiest.plist and oolite -help show the full version .

Latest.log only shows 1.93 as version, Title/Menu screen in game doesn't show any version .

For consistency I feel the logs should also show the full version , having the full version visible on the title screen would be a bonus.

[another_commander]

Latest.log only shows 1.93 as version, Title/Menu screen in game doesn't show any version .

This is now updated to show the full version string at the log header. The code is not committed yet, will do so later today.

For consistency I feel the logs should also show the full version , having the full version visible on the title screen would be a bonus.

The main menu screen has also been updated to show the full version when the -showversion parameter is passed to the startup arguments, as per original design.

While at it, I also fixed the watermark version not displaying properly in the snapshot builds.

[another_commander]

PR #552 opened for the full version string inlining.

[another_commander]

PR 552 merged. Note that the key indicating test/snapshot release or deployment build is called debug_functionality_support now. It has a value of yes for test release and snapshot builds and a value of no for deployment builds.

[hiran]

Thank you.

After that latest push I downloaded https://github.com/OoliteProject/oolite ... c6.flatpak and installed it using

Flatpak

Code: Select all

flatpak install --verbose Downloads/space.oolite.Oolite_1.93.0.7777-260225-4193bc6.flatpak

Now I have these applications installed:

Code: Select all

$ flatpak list
Name                              Application ID                                         Version                             Branch               Origin                 Installation
[...]
Oolite                            space.oolite.Oolite                                    1.93.0.7777-260225-4193bc6          master               oolite-origin          system
Oolite                            space.oolite.Oolite                                    1.92.1                              stable               flathub                system
$ 

When I execute this command

Code: Select all

$ flatpak run space.oolite.Oolite

I get a window titled Oolite v1.93 - Feb 25 2026. It is not the full version. Is that still the version before the PR, or is there something else missing? Well, if I specify the -showversion parameter, the window has the full version printed inside. However the plan was to get the version from outside. You could say I have it from using flatpak list, but then I would still have to know how to run a distinct version of the two.

Nevertheless, when I scan for Oolite installations, both flatpaks are detected. But how can I specify which one to run?

Edit: I also executed flatpak update. Amongst various downloads it also updated space.oolite.Oolite from flathub.
So far so good, but it is irritating to after the update see that I still have 1.92.1 installed. Can we add the full version number here too?

AppImage

I downloaded both
https://github.com/OoliteProject/oolite ... 4.AppImage
https://github.com/OoliteProject/oolite ... 4.AppImage
and placed them somewhere in my filesystem.

OoliteStarter detected both. And although the extraction of the full AppImage is clumsy, version detection plus identification of the debug build works.

Improvement

None of the builds (neither Flatpak nor AppImage) would print the version number using -version or -showversion. Especially on the AppImage such a feature would prevent that I'd have to extract the full image just to get that information.

If that could be added to https://github.com/OoliteProject/oolite ... _oolite.sh it would be a good step forward.
Alternatively, to catch both cases (version, debug_functionality_support) it would also help if simply the manifest.plist were printed to the console before the script terminates. A -printmanifest option could do the trick.

[mcarans]

Thank you.

After that latest push I downloaded https://github.com/OoliteProject/oolite ... c6.flatpak and installed it using

Flatpak

Code: Select all

flatpak install --verbose Downloads/space.oolite.Oolite_1.93.0.7777-260225-4193bc6.flatpak

Now I have these applications installed:

Code: Select all

$ flatpak list
Name                              Application ID                                         Version                             Branch               Origin                 Installation
[...]
Oolite                            space.oolite.Oolite                                    1.93.0.7777-260225-4193bc6          master               oolite-origin          system
Oolite                            space.oolite.Oolite                                    1.92.1                              stable               flathub                system
$ 

When I execute this command

Code: Select all

$ flatpak run space.oolite.Oolite

I get a window titled Oolite v1.93 - Feb 25 2026. It is not the full version. Is that still the version before the PR, or is there something else missing? Well, if I specify the -showversion parameter, the window has the full version printed inside. However the plan was to get the version from outside. You could say I have it from using flatpak list, but then I would still have to know how to run a distinct version of the two.

Nevertheless, when I scan for Oolite installations, both flatpaks are detected. But how can I specify which one to run?

Edit: I also executed flatpak update. Amongst various downloads it also updated space.oolite.Oolite from flathub.
So far so good, but it is irritating to after the update see that I still have 1.92.1 installed. Can we add the full version number here too?

AppImage

I downloaded both
https://github.com/OoliteProject/oolite ... 4.AppImage
https://github.com/OoliteProject/oolite ... 4.AppImage
and placed them somewhere in my filesystem.

OoliteStarter detected both. And although the extraction of the full AppImage is clumsy, version detection plus identification of the debug build works.

Improvement

None of the builds (neither Flatpak nor AppImage) would print the version number using -version or -showversion. Especially on the AppImage such a feature would prevent that I'd have to extract the full image just to get that information.

If that could be added to https://github.com/OoliteProject/oolite ... _oolite.sh it would be a good step forward.
Alternatively, to catch both cases (version, debug_functionality_support) it would also help if simply the manifest.plist were printed to the console before the script terminates. A -printmanifest option could do the trick.

You are one step ahead. I have backported the change on master to the 1.92 branch and added the packageinfo output as well as fixing the missing debug.oxp in the test appimages in this PR: https://github.com/OoliteProject/oolite/pull/553

Once that is merged, you will be able to do:

Code: Select all

> flatpak run space.oolite.Oolite packageinfo
{
        title = "Oolite core";
        identifier = "org.oolite.oolite";

        version = "1.92.1.7796-260226-dbf083e";
        debug_functionality_support = no;
        required_oolite_version = "1.92.1";

        license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
        author = "Giles Williams, Jens Ayton and contributors";
        information_url = "https://oolite.space/";
}

Code: Select all

> ./Oolite_test_1.92.1.7796-260226-dbf083e-x86_64.AppImage packageinfo
{
        title = "Oolite core";
        identifier = "org.oolite.oolite";

        version = "1.92.1.7796-260226-dbf083e";
        debug_functionality_support = yes;
        required_oolite_version = "1.92.1";

        license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
        author = "Giles Williams, Jens Ayton and contributors";
        information_url = "https://oolite.space/";
}

[hiran]

The PR is merged. I downloaded and installed the new artifacts.

Flatpak

Code: Select all

$ flatpak list
Name                         Application ID                                    Version                        Branch          Origin            Installation
[...]
Oolite                       space.oolite.Oolite                               1.93.0.7779-260228-d4a7a70     master          oolite-origin     system
Oolite                       space.oolite.Oolite                               1.92.1                         stable          flathub           system
$ flatpak run space.oolite.Oolite packageinfo
2026-02-28 22:48:01.888 oolite[47:48] Truncating thread name 'OOLogOutputHandler logging thread' to 15 characters due to platform limitations

Oolite started up and showed a window title 1.93 (using -fullversion displayed the upper line). But I did not get the manifest output.

AppImage

Code: Select all

$ ./Oolite_dev_1.93.0.7779-260228-d4a7a70-x86_64.AppImage packageinfo
2026-02-28 22:52:04.237 oolite[29686:29687] Truncating thread name 'OOLogOutputHandler logging thread' to 15 characters due to platform limitations
AL lib: (EE) GetLoadedHrtf: Invalid header in /usr/share/openal/hrtf/Default HRTF.mhr: "MinPHR03"
AL lib: (EE) GetLoadedHrtf: Failed to load /usr/share/openal/hrtf/Default HRTF.mhr$

Oolite started up and showed a window title 1.93 (using -fullversion displayed the upper line). But I did not get the manifest output either.




edit: There was no merge to the master branch. I am still too early...

[mcarans]

The PR is merged. I downloaded and installed the new artifacts.

Flatpak

Code: Select all

$ flatpak list
Name                         Application ID                                    Version                        Branch          Origin            Installation
[...]
Oolite                       space.oolite.Oolite                               1.93.0.7779-260228-d4a7a70     master          oolite-origin     system
Oolite                       space.oolite.Oolite                               1.92.1                         stable          flathub           system
$ flatpak run space.oolite.Oolite packageinfo
2026-02-28 22:48:01.888 oolite[47:48] Truncating thread name 'OOLogOutputHandler logging thread' to 15 characters due to platform limitations

Oolite started up and showed a window title 1.93 (using -fullversion displayed the upper line). But I did not get the manifest output.

AppImage

Code: Select all

$ ./Oolite_dev_1.93.0.7779-260228-d4a7a70-x86_64.AppImage packageinfo
2026-02-28 22:52:04.237 oolite[29686:29687] Truncating thread name 'OOLogOutputHandler logging thread' to 15 characters due to platform limitations
AL lib: (EE) GetLoadedHrtf: Invalid header in /usr/share/openal/hrtf/Default HRTF.mhr: "MinPHR03"
AL lib: (EE) GetLoadedHrtf: Failed to load /usr/share/openal/hrtf/Default HRTF.mhr$

Oolite started up and showed a window title 1.93 (using -fullversion displayed the upper line). But I did not get the manifest output either.




edit: There was no merge to the master branch. I am still too early...

You can try what's on the 1.92 branch here: https://github.com/OoliteProject/oolite ... 2520107707. If you scroll down on the RHS you should be able to see the artifacts. I just tested the snapshot appimage there and it worked:

Code: Select all

> ./Oolite_dev_1.92.1.7797-260228-9ca54c9-x86_64.AppImage packageinfo
{
        title = "Oolite core";
        identifier = "org.oolite.oolite";

        version = "1.92.1.7797-260228-9ca54c9";
        debug_functionality_support = yes;
        required_oolite_version = "1.92.1";

        license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
        author = "Giles Williams, Jens Ayton and contributors";
        information_url = "https://oolite.space/";
}

I'm not sure why the DOxygen build is failing in 1.92. On master the Doxygen build happens in readthedocs. I checked the logs there and it doesn't have this error and completes successfully - but it doesn't use coverxygen which seems to give this error. Have you come across an error like this before?

Code: Select all

Analyzing symbol: void HeadUpDisplay::drawMultiFunctionDisplay:withText:asIndex:(NSDictionary *info, [withText] NSString *text, [asIndex] NSUInteger index)
found symbol of type function at /home/runner/work/oolite/oolite/oolite/src/Core/HeadUpDisplay.m:3340
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.10/dist-packages/coverxygen/__main__.py", line 156, in <module>
    main()
  File "/usr/local/lib/python3.10/dist-packages/coverxygen/__main__.py", line 150, in main
    l_obj.process()
  File "/usr/local/lib/python3.10/dist-packages/coverxygen/__init__.py", line 358, in process
    l_symbols   = self.process_index(l_xmlDoc)
  File "/usr/local/lib/python3.10/dist-packages/coverxygen/__init__.py", line 319, in process_index
    l_symbols.extend(self.process_file(l_filePath))
  File "/usr/local/lib/python3.10/dist-packages/coverxygen/__init__.py", line 304, in process_file
    l_symbols.extend(self.process_symbol(c_def, p_filePath))
  File "/usr/local/lib/python3.10/dist-packages/coverxygen/__init__.py", line 283, in process_symbol
    if self.should_filter_out(p_node, l_file, l_line):
  File "/usr/local/lib/python3.10/dist-packages/coverxygen/__init__.py", line 249, in should_filter_out
    if self.matches_excludesymbol(p_node):
  File "/usr/local/lib/python3.10/dist-packages/coverxygen/__init__.py", line 220, in matches_excludesymbol
    l_fulldefstring = Coverxygen.extract_function_sig(p_node)
  File "/usr/local/lib/python3.10/dist-packages/coverxygen/__init__.py", line 119, in extract_function_sig
    return l_def.text + l_argsstring.text
TypeError: can only concatenate str (not "NoneType") to str

You are right that I have yet to bring those changes to master.

[hiran]

Unfortunately still neither the released nor the prereleased artifacts do provide their version numbers on the command line.
It means the clumsy handling of new builds is still required for OoliteStarter to detect the Oolite version.

The more the current version gets distributed the more this becomes a dilemma as the 'feature' becomes unusable.

Let's assume the user has some appimage installed. OoliteStarter does not know which version of Oolite it is.
While it might invoke '<appimage> packageinfo' and grab whatever ends up on stdout, Oolite never terminates. Instead, the game starts running.
Why so? Well, we just encountered the current release build which simply disregards the command line option and starts up.

To better react and only invoke the 'packageinfo' command line option we would have to know which version of Oolite is packaged. And to know which version it is we still have to extract the package. At that moment the command line option is completely useless.