Would you be able to make the max deflection "+" and "-" separate to one another? For example I want to be able to have "+40" and "-20"

I found out why! I was using 5x4 wing blocks and for some reason when I use 1x1 wing blocks it works fine.

Might be the added force on the rotor/hinge; I've recently tried to get a bit back into making things, and have noticed that rotors and especially hinges have become wonky when under load.

If you're using hinges, try adding more in parallel and see if that works better?

Whenever I attempt to take off, my control surfaces bug out. But they work fine on the ground. Do you have any idea what might be causing this?

Ahh, I see it now, that's really cool! It's nice to see that you've really thought about what people might want to make with this and planned acordingly

@Deltarray[0] Yes!
Seems i added it without documenting it.

In the config section at the top, there are 6 lines under //Control crosswiring

double RollToElevator = 0.0;
double RollToRudder = 0.0;

double PitchToAileron = 0.0;
double PitchToRudder = 0.0;

double YawToElevator = 0.0;
double YawToAileron = 0.0;

Setting RollToElevator = 0.5 for example, will add 50% of the Roll input, to the Elevators, setting it to 1.0 will make them get the full input.
Negative values invert direction of the input.

Heyo, is there a way to have one control surface controlled by multiple inputs (EG, the horizontal stabilizers on the F22 Raptor)?

No worries mate, glad to hear you haven't lost interest! If and when you do get back into SE scripting, I have had an idea that I am currently using this script and your other rotor control script for that I think you may be interested in publishing a dedicated one for. I'll hint and say it involves cyclic and collective pitch controls :D

Yeah, sorry, I've been absolutely slammed this semester, so I've not really been able to get into any extracurricular projects :/
Exams are over in a couple of weeks, and doing engineering internship for the first half of next year (so normal work day), one of my plans with my soon to be newfound free time is to go through my old SE stuff and update/fix, plus have a couple of unfinished projects.

So yeah, can't realistically say a time, but i'll get to it!

Hey dude, was wondering if you're still working on this script at all?

I too would love for a trimming feature. Awesome script, but if the plane isn't perfectly balanced out of the box then it would be ideal to use control surfaces to account for it. You can use the old override gyro trick but I hate that as it is totally undynamic and will act on the plane even when there's no lift being generated, which can cause issues when on the ground. I agree with TheMajesticCarabao that an extra line of configurable code either in custom data or in the pb itself would be user friendly and open up a whole new way of making cool planes.

probably setting it up in custom data

I see; are you thinking something that can be trimmed on the fly, or pre-configured, like putting a trim value in Custom Data?

for each individual rotors if that's alright.

Ah, neat! :)
There is not, shouldn't be difficult to add; Are you thinking individual rotors or the entire input? eg. trimming pitch (elevators)

Thanks for replying, I really wanted to replicate War Thunder controls to SE as close as possible. Another thing, is there a way to trim the rotor?

Adjust the Pitch/yaw/roll mult values to have a stronger reaction to key presses..

The technical reason is that keyboard inputs give the script a value of -1, 0 or 1, while mouse movement gives values that can be in the +/- hundreds, as they basically report mouse speed, Controllers give similar size values.

If the script was tuned for Keyboard out of the box, controller and mouse inputs would make the script go crazy :)

Why does keybind isnt reactive as much as the mouse bind?

Hmm, I think it's a question of my nomenclature not being intuitive.
PitchToAilerons sends Pitch output to Ailerons, eg. the surfaces that are for rolling, will now assist with pitching as well.

Hey, this works for the canards, but I think you're using/named the new variables wrong
The Pitch->Roll and Roll->Pitch ones are swapped in regards to their naming

Thanks for the script update, I'll try it out, my plane is rather unstable so maybe this will help it fix roll spins
I don't know if the control surfaces are treated as rotors or not but I'll try

@Shinobi
Had a new idea of how to make two inputs affect the same surfaces, I have added 6 modifiers for mixing the outputs however you want; You can now create Elevudderons if you want :p

The modifiers are under "Control Crosswiring" near the top of the script, setting for example
RollToElevator = 0.5;
Will make it so that 50% of output for Roll bound control surfaces, will be applied to the Elevators (Pitch bound control surfaces).

Did a quick test and it seems to be working very well, but post a comment if issues pop up.

The script doesn't really care about the mod in use; As long as the control surface can be spun on a rotor, it should work with the script :)

Thanks for the response, makes sense, I didn't know you had auto stab.
Does this script work with Draygo's Control Surfaces blocks?

It is not currently possible, I did mess around with it, but had issue with the auto stabilization when using it.
I might be able implement some a rudimentary, customizeable version of it some time tomorrow :)

Can it be possible to assign a group two of the control surfaces?
I've got canards on my plane and it would be really useful if they could do both aileron and elevator inputs rather than just one
Am I using it wrong?

im glad i can help, i would've made it my own but this game uses matrixes instead of quaternions, that and pids have never been my strong suit, thanks for making this program in the first place!

That one is completely on me, missed some switches.
It should be fixed now :)

I really appreciate the amount of details you bring, makes it a breeze to fix issues.

it seems the solution is that even if certain groups are disabled, say yaw for example, the program refuses to run, likely because GetRotors returns without continuing for some reason. When all rotors are present the program works

Cockpit not found
Using Fighter Cockpit
Caught exception during execution of script: not found, correct or clear name
at Program.GetRotors(String name, IMyShipController Troller, List`1 RotListR, List`1 RotListL)
at Program..ctor()

this is the buildinfo copy paste of the error, i seem to get this quite frequently and ive only gotten this script to work once, it does indeed work but i cant work out why it only worked the one time

It shouldnt be more than an hour or so depending how steams doing, thanks for the quick fix!

Interesting! That really shouldn't be happening and hasn't happened on any of my tests.
Anyhow, changed for-loops to foreach; There are no longer any indexes, which ought to fix them going out of range :)
I am unsure how much, if any, delay there is between me updating and your version being up to date, so just make sure it says "V1.04" near the top.

constant index out of range error somewhere, worked once