[RESOLVED] Axis-Limited RCS - Not responding after control transform change

[Shadowmage]

Hi all,

I have a few parts where I have multiple RCS modules on the part; each module is limited to input from specific axis through the RCSModule.enableXXX config fields.  This is done so that specific RCS blocks only fire when they are supposed to / fire only for their specific input (e.g. to stop angled pitch thrusters that might try and fire for yaw or translation commands).  Mostly used on service modules and command pods so far. 

This all works great.... until you set a custom control transform for the vessel.  As soon as you switch control transforms to one that is not aligned perfectly with the parts default control transform, most of the RCS ports stop responding;  this is because they are 'seeing' a different input axis being passed in -- an input axis relative to the vessels current control transform rather than relative to the parts orientation.

Now, I can manually remap the 'enableXXX' fields in the ModuleRCS for various control inputs -- if I had a way to tell when the control transform has changed.  Is anyone aware of a vessel event that is fired when the vessels control transform is set or changed?  I tried subscribing to nearly every event and never got any hits from changing transforms....  (even if I do this, I still would only be able to handle axis-aligned transforms; anything that was not on 90' angles to the part would not work out properly...)

Alternatively, it would be nice if the RCS module code responsible for this were 'fixed', so that it respected the -parts- orientation rather than the vessels orientation.  Or at least a bool in the module so that they can be setup to use that method.

 

In the end, the question comes down to -- how to fix the stock RCS module so that it respects the part-relative-input axis rather than control-transform-relative? (e.g. the actual transform should be ..transformed.. relative to the parts transform, so that the vessel-relative input (pitch) is seen by the RCS module as a part-relative input (yaw))

Edited March 18, 2016 by Shadowmage

[sarbian]

Did you try to use 1 RCS module with more transforms ? AFAIK there is not limit in the number of RCS transform on one model

[Shadowmage]

That was the original setup.. which... works... sloppily.  Many of the RCS transforms would respond to incorrect inputs (though, correct as far as the part/module are concerned), which would result in unwanted translation during rotation, or unwanted rotation during translation.

Which is why I split the transforms up to be controlled by different RCS modules with per-axis-input limiting.  So a set of transforms that should only respond to a 'translate forward' command will not respond to a yaw or roll command, and vice-versa.  This fixed up the inputs and allowed for a balanced RCS setup for the parts, as long as the vessel is controlled from the proper part/transform orientation.

For example, take the Orion ESM:

 

With a default stock setup (all transforms controlled by a single module) the bottom-most RCS quads (pitch/yaw quads) on this part will respond to translation inputs as well as pitch/yaw inputs-- which is undesired, and results in incorrect rotation for a translation input; those bottom blocks are not intended for translation, but rotation only, and should not respond to translation inputs at all.  The same happens to the roll/translation blocks on the upper/middle of the SM -- they will respond to yaw and/or pitch inputs incorrectly (they should only respond to translation and roll inputs).

So.. the multi-RCS-module setup fixes all those problems, but exposes the new problem of lack of proper input/response when the control transform is changed away from the part default transform.

Edited March 17, 2016 by Shadowmage

[NathanKell]

The stock code now is basically identical to my ModuleRCS fork if you want to dig into that.

That said, I'm not sure I'm understanding the problem. The issue is that you want an RCS port to only fire along a fixed axis of actuation, regardless of whether that is pitch, yaw, or half-n-half at a given time (due to reference transform shifts)? That would need a completely different setup, and ask @ferram4 how hard it is to determine the main axis of a vessel.

[Shadowmage]

It comes down to after a control-transform change, an RCS port that should only fire for 'yaw' input may not have any thrust transforms that are actually aligned for the new 'yaw' direction for the vessel.

I'm encountering this on a low-part shuttle fuselage with integrated docking port, where the RCS are setup for axis-limitation for the normal flight-direction.  If you switch to the docking ports control transform, the RCS that are labeled to respond to Y+/- translation input are now oriented towards the vessels Z+/- translation axis;  however, they will not respond to input for Z+/- translation.

 

 

The highlighted RCS thrusters are set to respond to only Y+/- input for translation, and pitch for rotation. (light blue arrows from RCSBuildAid)

Picture 1: default control transform.  The thrusters are oriented along vessel Y+/- (blue), and respond properly to input for Y translation or pitch (w/s / i/k input keys).
(note that parts align with Y=vessel forward, vessel aligns with Z=vessel forward; so in the images blue corresponds to vessel Y+ and green to vessel Z+)

 

Picture 2: controlled from docking port.  Thrusters are now oriented along the vessel Z+/- (green), but do not respond to input for Z translation (as they are set to only respond to Y translation).  They do still respond to pitch input.  They also no longer effectively respond to Y translation input, as they are now actually oriented Z+/-.

 

Some (or all?) of this might actually come down to the fact that I'm changing the reference transform for the single part fuselage from its normal transform due to the integrated docking port (docking port has a custom control transform specified); so I will do some investigation to see if the problem persists from an external docking port part.  The solution to that might be a bit simpler (reading through the posted code now), though I still don't think I can work around it on my end.

Edit:  The problem persists regardless of if I use the integrated docking port or one as an attached part; as soon as the vessel-control transform changes the RCS stop responding to input as per above.

 

But yeah, I understand the... fun... of different reference frames.  It took me awhile just to get my head around what was actually going on that could cause this problem, and how to visualize it properly in some manner that would make sense.  I even got about halfway through writing a module that would re-map the RCS module's enableXXX flags based on the current control relative to vessel control but then hit the question of 'how to handle a non-axis aligned transform?' (e.g. rotated 15' on an axis relative to the parts default transform);  I couldn't think of a way other than 'enable everything that faces even partially in the right direction'... which is mostly what the stock module already does when the input is not limited by config settings.

 

