wookiee_goldberg

Do you have the Kopernicus mod installed? I think that's the issue (Kopernicus adds the "relative/absolute exposure" and "change tracking body" buttons into the solar panel RMB menu). There's some discussion about solar panel stuff in this thread ->

you might have mentally combined the "... will be available in every gameplay mode as long as you have MH installed" (which only applies to the Dessert launch site) with the idea of the water-based launch pads

probably the physics term "Moment Of Inertia"

yeah that seemed to fix it, thanks

I downloaded the new version but my changes don't seem to have made it into the freedom file. It's there in the "source code" zip from github (and I saw that you merged/closed my PR), but not the main "ConnectedLivingSpace.1.2.6.0_04092018.zip" file for the mod content.

The 'variant' code exists in other non-DLC parts in 1.4 as well (like the skin-switcher for the fuel tanks), just none of those non-DLC parts matter for this mod, that I'm aware of, since the only engines and decouplers that change depending on variant are DLC parts. So he can still use fuel tank configs for research and debug logs in the meantime, to get a feel for how to detect variants, and then apply that knowledge to the length-switcher variant logic in the engines/plates for the DLC-support code.

Nobody should be under the impression that the DLC is required for the mod to work. The mod isn't even fully supportive of the DLC yet (the mod ignores EnginePlate parts for now), and even when it is, that will be "in-addition-to" the existing non-DLC support; it's not an "either/or" situation. So the 'designed to work with dlc but may work without' disclaimer you requested really isn't accurate to the present or future of the mod, it's just far more effective to put the DLC-specific code into the main mod instead of forking it into two separate mods (one with DLC support and one without). He's not distributing any unnecessary assets - the only assets included are the texture and normal-map for the shroud, which are different from any of the ones included in the game itself. The stuff you see in DecouplerShroud.cfg does not include any assets, it's just condition-handling code (a list of known parts and their associated default parameters). Compare the complete Squad-provided config file for the now-obsolete (pre-1.4) TR-XL Stack Separator with the corresponding code in the DecouplerShroud.cfg file: @PART[stackSeparatorBig]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 2.5 %defaultVertOffset = -0.01 %nSides = 24 %defaultThickness = 0.15 %bottomEdgeSize = .12 %topBevelSize = .04 } } All that the mod's configs do is allow pre-defined sizing/positioning parameters for the shroud-building code, instead of falling back to the "best guess" code - code which doesn't necessarily guess correctly, as you can see in the imgur album I posted with my config updates for the DLC conventional decouplers/separators. Compatibility for any HAS[@MODULE[ModuleDecouple]] part could be added this way, like parts from other mods, if those modders (or other community members) create the relevant configs and submit them to the navot. You actually see this quite a lot in the KSP community, for example there's a whole load of other-mod configs in ConnectedLivingSpace's configs folder for inter-mod compatibility. As for the pending DLC-specific support (engine plate compatibility), the idea is that the isEnginePlate variable will be false by default for unknown parts, and false in the config file for all base-game stock parts as well as all the currently-included (normal decoupler) DLC parts. When it's false, the mod will behave the same way it already does, so non-DLC players won't notice a thing. The only time it will be true is for config-file-specified DLC engine plates, so that's the only time the new functionality will be seen.

I submitted a pull request for updating the "Freedom" file with the 1.4 (base and MH) equivalents of the existing parts. It's my first time using github and only my second time contributing to a mod but I hope I did the process correctly, and if not, constructive criticism is fine.

