Psycho_zs

Yes, that is why these edges need to be small. Their point would be to cover any slight inconsistencies in diameter without a rough flange sticking out. if calculations were to start from the edge, it would become trickier to make the shroud flush.

No, see the edit of my previous message.

I had a different concept of bent edges in mind, more cosmetic: add them to existing cylinder/cone and protrude inward. So top and bottom diameter would be of the rib, not the bent edge itself. / \ < this bit is added | | < top diameter and upper node here | | | | | | < the main shroud stays the same | | | | | | < bottom diameter and base here \ / < this bit is added

Maybe start with 45 degree edges about 0.2-0.3 units in length (for 1.25 diameter, maybe scale with size), predefined. IMHO, it's better to find some predefined value and stick with it If it handles well, otherwise it might overcomplicate things. Suddenly, I also can not reproduce it. I used stock FL-T400>Terrier>TR18-A.

Another ideas to investigate: Make a virtual strut from decoupler to the part on which the shroud conlcudes (akin stock grandparent autostrut, but this part may not always be grandparent) Maybe it is possible to somehow hook generated shroud to stock ModuleJettison to make it jettisonable. If you ever decide to give shroud a concave collider, align collider's inner surface with shroud's outer surface. Otherwise engine colliders might not fit inside. 64 sides setting does not play well with most existing parts which have 24. When I use stock 1.25 decoupler, shroud's bottom is slightly smaller than top, despite both saying 1.25. (current github version) BTW, bottom 1.32 may look cooler on this decoupler. (see my previous screenshot of the release version) Any news on bent edges? They would come handy on size 0 decouplers.

Exactly. Is defaultVertOffset applied before or after auto shape?

No, I wanted to combine it with fairings, but that does not stage well. I'm removing engine shouds.

Well, I'm planning to go all in: @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@MODULE[ModuleJettison]]:FINAL { !MODULE[ModuleJettison]{} } Some defaults would be handy. Like enabling shrouds by default on decouplers, or adjusting decoupler-facing diameter. I meant just this. I've just went and actually checked it. BTW, you could increase the margin of error if you bend the ends of the shroud a bit inwards.

Stock fairing+decouler doesn't work well. Staging problems. What parameters does ModuleDecouplerShroud have?

What stock mechanisms are used? I wonder if it is possible to hook up stock fairings into this. Like add fairing module to decouplers, autocalculate initial shape, use stock mechanisms for further customization and ejection.

Is it possible to adjust some defaults through MM? like bottom diameter and vertical offset?

That looks amazing. Shrouds should have been a part of a decoupler right from the start ) What does the algoritm do? Hops over a part and looks for the next node size?

Throttle limit would affect calculations in other parts of the game and mods, because minThrust value is stock. It also would automatically fix slider issue. Offtopic:

That would be the point. Also, thrust limiter slider on the engines overrides minThrottle limit.

Yes. I've just re-checked on a clean KSP to be sure. I know, that was a part of my question.

It seems that when I start an engine with staging it gets stock thrust per throttle even if it is below the limit, until throttle is changed. BTW, what is the reasoning behind this design decision of using custom minThrottle parameter in ThrottleLimiterModule? Is it possible to use stock minThrust parameter and stretch the thrust with custom module? Purely theoretically it might mess less with various calculations, i.e. in Kerbal Engineer.

This is funny, both times I bumped into the ship by flying "up"

ThrottleLimiterModule.CheckThrust: part; LV-303 "Pug" Liquid Fuel Engine, stv: decrease ThrottleLimiterModule.CheckThrust: part; LV-303 "Pug" Liquid Fuel Engine, stv: off ThrottleLimiterModule.CheckThrust: part; LV-303 "Pug" Liquid Fuel Engine, stv: off Just reproduced it again. This was in the log in the moment of ignition. Simple craft: mk1 pod, FL-T100, Pug. (from overhauls). Throttle was cut off by pressing X. More precisely, engine starts when I bump the craft with a kerbal, not when I let go of the hatch. Among other mods there are RealPlume/Smokescreen. These have a history of messing with engines in weird way. Will try on stock soon... ...Yep, same thing on stock game + TLE. Mk1 Pod, FL-T100, Terrier. The craft is scared of bumping it with a helmet and flies away. Similar messages in the log.

Well, I went on EVA, let go of the ladder and the ship turned the engine on and flew away.

So, a while ago I posted a message about stock monoprop tank and certain heavy RCS thrusters wanting to be put together... Here is a config that makes it happen.

Well, time to start a new career...

A nested selector then, something like that? @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],#minThrust[0]]]:FINAL { vacKey = #$atmosphereCurve/0,[0, ]$ seaKey = #$atmosphereCurve/1,[0, ]$ @MODULE[ModuleEngines*]:HAS[#../vacKey[0],#../seaKey[1]] { ... } }

If I can not extract by value, then I will just filter out potential weird curves. How do I use a curve value in selector? With a second set of brackets for value? @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],#minThrust[0],#atmosphereCurve/key,0[0, ][0],#atmosphereCurve/key,1[0, ][1]]]:FINAL

Returned to the thrust lock conflict and got the culprit on second try: SmokeScreen and RealPlume. Not yet, I took more stock approach for now. You can find my MM config in that thread.

My previous statement that the mod affects kerbals on EVA is false. Totally unrelated coincidental thing. Haven't tested for mod conflicts yet, unfortunately. I am currently experimenting with limited throttle depth by tweaking minThrust and found out that DavonTC seems to ignore it. When enabled, engines with non-zero minThrust can be throttled past it down to 0.