(Semi) Contextual help

[Cholmondely]

Maybe it's me. I just can't help thinking that there's a better way to manage it (in game) than cycling through a list. I appreciate that In the early days the list would have been much shorter. Ho hum.

But this where Phkb's work adding in more Fast Activation keys is crucial.

Especially if one is using something like Touchportal or Streamdeck, where one can label the buttons!

As regards the "help key" I'd vote for something more intuitive.

Intuitive is good... is the '+' symbol currently in use, as in more info please?

Or "add into" the various help buttons for Windows & Linux as is done for the AppleMac?

[Redspear]

But this where Phkb's work adding in more Fast Activation keys is crucial.

Yes, that would help but it's a patch for the original design (may work excellently however).

Or "add into" the various help buttons for Windows & Linux as is done for the AppleMac?

I dunno, I suppose one man's intuitive is another man's... er...

(family members dying/disintegrating/being rushed to hospital/etc.)

Very sorry to hear that. My best wishes.

[Cholmondely]

Anyway, I'll PM you the text I've put together so far, and you can go to town on it.

I'm being a twit - just sneak a peek at Cim's excellent and immersive Ship's Manual (in his Ship's Library OXP).

[phkb]

I'm being a twit - just sneak a peek at Cim's excellent and immersive Ship's Manual (in his Ship's Library OXP).

That’s a good point. I’ll do that first.

[hiran]

Is that a technical limitation or how the game handling is intended?

Mostly technical. Just getting the Expansion Manager to copy the URL to the player's clipboard (on Windows, Linux and Mac) was hard enough.

Besides, I'm doing the help screens from Javascript, which has even fewer system rights. Launching a browser is definitely not one of them.

Well, maybe it reduces to simply forking another process. See https://stackoverflow.com/a/54334181
If Javascript cannot run the process directly, it might run a function in Oolite which then performs the fork depending on the OS?

Am really happy to code in Java, where exactly these caveats are all part of the platform.

[phkb]

Well, maybe it reduces to simply forking another process.

I've taken my time to reply because I wanted this response to have a more thoughtful and serious tone that my previous replies have been.

This exercise, and the idea behind this thread, was supposed to be something simple that can operate on the back of other updates I'll be pushing to trunk soon. The opportunity was there, and so I thought it was worth pursuing. I was certainly not considering a much larger piece of work to be the prequisite for implementing something like this. But let's have a look at what the implications of that change would be.

The difficulty in implementing the ability to launch system processes on three separate OSes goes beyond the actual mechanics of the code changes themselves. One of the benefits of our current platform is that it has no ability to launch anything (via core code or JS), and will only write to save game files or the GNUstepDefaults file. This means, from a security point of view, that Oolite is quite benign. It has few (if any) vectors that can be exploited for nefarious purposes.

By opening up a means by which processes can be launched greatly increases the security concerns for the app. But perhaps we could address those concerns, mitigate the risks in some way? How would you do that?

Well, the first thing you'd have to do it update all the linked DLL libraries to the most up-to-date and secure versions available. That would have to be the first step, because it would be the only way to ensure that all known security issues have been dealt with. Trying to back-port the massive list of security fixes onto our set of DLL's would be even worse. And as part of the dev team, re-implementing and re-linking all the DLL's is not a task we can take on. We just don't have the bandwidth to make it happen. Plus, doing so would likely break a lot of existing code (core and in OXP's).

And while there might be flow-on benefits for doing that work, there would need to be a really compelling reason why. Adding some context-sensitive help doesn't clear that bar. It's a "nice to have" only.

So, as part of the dev team, I'm saying that I don't want to add this ability to Oolite. I would need a lot of convinving, and there would need to be a massive increase in active members of the dev team, along with some rather critical Mac developers.

Just so it's clear - I'm not opposed to progress, and making improvements in the game. I want to make Oolite into the best version of itself it can be. I want to see the player-base grow. I want to see more players like arquebus doing YT videos of their gametime. And I don't want to pour cold water on your ideas. I think your enthusiasm is wonderful, and what you are achieving with OoliteStarter is great -- it will become a wonderful resource for players in future. But we won't be adding features at the expense of security.

[hiran]

[... long post ...]

My gut feeling was that creating/maintaining the content to be displayed would be the main work. I must be wrong here.

So I will take this as a 'no'. Thanks for elaborating the reasons for the decision.

[cbr]

Summary : this thread was started to find the missing key for a help function programmed to be inside oolite, nothing will be started externally and the key is to be positioned far away for Launch from station, Launch bomb or Launch missile?

That would help beginners and me

[Redspear]

Summary : this thread was started to find the missing key for a help function programmed to be inside oolite, nothing will be started externally and the key is to be positioned far away for Launch from station, Launch bomb or Launch missile?

That would help beginners and me

So many times on the Spectrum version of elite I pressed eject or energy bomb unintentionally (...oops, sorry innocent trader )