Psycho_zs

OK, it's somewhat salvageable. Anybody knows the correct syntax for adding a bumpmap? ...on the other hand, it won't be much visible.

Well, it looks like excrements. I'll probably try to bake something in Blender some day. But you get the idea: Edit: forum autoreplacer is hilarious.

ok, let's worry about clickability later. You can make an example patch that modifies existing BZ-52. I'll experiment with retexturing in a day or so, we'll see where that can lead.

In case of BZ-52, it may be hard to click on it in some situations.

BTW about DockRotate, is there a config switch for restricting manual control (for use with angled ports)?

So rotation controls would be available on both sides of the joint, is that correct? Then, let's target BZ-52, copy it, and place motor on the top node. Is physical insignificance ok for a motor?

Today I learned that stock BZ-52 attachment point has 'PhysicsSignificance = 1' effectively saving physical part count. IMHO doing that for other attachment points would be logical.

I thought of it too, haven't decided what is better yet. What would be a preferable configuration: motor is fixed to the parent part (attachment point variant), or motor rotates against the parent part (adapter variant)? New parts can be created by combining existing models in MM patch, like this. I can draw a new texture for BZ-52. We can make a patch that would create 2 new parts with BZ-52 model and the new texture: one in the original 1,25m size, the other x0.5 size for small things.

I can't find the revised stock docking port everybody is talking about. Oh, it's in SSPXr...

Linear ports are great! Even greater with DockRotate mod's auto-straighting feature. Here is a patch to relax capture restrictions up to 5 degrees in this case: @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @MODULE[ModuleDockingNode]:HAS[#nodeType[linear1]],* { %captureMinRollDot:NEEDS[DockRotate] = 0.99904822 } @MODULE[ModuleDockingNode]:HAS[#nodeType[linear2]],* { %captureMinRollDot:NEEDS[DockRotate] = 0.99904822 } } Cubic family struts seem to have misaligned nodes or models. There are gaps between them. Most noticeably on one end of Cubic-Family Large Strut:

Would you kindly consider this?

No escape from manual work... BTW, with this amount of repeated action it might be more optimal to mark modules with some variable first, and then assign actual configs based on that mark. like this: @PART[engine1|engine2|lots|of|other|engines|] { throttleProfile = shallow } @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer]],!MODULE[ThrottleLimiterModule],#tags[*land*]] { throttleProfile = deep } @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer]],!MODULE[ThrottleLimiterModule],#tags[*sustain*]] { throttleProfile = shallow } ... ... // lots of other markings ... ... @PART[*]:HAS[#throttleProfile[shallow]] { @description ^= :(.)$:$0 Shallow throttle; minThrust down to 80% of maxThrust.: MODULE { name = EngineAGThrottleModule } MODULE { name = ThrottleLimiterModule minThrottle = .80 // 0 to 100 } } @PART[*]:HAS[#throttleProfile[deep]] { @description ^= :(.)$:$0 Deep throttle; minThrust down to 20% of maxThrust.: MODULE { name = EngineAGThrottleModule } MODULE { name = ThrottleLimiterModule minThrottle = .20 // 0 to 100 } } // remove markers @PART[*]:HAS[#throttleProfile] { !throttleProfile } Or even mark with throttle coefficient right away and match :HAS[#throttleDepth[>.35],#throttleDepth[<.65]] as medium (for different descriptions)

That mod is irrelevant. The point is not to set minThrust to 0 (like by not applying the patch). The point is to shut down engines that have minThrust > 0. One way to do it is to dynamically set minThrust to 0 when ship's throttle is 0 and revert the value when throttle is not 0. This can not be done by MM patch.

How much hassle would it be to account for possibility of minThrust changing at runtime? There is a plugin that uses this trick to allow shutting down engines with non-zero minThrust: https://forum.kerbalspaceprogram.com/index.php?/topic/173478-minthrust-handling-request/ But it does not work while DTC is in control.

Modded. Like by this kind of patch. You missed the point.

Have you looked into my "Isp gap" method?

Is it possible to enable/disable attachment node?

To apply a theme you have to click on a tiny icon inside a theme item.

Variants can be associated with common themes. A theme can then be selected in VAB's advanced categories and applied to all parts that have variants marked with such theme. Also, multiple ModulePartVariants instances per part give multiple selectors (or has something changed in 1.4.2?)

Hello everyone! Since Squad hasn't yet addressed the problem with minThrust handling (engines with minThrust > 0 can not be shut down by throttle, complex bug report is here) , I would like to request the simplest possible mod solution that does just that without affecting anything else. A good starting point would be ThrottleControlledShutdown plugin by @NotTheRealRMS which dynamically sets engine's minThrust to 0 when ship's throttle is 0. Maybe someone would be kind enough to refurbish and clean this thing up, (i.e. 'foreach' are bad as far as I heard). Or maybe there is a better way to solve the problem altogether. Edit: this plugin works in 1.4.2. Although it sometimes lags behind throttle and other ships coming into physics bubble may have their engines unaffected and therefore ignited.

@Kerbas_ad_astra Are you sure that tag selection works? I recently found out the hard way that OR operator ("|") does not work in HAS blocks.

Cool! I haven't tested anything yet, but is there any progress on resolving conflict with SmokeScreen/RealPlume? Edit: on first glance I do not see throttle lock problem anymore with SS/RP installed.

Essential and on-point stuff. Sounds great!

That's what I ended up with for now:

nodeType is inside ModuleDockingNode. With this selector it would probe for it in root.