Oolite Bulletins

• 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)

Cholmondely wrote: ↑Fri Feb 19, 2021 8:30 am

maik wrote: ↑Fri Feb 19, 2021 12:17 am

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

Cholmondely wrote: ↑Fri Feb 19, 2021 8:30 am

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

Cholmondely wrote: ↑Fri Feb 19, 2021 8:30 am

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!

Cholmondely wrote: ↑Sun Feb 21, 2021 6:13 pm

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 wrote: ↑Fri Feb 19, 2021 10:09 pm

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

maik wrote: ↑Tue Feb 23, 2021 6:29 pm

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

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

tsoj wrote: ↑Tue Feb 23, 2021 8:33 pm

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 wrote: ↑Tue Feb 23, 2021 6:29 pm

maik wrote: ↑Fri Feb 19, 2021 10:09 pm

[...] 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

maik wrote: ↑Fri Feb 19, 2021 10:09 pm

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 wrote: ↑Sun Mar 07, 2021 10:06 pm

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

Cholmondely wrote: ↑Fri Feb 19, 2021 8:30 am

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.

Disembodied wrote: ↑Sat Aug 20, 2016 4:15 pm

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

Redspear wrote:

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.

Disembodied wrote: ↑Fri Apr 22, 2016 7:57 am

cim wrote:

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.

Disembodied wrote: ↑Sun Apr 24, 2016 11:14 am

Astrobe wrote:

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!

maik wrote: ↑Tue Feb 23, 2021 6:29 pm

maik wrote: ↑Fri Feb 19, 2021 10:09 pm

[...] 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

maik wrote: ↑Sun Mar 07, 2021 10:06 pm

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 wrote: ↑Mon Apr 12, 2021 9:48 pm

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

Cody wrote: ↑Mon Apr 12, 2021 9:50 pm

RockDoctor wrote: ↑Mon Apr 12, 2021 9:48 pm

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

Is your local council not doing its job?

RockDoctor wrote: ↑Sat Jun 04, 2016 12:15 am

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

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.