Will this page ever have a video on how to do everything? this mod has such great potential but it seems to be VERY finicky and a pain to set up and the only videos out are showing the end of the build when it works

I seem to have a problem regarding one of the two rotors on the opposite side unable to move. The left rotor works as intended, but the right don't.

I cant find the mod either. But you said about max holding force and increasing some values. What are those values?

It increases the max thrust on the rotors so they can can resist the thrust force.

Ill take a look for that mod. But i think it tries to adjust to the center mass, am i correct?

The force created by the thrusters causes the physics engine to go crazy. You can increase the values to hold the rotor/hinge in place.

There's a mod that greatly increases the max holding force, but I don't remember what it is (was).

I want to use this script on my ship with 4 thruster rotors. I tried this script on a smaller ship which works fine, but when I try this on my ship it spins out of control. You know how to fix this?

Try increasing the braking forces. If there's a lot of thrust, it overcomes the rotor 'hold' ability and spins it.

I'm using this with Whip's Subgrid Thrust Manager. I've got a rotor on either side of the ship, rotating in the YZ plane. I'm in space, and the two rotors just spin wildly when I try and move in a direction.

I tested a while ago, but yes.

Does this work with hinges?

Whatever makes the control inputs change. This means if you can 'fly' a ship with it, then it can be used.

So, yes. mouse input can be used.

Hey, is there a way to use mouse input instead for the sake of aerodynamic control surfaces?

Ok and how i can disable the braking?

That ability is not in the script. It's meant to change the rotor orientation to match the direction of travel requested.

is it possible to let a rotor turn as long as i press (e.g) W ... so without limits?

Yeah I just wanted to be sure, as people have been saying they've had more success with this script but I haven't seen the designs. I've got it working now by using a mod that massively increases the maximum torque available for rotors and hinges, however it is far less effective with this script than with VT2. Doing it that way will create problems of it's own most likely, but to be honest VTOLs of this style aren't that useful, so I'm probably only going to use them for videos.

@Cynical: This will happen with any subgrid thrusters. You can use Whiplash's subgrid thruster script to integrate thrusters better.

The thrust is centered on each subgrid's mass, which then acts via game physics on the parent grid just as when two totally unconnected ships collide and push each other around. Effectively, subgrid thrusters recreate a similar effect as various realistic thruster mods that do this for all thrusters even on the same grid. You avoid this by avoiding subgrid thrusters.

If you want to totally eliminate this problem, use merge blocks to fuse the subgrid back onto the parent grid once it's rotated into desired position.

Yes. That is a keen physics problem.

I have a blueprint I can share if you're interested.

I take it this script suffers the same as VT2 from the weird effects of rotors not being on the same axis as the centre of mass?

P.S. I find that for consistent results like precision maneuvers and docking, it helps to have a hybrid ship with minimum thrust in all 6 directions for station-keeping and minor RCS-type adjustments/positioning. And maybe some redundant 50% sufficient thrust (either upward and/or forward for lift in grav wells and forward movement). Then put the big honker thrust on gimbal rotors to supplement the base thrust in each direction and efficiently put the gimbal thrust in the directions most needed in flight.

This is AWESOME. On a planet (1G Earth-like), with gravity and dampeners set false for this, just using the rotor orientation is a great VTOL/vectored thrust experience. Controlled, predictable, puts the gimbal thrusters exactly where the user wants them. Vermilion's vector thrust 2 and this script's dampener-true mode both try to, well, dampen and anticipate the craft's movement, which I appreciate. But I find that makes for less predictable flight behavior b/c my thrust is constantly being taken away from me. Kind of like the difference between modern car traction control versus the driver having to know when to manually pump the brakes etc.

My bad, syntax error. however, now they're not working properly as dampeners.

haven't tested with hinges. but as long as you only try to use the only direction that hinges 'rotate', they are just like rotors.

Having issues setting up a hoverbike that uses hinges. Do hinges have to be set up differently? Are they supported at all? Is it because the hinges are on the end of rotors?