Edited March 18, 2016 by Shadowmage

[NathanKell]

Yep, exactly. I don't have any bright ideas either there, I'm sorry to say. And besides, if I added a flag to use vesselTransform instead of ReferenceTransfrom, then what you got when you hit pitch wouldn't actually be pitch if those transforms didn't align! (i.e. doing it without a rotation to the new space). The alternative (doing the rotation) would be as you say: actuate if the dot is >0, but then axis-limiting isn't doing you much good.

[Shadowmage]

No worries, and thanks for your input and information

I tend to push the boundaries of what the game can do given its intended setup, so I expect to run into unworkable stuff once in awhile.  I've a couple other ideas for that part that might alleviate the problems -- such as...I don't think I actually need the axis limiting on that part.  It'll have some pitch and/or yaw component with roll input, but it already has some roll with the yaw due to the thruster locations.. so a bit more off balance would probably not even be noticeable.

Marking as resolved for now, and I'll keep in mind the limitations of the RCS-axis-limiting stuff when designing future parts.

[NathanKell]

In the very, very special case where axes _are_ aligned, i.e. your example where roll is swapped with yaw, you can get away with doing things that way. And I can certainly add an event for reference transform switch.

[Shadowmage]

22 minutes ago, NathanKell said:

In the very, very special case where axes _are_ aligned, i.e. your example where roll is swapped with yaw, you can get away with doing things that way. And I can certainly add an event for reference transform switch.

The event would likely be useful more generically/applicable to more mods/situations; likely a few others would get use out of it as well (contrast to the RCS stuff... where as far as I know I'm the only one using those features).

So, aye, if you add that event I'll take another look over the RCS/control swapping stuff after/during the 1.1 update

[NathanKell]

Ok. This will now fire an event showing the old transform and the new transform. However due to how vessel stores the old transform, in the case where the old transform and new transform are on the same part, all you'll get will be two references to the new transform. You'll still know it's happening though.

[Shadowmage]

1 minute ago, NathanKell said:

Ok. This will now fire an event showing the old transform and the new transform. However due to how vessel stores the old transform, in the case where the old transform and new transform are on the same part, all you'll get will be two references to the new transform. You'll still know it's happening though.

Awesome, the event triggering is all I would need.  Technically it could be done through per-tick polling... but I generally reserve that for where absolutely necessary.

So, thanks, much appreciated

[Jso]

Couldn't you stash a copy of the transform away on initialization and compare that to the new transform when the event fires? Then assuming it's a 90 degree rotation remap the appropriate enableXYZ fields.