The plate names are: EnginePlate1p5 EnginePlate2 EnginePlate3 EnginePlate4 The way that the plates drop their fairing is by using a jettison module (almost identical to the one in, for example, the stock LV-T45 engine): // LV-T45 engine, as an example MODULE { name = ModuleJettison jettisonName = fairing bottomNodeName = bottom isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 5 jettisonDirection = 0 0 1 } // engine plate also has these 2 additional parameters in the module stagingEnabled = false useMultipleDragCubes = false I plan to play with this some to see if i can at least get the EP fairings to behave properly, even if their size is horribly wrong. As for how to do the sizing, I was thinking if you add a boolean for "%isEnginePlate = true/false" and assume "false" if no part-specific answer is provided. And changing the names of bottom/top variables to base/remote, respectively, and then let the plugin assign top-ness and bottom-ness based on the value of "%isEnginePlate". %defaultBotWidth -> %defaultBaseWidth %bottomEdgeSize -> %baseEdgeSize %topBevelSize -> %remoteBevelSize That way the "base" size will always be the size of the decoupler/plate itself, and the "remote" size will always be the one you fetch from other parts. And perhaps also for "%isEnginePlate" to inverse the directions of height and vertical offset such that a positive value is always "away from the base, towards the remote", rather than "from bottom to top". For the height, you only have to check against the decoupler itself, rather than worrying about what's attached to it. I'm not sure if i'm actually allowed to copy/paste large sections of the stock configs to someone who doesn't own the DLC though (as one could do for base-game parts), but I'm gonna read through your existing code and try and get an idea how this stuff works so I can maybe provide some better info about that part of it. Or maybe I'll actually learn C# in the process, who knows... I've done some programming before, bash scripts, a tiny bit of JS, and some VisualBasic 6/.Net back in the day... and your code is already developed enough I might be able to figure out its workings just by reading through it.

