Psycho_zs

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?

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.