Poodmund

The 7th value in a node definition line is the node size, parts are more easily snappable to nodes of larger sizes so you could potentially make the lower node size 1 and the upper node size 3.

Ah that is a great spot... that damn plugin is more hassle than its worth. Thanks for letting me know, I'll keep it in mind in future. EDIT: This is why all forums should have the option to turn off the WYSIWYG editor. *shakes fist*

https://github.com/Sigma88/Sigma-Cartographer - Sigma88 basically created a plugin as I kept of moaning about a few things like leaflet style map exporting, altitude point info and a few other things and because he's awesome... he made this plugin. Can't give enough thanks. I'll just take that out I think.

Probably revamped parts that got new titles like the Stayputnik v2 or the Spark v2 etc. etc.

Good to hear they work, I cannot attest to their cost/mass balance though.

It causes considerable input lag for myself, both in mouse input and any in-game action. Usable... barely... but 'working' nonetheless.

The lower top node was positioned to be on the underside face of the payload adapter so you could mount things between the space of the fuel tank below and the payload... like a probe core or something. It was quite handy to be honest.

The best reason to install ReStock+ is because you want all the additional parts listed in the OP.

@Virtualgenius I found my old spreadsheet that I used to extrapolate the values for the 0.625m and 1.875m fairings and expanded it to give me the stats for 3.75m, 5m, 6.25m and 7.5m fairings using the 2-Slice KW Fairing (the ones that the 1.25m and 2.5m fairings used originally with only 2 sides). I've done a quick check in game and they are all showing up and scaled correctly but not tested them in flight. The configs can be found here: https://www.dropbox.com/s/sod328vucuqzifb/SAF_KW_375_to_75_2Slice.zip?dl=0

It seems that when putting a lot of embedded content within a spoiler tag a large blank, un-removable amount of whitespace seems to get added to the top of the spoiler content. See: See: @ManeTI, do you have any idea as to why this is happening?

For those uninformed, it became apparent that a group of people, primarily based on the site https://bbs.3dmgame.com/forum-1214-1.html were redistributing a handful of KSP add-ons/mods that were under either restrictive, non-derivative or non-commerical based licenses and hosting them elsewhere behind a paywall to the Chinese Kerbal community. EDIT: To expand on this, the mods in question were being redistributed with a password on the archive and the password was being sent upon the receipt of payment to the distributor. Moderaters/Staff may also want to enquire into this issue as the site seems to be hosting a download for the full game also: https://bbs.3dmgame.com/thread-3950304-1-1.html. For disclosure, I will be reporting my post to the Moderating team for visibility.

Updated Gaseous Giganticus Tutorial There was an issue with compiling Gaseous Giganticus when increasing the exported cube face texture size above 2048px x 2048px; I have updated the tutorial with a fix for this but running a small patch file generously written by Thomas P. @smcameron you may be interested in this amendment.

I think this is probably the best post I've ever seen on this forum.

@Drew Kerman could you list you results in a PM or spoiler tag as it would be handy to see if there are any affected mods out there that don't currently have .whitelist support.

That is correct, basically it just allows you to create a PR against a branch of your repo and it automatically builds and packages the mod from the files on the repo and deploys it as a github and spacedock release simultaneously. I saw you said that you were still doing spacedock releases by hand so thought this might be of interest. For reference this build method (and git repo) is from Nertea and is used for all his mods and also ReStock; it allows any authorised contributor on the repo to initialize the build and release process.

@linuxgurugamer you may find this helpful: https://github.com/post-kerbin-mining-corporation/build-deploy/blob/master/README.md

You could just create a part that scales the 2.5m Fairings up by a factor of 2. That's essentially what I did when I made the PR to add the 0.625m and 1.875m fairings into this mod: https://github.com/blowfishpro/SimpleAdjustableFairings-KWRocketry/blob/master/GameData/SimpleAdjustableFairings-KWRocketry/Parts/KWFairings/KWFairingSize0.cfg

