Oolite Bulletins

I am evaluating the idea for an easy to use mission engine that would make mission creation a lot easier.

It could react to arbitrary game events and interact with the player through mission screens and comms messages. Player's input on mission screen or activities in the ship would be fed into the engine to move the story.

Here I'm not trying to reinvent the wheel. Interactive fiction is a big topic, and in this area there exist languages with editors, execution engines, validators, documentation and forums to get support.

So my idea is to squeeze such an execution engine into an OXP. But the peculiarities of Oolite JavaScript make this anything but easy. I still need to overcome some hurdles.

While doing that another idea is emerging:
Meanwhile lots of Oolite events are available in MQTT. And a feedback channel exists where messages received via MQTT are executed in Oolite's JavaScript engine.
Essentially that means we could move the mission engine outside of Oolite and overcome internal hurdles.

At the same time it would open pandora's box with vast possibilities and pitfalls. It's similar as with the external expansion manager 'OoliteStarter'. How do you think about 'external addons'?

I cannot believe noone has any opinion or comment.
Is my post that unclear? Ask, I'll try to explain...

hiran wrote: ↑Thu Aug 08, 2024 9:20 pm

I cannot believe noone has any opinion or comment.
Is my post that unclear? Ask, I'll try to explain...

How do you think about 'external addons'?

I love the idea. Prior to Starter getting its MQTT wings,I'd waved similar flags, with the shield of "clear sky thinking", only to be reminded that skies are not clear, unlike the existence of glaring security holes.

My hasty proposals had of course, been in the context of shimming the OXP stuff to allow things like Telescope's (external python) "other OXP ships scanner" to be automated, and more selfishly (for me, not a JS/Java lover) to be able to use my tools of choice, Bash/Perl/Python, for OXPs, and to be able to interface whatever mad hardware I could conjure. I grasp how allowing arbitrary languages to be called from otherwise sandboxed OXPs might be considered a bit of a security concern.

Now though, I'd like to think that there's a potential to grant MQTT & Debug Oodles more control, and access to internals in such a way that OXP's are still 'safe', while granting 'full monty' access for mad tinkerers.

This is a space opera. Perhaps the sky should not be the limit!

I'd truly love to have all my MFD's on other screens/devices/browsers. I want to be able to inject keystrokes, and/or read what keys have been received by the game (NOT A GENERAL KEYLOGGER!). In the latter case, any external program COULD be able to capture a password inadvertently typed into the Oolite window, though that COULD be mitigated to some extent by only forwarding actual keystrokes, and then only the ones configured to have effect within Oolite. Anyone using passwords which might pass that filter should sanity check their password policy.

I'd advocate retention of a slight but unavoidable 'technical hurdle' which might act as a cause to RTFM, and therefore a natural safety-obstacle to those who would otherwise not read any warnings we perhaps should put in place.

I'd understood what you were saying as proposing to create another external programme which itself then writes OXPs.

In either case, success would be interesting!

Cholmondely wrote: ↑Fri Aug 09, 2024 6:13 am

I'd understood what you were saying as proposing to create another external programme which itself then writes OXPs.

In either case, success would be interesting!

Almost.
I'd try to expand Oolite by breaking out of the limitations of OXPs.