hm well the compiling gives a clean but the extra thrusters are on the same block as the large hydros, aka all one rotor, but i found the simple rotor vanilla option to do what i need it to. but i have made what i was after directly and instead of your script i have one more fitting for the ships role, being my miner its got excovOS *good script and easy to use*

This script aims thrusters on rotors in the 'desired' direction. You didn't say if the secondary thrusters are on rotors/hinges.

I'm also not sure if this script doesn't have errors since it's been a year since I touched it.

HMMM just trying to get my head around this so i can use a pure hydro VTOL miner with my main center of thrust being between my 2 cargo units and i want to use my large thrusters for forward and down only but on the same unit it has 2 forward small hydro thrusters that i want to act as secondary down thrusts for when im landing and hopfully they work in that manor :P i have sideways and down attached to the ships haul.

Hmm. I look at making that plan.

Are there plans to add roll function? I would like to press 'Q' and 'E' to send my port and starboard thrusters into opposing directions and spin the craft.

Just found out about this script, seems really cool, well done. I'm surely using it into my next designs :D Thanks!

That would fundamentally require a lot more information, such as where the subgrid is attached compared to center of mass, how far the thruster(s) are off axis on that subgrid (and potentially one grid down) which could be done, as it is done in Timotei's mARMos script essentially.
I kind of doubt that many people would be willing to go through that kind of setup, unless it's a very specific project.
In a realistic setting however that would be awesome.

What I mean is, when you do input for ship rotation, like pitch, roll and yaw.

I'm not sure what you're asking for.

This script is to change rotors orientation in response to user input (or dampening or gravity).

It does not actually change the orientation of the ship itself.

Hi! Would it be possible to add functionality for rotating the ship arount its 3 axes? That would be extremely helpful for very long or very wide ships for example. Thank you for considering!

You'll probably need to change the example to match the orientation of your rotors.

Also, make sure it's a ship and not a station.

I mean there's not much in the way of a blueprint to give? I make a platform with one rotor and an engine strapped to the side. With 2 program blocks, 1 with this script, 1 with the subgrib script, and I just copy paste the example custom data into the rotor..

Please link a blueprint and I will check.

So I'm not exactly sure what I'm doing wrong. I'm just doing a simple platform (no fancy ship yet) to run tests on getting the script to work. While I was able to get Whip's subgrid to work fine, I can't seem to get this to operate on even the simplist of things, and I'm not exactly sure what I'm doing wrong as I load the script in a program block, and used the top most example custom data just as a means of testing, and it won't work.

@Wicorel Thanks for the response, will do that as soon as I can if I can't figure it out myself. I am sure it's something wrong on my end.

Please link a blueprint and I'll check.

Anyone have any clue why the auto dampening it not working when moving forward or backward? It is not compensating at all. Moving up and down does dampening properly.

Putting this seems to work though:
[GIMBAL]
GimbalZMinus=80
GimbalZPlus=280

Unfortunately it seems the limits get overridden by the script.

Been a while since I went through the code in detail.

It tries to go the 'shortest' distance, but at 180 it might not be picking the 'right' direction.

Try setting limits for the rotor/hinge.

Is there a way to set it up so it doesn't do a full 360 degree turn? For example having a 180 degree arc it can move (so it can thrust forwards, backwards, and up) movement on a rotor but preventing it from doing a complete circle so the thrusters don't hit any blocks in a certain arc.

Is it posible for this scrip to control two rotors with the gimbal custom data that are mounted on a third rotor / hinge that the script ignores? Or can it be made to work like that? I'm trying to make fold out/ retractable manoeuvring thrusters. I've got the script working with 2 rotors/ a rotor and hinge, but as soon as I mount that on another rotor or hinge to fold them away when not using the script stops working. The third rotor has no custom data so I thought the script should ignore it but for some reason it stops it from working.
Thanks for the awesome script anyway though.

The amount of processing the script does changes depending on if any Shp Controller is occupied and the number of rotors to be processed.

By runtime, do you mean the elapsed time the script takes to run?

I don't have this script output that information. The time for the last run is easily available to script. current run time would have to be tracked. There's also the number of instructions used which is another measurement of runtime.

What's the average runtime of the script?