@Drew Kerman I saw you asking about a mini-science-return capsule elsewhere and thought I'd point out there's an awesome one in ReStock+ if you were unaware. It's perfect to stick a heat shield on the underside and a parachute on top and fling back through the atmosphere filled with experiments.

In regards to the drain valve, I think you're being entirely unfair. The IntakeAir bug is just a mistake but sure the actual thrust being produced could be "balanced" a little differently. The biggest issue here is the bug to do with the KAL curve tangents not being clamped to upper and lower bound values... which in turn allows for many rediculous exploits. Screw krakentech of whatever people call it, you are essentially exploiting game bugs.

You can avoid that by having two textures, one without the blue stained ocean ground that is used to set the ground colour for the PQSMod VertexColorMap for when you are near the surface and then another texture that is used for ScaledSpace that has the blue stained ocean ground that renders when you are high up in orbit. You essentially fade between the two when the ocean starts to get rendered through the ScaledSpace <-> PQS transition.

Have you seen Scott Manley's video on this? If you look at the generic resources file: Kerbal Space Program\GameData\Squad\Resources\ResourcesGeneric.cfg where IntakeAir is defined, there seems to be a typo too: RESOURCE_DEFINITION { name = IntakeAir displayName = #autoLOC_501005 //#autoLOC_501005 = Intake Air abbreviation = #autoLOC_6002101 //#autoLOC_6002101 = Air density = 0.005 unitCost = 0 hsp = 10 flowMode = ALL_VESSEL transfer = PUMP isTweakable = false isVisible = false iRESOURCE_DRAIN_DEFINITION { isDrainable = false showDrainFX = false } } See how the node RESOURCE_DRAIN_DEFINITION has a lower-case 'i' at the start, compared to, say: RESOURCE_DEFINITION { name = LiquidFuel displayName = #autoLOC_500999 //#autoLOC_500999 = Liquid Fuel abbreviation = #autoLOC_6002095 //#autoLOC_6002095 = LF density = 0.005 unitCost = 0.8 hsp = 2010 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP isTweakable = true volume = 5 RESOURCE_DRAIN_DEFINITION { isDrainable = true showDrainFX = true drainFXPriority = 7 drainForceISP = 5 drainFXDefinition = gasDraining } } Which does not (like all the others). So it seems IntakeAir being drainable is a bug and someone fat fingered the config. This doesn't address all your other concerns but it is still quite funny nonetheless.

To save myself the rigmarole of doing it all again in the future, you can extract the in-game assets using something like https://github.com/Perfare/AssetStudio or https://github.com/DerPopo/UABE and then open the asset bundles in KSP/KSP_x64_Data folder. Export all 17 of the asset bundles and then you should be able to find all the textures and filenames you need. Pro-tip, use the AssetStudio software, then load the whole KSP_x64_Data folder and then go Filter > Texture2D then Export > Filtered Assets, this should export all the textures from the whole game. Then sort the extracted files by filesize descending and the large textures should be near the top.

Could you please elaborate as to what mod this was so that it can be looked into please?

I think Mircea has been misunderstood in that I think the statement of intent was more one of "if the current dev team do not have the time or wish to put an incredible amount of spare time into the mod, is it time to look for new dev blood?"... which is not a bad sentiment... however, I think the current dev team have always been open to new blood to help with Kopernicus to a competent level but volunteers are hard to find. In short, everyone can wish the best for the dev team but if no one steps forward with the capability and enthusiasm to help Thomas, Sigma et al, then it makes no difference either way. We can wish the mod gets updated when a new KSP version comes out but that's all you can do as a consumer, wish.

@Danilo Coelho these are the parts that I whitelisted when using MKS, FTT and Karbonite: Squad/Parts/Resources/RadialDrill/ Squad/Parts/Command/advancedSasModuleLarge/ Squad/Parts/Utility/dockingPortSr/ These were the only stock parts that were referenced in RoverDude's mods as far as I am aware. Please let me know if you are aware of any more parts not working correctly.