Yeah, tried that. I'll give it a shot in SP just to play with it :)

Checked today, seems to be working. Make sure you recompile the script if you add more gyros, it needs to know all of them so no gyros without override are left when you switch.

Just wanted to ask if this was still usable - tried it out and when I double tap space, the LCD screen updates as expected, but the ship still moves like normal mouse controls and doesn't continue to rotate?

All good, it doesn't matter all that much, because now that I think of it, it would be pointless to have the HUD available in the battle bridge since it's buried and only possible to navigate in 3rd person hahaha!

Currently, no. You can use internal screens of the cockpits in this manner, but if you use LCD then it's single. I can do something about it in the next version.

Is it possible to output the display to more than one LCD? I got two bridges (battle and standard nav bridge) that I want to see the PB's output in.

thank you!

Find this line in the code:
UserCtrlTest.Cumulative += r;
Add this line immediately after:
UserCtrlTest.Cumulative.X = 0;

is it possible to disable one of the axis? (I have a boat and only wish to have yaw)

Looks not terribly useful imo but I added that in todays' update. Have fun.

Actually, NVM.

It's probably what i mean,t but we have diffrent definitions of it, lol.

Do it! : D

Mh no, that's not the same

imagine the joystick that you have on your ingame LCD, getting pulled back to the center, slowly, instead staying in place (unless i move the mouse, or reset with spacebar)

I think you're suggesting a kinda "define desired direction by mouse delayed" mode, like move mouse pointer to a direction you want your craft to turn to, then wait while the automation turns the grid there for you.

what this script lacks, is an option to turn on "decay" of the input.

making the "joystick" slowly move back to the center, without me needing to hit spacebar twice, or move the mouse to the center myself.

so basicily, reverting it to "basic SE control" BUT with a longer Decay of input, which doesnt force you to slide that mouse over the table 5 times a second, but 1 time every 2 seconds or so

Awesome, I've expected this type of control for a long time and definitely gonna try it. Keen should put this feature into the game.

this is awesome thank you this

I changed default value of priorityLcdName to "LCD delta steering". That would force some users to rename their LCD to get them working again. If that caused troubles, excuse me!

Added vertical offset option to align indication center with crosshair for head-up placed T-LCD. Default value is 0, if you use large LCD in front of control seat, you want to change that to -0.5.

Woop woop. That should make it a firm fixture in all my cockpits, now! :D

A friend of mine built me a couple of transparent screens and I've fixed the issue. Should work as expected now. It looks cool, another thing I want to do now is to somehow align the delta center with crosshairs.

Thanks for the quick turn around on that. The transparency thing didn't work. I've looks at other scripts, and as far as I can tell, you're doing it right. Very odd.

The reset works, though, so thanks for that. :)

Thanks for feedback and suggestions. I see your point about unsafe override toggle. So I've changed that to dead center reset at space tap (on override state change).
I've also added an LCD alpha setting at the top of the code, with zero default value. I don't have DLC and can't test that, so let me know if that worked.

I love this script, but there's a comple of suggestions I'd like to make; This would work great on a transparent LCD, but the solid background means that I have to turn it off at times, and the vector still changes when the override is off, making it somewhat risky to change mode.

Keep up the great work. :)

Okay thanks to your solution I figured the problem out. It was that keens' gyro sign BS in addition to the fact that they silently swapped signs in new gyro rotation setters compared to old SetValue methods (which I still used until now).

Thanks! I made two quick attempts few days ago, one was going from local control torque to world, and then apply rotation transform for each gyro, and another was getting rotation matrix as a difference between reference gyro and each other. Both failed at some gyros. I always felt that this could be done the elegant way, without dozens of IFs, but I failed my skill check lol

Neat script. You can make the main gyro agnostic to its orientation with some vector transforms like so:

https://forum.keenswh.com/threads/method-apply-gyro-override.7399386/

