I don't believe this simple script has such options, but you can probably hack the script to do it pretty easily if you're scripty at all. Gravity Aligner is probably what you want.

can i exclude a gyro

idk, I rarely use autopilot and can't vouch for it

No, it's pointed the correct way. I can also control the tram with the remote control myself. It's just the autopilot that causes it to roll.

hmm maybe the remote is oriented wrongly

I am using Gravity Aligner right now, but it has the same exact problem. It can allign perfectly well, if I control it with a seat it stays upright perfectly. However, when I turn on autopilot on my remote control (it's an automated tram system), it puts the override on 60 rpm to one side and just flips the train.

due to how Keen handles gyros, it's truly difficult to make them balance under load against gravity, so if this train is heavy, you may have a bad time. The train would need to be bottom-heavy. When I tried using hoverrails, it didn't work out so well. My train could balance, but when it hit one of the sharp turns, it'd not be able to handle the turn and usually try to go off the rail or fall over. Leveller doesn't have very many options, so it's not very tuneable for such purposes, you may want to upgrade to Gravity Aligner which has far more dials to fiddle with.

So, I'm using this script with the hoverrails mod. However, when I turn on the remote control, the script puts the roll override on full to the right which causes the train to immediately roll of the track.

Any way to prevent this?

I have not tried that yet.

have you ever tried just leaving a gyro on Override but set to zero velocity?

Haha, okay, I actually have that script on the same ship, I use the leveler script for cancelling out the phantom force as mentioned here a while back, and this script for leveling within gravity fields.

crash course in programming!

a simpler way might be to use my other script, Gravity Aligner, which has better filtering options

I appreciate the response, however I am no programmer. Do I paste that over the AllControllers() function?

in AllControllers() function you could filter out those that aren't set to Main cockpit by something like:
if (c != null && c.IsMainCockpit) yield return c;
or could do same sort of thing inside ManageController instead.

Is there a way I can disable the gyroscope override, or at least make certain seats exempt from the script making them control the gyros?

For large gyros they can only turn at 30 RPM maximum to you may should reduce the script's configured maxRotation to PI * .25f, with those changes it seems to be working fairly well, about as well as GA anyway. GA has some extra fancy protection vs. this gyro behavior, handles it better out of the box. It seems it would also help if the trains were not quite so top-heavy, this is a design flaw that can be alleviated by using lighter blocks, putting the heavy blocks like the gyros near the bottom, may not need so many gyros and reactors. Anyway if you make the train split in more cars so it can bend, it'd handle the corners much better.

@Laaven yeah your tram does not work w Leveller, it's pretty strange, unsure why yet. I must add more instrumentation and logging to see what's up. But it indeed acts pretty wonky. You have the new version with the bugfix. I tried setting Leveller to use UpdateFrequency.Update10 (so runs 6x per second instead of 60x) and that actually helps a lot in such cases since the real issue seems to be Keen's quirky gyroscope controller behavior, as usual, if you (or the script) fiddle with the controls too frequently, they don't work, each time the sliders change, even slightly, it resets the gyro's internal PID controller somehow and it must spin up again!

or maybe turn it off

try rotating your remote control the same way as your cockpit

i have remote control and cockpit

@Laaven you don't happen to have an extra remote control somewhere do you?

once my ship tilts its unable to roll back it stuck at 90 degree angle

Wow I finally figured out a huge bug w the script, it was stupid, just the rotation rate limiter being applied in such a way that it could change your steering direction. Stupid bug, squished!

this script Leveller is made to combat roll, it should do the trick. You need a gyro and remote/cockpit, though.

I subscribed to most of your scripts. Any advice what type i can use for best results?

I using hover rail mod and have 2 hover engines on platform that travel on single rail. What i am after is to fight "roll" of platform a am traveling on.
Some other scipts are good but until a go on rail curve, many scripts "fail" to fight roll and platform just flip to side 80° with showing like nothing has happend.

Same! haha, phantom force has been the bane of my existence up until finding this!

I'm glad it's helping!

Keep in mind that my current usage of this script is to simply keep my ship from rotating due to "phantom force" caused by pistons, hinges, and rotors. I can absolutely confirm that this script has solved that annoying issue, and my ship has not budged at all in a long time now!

It would certainly be helpful if the script were to be changed to identify control seat/cockpit permissions, but it isn't all that urgent. I put in place a temporary solution using Whip's seat trigger script. I just have it trigger a timer block that sends the "stop" command to the PB when I sit in the seat, and then send the "go" command when I exit the seat lol.

it seems in the underlying IMyShipController API there's CanControlShip and IsMainCockpit and IsUnderControl, and there's ControlWheels and ControlThrusters properties, but there seems to be missing a corresponding property to query the flag for the control of gyros. So idk if I can actually honor that flag after all. Would be sufficient to use if (c.CanControlShip && c.IsMainCockpit) or something like that, instead.

ah yeah this simple script doesn't bother to check the permissions, the cockpit isn't technically what's controlling them, it's fly-by-script! iirc Gravity Aligner checks those permissions, I could find the code that checks if you need it

Correction: *the script overrides all cockpits' gyro control permissions.

It seems that this script overrides all cockpit's permissions for ship controls. For example, I got a control seat that is only meant for interfacing with ship sub-systems, so I have gyro and thruster controls disabled on it. However when the script is running, I can control gyros again, but not the thrusters. Is there a way to disable this, or make the script only operate with one cockpit?

Thanks for your response! I'll try learning some C and/or try GA.

you might also try my other script Gravity Aligner which is much more configurable but you would need to expand the pitch limits.

@condottiere not without editing the script, it's not that fancy. You can change AllGyros() function to yield return only the block you want somehow, C# has a variety of ways this could be accomplished, I'm lazy here just doing GridTerminalSystem.GetBlocks(blocks); then removing the ones on different construct, you could remove the ones you don't want in a similar way. Just takes a wee bit of coding.

Hi p3st|cIdE! Of all the hover/levelling scripts I've tried, yours seems to be a good balance of effect and nonintrusive control so that my ships can act as hover turrets when needed (doesn't fight my pitch, while preventing roll). So thank you!

