External dashboards

[maik]

As teased here, I have been trying my luck at making game data available outside Oolite. Potential uses are dashboards on other screens, integration with your home automation, and whatever else you can think of.

At this time this is a proof of concept and very much in its infancy: I am providing the player ship's speed every 0.1s as an example for a gauge, alert condition info when it changes as an example for event based data, and comms messages just because I wanted them on another screen.

You will need

• the debug version of Oolite because I am using its TCP channel to talk (does not work with the current MacOS version of Oolite)
• my oolite-mqtt-bridge.oxp that pushes the data as JSON strings to the debug channel
• my oolite-mqtt-bridge server which is what Oolite ends up talking to (it runs on Node.js, so you need this as well)
• an MQTT broker (I am using Mosquitto)
• a consumer for the MQTT topics to read out the data and do something with it (I provide sample flows for a Node-RED dashboard)

The oolite-mqtt-bridge components and the Node-RED sample flow are available in my github repository. Please try them out, I am happy for any feedback.

[maik]

Continuing from a thread in the discussions forum: thank you for the suggestions, I didn't think of using it like this

Question: Which game data would you like to see made available to an outside console?

Just very quickly, off the top of the old noggin,

There are maybe two contrasting uses for a second monitor: One player use and two player use.

One player use would really be having somewhere to park other views just out of the line of sight.

I suppose that I'm thinking of
1) superfluous MFDs and
2) another view (sideways/backwards/outside views etc) - or the F5/F6/F7/F8 options

1) is probably possible for a lot of things
2) will not be possible. In my tests, I get game data with a frequency of 0.1 seconds quite ok. Since Oolite does not support multiple screens, I would need to send the complete world state and render the views from scratch. Not only is that way above my paygrade, it is also not feasible with this frequency and (my choice of) technology.

OR one could have for example
i) a trading console with the F8 markets view and say a Cargo Hold list & the Market Enquirer MFDs
ii) a navigation console with the F6 & F7 views, and a Navigation MFD. Both F6 views would be nice.
iii) a communications console with the Communications and Broadcast Communications MFDs

i) and iii) seem possible again, ii) will require writing the views from scratch (although I seem to remember someone doing this in HTML/JavaScript already)

Any of these might already start to give a minimal role for a second player, which could then be developed.

In the fullness of time it might be possible to develop
i) a gunners turret console with (say) a rear view and controls for the rear gun turret
ii) an Engineering Console where the use of repair bots was made more hands-on - choosing what to repair and maybe even making choices about how the repairs are done. And a first-aid option for my poor cat who gets regularly assaulted by my repair bots!

i) needs real-time graphics again, so not possible. ii) is conceivable.

I think from a feasibility point of view you can structure it like this:
1) anything that involves rendering game graphics in real time is not possible with my approach
2) anything that shows plain data (numbers, text, regardless of their presentation) is relatively easily possible, see my dashboard example
3) anything that is more complicated but does not require real-time updates, like planet charts, market information etc. seems possible but a lot of work

[Cholmondely]

Commander Day's Diplomancy.oxp shows War & Peace maps accessed through the F4 screen while docked (and using ANA). Would these be showable (while docked) (and be potentially contrastable with the F6/F7 displays), or would it be non-trivial to set it up? What about just the reference legend for his maps?

Ditto with the import/export restrictions for Phkb's Smugglers.oxp.

We can, of course, one presumes, always access separate maps (such as Phantorgorth's/Solo's/ClymAngus's/Phkb's Oolite Galaxy Maps) on the second screen without needing to use Oolite for it.

[maik]

Commander Day's Diplomancy.oxp shows War & Peace maps accessed through the F4 screen while docked (and using ANA). Would these be showable (while docked) (and be potentially contrastable with the F6/F7 displays), or would it be non-trivial to set it up? What about just the reference legend for his maps?

Ditto with the import/export restrictions for Phkb's Smugglers.oxp.

We can, of course, one presumes, always access separate maps (such as Phantorgorth's/Solo's/ClymAngus's/Phkb's Oolite Galaxy Maps) on the second screen without needing to use Oolite for it.

