Cockpits, HUDs and other displays

[Cholmondely]

I can reproduce Maik's experiments.
I have an extra window that shows speed, alert status and comms messages.

Well done!

[hiran]

OoliteStarter v0.1.32-gelsemium.2 will now detect whether the debug oxp is available. This is a prerequisite for MQTT data export.

Who is interested in testing once I have more functionality?

[Cholmondely]

Who is interested in testing once I have more functionality?

Alas, failed to open v.0.1.30 - getting the message that it would not function on my Mac...

[hiran]

Who is interested in testing once I have more functionality?

Alas, failed to open v.0.1.30 - getting the message that it would not function on my Mac...

Thank you for trying. What I find difficult is that we face so many problems just to have a look.
Do we have any alternatives? Remember how we experimented with Nexus?

[Cholmondely]

Who is interested in testing once I have more functionality?

Alas, failed to open v.0.1.30 - getting the message that it would not function on my Mac...

Thank you for trying. What I find difficult is that we face so many problems just to have a look.
Do we have any alternatives? Remember how we experimented with Nexus?

Next week should be doable. I've just downloaded your latest (gelsenium) as linked just above, and again, "oolite starter can't be installed on your computer". But 0.1.29 flavescent.7 opens just fine. So between flavescent 7 and 0.1.30 something changed. And if you have automated the packaging process, then I would guess that something might have been changed for you there.

[MrFlibble]

OoliteStarter v0.1.32-gelsemium.2 will now detect whether the debug oxp is available. This is a prerequisite for MQTT data export.

Who is interested in testing once I have more functionality?

Happy to help if I can. I now have instances of Windows and MacOS which are at least good enough to check 'does it load?', and 'will they talk?', as well as my usual heaps of Linux. MQTT on standby.

[hiran]

OoliteStarter v0.1.32-gelsemium.2 will now detect whether the debug oxp is available. This is a prerequisite for MQTT data export.

Who is interested in testing once I have more functionality?

Happy to help if I can. I now have instances of Windows and MacOS which are at least good enough to check 'does it load?', and 'will they talk?', as well as my usual heaps of Linux. MQTT on standby.

You've got MacOS for testing? That's great!
Maybe you could already have a look whether OoliteStarter is usable on a Mac - just as Cholmondely pointed out. Enabling him for testing would be huge value already - not to talk about the other gimmicks that are to come.

[hiran]

MQTT on standby.

Fire it up, this next build is for you!

I made the MQTT connection data configurable so now you should be able to make use of it. However it is a manual step not included in the GUI.
(am boldly assuming if you can configure MQTT and respective clients, you will be able to fiddle an XML configuration). Here you can see what needs to be done:
https://github.com/OoliteProject/Oolite ... figuration

And here's the new version: OoliteStarter v0.1.32-gelsemium.6

Oh, and I would not mind if someone knew how to make powershell add the processor architecture to a filename.

[MrFlibble]

MQTT on standby.

Fire it up, this next build is for you!

I made the MQTT connection data configurable so now you should be able to make use of it. However it is a manual step not included in the GUI.
(am boldly assuming if you can configure MQTT and respective clients, you will be able to fiddle an XML configuration). Here you can see what needs to be done:
https://github.com/OoliteProject/Oolite ... figuration

And here's the new version: OoliteStarter v0.1.32-gelsemium.6

Oh, and I would not mind if someone knew how to make powershell add the processor architecture to a filename.

On it. I have a heap of ESP8266's and suchlike, OLED displays etc. and micropython everywhere. This is going to be FUN!!!

Now all I have to do is remember where it all is, and find it all at the same time.

[MrFlibble]

This is my attempt on my LinuxMint laptop. I don't often use starter (limited RAM), so I found a few quirks.

I had to apt remove the previous version of oolitestarter first, as apt was convinced that this was an older version.

Starter tells me there's a new update for Oolite. I close starter, upgrade Oolite to 1.91.0.7616-240527-f882b71-linux-dev-x86_64. Reload starter.

Starter shows that I have 1.90.0.7282-200829-0b1ff49 and it's not debug capable. Ah wait! I know what's happening... it just didn't verify the version which had been upgraded in-place several times. So I ran the scan, (hint.. don't have deep trees mounted!). Now it shows the new version AND the old one, both at the same location. A scary 'delete and confirm' later, and it all looks good.

My 2p-worth: Perhaps that 'delete' should be called 'remove' and/or placed next to 'add', with some clarification that it won't actually delete the installation. Could there be an option to re-check the existing installation version, or just do that at startup as a matter of course?

MQTT up and running. Ignoring protest about missing Spara.SothisTC. Onward.

Code: Select all

# mosquitto_sub -u Username -P "Password" -t 'oolite/#' -h 127.0.0.1 -p 1883 -v
oolite/configuration <?xml version="1.0" encoding="UTF-8"?>
#Boring plist data hidden.
oolite/alert {"msgType":"alert","alertCondition":2}
oolite/controls {"msgType":"controls","speed":157.5,"maxSpeed":315}
oolite/comms {"msgType":"comms","message":"Rabiarce Traffic Control: Bon voyage Commander Flibble. Please clear the approach lane as soon as possible.","sender":null}
oolite/comms {"msgType":"comms","message":"Rock Hermit beacon detected","sender":null}
oolite/alert {"msgType":"alert","alertCondition":1}
oolite/alert {"msgType":"alert","alertCondition":0}
oolite/controls {"msgType":"controls","speed":0,"maxSpeed":315}

