OoliteStarter

[MrFlibble]

This is the currently stable one:
https://github.com/OoliteProject/Oolite ... ag/v0.1.31

I think if you stick to the builds on the master branch it would be fully sufficient. Experimental versions all have a branch name, as currently 'gelsemium'.

Cool. I cheated, 'cos I skipped the Maven headache by re-using the jar from the generic dist. I've managed to knock together a build script that does it all with little editing. Should be able to repeat this by just changing the version number.

Here's the app, simply zipped.
OoliteStarter-0.1.31-MacOS-x86_64.zip (56.96 MB)
And here, wrapped up in an installer.
OoliteStarter-0.1.31-x86_64.pkg (56.67 MB)

Thank you! I cannot check the content, but I added them to the stable release.

These uploads will self-destruct on July 12th at about 22:22.

Ummmm - I hope I understand the scope right...

Edit: I had failed to get maven build working due to

Code: Select all

src/test/java/oolite/starter/OoliteTest.java:        command.add("/usr/bin/ls");

/bin and /sbin were traditionally the home of stuff needed to boot the system and effect simple repairs before even mounting /usr (which might have been an NFS share).
It's ONLY at the more standard /bin/ls on the Mac. Most Linuxes these days assume a largely flat filesystem, with a symlink /usr/bin to /bin so 'ls' appears in both places.
IMHO, /bin/ls is a more robust choice. I've patched around it in my MacOs-x86_64 build script with sed, and can now build from scratch in one hit.

Ok, that unit test is no good choice. I just checked, and on Ubuntu ls is in the path I gave. But you are right, /bin is a symlink to /usr/bin so I can follow your suggestion.

All I need to do is edit the version number. Output files in $HOME/starter/build/target. I've pasted the build script below in case I have a nasty run in with the 'goids.

Code: Select all

#!/bin/bash

distVER=0.1.31
arch=x86_64

#Builder for Mac.
distURL=https://codeload.github.com/OoliteProject/OoliteStarter/zip/refs/tags/v$distVER
builddir=$HOME/starter/build

kaput(){ echo "$1" ; exit 2 ; }

[ "x$distVER" = "x" ] && kaput "Version is nonsense"
#jpackage won't accept the first digit of version being zero.
# so we patch it here.
MacVER=$(echo "$distVER" | sed 's@^0\.@1.@')

mkdir -p "$builddir" && cd "$builddir" || kaput "Can't make build dir $builddir"

getTar(){
	curl -L -o dist-${distVER}.zip $distURL
	unzip -qq dist-${distVER}.zip
	ls -al
}

doMaven(){
	#PATCH FOR MAC.
	#BSD sed insists on a suffix for backup when using -i to edit inline.
	sed -i flibble 's@/usr/bin/ls@/bin/ls@' \
 	 OoliteStarter-$distVER/src/test/java/oolite/starter/OoliteTest.java
	export PATH="$PATH:$HOME/maven/bin"
	cd OoliteStarter-$distVER || kaput "failed to cd to source" 
	mvn versions:set "-DnewVersion=$distVER"
	mvn -B package -e --file pom.xml
	cd -
}

doBuild(){
echo "$distVER"
jpackage \
 --type app-image \
 --app-version $MacVER \
 --copyright Copyright \
 --description "OoliteStarter $distVER" \
 --name "OoliteStarter" --dest target/appimage \
 --temp target/oolite-starter-tmp --vendor "OoliteProject" --verbose \
 --icon OoliteStarter-$distVER/src/main/resources/oolite_logo.png \
 --input OoliteStarter-$distVER/target/dist \
 --main-jar OoliteStarter-$distVER.jar \
 --main-class oolite.starter.MainFrame --mac-package-name "OoliteStarter" \
 --resource-dir OoliteStarter-$distVER/src/jpackage/resources-mac \
 --vendor OoliteProject
}

doApp(){
 jpackage \
  --type pkg \
  --verbose \
  --app-version $MacVER \
  --app-image target/appimage/OoliteStarter.app \
  --name "OoliteStarter" \
  --icon OoliteStarter-$distVER//src/main/resources/oolite_logo.png \
  --dest target \
  --resource-dir OoliteStarter-$distVER/src/jpackage/resources-mac \
  --vendor OoliteProject
}

makeZipDist(){
 cd target/appimage
 zip -qr ../OoliteStarter-${distVER}-MacOS-$arch.zip  *
 cd - ; cd target
 mv OoliteStarter-${MacVER}.pkg OoliteStarter-${distVER}-$arch.pkg
}

