Psycho_zs

Whoa, how is that supposed to work? nodeType is a value, so it should be #nodeType. Anyway, I've checked your syntax with both #nodeType and @nodeType. I've also used "size1|size2" selector, but nodes with size0 were also affected, so something is wrong here.

Yes it is, this syntax is correct from the hierarchal standpoint. I want to select only stock-compatible docking ports.

Hi! I'm trying to use this selector: @PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#nodeType[size0|size1|size2]]] It does not work. The problem seems to be in "size0|size1|size2" part. Is this a bug, or OR is not supported in HAS values by design?

An update for angled docking patch: instead of targeting specific parts, target ModuleDockingNode's nodeType (by stock values): // Add angle snapping to Docking ports with stock nodeType values (12 increments as on textures) // Author: Psycho_zs @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @MODULE[ModuleDockingNode]:HAS[#nodeType[size0]],* { // If you want X degrees wide margin, use cos(0.5*X) as captureMinRollDot // 0.5 degrees = 0.99999048 // 1 degree = 0.99996192 // 2 degrees = 0.9998477 // 3 degrees = 0.99965732 // 5 degrees = 0.99904822 %captureMinRollDot:NEEDS[!DockRotate] = 0.99996192 // more relaxed version to use with DockRotate %captureMinRollDot:NEEDS[DockRotate] = 0.99904822 %snapRotation = true %snapOffset = 30 } @MODULE[ModuleDockingNode]:HAS[#nodeType[size1]],* { %captureMinRollDot:NEEDS[!DockRotate] = 0.99996192 %captureMinRollDot:NEEDS[DockRotate] = 0.99904822 %snapRotation = true %snapOffset = 30 } @MODULE[ModuleDockingNode]:HAS[#nodeType[size2]],* { %captureMinRollDot:NEEDS[!DockRotate] = 0.99996192 %captureMinRollDot:NEEDS[DockRotate] = 0.99904822 %snapRotation = true %snapOffset = 30 } } First, It is logical to target nodeType since it kinda represents a mechanical standard . Second, this patch will also affect any mod stock-compatible docking port, so compatibility is preserved. Also added a version to go with the great DockRotate mod (It adds ability to rotate docking ports in-flight and auto-straightens angle-locked ports): Edit: There seems to be a problem with selector "size0|size1|size2" inside HAS, so I've expanded it into multiple node statements. ",*" should help with "universal" docking ports that have multiple nodes of different types.

A step towards the universal node rotator

Brilliant!

Is there / will there be a full documentation on ModulePartVariants?

Jumbo tank has 'sideTubes = true' object in orange variant, but I do not see any geometry changes when switching themes on this tank. Is this a bug?

Sadly, not even close. Not enough of those sharp cracks and low pitched rumble that shadows them with amplitude pulses. BTW it is also used in RealPlume.

Re: engine sounds This should be stock

Good news. @NecroBones just released Fuel Tanks Plus fully converted to stock mesh switching. From what I can see, (in FTP case) it is a simple boolean list of objects in each variant. I also messed around with config a bit, multiple instances of ModulePartVariant give multiple selectors for a part, and as long as variants in instances do not contradict each other, those selectors are independent. Judging from Making History previews it is also possible to manipulate stack nodes, but I've seen no config examples as of yet.

Offtopic: how does triple joint work? Is it just a triple-strength joint, or three actual joints, do they have geometric offset?

Down with the endcaps. Partcount isn't worth the trouble.

Congrats with new release! Is custom node selection going to make its way into your TODO?

Do these shrouds work correctly with FAR? It seems, FAR does not voxelize them, at least judging by debug in VAB. I only know how to exclude part from FAR calculations by removing GeometryPartModule Maybe some kind of reverse action would help.

BTW, it would be logical to treat multidock situations with unrestricted ports similar to restricted ports, only in this case snap to angle that would put secondary pairs into the best possible alignment.

Judging by angle readout, snap usually misses by 0.02 degrees. I've also tested multidock with two pairs of ports. On one attempt vessels docked successfully, with the second pair of ports was slightly misaligned (although connected). Usual Stock situation. Trying to rotate to snap on primary pair didn't work. Perhaps, multidock ability also requires suppressing and reinstatement . On second multidock attempt I've got logspam from DockRotate: "advancedRotation() called on wrong module, ignoring". Undocking didn't stop it.

Looking good. So, the next step would be to disable controls on strict ports... Unrelated tricky bugs: if you set step to 0, press rotate to snap, it will start rotating very slowly. If you undock while it rotates, there would be a spam of NullRefs. But I couldn't reproduce it reliably more than two times.

This reminded me...

Ah, KSP, the pinnacle of elegance!

I thought more of non-interactive mandatory "rotate to snap" in case of restricted ports. My patch is just an example of stock feature usage. You have a module that gives ability to rotate nodes. It has enormous potential if its usage would be determined by MM patches. Consider a couple of changes to the module: add 'rotateNode' parameter that would allow to manually select a specific node of the part. By default it would get value from ModuleDockingNode/referenceAttachNode if present. If part has ModuleDockingNode/snapRotation = true, rotation would become non-interactive automatic snapping to the nearest ModuleDockingNode/snapOffset simulating a realistic docking port. Default patch would do just what it does now: add free rotation ability to docking ports. But more advanced usage would be possible by adding optional MM patches. Like making realistic docking ports, or creating re-purposed parts for acting like rotational actuators. I would gladly use a patch to copy FL-A10 Adapter and turn it into a rotating base by applying ModuleDockRotate with rotateNode=bottom.

Great mod! But a bit cheaty for my taste. On the other hand, I see huge potential for more realism here. Stock docking module has angle restrictions. You can see my MM patch here under "Angled Docking Ability": But stock does not snap, it only restricts ranges at which docking can occur. So if you set a 1 degree margin and dock at 0.7 degree offset, that's it, your ship is twisted by 0.7 degrees. If you set a very thin margin, it becomes near impossible to dock. Mechanically it does not make much sense, since IRL docking latches would probably do the actual snapping-to-correct-angle work. So, my suggestion: realism mode. If a port has stock snapping enabled, disable arbitrary rotation, but autocorrect angle upon docking. This would make possible to set wider magin in captureMinRollDot. (i wonder if multiport docking would work if actual docking occurred with ports misaligned and corrected later). Maybe a separate angle autocorrector module? It could be assigned via MM on parts that have 'snapRotation = true'.

Everything looks great. I've adjusted some numbers in the pull request. Also I changed size0 snap to 0.63, since it is impossible to get 0.625 from menu. Another thing: some parts have cylinders exactly the right diameter. (Poodle for example), this results in z-fighting. Perhaps now that we have bevels it is feasible to place outer texture some 0.002 units further outwards than chosen diameter.

Looks great. Those size 0 decouplers are less than 0.625, so both 0.62 and 0.63 shroud look better with that bent edge. If there were a small bevel on the top, it would fit nicely if snapped to 0.63

Loading the game now... How about a bevel 1/2 or 1/3 of shroud thickness on top?