Cockpits, HUDs and other displays

[MrFlibble]

MQTT

MQTT is the IoT protocol, yes? Are we ever going to get, "Hey Google, fire a missile."?

Asking for a friend.

DuckDuckGone!!

[hiran]

MQTT

MQTT is the IoT protocol, yes? Are we ever going to get, "Hey Google, fire a missile."?

Asking for a friend.

So if I triggered such a command, what would you expect to happen?

Code: Select all

mosquitto_pub -h <brokerHost> -p <brokerPort> -t <topic> -u <username> -P <password> -m "Hey Google, fire a missile."

[hiran]

I seem to be doing something wrong as I do not see the desired reaction from Oolite.
While I get the acknowledge that my request was received the expected response is missing...

@MrFlibble: Could you check if these commands can be used in a meaningful way on the debug console?

You must have read my mind. I tried it as soon as I saw it. PS.fireMissile() does the job. I couldn't (quickly) find a way to switch missiles. PS.target.dumpCargo() is fun

Exception: TypeError: PS.target.energy is not a function. Tried PS.targetEnergy() as well.

edit: PS.target.energy without brackets does pop the relevant data

Now I am sure: I must be doing something wrong!
For me neither the PS.fireMissile() nor the PS.target.energy gives the expected reaction.

I've been toying with using Tasmota on a TTGO T-Display (rolling a custom image with more MQTT goodies). It's got a tiny colour screen and two buttons which understand multiple clicks. Maybe half a dozen actions can be set up to fire at the debug topic. I'm looking forward to tying micro-controller toys in with Oolite.

Now this is really cool. Although I am hoping the touch display would be bigger than one single button...

[MrFlibble]

Now this is really cool. Although I am hoping the touch display would be bigger than one single button...

Just the two clicky switches on that board. It is really too small for touch. It's a doddle to add keypads, switches, sensors, rotary knobs etc.

There is a slightly larger touch version available, and cheapo resistive touch 320x240 spi/i2c screens... though I'd expect old androids would be better for that.

[Cholmondely]

Question!

 Useful MFDs often drops information if a preceding line it too long! Is this fixable on your alternate displays?


See below (long "ship name" & long "solar wind flux" details have pushed the parcel-carrying reputation and the time stamp off the bottom of the left MFD)

[MrFlibble]

Looking at what might be fun to have published via MQTT, I drilled in:

Code: Select all

> Object.getOwnPropertyNames(PS)
["manifest", "activeMissile", "aftShield", "aftShieldRechargeRate", "chartHighlightMode", "compassMode", "compassTarget", "compassType", "currentWeapon", "crosshairs", "cursorCoordinates", "cursorCoordinatesInLY", "docked", "dockedStation", "fastEquipmentA", "fastEquipmentB", "forwardShield", "forwardShieldRechargeRate", "fuelLeakRate", "galacticHyperspaceBehaviour", "galacticHyperspaceFixedCoords", "galacticHyperspaceFixedCoordsInLY", "galaxyCoordinates", "galaxyCoordinatesInLY", "hud", "hudAllowsBigGui", "hudHidden", "injectorsEngaged", "massLockable", "maxAftShield", "maxForwardShield", "messageGuiTextColor", "messageGuiTextCommsColor", "missilesOnline", "multiFunctionDisplays", "multiFunctionDisplayList", "price", "pitch", "primedEquipment", "renovationCost", "reticleColorTarget", "reticleColorTargetSensitive", "reticleColorWormhole", "renovationMultiplier", "reticleTargetSensitive", "roll", "routeMode", "scannerMinimalistic", "scannerNonLinear", "scannerUltraZoom", "scoopOverride", "serviceLevel", "specialCargo", "targetSystem", "nextSystem", "infoSystem", "previousSystem", "torusEngaged", "viewDirection", "viewPositionAft", "viewPositionForward", "viewPositionPort", "viewPositionStarboard", "weaponsOnline", "yaw"]

> Object.getOwnPropertyNames(P)
["ship", "feudalRankGenerator", "alertAltitude", "alertCondition", "alertEnergy", "alertHostiles", "alertMassLocked", "alertTemperature", "bounty", "contractReputation", "contractReputationPrecise", "credits", "dockingClearanceStatus", "escapePodRescueTime", "legalStatus", "name", "parcelReputation", "parcelReputationPrecise", "passengerReputation", "passengerReputationPrecise", "rank", "roleWeights", "score", "trumbleCount"]

