Space Engineers Feedback

Let PBs listen to keyboard bindable player actions
It could be very useful if PBs could listen for specific player actions. Usually those actions have some keys assigned, for example WASD, Q, E, Y, Z, C, SPACE, P, LShift at least in some cases F. Not saying that everything should be available, and especially it should not be a full blown keyboard listener as that would become security issue, just gameplay related actions. Also events triggered should carry some context information, like was F pressed while in camera/cockpit/etc The only HUD related shortcut I would love to have possibility to listen - is Shift+ (for toolbar page switching). That could allow to get rid of walls of LCDs explaining purpose of each toolbar action in each page. When player switches page, we could update contents of single LCD with relevant to that page info. I believe this feature could open doors for much more flexibility and higher variety of creations, more efficient scripts, also quite often less bulky grids. Some other examples of usage: - WASD, C and SPACE would help for creations which movement rely on rotors and pistons (mechs, tanks, one engine hovering ships, etc); - Y could help to detect when grid is powering up, so some boot-up fun could be done, like boot screens in LCDs; - F when pressed in camera could execute some code, like parking, locking and powering down camera and so on.. There is wonderful Digi's mod attempting to tackle this needs, but these things should really be part of vanilla. Link to mod:

Krienas shared this idea 20/08/17 16:32
Krienas 20/08/17 19:54
uf, I think you should patch this feedback tool to keep newline formatting.
DeckerMMIV 23/08/17 19:26
Some issues I see; - How should 'this PB' (of many PBs on the same grid) determine to "listen to" which 'seated player in the grid' (of many seated players in a multiplayer game)? - Player intended movement (WASD,C,SPACE) when in in control of cockpit/remote-control, isn't that already today 'detectable' by PB script, with IMyShipController#MoveIndicator and #RotationIndicator fields? - I haven't played multiplayer, so I do not know if 'two or more players' can use/view one camera-block at the same time. But if they can, then which player's action of 'pressing F' (to leave the camera) should execute some code? Though I am all in for your Shift+{toolbar number} suggestion, as that would be useful to somehow have such an input-action on a IMyShipController block also call 'a PB' with indications of the new toolbar number. - Problem is just, which PB to call (of potentially many PBs) on the grid. My work-around for that so far, is to assign each toolbar-slot with a unique argument - i.e. calling a PB with arguments; toolbar one; 11, 12, 13 ... 18, 19, toolbar two; 21, 22, 23 ... 28, 29, and so forth. - So when my PB script detects that 'argument number has changed by -/+10 or more', it will "know" that the player has switched to a different toolbar, and can then update LCD with new instructions without actually performing the instruction. But setting up 9 * 9 toolbar slots with unique numbers is quite annoying to do - which is why I suggest a setToolbarSlot() method accessible for in-game scripts and ModAPI.
Krienas 25/08/17 00:39
Hey DeckerMMIV, thanks for extensive comment. - In regards of the first concern: events fired should carry context information about cockpit it came from, script may take a look and decide does it want to do anything. PB doesn't think, script thinks. - Now in regards of movement indicators. I didn't really know about them, so am not sure what they indicate. From what I read, there is really good chance that you are right. Will give it a try next week. Thanks for tip. - For cameras I am not sure are they exclusive for one player use or not. Just I do not really see issue here. If PB gets info when and who starts to use it and also who decides to leave it. Then it is up to scripter and needs of feature to track state of camera usage and decide when and what to execute. You can do something on the first player leaving/the last leaving or run some code each time somebody leaves. Interesting idea about toolbar pages. Sadly LCD gets updated only after user presses something. So instructions about action comes after action is done. Not ideal. Also putting PB calls with arguments in every slot obfuscates purpose of it as UI isn't really helpful for end user when everywhere the only thing visible is PB->run and the only difference is argument. Arguments are not visible and we are not allowed to put custom labels.. yeah UI still has space for improvements. :D In regards of question "which PB to call". I would expect opt-ins typical for event driven approach. Engine doesn't care about PBs, it just fires events. PBs opt in by registering event listeners. So for specific event, there can be code triggered: a) from several PBs; b) from one if only one registered and c) none if there are no listeners.
andreykl 14/09/17 23:09
Similar topic: @DeckerMMIV Acotrding to API things you listed show current position, speed, rotation, e t c, not the position pilot tries to achieve. They aren't triggered by keyboard unless said keyboard triggered wheels, engines or gyros. So you can't force a walker to walk with them.
Krienas 13/02/18 18:00
Had tried indicators form API recently, they work great, so can be used to solve part of needs, but they are only about movement. There could be more actions exposed for PB. @andreykl that idea only sounds similar, but should be way more complicated to implement. I ask for exposing events for PB, so we can implement what we need ourselves, while that idea asks for binding UI to be able to click and be done. Do not really see that happening in close future.
andreykl 14/02/18 08:59
>that idea only sounds similar, but should be way more complicated to implement Unlikely that it is more complicated. It requires simply exposing existing functionality to script API with some checks. Or in more complex case exposing and updating UI to use it.