Hi, I noticed that part-specific configs for the DLC parts were missing (resulting in auto-size shrouds having a BotWidth only 25% the size it ought to be for the 1.875m and 5.0m decoupler/separator parts) so sorted the base-game parts' configs by size and then added the DLC part configs beneath those, for aforementioned parts as well as the 1.875m strut type (Soyuz-interstage analogue) decoupler. The default thickness 0.08 for the strut-style 1.875m decoupler was because anything larger resulted in see-thru gaps when looking up from below (seeing inside the structure of your shroud, I guess) so I decreased that until the effect stopped happening -- though if your shrouds had a bottom surface like they have a top surface, then this effect could be solved that way too. For the normal 1.875m and 5.0m parts I used a thickness more fitting with the steadily-increasing values seen in the rest of the size series. Below is the full text of my version of 'DecouplerShroud.cfg' if you want to sanity check it: @PART[*]:FOR[DecouplerShroud]:HAS[@MODULE[ModuleDecouple]] { MODULE { name = ModuleDecouplerShroud //Amount of faces every cylinder of the shroud has nSides = 24 //If the shroud is enabled by default shroudEnabled = false //If size detection is on by default autoDetectSize = true //Default Thickness defaultThickness = 0.15 //Default bottom width for auto detecting size //0: checks the collider size // != 0: value will be default bottom radius defaultBotWidth = 0 //Default vertical offset for auto detecting size defaultVertOffset = 0 //Default texture that will be used textureIndex = 1 //Error margin for snapping to standard size (as percentage of the radial size) radialSnapMargin = .05 //Size of the bottom Edge bottomEdgeSize = .1 //Size of the top bevel topBevelSize = .05 //Size increase to top and bottom radius to avoid Z-Fighting antiZFightSizeIncrease = 0.01 } } // CONFIGS FOR 'Squad' PARTS @PART[Decoupler_0]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 0.63 %defaultVertOffset = 0.01 %nSides = 24 %defaultThickness = 0.08 %bottomEdgeSize = .05 %topBevelSize = .02 } } @PART[Separator_0]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 0.63 %defaultVertOffset = 0.01 %nSides = 24 %defaultThickness = 0.08 %bottomEdgeSize = .05 %topBevelSize = .02 } } @PART[Decoupler_1]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 1.25 %defaultVertOffset = 0.06 %nSides = 24 %defaultThickness = 0.12 %bottomEdgeSize = .08 %topBevelSize = .03 } } @PART[Separator_1]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 1.25 %defaultVertOffset = 0.0 %nSides = 24 %defaultThickness = 0.12 %bottomEdgeSize = .08 %topBevelSize = .03 } } @PART[Decoupler_2]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 2.5 %defaultVertOffset = 0 %nSides = 24 %defaultThickness = 0.15 %bottomEdgeSize = .12 %topBevelSize = .04 } } @PART[Separator_2]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 2.5 %defaultVertOffset = -0.01 %nSides = 24 %defaultThickness = 0.15 %bottomEdgeSize = .12 %topBevelSize = .04 } } @PART[Decoupler_3]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 3.75 %defaultVertOffset = 0 %nSides = 24 %defaultThickness = 0.2 %bottomEdgeSize = .15 %topBevelSize = .05 } } @PART[Separator_3]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 3.75 %defaultVertOffset = 0 %nSides = 24 %defaultThickness = 0.2 %bottomEdgeSize = .15 %topBevelSize = .05 } } // CONFIGS FOR 'SquadExpansion' PARTS @PART[Size1p5_Strut_Decoupler]:FOR[DecouplerShroud]:NEEDS[SquadExpansion]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 1.87 %defaultVertOffset = 0 %nSides = 24 %defaultThickness = 0.08 %bottomEdgeSize = .05 %topBevelSize = .04 } } @PART[Decoupler_1p5]:FOR[DecouplerShroud]:NEEDS[SquadExpansion]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 1.87 %defaultVertOffset = 0 %nSides = 24 %defaultThickness = 0.14 %bottomEdgeSize = .10 %topBevelSize = .04 } } @PART[Separator_1p5]:FOR[DecouplerShroud]:NEEDS[SquadExpansion]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 1.87 %defaultVertOffset = 0 %nSides = 24 %defaultThickness = 0.14 %bottomEdgeSize = .10 %topBevelSize = .04 } } @PART[Decoupler_4]:FOR[DecouplerShroud]:NEEDS[SquadExpansion]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 5.00 %defaultVertOffset = 0 %nSides = 24 %defaultThickness = 0.2 %bottomEdgeSize = .18 %topBevelSize = .06 } } @PART[Separator_4]:FOR[DecouplerShroud]:NEEDS[SquadExpansion]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 5.00 %defaultVertOffset = 0 %nSides = 24 %defaultThickness = 0.2 %bottomEdgeSize = .18 %topBevelSize = .06 } } // ============================= // === OLD DECOUPLER CONFIGS === // ============================= @PART[stackDecouplerMini]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 0.63 // assuming bent edges %defaultVertOffset = 0.01 %nSides = 24 %defaultThickness = 0.08 %bottomEdgeSize = .05 %topBevelSize = .02 } } @PART[stackSeparatorMini]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 0.63 // assuming bent edges %defaultVertOffset = 0.01 %nSides = 24 %defaultThickness = 0.08 %bottomEdgeSize = .05 %topBevelSize = .02 } } @PART[stackSeparatorBig]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 2.5 %defaultVertOffset = -0.01 %nSides = 24 %defaultThickness = 0.15 %bottomEdgeSize = .12 %topBevelSize = .04 } } @PART[size3Decoupler]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 3.76 %defaultVertOffset = 0 %nSides = 24 %defaultThickness = 0.2 %bottomEdgeSize = .15 %topBevelSize = .05 } } @PART[decoupler1-2]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 2.5 %defaultVertOffset = 0.03 %nSides = 24 %defaultThickness = 0.15 %bottomEdgeSize = .12 %topBevelSize = .04 } } @PART[stackSeparator]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 1.28 %defaultVertOffset = -0.04 %nSides = 24 %defaultThickness = 0.12 %bottomEdgeSize = .08 %topBevelSize = .03 } } @PART[stackDecoupler]:FOR[DecouplerShroud]{ @MODULE[ModuleDecouplerShroud]{ %defaultBotWidth = 1.28 %defaultVertOffset = 0.06 %nSides = 24 %defaultThickness = 0.12 %bottomEdgeSize = .08 %topBevelSize = .03 } } Imgur album of the before/after of my changes: For the "engine plates" I'm not sure if that can be accomplished within the cfg file directly or not, or if that would require changes to the plugin. Would need a way to look down rather than up to get the automatic shroud diameter (pre-defined topWidth and auto-detected bottomWidth, the opposite of a decoupler), and then to extend the shroud down from the decoupler by a height taken from the variant 'node_stack_bottom' 2nd value for the plate itself, rather than worrying about the distance between top/bottom nodes of the engine(s) attached to by the plate's 'ModuleDynamicNodes' nodes. I'm interested in assisting with that how I can, but I'm still really new to mods (never made my own, only tweaked others' mods) so it probably makes more sense to you what needs to be done to get this mod to work with the engine plates. One thing I did notice is that the engine plates have both the "decouple" and the "jettison" module, whereas decouplers only have "decouple", so it seems like that might be a key part of differentiating between the two part types, based on my reading of the engine plate config files.