Honestly, I have no idea if I can access data that is being added by OXPs. Maybe someone with more experience from scripting OXPs could help answering this? If this is possible, I would have to make the raw data available to the outside, and need to re-develop the rendering of the data in case of a map. So maps are non-trivial. Import/export restrictions are probably just text, that would be easier.

I would be interested in doing something useful with this. Comms and system messages is something you mentioned, and I already played around with showing them, so I would start with this. However, I am quite inept with pretty user interfaces. Is there someone here who knows modern HTML well enough and would like to lend a hand? I would work on the backend and deliver JSON via MQTT. Node-RED is a platform that can easily digest this, and it has a generic HTML widget, so I propose to work with this. Any other idea for a frontend is welcome as well

[maik]

[...] integration with your home automation [...]

I just ordered an RGB bulb to interface via Zigbee, so I can show the Oolite alert condition with appropriately coloured light

[tsoj]

I just ordered an RGB bulb to interface via Zigbee, so I can show the Oolite alert condition with appropriately coloured light

Ohh, that is an awesome idea!

Regarding the scripting, I believe you can do this:

Code: Select all

var l = worldScripts.Smugglers_Illegal.$illegalGoodsList(0, null)

where Smugglers_Illegal is the this.name of the script you want to access. I am not 100% sure though.

[maik]

Regarding the scripting, I believe you can do this:

Code: Select all

var l = worldScripts.Smugglers_Illegal.$illegalGoodsList(0, null)

where Smugglers_Illegal is the this.name of the script you want to access. I am not 100% sure though.

Thank you, I will try this!

[maik]

[...] integration with your home automation [...]

I just ordered an RGB bulb to interface via Zigbee, so I can show the Oolite alert condition with appropriately coloured light

It arrived, and I can make it blink in red now when the bridge in Oolite is unmanned and the alert condition turns red

The oolite-mqtt-bridge components and the Node-RED sample flow are available in my github repository. Please try them out, I am happy for any feedback.

I added an installation section to the README, and also some screenshots (a new sample UI, and its Node-RED flow). The UI is now based on vue.js (via the Node-RED UIBuilder), so I can use HTML/CSS/JavaScript for full versatility. The only problem is: I am not a designer... Is there someone here who is interested in this and wants to lend a hand?

[Cholmondely]

Is there someone here who is interested in this and wants to lend a hand?

I so wish that I had the skills to help out!

But, thanks to Redspear I've finally found the post I've been searching for for the past months as mentioned here:

There are maybe two contrasting uses for a second monitor: One player use and two player use.
...
There was also a second thread (which I've yet to locate) with ideas based on using a second game of puzzles needing solving in order (something a bit like Pipe Mania or Pipe Dream) to fix engineering problems or whatever.

This is that thread/post (needless to say, it was one of Disembodied's):

This is a good point: there is a place for a game where the action is relatively rare, but exciting when it happens, and made all the sweeter by the pauses in between. As Cim has said before, maybe what we should be thinking about is not how to skip past "the boring bits" but instead to give the player something else to do rather than stare out of the window.

Are there things the player can do, during the longeurs? (Non-compulsory things, so if they want to stare out the window, they can.) Things like:
1. Peruse the news
2. Bid for cargoes and contracts, in advance - perhaps with time-dependent elements, so there would be pressure/reward in reaching the station by a certain time
3. Communicate with nearby ships
4. Enable further interaction with other ships - side-to-side docking, perhaps, and inter-ship trading
5. Run system checks and perform onboard repairs and tune-ups
6. Run long-range scans, and try to discover information about what other ships and stations are out there, and where
7. Look back over the ship's log

Of the above, I think 3 and 4 have potential and I like the sound of #6 as it could be strategic. 5 could be... well, I'm really not sure about that one being fun.

5. Run system checks and perform onboard repairs and tune-ups
It would depend on how it's done. They would need to be gamified somewhat - essentially, take some minor timewaster games like Minesweeper, Hunt the Wumpus, Freecell, Pipe Mania etc. and repurpose them (simplifying/streamlining where necessary) into "purging the energy grid", "isolating a damaged interlink", "smoothing the plasma flow", "improving energy distribution", and so on. The advantage in doing these things would be to delay the next maintenance overhaul a bit - possibly important on a long, time-critical journey, but not compulsory by any means.

You might ask, why not just play a timewaster game? I would argue that - given an in-game purpose and context - these wouldn't feel like timewasters. There's lots of precedence for this sort of thing - a variant of Pipe Mania is used to simulate hacking in BioShock, for example.

Edited to show flow of ideas.

Further edited to add:
Other posts by Disembodied on this:

I'd split the 100 systems up into clusters of 10-20 separated by (mostly...) boring stuff: that sort of distance can be important too.

In-system scale is the other problem: I think Oolite is closer to "right" than ED's realism here (though ED's supercruise is mostly better than Oolite's torus drive), but it's still a massive compromise whatever choice you make. Dense orbital complexes traversable at conventional speeds separated by relatively quick but mostly empty interplanetary travel is probably the way to go here (though a lot of detail-building).

Again, here, too, is an argument that must be difficult for commercial designers to swallow: that the genre requires "boring bits" - long (but not too long) stretches of routine flight, to create the sense of scale (and, indeed, to make the exciting bits stand out). I think there's a role here for intelligently created mini-games, of the timewaster variety: non-compulsory things to fiddle with during the quiet patches ("calibrating scanners", or "adjusting inertial loading", or "reversing the polarity of the neutron flow", or whatever), which can have minor temporary benefits. It would likely be difficult to do well, but small, skill-based tasks, which can be started and abandoned easily, would do a lot to pad out these necessary sections of the game. The trick would be to make them feel like an organic part of the main game.

Perhaps a simple thing to do is to make the F4 screen available in-flight. There's a lot of information there that can keep you busy for a while (checking email, news, available contracts, etc.).

Yes, definite possibilities there! Perhaps, too, if there was more information available about the state of the ship - if it was possible to check (and adjust) the engines, fine-tuning them to the curvature of local space or whatever, which would provide a small speed boost (and possibly slow down system degradation, increasing the amount of time until the next service is required). Similarly one could fiddle with the cooling coils on the laser to slightly speed up laser cooling, or optimise the energy grid to slightly increase recharge rate, or balance the shields to slightly strengthen them ...

Of course, these tasks would need dedicated screens of their own, with gauges, network diagrams, and so on, and would need to be interactive: a lot of GUI work would be needed!

[RockDoctor]

[...] integration with your home automation [...]

I just ordered an RGB bulb to interface via Zigbee, so I can show the Oolite alert condition with appropriately coloured light

Pretty much the first useful use I've heard of for "Home Automation" in general, and colour-changing lights in particular. It might be coming closer though - I've seen Zigbee stuff in the "Middle @ Lidl" aisle so it's approaching "probability level 1:1, we have reality".

[RockDoctor]

It arrived, and I can make it blink in red now when the bridge in Oolite is unmanned and the alert condition turns red

Rockdoctor is occupied searching for hacking interfaces to the street lighting.

[Cody]

Rockdoctor is occupied searching for hacking interfaces to the street lighting.

Is your local council not doing its job?

[Cholmondely]

Rockdoctor is occupied searching for hacking interfaces to the street lighting.

Is your local council not doing its job?

I was heading towards the star to top off the tanthoseks before leaping into an Anarchy

He lives in an anarchy! What do you want from the poor chap?

[Cody]

Scotland is an anarchy? <recalls time spent in Glasgow> You might be right!

[RockDoctor]

What did I have to say, that I put in the clipboard?

ii) an Engineering Console where the use of repair bots was made more hands-on - choosing what to repair and maybe even making choices about how the repairs are done.

Yeah, "Repair Bots" does have an ... esoteric ? ... incomprehensible ? ... way of deciding which borked equipment to be working on next. For an example, given a choice between repairing the ECM system, or the Station Destruct codes, I'd like to weight the decision slightly towards the ECM. Or at least know about the coming sequence, so I can maybe choose the 3 hour longer route via a Democracy system over going through two anarchies in a row.

Ah, there's the thread.