getTar
doMaven
doBuild
doApp
makeZipDist

Let's add that to the project. Just give it a meaningful name, add comments inside what it intends to do and stuff it besides pom.xml. I'm happy to accept a pull request.
Obviously I will never run that script, so maintenance is on you.

Responsibility.. erm.. yay!

That can be trivially tweaked to take args or env vars for arch and version, then it could reduce the github deps by just a ton. If devs can roll their own binaries to test, and the yaml stuff is simplified to-boot, surely life is better.

[MrFlibble]

Testing this on the Mac. A couple of issues.

Selecting a pre-saved Jameson (found by starter in ~/Documents) and hitting resume opens Oolite 1.90 on the main menu. Saving as a new name while "starter-started" makes no odds. Resume doesn't resume, it loads. Still one can open the savegame from the game main menu.

With a low-ish res, the problem of MQTT topics extending beyond the screen limit (1280x800) is beyond cosmetic. It actually pushes the save/cancel buttons so far off the bottom that even with dock-autohide on, you can't click them. You can use tab to highlight, and space to accept, as you can see about a pixel row to know which one is selected. One more topic, and no more buttons!

EDIT : I just read viewtopic.php?t=20877 : Summary at the bottom of this post. I've left the rest in in case anyone else searches this issue in this context.

MQTT ouptut is somewhat lacking:

Code: Select all

mosquitto_sub -h localhost -p 1883 -u admin -P "simple" -t '#' -v
users/mcflibble/games/oolite/starter connection test
users/mcflibble/games/oolite/starter started
users/mcflibble/games/oolite/starter Oolite started
users/mcflibble/games/oolite/starter Oolite stopped

That's from loading commander, launching, and changing speed. The last three lines simply repeat on re-attempt. I tried opening up the mosquitto acl for mcflibble, but it doesn't look like writes are attempted elsewhere.

Could this be to do with the built-in debugger on the 1.90 MacOS version?

Hang on! What's that odd sensation in my noggin? Wait! a memory  Debug_OXP

...in debugConfig.plist. For external console support on the same computer under Mac OS X, console-host must be explicitly set to “127.0.0.1”; if this is not done, the integrated JavaScript console will be used instead.

Ha!!! I was going to look that up for another reason already.

The file is at:
$HOME/Library/Application Support/Oolite/AddOns/Debug.oxp/Config/debugConfig.plist
Edit the file and uncomment: EDIT: Don't bother!
<code>
// console-host = "127.0.0.1";
// console-port = 8563;
</code>

Save. Sorted? Ah! no.

We get the "users/mcflibble/games/oolite/configuration <?xml version="1.0" encoding="UTF-8"?>" and the rest of the plist, then Oolite hangs on a black screen until I close starter.

Trying with DebugConsole2, running without Starter, I get this:

Code: Select all

DebugConsole: ERROR    Unsupported var console-host: 127.0.0.1, type: <class 'str'>
DebugConsole: ERROR    Unsupported var console-port: 8563, type: <class 'str'>

..and again it hangs on black until I close the connected debugger.

One last shot!

Code: Select all

python3 -B pySimpleConsole.py
Python Oolite debug console
Type /quit to quit.
Waiting for connection...

Opened connection to Oolite version 1.90

Oolite hangs until I hit ctrl-c on the debugger.

I'm thinking this...

Code: Select all

echo "Debugger" | sed 's/De//'

Summary re: debug and MQTT on OSX version of Oolite 1.90

Reading viewtopic.php?t=20877 leads me to think that the wiki page saying MacOS Oolite can talk to an external debugger may not be true for at least 1.90. Has anyone ever had external debugger working on Oolite for MacOS 1.90?

[hiran]

Testing this on the Mac. A couple of issues.

Selecting a pre-saved Jameson (found by starter in ~/Documents) and hitting resume opens Oolite 1.90 on the main menu. Saving as a new name while "starter-started" makes no odds. Resume doesn't resume, it loads. Still one can open the savegame from the game main menu.

Unfortunately a known bug in Oolite:
viewtopic.php?p=291772#p291772

With a low-ish res, the problem of MQTT topics extending beyond the screen limit (1280x800) is beyond cosmetic. It actually pushes the save/cancel buttons so far off the bottom that even with dock-autohide on, you can't click them. You can use tab to highlight, and space to accept, as you can see about a pixel row to know which one is selected. One more topic, and no more buttons!

Could I have a screenshot please? And do you have an idea how a fix could look like? (on the screen, not in code)

