Using small Programing_block main LCD as menu and second as debug?

Yeah, that would make sense for compact builds, thanks!

First off, this is functionality that SE really, really needed. So, thank you for working on this!

Would it be possible to use the mouse buttons to perform the enter and escape actions instead of/in addition to E and Q?

You're welcome!

Unfortunately, scripting API does not give access to user mouse actions. The script "captures" Q, E and mouse move just because they represent grid rotation control.

The only thing I can do about mouse click - I can make script listen to welder or grinder that is activated on toolbar. This way we can get LMB click, but not RMB, so the issue with escape action would persist anyway.

OK got it all working [remote was missing lol]. Great mod.

Mouse movement is inverted on the y axis. I have my mouse y axis inverted so that flight in game acts like a normal aircraft. The script uses this inversion within the mouse capture menu interaction; which makes sense! Is there a way to have a MouseInverted=true/false parameter in the scriipt? Would that be even doable?

@Rusted Droid, I've included the option of using main PB screen as menu (but it works... different. Not sure if it's Keens' fault or mine). To use it, set MenuScreenIndex to -1 (otherwise the script would use cockpits' screen).

@Boobies, done.

Block query batch commands - run in a single user action.

Ability to print messages in screen. I'm working on an indicator light, but being able to say "Refuel In progress" or to display debug information on the LCD could make things easier to understand and debug.

Originally posted by cheerkin:

You're welcome!

Unfortunately, scripting API does not give access to user mouse actions. The script "captures" Q, E and mouse move just because they represent grid rotation control.

The only thing I can do about mouse click - I can make script listen to welder or grinder that is activated on toolbar. This way we can get LMB click, but not RMB, so the issue with escape action would persist anyway.

This doesn't fix the problem, but would another possible workaround be to include an action to escape back to the previous menu in the tree? That way, someone could still have the left click action if they want, and they'd be able to navigate the tree with just one key instead of two

Originally posted by UF1Goat:

Ability to print messages in screen. I'm working on an indicator light, but being able to say "Refuel In progress" or to display debug information on the LCD could make things easier to understand and debug.

How would it work?

Originally posted by UF1Goat:

This doesn't fix the problem, but would another possible workaround be to include an action to escape back to the previous menu in the tree? That way, someone could still have the left click action if they want, and they'd be able to navigate the tree with just one key instead of two

What do you mean? Adding a button for "navigate back"?

Originally posted by cheerkin:

Originally posted by UF1Goat:

This doesn't fix the problem, but would another possible workaround be to include an action to escape back to the previous menu in the tree? That way, someone could still have the left click action if they want, and they'd be able to navigate the tree with just one key instead of two

What do you mean? Adding a button for "navigate back"?

Yep! It does exactly the same action as hitting the Q,just sends you back one level int he tree

Fair enough, goes right into TODO list.

Originally posted by cheerkin:

Originally posted by UF1Goat:

Ability to print messages in screen. I'm working on an indicator light, but being able to say "Refuel In progress" or to display debug information on the LCD could make things easier to understand and debug.

How would it work?

This is really, really sloppy I'm sure, but I'm imagining something like:

DisplayName=Refuel Primary Tanks;[group:Primary Fuel:Stockpile_Off],[group:Backup Fuel:Stockpile_On];[DisplayText:Refuel in progress]

The DisplayText would display text either in the same line, a new break line, or if there was a dedicated line of the screen for "Header", it would display there.

So you may have something like.


-Standby-
Refuel Primary Tanks

On the screen, but when you activate Refuel Primary Tanks, the screen changes to:

-Refuel in Progress-
Refuel Primary Tanks.

There's a a few use cases I can think of off the top of my head for being able to show on screen what's going on, but that' kind of the easiest example.

But what would be the condition for showing DisplayText? Just show/hide toggled by every activation? Or dependent on property values?
I guess your logic would be showing that header when you first activate that whole command, but when to hide it?