got a sample craft file?

It will be fixed in tomorrow's 1.4.1 update:

mesh-switching like multiple-choice part models, but so far only really applies to MH parts. See this video at 10:15

you mean the Sentinel thing? that was in the game before 1.4

no i mean altering the text of the .cfg file to change from a mk1-2 to a mk1-3, or a Rockomax Brand Decoupler to a TD25, etc. That way the resultant craft would be using only current-era parts and therefore futureproofed.

it's a good use case for a simple mod to handle this. if we know exactly what parts are going to get replaced then it shouldn't be too hard to make a 'craft converter' that will automatically replace all such parts with compatible 1.4-onward equivalents. It might not be perfect (like if your symmetry for a mk1-2 pod uses radially mounted parts that go where the mk1-3 pod's hatch/ladder are) but it should be mostly good enough to update old craft files. perhaps even in such a way as to convert-and-copy when such a vessel is loaded in-game so that the player can just check over the converted craft without altering the original file.

Nah that's what the "spread angle" one does, this "Canopy Max Rotation Rate" slider is new and different - I checked 1.3.1 and the "Canopy Max Rotation Rate" slider does not exist, but "spread angle" does: Here's "spread angle" in action:

What Atkara means is you are backwards on the enabled/disabled thing. If you want the role-based capabilities to be enforced then leave 'Kerbal Experience' enabled(default). If you want to remove the restrictions and make it behave like sandbox, make 'Kerbal Experience' disabled.

it's the same root cause for both things though - the nodes were moved to be in-plane with the top and bottom of the donut tank instead of being sunken deeper into it, and what you attach to those nodes (another tank, or an engine) is up to you, but regardless of what you attach it will still be further from the center-plane of the tank than in pre-1.4 releases. the tank-stacking-anti-clipping thing would be the actual intent of the change, and the protrusion of the spark engine would be a side-effect. The only alternative (that doesn't involve the Offset Tool) would be a tweakable on the RMB menu for the tank that lets you change the node positions like you can on the MH engine plates or the 'interstage nodes' option on payload fairings. Or a way to move the engine's top attach node down into the turbopump area of the engine instead of at the top surface, and make that an option for the engine (like the MH engines have, tank-butt or bare attach... but for Spark you could call it "donut tank attach")

On the far left of the editor click the + button for "create custom category" and make up a name and pick and icon. After that you can click the small + icons for any part and assign it into that category. If you have a habit of using the same set of parts for a certain kind of vessel then you can just group those parts into that bin. Like if you want to make a bin for "MK2 SSTO parts" and shove all the mandatory parts for such a craft in there. Purely speculation from here onwards: It wouldn't surprise me if it also has tie-ins to the mission builder (perhaps you can choose a list of parts a mission-player is allowed to use and include that in the mission file? Just a guess but it seems plausible to do) to keep the player from taking the 'easy route' and making an overkill vessel, or, to give bonus points for sticking within the parts category you provided as an optional mission objective but not failing them for choosing otherwise, since there's a scoring element in addition to a success/failure element.

based on what Roverdude said I'm taking it as a deliberate change to prevent stock parts from intentionally clipping each other -

It's still there, you just have to enable Advanced Tweakables in the game settings. Fairing Staged, Rigid Attachment, Autostrut, Aim camera, are all hidden when Advanced Tweakables is turned off.