> Object.getOwnPropertyNames(S)
["allDemoShips", "allShips", "allVisualEffects", "ambientLevel", "breakPattern", "description", "economy", "economyDescription", "government", "governmentDescription", "ID", "info", "inhabitantsDescription", "isInterstellarSpace", "mainPlanet", "mainStation", "name", "planets", "population", "populatorSettings", "productivity", "pseudoRandom100", "pseudoRandom256", "pseudoRandomNumber", "stations", "sun", "techLevel", "waypoints", "wormholes"]

Perhaps:
PS.serviceLevel
PS.targetSystem
PS.nextSystem
PS.previousSystem
P.legalStatus
P.score
P.rank
P.credits
P.escapePodRescueTime
... could be published as persistent messages on load and change? (sorry if some of those already are!)

I expect there are a few other attributes from above which might be handy for dashboard purposes. Some of the S.* stuff might be good to publish on load and when reaching a new system.

I can think of a few handles which would be nice to have too... List of missile(types and slots)/targets, all the flight controls (effectively, keyboard inject), local system market prices.

Looking ahead, were more possibilities to be created, in order to avoid swamping the MQTT server, perhaps a topic of 'available_pubs' could list the possible pub messages for the running Oolite version, and another topic 'wanted_pub' could exist to turn topics off/on, with some defaults set if the topic is empty on start.

I've had a play with node-red today. Fun!

[hiran]

Looking at what might be fun to have published via MQTT, I drilled in:

Code: Select all

> Object.getOwnPropertyNames(PS)
["manifest", "activeMissile", "aftShield", "aftShieldRechargeRate", "chartHighlightMode", "compassMode", "compassTarget", "compassType", "currentWeapon", "crosshairs", "cursorCoordinates", "cursorCoordinatesInLY", "docked", "dockedStation", "fastEquipmentA", "fastEquipmentB", "forwardShield", "forwardShieldRechargeRate", "fuelLeakRate", "galacticHyperspaceBehaviour", "galacticHyperspaceFixedCoords", "galacticHyperspaceFixedCoordsInLY", "galaxyCoordinates", "galaxyCoordinatesInLY", "hud", "hudAllowsBigGui", "hudHidden", "injectorsEngaged", "massLockable", "maxAftShield", "maxForwardShield", "messageGuiTextColor", "messageGuiTextCommsColor", "missilesOnline", "multiFunctionDisplays", "multiFunctionDisplayList", "price", "pitch", "primedEquipment", "renovationCost", "reticleColorTarget", "reticleColorTargetSensitive", "reticleColorWormhole", "renovationMultiplier", "reticleTargetSensitive", "roll", "routeMode", "scannerMinimalistic", "scannerNonLinear", "scannerUltraZoom", "scoopOverride", "serviceLevel", "specialCargo", "targetSystem", "nextSystem", "infoSystem", "previousSystem", "torusEngaged", "viewDirection", "viewPositionAft", "viewPositionForward", "viewPositionPort", "viewPositionStarboard", "weaponsOnline", "yaw"]

> Object.getOwnPropertyNames(P)
["ship", "feudalRankGenerator", "alertAltitude", "alertCondition", "alertEnergy", "alertHostiles", "alertMassLocked", "alertTemperature", "bounty", "contractReputation", "contractReputationPrecise", "credits", "dockingClearanceStatus", "escapePodRescueTime", "legalStatus", "name", "parcelReputation", "parcelReputationPrecise", "passengerReputation", "passengerReputationPrecise", "rank", "roleWeights", "score", "trumbleCount"]

> Object.getOwnPropertyNames(S)
["allDemoShips", "allShips", "allVisualEffects", "ambientLevel", "breakPattern", "description", "economy", "economyDescription", "government", "governmentDescription", "ID", "info", "inhabitantsDescription", "isInterstellarSpace", "mainPlanet", "mainStation", "name", "planets", "population", "populatorSettings", "productivity", "pseudoRandom100", "pseudoRandom256", "pseudoRandomNumber", "stations", "sun", "techLevel", "waypoints", "wormholes"]

Perhaps:
PS.serviceLevel
PS.targetSystem
PS.nextSystem
PS.previousSystem
P.legalStatus
P.score
P.rank
P.credits
P.escapePodRescueTime
... could be published as persistent messages on load and change? (sorry if some of those already are!)