For my question, is there a way to limit/exclude gyro inclusion? I have 2 rotor gyros for custom turret controller elevation/azimuth on override for targeting. I have 1 main grid gyro that I would like to designate for the Leveller script. Sorry to bother you with this!

If you want further support for RotorAlign, please comment on that script.

RotorAlign was designed to have a PB and remote on the grid being aligned. Seems you're using it in reverse somehow? Perhaps I'm misunderstanding what kind of vehicle you're making. It's probably not that hard to change RotorAlign, but if it's for a one-of-a-kind ship, I probably don't have time to do it.

Hi, I tried RotorAlign. For some reason the rotor speed was inverted, i just put rot.TargetVelocityRad=-r at line 62.
I needed to replace all the rotors, being sure that wheels are attached by rotor body instead of rotor part. 0° is up.
Is it possible to choose the aligning rotor by name instead of using the first?

Thank you, I will try RotorAlign. Do you think it will work? I have the wheels on 4 rotors on the roll direction underneath the vehicle, it is not to align only the drills but the whole thing with cockpit and cargos.

sometimes making Leveller run only 6x/second instead of at full rate can help with that stuckness problem. It happens when the script changes the overrides too frequently.

That's "static angular friction" or how gyros work in this game, and is pretty much why I stopped using Leveller for that and made RotorAlign

Hi, I'm working on a mining rover with wheel axis attached to rotors. The purpose of this contraption is to remove the roll and keep the body of the rover vertical even in slopes so I can dig leveled tunnels.
It is working perfectly with astonishing performance, keeping it upright in slopes and turns..... until I reload the game... Your script is overriding all gyros at roll 60 or -60, but nothing is moving and it just leans on a side. If I turn off the programmable block with your script, the 60 override will make the whole vehicle to roll over until it self-destructs. It seems that manual roll overryde from the control panel is working, but overrides from your program are not applied.
Also copy/pasting the vehicle after it is detached causes this issue.
Rotors are off with 0 braking torque. Drills not yet on place. All 8 wheels are in 4 subgrids.
This happens also in vanilla and before loading whip's subgrid wheel control script.
Do you have any ideas on what could be happening?

sometimes just setting a gyro to override with yaw pitch roll left at zero helps

I'm pretty sure this script is working perfectly. I've had it running this whole time, and my ship hasn't budged. Of course I'll let you know if anything changes, otherwise this script is perfect for combating phantom force in space!

If all you want to do is park, they have landing gear for that. In fact if you get rotational motion buildup when stopped, the problem is clang... physics constraints fighting each other. That's a design issue. Otherwise yeah sub-grids do cause issues, I'm just not sure I can correct for them. I'm thinking something that analyzes the orientation, whenever input isn't provided, counter-act any detected drift away from prior orientation. I could implement some sort of orientation lock maybe but seems it could automatically understand it should stay at the last orientation it received player input after. So like an augmented angular inertial dampener. I fear clang will take it and make the problem worse if I mess with it though. I still must find time to work on it, idk when..

I'm only talking about purely rotation caused by sub-grids via rotors, pistons, or hinges. It often is super slow and gradual, rarely it could be abrupt. I've been looking all over for a script that would take note of the grid's current world orientation, not relative orientation to another object, and use gyroscopes to maintain that orientation with no movement involved. Almost like a "parking" script, to be able to park your ship at some gantry without worrying that you'll come back to it later completely turned over on top of the gantry. Hopefully this all makes sense.

pretty sure Leveller currently does nothing in zero-G btw

are you talking about the drift that happens with no inputs when moving with such multiple grids? That's probably a bug in their inertial dampening somehow. Also clang of all people is involved, some of the reason is numerical imprecision when calculating velocities and solving physics, and this gets worse the further from the global world origin you get. But I might be able to do *something* about it, by detecting un-steered angular velocity and just countering it. I'll think about it.