Right now the Auto Decouple feature is controlled by a timer if I am not wrong. Which might lead to RUD if the burn time is higher than the time which is set in the config and the interstage tries to leave in the wrong direction.

Maybe a feature like checking if the solid fuel is spent, then engage auto decouple or setting a manual timer in the RCM in the VAB might be possible?

They already use the fuel to determine when to decouple (when set to auto). The timer is in addition to the fuel checks.

https://github.com/shadowmage45/SSTULabs/blob/master/Source/Module/SSTUInterstageDecoupler.cs#L434-L457

Right now what happens is, if auto-decouple is enabled, it will check each tick to see if there is fuel remaining. If fuel is still there, it does nothing. Once fuel is depleted it initializes a countdown timer, based on config setting. Once this timer has elapsed, then it will proceed with decoupling.

So, if I'm understanding your request correctly... that mechanism is already in place.

Sorry from my side, this behaviour gets somehow overwritten in RO and I won't ask any further as I know there's no RO support from your side, so I'll see and try to fix it. Sorry again.
(Although it shouldn't break as the only thing MM changes in RO for this specific part are some diameter definitons, it still uses Solid Fuel, will investigate)

In stock it works as intended, I still think the manual timer setting in the RM might be a nice feature to consider in the future. Right now it seems a little long.

I'll close this later if you want, my phone is doing hickups..

Go ahead and leave it open, as the RO problem reminds me of something I do need to fix :)

Currently I believe it is hard-coded to look for SolidFuel as the resource; RO tends to be heavy-handed with its patches and has likely replaced this with HTPB or other solid fuel... which of course screws up the resource-monitoring.

What I can do to fix this problem is to allow config-specification of the fuel type to look for, by simple fuel name. E.G.:

resourceName = SolidFuel

or

resourceName = HTPB

Hmm.. strange. Looking again at the code, it is not hard-coded for a specific fuel-type, but rather relies on the engine modules 'flameout' status.

Nor am I seeing any RO related patches specifically for that part, so I'm not quite sure how the config is getting manipulated. Any idea what patches are affecting it?

Will attempt to do some investigation on this in the future, but no idea on what kind of time-scale it will be happening.

Shadowmage,

that's the thing - It's not changed by RO to another resource. The whole part is OP as hell anyways which can be adressed by RO community - the only thing we manipulate are these:

`
@part[SSTU-SC-GEN-ISDC]:AFTER[SSTU]
{
%RSSROConfig = True

@MODULE[SSTUInterstageDecoupler]
{
    @minDiameter = 0.5
    @maxDiameter = 20
    @maxHeight = 15
    @diameterIncrement = 0.5
    @heightIncrement = 0.5
}

}

Do the triggers appear in the logs? I can test fly a vessel with auto decouple on look for hints and upload.
`

Interesting. It might come down to differences between the stock engine module and the real-fuels engine module (which I believe is generically added to all engine-enabled parts through a separate RO patch).

But from looking at the code... it -should- work even with ModuleEnginesRF... unless it is doing something weird regarding the flamout status for that module. I'll see about taking a look over the RF code.

Sadly this will likely have to wait until I have time to do RO testing again, which might be awhile.

Well, I just looked. We have Ullage Constructor called onto the part but that's not the issue.

FAR causes the known NRE exception spam onto this part, as well. Maybe that's it, going to test it.

• EDIT - No, still works. I'm gonna dig further. Thanks anyways!

Yes I think I found it.

@PART[*]:HAS[@MODULE[ModuleEngines],#RSSROConfig[*]]:FINAL { @MODULE[ModuleEngines],* { @name = ModuleEnginesRF } }

(- same for ModuleEnginesFX)

is added to any part with ModuleEngines, the ISDC has this aswell, but the AutoDecouple logic calls the now obsolete ModuleEngines?

It uses polymorphism to use the most generic base class with the features it needs, which is ModuleEngines. It should still properly access ModuleEnginesFX or ModuleEnginesRF if they are on the part instead; all it looks for is something derived from ModuleEngines.