I expect there are a few other attributes from above which might be handy for dashboard purposes. Some of the S.* stuff might be good to publish on load and when reaching a new system.

I can think of a few handles which would be nice to have too... List of missile(types and slots)/targets, all the flight controls (effectively, keyboard inject), local system market prices.

Looking ahead, were more possibilities to be created, in order to avoid swamping the MQTT server, perhaps a topic of 'available_pubs' could list the possible pub messages for the running Oolite version, and another topic 'wanted_pub' could exist to turn topics off/on, with some defaults set if the topic is empty on start.

I've had a play with node-red today. Fun!

That is a wealth of data, but unquestionable it is needed.
We should think of when it will be published (is there a specific event, or should we just fire it regularly (e.g. every second)?
Also we need to review which message gets pushed to which topic.

And I fully agree some of the messages should be configurable to not create load if they anyway do not get consumed.

[MrFlibble]

Looking at what might be fun to have published via MQTT, I drilled in:
[blah!]
were more possibilities to be created, in order to avoid swamping the MQTT server, perhaps a topic of 'available_pubs' could list the possible pub messages for the running Oolite version, and another topic 'wanted_pub' could exist to turn topics off/on, with some defaults set if the topic is empty on start.

That is a wealth of data, but unquestionable it is needed.
We should think of when it will be published (is there a specific event, or should we just fire it regularly (e.g. every second)?
Also we need to review which message gets pushed to which topic.

And I fully agree some of the messages should be configurable to not create load if they anyway do not get consumed.

Thanks. So configuring the 'what' is likely to become essential. On to the when...

I'd say that *all* relevant variables which can, should be published on game load, the rest on launch. After that, only when a value changes should it be published, perhaps with a selectable throttle where rapid change is likely. Some core (flame shields up) 'tweaks' are likely to be required to achieve this, and that's the only way to avoid bogging things down re: chatter between game, starter, and MQTT server/clients.

Changes *will* be needed to get the best possible function from the potential offered by MQTT, like key event injection, missile list/selection etc.

I'm going to hide under a table now.

[phkb]

Aren’t we just taking about the properties of the player ship? Ie https://wiki.alioth.net/index.php/Oolite_JavaScript_Reference:_PlayerShip

[MrFlibble]

Aren’t we just taking about the properties of the player ship? Ie https://wiki.alioth.net/index.php/Oolite_JavaScript_Reference:_PlayerShip

Pretty much.

My point is that those appear somewhat limited if one wants to view or control things remotely for either external controls, or automation. For example:-

Code: Select all

activeMissile : Number (read-only integer)
Index in the missiles array of the currently selected missile.

It is not obvious to me, if even possible, how to manipulate or even access arrays/variables to select/view the missile types in the various slots, or fire them.

This could enable e.g. the use of another laptop, or even an old android as a touchscreen list of missiles, like on the HUD but with fire-on-touch, without all that single button toggle-go-round. I'd personally use a text list (1: missile, 2: hardened, 3: QCM, 4: whatever), rather than have to remember which icon is what. Even the targets locked by the individual missiles could be listed. (3: Missile : Asp).

The controller could be as simple as a bash script with dialog or zenity as a front end, a node-red program with an android web browser, or even an arduino with an LCD screen and telephone keypad.

I can view speed, but not accelerate/decelerate.

Ability to inject either keyboard controls or the functions they command, and peek/poke more/most/all variables through debug console is my perceived goal when attempting remote consoles/controls/HUDs etc. as per this topic.

Maybe that's all already doable, but it's quite opaque to me from my approach angle.

[hiran]

We should think of when it will be published (is there a specific event, or should we just fire it regularly (e.g. every second)?
Also we need to review which message gets pushed to which topic.

And I fully agree some of the messages should be configurable to not create load if they anyway do not get consumed.

Thanks. So configuring the 'what' is likely to become essential. On to the when...

I'd say that *all* relevant variables which can, should be published on game load, the rest on launch. After that, only when a value changes should it be published, perhaps with a selectable throttle where rapid change is likely. Some core (flame shields up) 'tweaks' are likely to be required to achieve this, and that's the only way to avoid bogging things down re: chatter between game, starter, and MQTT server/clients.

Changes *will* be needed to get the best possible function from the potential offered by MQTT, like key event injection, missile list/selection etc.

I'm going to hide under a table now.

You are giving me ideas. Now I dream up about a cockpit, maybe several little touchscreens on my desk within an arm's reach. They for a curved line between me and my monitors. As soon as I start OoliteStarter, they go alive but show only dark gey - maybe an Oolite logo or some boot screen.
As soon as OoliteStarter starts Oolite, the screens will fire up with their intended data, but the data is static - after all the ship is still docked.
And as soon as the ship launches all the gauges get alive will real data, helping me to control the ship until the ship docks again. Finally when Oolite terminates the screens go back to the boot screen, and when OoliteStarter terminates they all go black/turn off again.

[Cholmondely]

When docked your screens can be displaying information: the F6, F7 and F8 screens. Also, from the F4 screen options they can display the Galactic Almanac, the Commodity Markets screen, e-mails, the Missions available list, etc.

[hiran]

When docked your screens can be displaying information: the F6, F7 and F8 screens. Also, from the F4 screen options they can display the Galactic Almanac, the Commodity Markets screen, e-mails, the Missions available list, etc.

...and others could still give direct visibility on equipment, repair status and else. True.

[hiran]

Perhaps:
PS.serviceLevel
PS.targetSystem
PS.nextSystem
PS.previousSystem
P.legalStatus
P.score
P.rank
P.credits
P.escapePodRescueTime
... could be published as persistent messages on load and change? (sorry if some of those already are!)

I expect there are a few other attributes from above which might be handy for dashboard purposes. Some of the S.* stuff might be good to publish on load and when reaching a new system.

I can think of a few handles which would be nice to have too... List of missile(types and slots)/targets, all the flight controls (effectively, keyboard inject), local system market prices.

Looking ahead, were more possibilities to be created, in order to avoid swamping the MQTT server, perhaps a topic of 'available_pubs' could list the possible pub messages for the running Oolite version, and another topic 'wanted_pub' could exist to turn topics off/on, with some defaults set if the topic is empty on start.

I quickly added the above items into the messages to oolite/controls. No real design behind that choice - I just wanted to make those values available so we can play around with them and get more experience. So now you should see messages like

Code: Select all

oolite/controls {"msgType":"controls","speed":189.03811645507812,"maxSpeed":350,"serviceLevel":95,"targetSystem":151,"nextSystem":151,"previousSystem":81,"legalStatus":"Clean","score":4261,"rank":"☆ Deadly ☆","credits":99999998558440.11,"escapePodRescueTime":0}

This is available in v0.1.33-hoopsnake.2

There is also something I am wondering about. I am getting the below log output and don't know how to fix it. What is Oolite trying to tell me?

Code: Select all

07:47:07.148 [NioProcessor-2] DEBUG oolite.starter.mqtt.MQTTAdapter - receivedCommandResult({color key=exception, emphasis ranges=com.dd.plist.NSArray@45343bab, message=Exception: TypeError: cyclic object value
    Active script: oolite-starter-oxp 0.1
    script.js, line 503:
        debugConsole.consoleMessage(JSON.stringify(msg));, packet type=Console Output})

[MrFlibble]

Perhaps:
PS.serviceLevel
...
P.escapePodRescueTime

I quickly added the above items into the messages to oolite/controls. No real design behind that choice - I just wanted to make those values available so we can play around with them and get more experience.

Most excellent!

So now you should see messages like

Code: Select all

oolite/controls {"msgType":"controls","speed":189.03811645507812,"maxSpeed":350,"serviceLevel":95,"targetSystem":151,"nextSystem":151,"previousSystem":81,"legalStatus":"Clean","score":4261,"rank":"☆ Deadly ☆","credits":99999998558440.11,"escapePodRescueTime":0}

Is there a reason for bundling everything into 'controls' topic rather than containing them in topics which mirror their origins? Like: P or player, PS or player.ship, S or system, which might make less of a bump in the road for those switching between MQTT, debug, and OXP authoring/hacking.

I'll be sure to pop on my sturdy gauntlets and have a play with v0.1.33-hoopsnake.2

What is Oolite trying to tell me?

Code: Select all

MQTTAdapterranges=com.dd.plist.NSArray@45343bab, message=Exception: TypeError: cyclic object value
    Active script: oolite-starter-oxp 0.1
    script.js, line 503:
        debugConsole.consoleMessage(JSON.stringify(msg))

Blind stab... Can you throw in some temporary debug spew to figure out which value(s) is/are being parsed when that occurs? Then, is this article any help?