Nice!

Pity it won't run alongside debug console, one blocks the other.

I'll check the other platforms later if nobody else chips in with results by the time I'm next idle. If you need it done fast, yell.

[hiran]

Starter shows that I have 1.90.0.7282-200829-0b1ff49 and it's not debug capable. Ah wait! I know what's happening... it just didn't verify the version which had been upgraded in-place several times. So I ran the scan, (hint.. don't have deep trees mounted!). Now it shows the new version AND the old one, both at the same location. A scary 'delete and confirm' later, and it all looks good.

My 2p-worth: Perhaps that 'delete' should be called 'remove' and/or placed next to 'add', with some clarification that it won't actually delete the installation. Could there be an option to re-check the existing installation version, or just do that at startup as a matter of course?

Good point. I'll think about it.

Nice!

Pity it won't run alongside debug console, one blocks the other.

Congratulations! Seems the way I documented really works....

For Oolite Starter AND the debug console: Well only one application can listen on one ip/port. And Oolite connects to that application - but only once. So that architecture is craving for impact.

In case you want to debug you can still use OoliteStarter. Just start the debug console prior to running Oolite. OoliteStarter will only try to block the debug tcp port when launching Oolite and does not complain if it is taken already.

If that's not good enough let's discuss alternatives.

[MrFlibble]

In case you want to debug you can still use OoliteStarter. Just start the debug console prior to running Oolite. OoliteStarter will only try to block the debug tcp port when launching Oolite and does not complain if it is taken already.

I'd discovered that, realised it was mutually exclusive, and that you were probably using the TCP connection.

I know the connection with debug console is via TCP, effectively console is server, Oolite is client. I expect there was a good reason it got implemented that way round. I didn't know whether some other handle (unix socket or similar) existed to talk with Oolite's debug.

What if starter were able to subscribe to a topic, and send anything published there back to Oolite, with filtered responses published. That would allow a kludgy debug console, and also facilitate instruments sending commands to oolite (pause on red alert if bridge empty).

It's only a pity that both can't work at once. Not the end of the world.

I think this is an excellent idea, and look forward to seeing what people do with it.

MQTT Dashboard on Android, although closed source, might be fun to use with this!

[hiran]

In case you want to debug you can still use OoliteStarter. Just start the debug console prior to running Oolite. OoliteStarter will only try to block the debug tcp port when launching Oolite and does not complain if it is taken already.

I'd discovered that, realised it was mutually exclusive, and that you were probably using the TCP connection.

I know the connection with debug console is via TCP, effectively console is server, Oolite is client. I expect there was a good reason it got implemented that way round. I didn't know whether some other handle (unix socket or similar) existed to talk with Oolite's debug.

Spot on. I will add some information to the readme - not everybody might guess right just like that.

What if starter were able to subscribe to a topic, and send anything published there back to Oolite, with filtered responses published. That would allow a kludgy debug console, and also facilitate instruments sending commands to oolite (pause on red alert if bridge empty).

An excellent idea to reuse the existing tech stack. So the Oolite Debug Console could preserve it's use to alternatively show/produce MQTT messages while at the same time more and more instruments could be developed and attached. Which would again encourage others to take that route.
That's a win-win situation.

I think this is an excellent idea, and look forward to seeing what people do with it.
MQTT Dashboard on Android, although closed source, might be fun to use with this!

Something like this is what I had in mind when writing viewtopic.php?p=296692#p296692
It's good to see we are getting closer.

[hiran]

What if starter were able to subscribe to a topic, and send anything published there back to Oolite, with filtered responses published. That would allow a kludgy debug console, and also facilitate instruments sending commands to oolite (pause on red alert if bridge empty).

An excellent idea to reuse the existing tech stack. So the Oolite Debug Console could preserve it's use to alternatively show/produce MQTT messages while at the same time more and more instruments could be developed and attached. Which would again encourage others to take that route.
That's a win-win situation.

Thinking about this:

OoliteStarter should then forward all messages from Oolite. If it is not meant for a special topic (e.g. oolite/comms) it should go to a default topic like oolite/debugConsole. This way an MQTT oriented debug console could still decide which messages to react on.

At the same time I will introduce a topic like oolite/input. Messages here will be forwarded to Oolite on the debug console interface - which means they need to contain some JavaScript command. And again this would allow Oolite to react.

I was experimenting in that respect and created this code:
https://github.com/OoliteProject/Oolite ... r.java#L78
But that one is too ship speed oriented. We will need something more generic.

[hiran]

I had to apt remove the previous version of oolitestarter first, as apt was convinced that this was an older version.

This is an effect on experimental versions. Same happens on Windows.
Seems like operating systems want to look at three digits in version numbers only. But I want to keep the semver style which has four of them.