MQTT ouptut is somewhat lacking:

Code: Select all

mosquitto_sub -h localhost -p 1883 -u admin -P "simple" -t '#' -v
users/mcflibble/games/oolite/starter connection test
users/mcflibble/games/oolite/starter started
users/mcflibble/games/oolite/starter Oolite started
users/mcflibble/games/oolite/starter Oolite stopped

That's from loading commander, launching, and changing speed. The last three lines simply repeat on re-attempt. I tried opening up the mosquitto acl for mcflibble, but it doesn't look like writes are attempted elsewhere.

The messages you see are all from OoliteStarter telling you it started/stopped Oolite. No message inbetween means Oolite has not sent anything. And this is likely because it did not connect. But you figured that out yourself...

So yes, there are a number of issues in the Oolite Mac version that do not exist the same way on other platforms. Again it shows we lost Mac support long time ago...

[MrFlibble]

Testing this on the Mac. A couple of issues.

Selecting a pre-saved Jameson (found by starter in ~/Documents) and hitting resume opens Oolite 1.90 on the main menu. Saving as a new name while "starter-started" makes no odds. Resume doesn't resume, it loads. Still one can open the savegame from the game main menu.

Unfortunately a known bug in Oolite:
viewtopic.php?p=291772#p291772

Sigh!

With a low-ish res, the problem of MQTT topics extending beyond the screen limit (1280x800) is beyond cosmetic. It actually pushes the save/cancel buttons so far off the bottom that even with dock-autohide on, you can't click them. You can use tab to highlight, and space to accept, as you can see about a pixel row to know which one is selected. One more topic, and no more buttons!

Could I have a screenshot please? And do you have an idea how a fix could look like? (on the screen, not in code)

Not a problem. For some reason I'm not even getting the top edge of thee buttons now!

That's with OoliteStarter (OoGO Boss!!) fullscreen, and panel set to hide.

Fix? I'd say a dynamic vertical-elevator/scroll-bar for the whole the right-hand panel would be the most normal fix from a user perspective. As the page grows (or window shrinks), allow the panel to be rolled up and down. Like the ones you have in the Expansions panel, manifesting as required.

I the left panels could have one too, just in case someone has a great many installations

Easy to test, just shrink the window

Another workaround would be as I suggested earlier in this thread. Having brooded a while I realise it would be of limited worth, especially if the list grew much longer.

Code: Select all

Oolite will use this as a parent topic: users/mcflibble/games/oolite
It will subscribe to this/these topics beneath that: input
And publish to these: /, /alert, /commandAcknowledge, /comms, /configuration,
 /console, controls, log, showConsole, starter, unknown, worldEvent

A third, perhaps more aesthetically pleasing possibility, is to have the scrollbar, AND only show one or two sub/pub examples, making the full list available via a button, which would spawn a pop up window (select and copy-able).

One more... Bung-em in a panel under the versions. That could be scrollable AND copyable AND always visible. You have a widget to slide the panel left and right, another to scale the (now) two panels vertically.

Code: Select all

------------------------------------------------------------------------
|Scan|Add|Edit|Remove| etc.                                            |
|----------------------------------------------------------------------|   VERTICAL
| Installation 1        | Home dir [                              ] |##| <-ELEVATOR
| Installation 2        | Version  [                              ] |##|
|  etc.                 | Execu... blah!                            |  |
|                       |                                           |  |
|                       |: <-HORIZONTAL RESIZER                     |  |
|                       |                                           |  |
|                       |                                           |  |
|      vert resizer     |                                           |  |
|          v            |                                           |  |
|         ..            |                                           |  |
|-----------------------|                                           |  |
|pub|                   |                                           |  |
|sub| topic             |                                           |  |
|-----------------------|   VERTICAL                                |  |
|sub|topic/thing     |##| <-ELEVATOR                                |  |
|pub|topic/ver       |  |                                           |  |
|pub|topic/verylong/t|  |                                           |  |
|pub|topic/a         |  |                                           |  |
|pub|topic/b         |  | More Conf....                             |  |
|--------------------|  |                                           |  |
|##                  |  | (extends below window hence elevator)     |  |
------------------------------------------------------------------------
       ^
    HORIZONTAL
    ELEVATOR

MQTT ouptut is somewhat lacking:
...
So yes, there are a number of issues in the Oolite Mac version that do not exist the same way on other platforms. Again it shows we lost Mac support long time ago...

[hiran]

