flart

You missed SCAN-12 "MS-R", hyphen in the SCAN-43, quotes in the SCAN-52 "R2" and probably you could sort them by titles UPD. I make a dark version png spreadsheets

I never test it, but that suppose to be working. On the next week I will look into.

@JadeOfMaar while you looking in the JNSQ, JNSQ/master from several weeks ago was having this (ALeonov), though maybe it was my local bug. Also some new 1.12 Launchsites/Anomalies are not just underwater, but under bottom of oceans, for example

RemoteTechRedevAntennas Reflectron-128 is Extended by default, but the button show "Extend Antenna" and an animation start playing from the retracted state.

CommNet Antennas Info 3.1.0 add Vessel Antenna Rating and Vessel Relay Rating a button in the PAW of Internal Antenna (probes, pods) in the Editor and Flight support NF:Exploration optimizations MM 4.2.1 CommNet Antennas Consumptor 3.5.2 ksp 1.12.2 MM 4.2.1 CommNet Antennas Extension 2.1.5 lower volumes based on bounding box MM 4.2.1

KSP 1.12.2, JNSQ, "very low" preset dims light underwater, but vessel's lights also are not working, so it's very dark there. I temporally disabled "ocean" and "dim light underwater", and located the stock Mahi-Mahi launch site, that in the JNSQ is underwater. Maybe default very low preset need to not dims light underwater ?

Stumbled upon https://forums.getpaint.net/, the dark theme is soo nice!

@linuxgurugamer if you missed it — https://github.com/linuxgurugamer/KSP_PartVolume/pull/4 otherwise in the case "time has not come" yet - it's ok

using the https://avatarmaker.com/ and some ksp wallpaper — png (or svg):

the solution is Vector3 offset = nodeA.owner.transform.rotation * nodeA.position + nodeA.owner.transform.position - nodeB.owner.transform.rotation * nodeB.position + nodeB.owner.transform.position; or simplified: Vector3 offset = part.transform.rotation * (nodeA.position - nodeB.position);

So you talking about roleplay concept, that IRL harbors will not be placed where the WLS is placed, but not the safety in the game? That's probably true. WLS is not on the East of Launchpad (that would make it unsafe even in-game), but on the North-East (latitude of WLS is in between Launchpad and Runway), that would make WLS in-game pretty safe and interesting (sic!) — you will see WLS and sea-ships around it on a plane or a rocket takeoff, but at the same time they are pretty safe. WLS is visible on the default camera angle on the KSC scene, and iirc bottom of the water on the East is more suitable for the underwater Launch site. I remember there was some problem on the North bottom, though don't remember exactly. Also on the picture you provide there is a JNSQ Harbor (or some Extended KSC harbor), so you have place to roleplay-safely store and launch sea-ships, and why you want to have WLS almost in the same spot? To summarize, moving the WLS: pros: IRL roleplay concept cons: less interesting (hidden by the ground on a rocket/plane launch) no visible on default camera angle on KSC scene possible problems on the bottom for the underwater launch site other mods harbors already there Finally, I heard that the last version of KK fixed the Ctrl-K GUI problem, so you can move the WLS as you want, and I include patches or KK-configs as .txt files, ready for the replacement by users locally

I have this function based on the one in the Konstruction mod: private Vector3 GetOffset(WeldingData wData) { //var nodeA = WeldingNodeUtilities.GetLinkingNode(wData.LinkedPartA, wData.part0); //var nodeB = WeldingNodeUtilities.GetLinkingNode(wData.LinkedPartB, wData.part0); //Vector3 offset = nodeA.position - nodeB.position; // offset in wrong direction, depends an an angle of the craft? //Vector3 offset2 = nodeA.nodeTransform.localPosition - nodeB.nodeTransform.localPosition; // // nulref // works for a stack of simple simmetrical parts (tanks) Vector3 offset3 = wData.LinkedPartA.transform.localPosition - wData.LinkedPartB.transform.localPosition; offset3.Normalize(); offset3 *= WeldingNodeUtilities.GetPartThickness(wData.part0); return offset3; } // ..... partB.transform.position += offset; Idea there pretty simple, we take vector (direction) of an future shift as difference of positions, normalize it, and then give it the desired length. offset3 use linked parts for that difference, while mathematically it's enough (and make more sense) to use corresponding nodes of the part0 for that difference. Also this way it will not be dependent on models of linked parts. (I consider .transform.localPosition as some kind of center of a part). I have tried to use nodes (offset, offset2), but it is failed. How to switch to using nodes?

the person just need to not include changed .sln / .csproj in the PR. Also looks like Source\Repo-Kaboom112.sln include only Kaboom.cs and no other files. I tried to add them, and there is some problems: the Constants could not be found, and config.cs is not in the Kaboom namespace so it can't find Log

@zer0Kerbal do you miss the VS solution/project files in the repo or was using some other ide/tools? I was trying to look into https://github.com/zer0Kerbal/Kaboom/issues/5 but couldn't find the .sln or .csproj

Version 2.0.0 mass using stock resource system (thanks to @JadeOfMaar): enable number mode (#) in the PAW and set any value from ranges: kg: 1-1000 ton: 1-500000 mass b9switch is leaved for a compatibility and it's quicker to use it for the most round numbers. default mass is 0t instead of 1t mass lower than 1t is removed: use kg resource. added 5.0m size