And, I forgot to mention, no worries about other gyros chilling while forward-gyro does the work. They all contribute to angular acceleration even if only one is overridden. Although they get distracted to user input, so your small mouse movements make them rotate a ship a bit for a fraction of time (default game behavior). In normal mode it's hardly an issue, as we move mouse where we want the ship to rotate to anyway.

Yeah, it's a known issue, as syncing arbitrary-placed gyros looks like non-trivial task at first glance. I can easily make all gyros oriented the same as forward to assist said gyro, but that would complicate installation and force players to do changes to their builds, the thing I always tried to avoid. Another thing is that I use this script with my other cruisecontrol/autopilot simultaneously, so I can influence the craft without shutting down the autopilot script.

That seemed to be the issue with the inversion, but the other gyros are still failing to assist the script-gyro. At least I know which direction is actually forwards on the gyros now, sorry about that.

The fw direction of small gyro is that one to where it slightly "nods". Or if we look at it from the side and it's ball part is banked clockwise, then the fw would be at 3 o'clock. From your description I have impression that the fw of your gyro faces backward. That would explain why roll and pitch are inverted, while yaw is OK.

I currently have that new bugs which prevents me from uploading blueprints to the workshop, but the testbed ship I used was more or less a cockpit with a battery and atmospheric engines in every direction. The important part was that I had 2 gyroscopes on it facing the same direction, one of which was the scrip-gyro. It was small grid so there was no control-panel to tell which end was forward, but from what I know the upper most emissive circle on the gyroscope is slightly angled backwards away from the brace, so the other direction is forwards. Assuming this is correct the script-gyro was facing forwards correctly. Also now that you mention that the indicator shows the opposite direction to the virtual flight-stick it makes more sense (but is still a bit confusing to fly at times, for me at least). Thanks, I hope this helps.

Yes it is.

This is a script right?

I've just rechecked the script version from the workshop on my test grids, it works exactly as before. If it's possible, show me your build so I could sort the things out. At this point I have no ideas other than gyro misorientation.

The interfaceUpscale is a floating point variable, so yes, you can use 1.5f (the f literal is needed so the compiler would not ♥♥♥♥♥ about double to float conversion).

Roll indicator is a nice idea, but I'm not sure how would it be in case of the "plane" mode. The LCD indication was initially intended to show user control position, not the craft rotations (think of it like representation of a "flight stick"). In normal mode the indication mirrors the grid rotation, but in other mode it may be really confusing.

In standard & plane modes; pitch and roll are inverted, yaw is fine. When one or more extra gyros are added onto the grid the extra gyros act independent of the script and as would be expected with the script disabled. The HUD script seems to work fine (showing how the ship should be moving). "forward-gyro" was oriented correctly during testing (single player). It's probable that the recent update broke the script, like it did with a handful of others. Other than that I think the HUD could do with a visual indicator to which direction the craft is rolling, and the scaling could include integers (ex. 1.5). I look forward to using the script once it is working as intended again.

Won't be in game again for about two weeks but will have a play then.

Great, thank you.

No CustomData support yet. You have to change the "swapRollYaw" variable to true at the top of the code.

How is this used, is it done by changing a setting in custom data?

Thank you, that's great! So, now the LEFT/RIGHT on the mouse can control roll and Q/E the yaw? Yes, I've always noticed that yaw starts to roll slightly the further you move.

Very cool! Can't wait to test this out.

woostyboy I've added an option to swap roll/yaw in today's update. Idea sounded cool, but in practice it feels wonky. The main issue is that we can't fully suppress user input from a cockpit, i.e. when I press Q it yaws but it also rolls (even if you override gyro on all axis it would still respect user input from cockpit).

I wonder if you could help please?

SCRIPT REQUEST :)

Would you be able to make a PB script to switch ROLL and YAW axis on gyros? I want to fly a plane with PITCH / ROLL on the mouse, instead of PITCH / YAW. Would need to make 'Q' and 'E' the YAW.

Many thanks in advance!! ;)

Nice one