This would be particularly useful on V-tailed aircraft, where the rudder and elevators are combined. Currently, pulling (for example) full up elevator and full left rudder at the same time on a V-tail would cause the left elevator to rotate twice as far as it's meant to, while the right one would return to neutral as it should. Reducing the values of one of the rotation variables would fix the underrotation, but then cause the elevator that's meant to be neutral to stay slightly deflected. "rotationClamp [x, y, z]", where x, y, and z are the maximum rotation distances for each of those respective axes, would fix this. This would keep the left elevator in the previous example at its intended full deflection and allow the right one to return to neutral, which is how V-tailed aircraft execute a turn using the rudder in real life.

So what you're saying is v-tail aircraft don't have rudders, and they use their elevators to make turns? In that case, you're using you elevators as rudders, so when you do up elevator and left rudder, issues happen? Am I understanding correctly?

Yes, that's what I'm saying. The elevators go too far when you pull both rudder and elevator, and it looks dumb, not to mention isn't realistic. A clamp would prevent them from going too far while also allowing them to still rotate the full distance, unlike just making the rotation variables smaller.

See now, the problem is that doesn't make sense. If you do it that way, you'll have literally no difference in deflection if you have full elevator and no rudder, and full elevator and full rudder. Either the left side will be stuck full up, or both will. Your comment about the right being neutral doesn't make sense, as if you apply rudder variables to both elevators then they'll both rotate during a turn. Not just the left one. What I see in yours is you want the elevators to never go up unless you're only using elevator and not rudder. That's not a clamp. That's coding.

"Either the left side will be stuck full up, or both will."

That's exactly what I want. Right now the left side goes up twice as far as it's meant to, and making the rotation variables smaller would keep them from going far enough when only one axis is active. A clamp would make them move the same distance when one axis is active, but keep them from going too far when both are active. As to the right being neutral, what happens is that the elevator rotates and then the rudder rotates the same control surface in the exact opposite direction, so they cancel each other out and make the right look like it hasn't moved. That's how it should look if you're pulling both elevator and rudder in a V-tail aircraft.

Here's an example image.

Ah. THAT I get. I won't be able to do much to make the throttle behave itself except perhaps change the return value for it in the animation, but the clamping for animation variables? That I can do easy enough. I already have such a system in place for the instruments. Shouldn't be hard to extend it to the rotations and translations.

For the throttle, just make it return a fixed small value whenever reverse thrust is active. Or add a clamp for translations as well as rotations, like I suggested. Again, separate clamps for positive and negative animations would be beneficial.

So I just realized I derped. The throttle wouldn't have any issues since its variable is always positive. The control I was actually talking about was the pitch control. Everything still applies, just replace everywhere you see "throttle" with pitch control.

So I decided to test these today and they don't work. Behavior is exactly the same as before. Either I'm doing it wrong, or you coded it wrong, both of which are equally likely. I took a look in the code and it appears that you're only factoring in the variable that the rotation clamp is attached to, which obviously wouldn't do anything. The entire issue is that multiple variables add up to make the elevator move too far.

Well, the big issue is each JSON rotation is applied in sequence. There's no way to clamp the entire rotation if you have two entries as they're not applied at the same time, so MTS has no way to know what it needs to do. So while I coded it as correct as I could, I realize now it actually doesn't fix your issue. That being said, I don't have a good way to fix such an issue without significant overhauling of code, and I ain't gonna do that for a small rotation thing. Especially since I keep getting complaints when I re-do rotation systems to get towards new animation code.

Well darn... sorry for wasting your time. Guess I have an excuse to make a conventional-tailed Leone now, just so that it'll look right...

Eh, it's not a waste. I already had the clamp in for the instruments with the new code, so adding the clamp for each rotation wasn't hard. Nor will it be a waste for some things like the throttles you mentioned. Perhaps when I do the custom animations I'll be able to support a double-rotation clamp. Though let me take a second look to see if I can make MTS "cache" the rotations is has applied to a object. I might be able to make it smart enough to apply a clamp if it sees the rotation being performed has already been performed on the same part and axis, and know to clamp it by the remainder of the prior rotation. Would require you to put the rotations sequential in order in the JSON, but it might be do-able.

Actually it's not really very useful for the throttles at all, since throttle only goes from 0 to 1 and thus won't overflow. I needed it for the pitch control, actually, but since you have it so that the clamp is the same positive and negative it won't work. I need the pitch control to be able to move a good distance forwards but not backwards.

I could switch it to positive and negative, though that'd require a re-do the instrument clamping already in place to have it do double-clamping. If I do that, then I'll be taking into account the rotationOffset portion of the rotation in the clamp.

Doesn't sound too hard, but don't quote me on that. You're the code guy, after all.

Just means I'll have to re-do some instrument JSON parameters in the OCP, but that's not released yet so it won't be too bad.

Took a few beatings, but got it in V17.1.0.