Uh, that's .... hmmm. Ok, needs some better handling indeed.
Quick testing even shows me that it's worse than I thought. Also wondering how it could have gotten into this state without me noticing.

[hiran]

Ok, here's the fix: OoliteStarter v0.1.32-gelsemium.12

[MrFlibble]

Ok, here's the fix: OoliteStarter v0.1.32-gelsemium.12

Nice solution!

Here are the x86_64 builds. I fixed the filename on the pkg to include 'MacOS'.

OoliteStarter-0.1.32-gelsemium.12-MacOS-x86_64.pkg (57.89 MB)
OoliteStarter-0.1.32-gelsemium.12-MacOS-x86_64.zip (58.18 MB)

Links valid for a month.

Edit. Built against wrong JDK. Would work, but not right.. New upload imminent.

[hiran]

Ok, here's the fix: OoliteStarter v0.1.32-gelsemium.12

Nice solution!

Here are the x86_64 builds. I fixed the filename on the pkg to include 'MacOS'.

Links valid for a month.

Thanks.
Now that I am back online I can take a look and find them already uploaded to Github. What a service!

[MrFlibble]

Ok, here's the fix: OoliteStarter v0.1.32-gelsemium.12

Nice solution!

Here are the x86_64 builds. I fixed the filename on the pkg to include 'MacOS'.

links

Thanks.
Now that I am back online I can take a look and find them already uploaded to Github. What a service!

I don't have access to edit starter releases pages. I had a look. A penny dropped! Seems I should have been using OpenJDK but may or may not have stumbled on the path of least resistance at my first pass of this (whoops!). Please zap the links in your reply to me, and upload the versions below.

These are built using OpenJDK 22.0.1, which was quite strongly offered at the OpenJDK download page when I went looking for 21.

OoliteStarter-0.1.32-gelsemium.12-MacOS-x86_64.zip (63.53 MB)

OoliteStarter-0.1.32-gelsemium.12-MacOS-x86_64.pkg (62.94 MB)

[hiran]

I don't have access to edit starter releases pages. I had a look. A penny dropped! Seems I should have been using OpenJDK but may or may not have stumbled on the path of least resistance at my first pass of this (whoops!). Please zap the links in your reply to me, and upload the versions below.

@a_c, @phkb: Could one of you grant MrFlibble more privileges to directly upload his OoliteStarter build into Github?

These are built using OpenJDK 22.0.1, which was quite strongly offered at the OpenJDK download page when I went looking for 21.

Should not be an issue. While one might believe the JDK matters as it would require a matching runtime, OoliteStarter gets packaged together with the runtime into a native installer. The Java code always comes with a suitable Java runtime.

I uploaded the two builds.

[another_commander]

MrFlibble has now Maintainer level access to the OoliteStarter repository.

[hiran]

MrFlibble has now Maintainer level access to the OoliteStarter repository.

Perfect, thanks

[Cholmondely]

Alas, MrF's most recent (OoliteStarter-0.1.32-gelsemium.12) requires me to update my OS which I'm loathe to do...

You can’t use this version of the application “OoliteStarter” with this version of macOS.

You have macOS 10.15.3. The application requires macOS 11.0 or later.

Oolite used to be playable with old machines, which meant that for example, those in third world countries with old machines could join us.

Now, not only do we not have versions which they can play (Spara's woes, passim), but we require them to update everything too!



Is this really the path we should be treading?

[MrFlibble]

Alas, MrF's most recent (OoliteStarter-0.1.32-gelsemium.12) requires me to update my OS which I'm loathe to do...

You can’t use this version of the application “OoliteStarter” with this version of macOS.

You have macOS 10.15.3. The application requires macOS 11.0 or later.

Oolite used to be playable with old machines, which meant that for example, those in third world countries with old machines could join us.

Now, not only do we not have versions which they can play (Spara's woes, passim), but we require them to update everything too!



Is this really the path we should be treading?

I'll look at whether I can do something to reduce need to update. Did my previous builds work? It may just be the version of Java I'd switched up to (as the previous one was no longer getting updates).

[Cholmondely]

I'll look at whether I can do something to reduce need to update. Did my previous builds work? It may just be the version of Java I'd switched up to (as the previous one was no longer getting updates).

I'm not blaming you. Your work on resurrecting gubbins for the AppleMac is superb. And I presume that it is the fault of the software you are using to transmogrify everything for the Apple. But I feel that it is a sad commentary on how things are being changed...

Your previous but one version seemed to work just fine (as proclaimed earlier). I never tried the immediately previous one.