DuckDuckGone!!
Cockpits, HUDs and other displays
Moderators: winston, another_commander
Re: Cockpits, HUDs and other displays
- hiran
- Theorethicist
- Posts: 2358
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: Cockpits, HUDs and other displays
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."
Sunshine - Moonlight - Good Times - Oolite
- hiran
- Theorethicist
- Posts: 2358
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: Cockpits, HUDs and other displays
Now I am sure: I must be doing something wrong!MrFlibble wrote: ↑Wed Jul 10, 2024 9:36 pmYou 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 funhiran wrote: ↑Wed Jul 10, 2024 8:49 pmI 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?
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
For me neither the PS.fireMissile() nor the PS.target.energy gives the expected reaction.
Now this is really cool. Although I am hoping the touch display would be bigger than one single button...MrFlibble wrote: ↑Wed Jul 10, 2024 9:36 pmI'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.
Sunshine - Moonlight - Good Times - Oolite
Re: Cockpits, HUDs and other displays
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
- Archivist
- Posts: 5290
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: Cockpits, HUDs and other displays
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)
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)
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
Re: Cockpits, HUDs and other displays
Looking at what might be fun to have published via MQTT, I drilled in:
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!
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
- Theorethicist
- Posts: 2358
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: Cockpits, HUDs and other displays
That is a wealth of data, but unquestionable it is needed.MrFlibble wrote: ↑Sun Jul 21, 2024 12:08 amLooking at what might be fun to have published via MQTT, I drilled in:
Perhaps: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"]
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!
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.
Sunshine - Moonlight - Good Times - Oolite
Re: Cockpits, HUDs and other displays
Thanks. So configuring the 'what' is likely to become essential. On to the when...hiran wrote: ↑Sun Jul 21, 2024 7:32 pmThat is a wealth of data, but unquestionable it is needed.MrFlibble wrote: ↑Sun Jul 21, 2024 12:08 amLooking 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.
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.
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
- Impressively Grand Sub-Admiral
- Posts: 4821
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Cockpits, HUDs and other displays
Aren’t we just taking about the properties of the player ship? Ie https://wiki.alioth.net/index.php/Oolite_JavaScript_Reference:_PlayerShip
Re: Cockpits, HUDs and other displays
Pretty much.phkb wrote: ↑Mon Jul 22, 2024 7:02 amAren’t we just taking about the properties of the player ship? Ie https://wiki.alioth.net/index.php/Oolite_JavaScript_Reference:_PlayerShip
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.
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
- Theorethicist
- Posts: 2358
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: Cockpits, HUDs and other displays
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.MrFlibble wrote: ↑Mon Jul 22, 2024 2:04 amThanks. So configuring the 'what' is likely to become essential. On to the when...hiran wrote: ↑Sun Jul 21, 2024 7:32 pmWe 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.
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.
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.
Sunshine - Moonlight - Good Times - Oolite
- Cholmondely
- Archivist
- Posts: 5290
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: Cockpits, HUDs and other displays
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.
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
- hiran
- Theorethicist
- Posts: 2358
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: Cockpits, HUDs and other displays
...and others could still give direct visibility on equipment, repair status and else. True.Cholmondely wrote: ↑Mon Jul 22, 2024 8:16 pmWhen 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.
Sunshine - Moonlight - Good Times - Oolite
- hiran
- Theorethicist
- Posts: 2358
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: Cockpits, HUDs and other displays
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 likeMrFlibble wrote: ↑Sun Jul 21, 2024 12:08 amPerhaps:
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.
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}
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})
Sunshine - Moonlight - Good Times - Oolite
Re: Cockpits, HUDs and other displays
Most excellent!
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.hiran wrote: ↑Tue Jul 23, 2024 5:55 amSo 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}
I'll be sure to pop on my sturdy gauntlets and have a play with v0.1.33-hoopsnake.2
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?hiran wrote: ↑Tue Jul 23, 2024 5:55 amWhat 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))