atomontage

Published a pre-1.8.0 build directly to the root of the repo (see OP). Its not on CKAN, its MiniAVC support is disabled but it should work on all versions from 1.4.5 to 1.7.3. (Edit: MiniAVC support should be okay now as of 0.2.2+ for pre-1.8.0 versions as well.)

@HebaruSan, is there an option to wildcard the $kref property in a netkan file? I got a few requests to produce a pre-1.8.0 version. I've prepared the binaries and the repo locally, split the necessary files, etc. I can distribute the same mod version with two archives in a single release: one for pre-1.8.0 KSP, the second one for 1.8.0+. I would prefer the following format: {MODNAME}_vX.X.X-1.7.3-.zip and {MODNAME}_vX.X.X-1.8.0+.zip respectively. So is it possible to wildcard an archive download link like *-1.7.3-.zip without breaking the mod versioning and creating additional repositories? If it is, then I'll be able to create two separate distributions that lead to the same GitHub repo but different archives. When pre-1.8.0 support is dropped, I'll just file a pull-request to remove the obsolete .netkan file and update the current one. Thank you!

Actually no. After reading this, I've tested the issue in question. Unfortunately, the minimum supported version is now 1.8.0 due to Unity and 3rd-party library dependencies. I'd be ashamed if it was not my first KSP mod. Well, nevermind - I still am. Fortunately, I've discovered it now and not a few days later after. Anyways, thank you sir for both asking this and for your pull-request! Much appreciated! UPD: forgot to mention that I also discovered a few annoying bugs. Fixes are rolled out now. So double thanks!

Hey @IgorZ ! Thanks again for the great development suite! PAWRangeBuff has just gone wild so you can add it to your Mods that use KSPDev Utils list if you want.

This mod automatically increases the Part Action Window maximum EVA click distance based on the part size. Sometimes you are in a situation when you have a big part (like that new shiny 3.75m Habitation Module from SSPX you've just researched) and you wish you were able to interact with it. But you are not because of the part size: Bill just can't reach the part although literally touching it. It seems that when you right click on the part, KSP calculates the distance to it's center making kerbanauts unable to interact with large enough parts. This even happens with 3.75m parts (and there are even larger ones!). It also seems that KSP defaults the distance required to 2 meters. Unfortunately, most mods do not modify the maximum distance to PAW. DOWNLOAD Source code Both links lead to the same repo though... ####################### INSTALLATION The mod can either be found on CKAN or downloaded manually using the link above. If manual is chosen, just extract the contents of the archive to your KSP root directory. INSTALLATION FOR KSP PRE-1.8.0 In the repository root, there is a separate .zip archive for KSP 1.4.5 - 1.7.3 with the latest (0.2.2) version. I do not intend to keep it up-to-date. However, the mod is very simple and small so I don't think there will be many updates. SETTINGS In case you need more, the coefficient can be modified in the Settings.cfg file located in the mod's directory. ####################### This mod takes every action available through the PAW and increases its EVA availability distance according to the part's biggest attach node. The exact formula is quite simple: Take the current part's biggest attach node. Add a value to the current (or KSP default) maximum action range based on the following: -- 0.625m => 0. -- 1.250m => 1. -- 2.500m => 2. -- 3.750m => 3. -- 5.000m => 4. Multiply the sum by the coefficient specified in Settings.cfg (default: 1.0). CHANGELOG ####################### Thanks to -- @IgorZ for KSPDev Utils & Release Tools which are used by this mod. -- the fellowship of the KSP community that is the greatest I've ever seen. For all the mods, non-dying enthusiasm, support and inspiration. And gameplay features! Dude... -- and obviously... @SQUAD and the dev team for making the greatest game of all time! ####################### LICENSE The mod code is licensed under the MIT license.

This mod automatically increases the Part Action Window maximum EVA click distance based on the part size. RELEASE THREAD: Sometimes you are in a situation when you have a big part (like that new shiny 3.75m Habitation Module from SSPX you've just researched) and you wish you were able to interact with it. But you are not because of the part size: Bill just can't reach the part although literally touching it. It seems that when you right click on the part, KSP calculates the distance to it's center making kerbanauts unable to interact with large enough parts. This even happens with 3.75m parts (and there are even larger ones!). It also seems that KSP defaults the distance required to 2 meters. Unfortunately, most mods do not modify the maximum distance to PAW. DOWNLOAD Source code Both links lead to the same repo though... ####################### INSTALLATION Download the archive & extract it into your root KSP directory. SETTINGS In case you need more, the coefficient can be modified in the Settings.cfg file located in the mod's directory. ####################### This mod takes every action available through the PAW and increases its EVA availability distance according to the part's biggest attach node. The exact formula is quite simple: Take the current part's biggest attach node. Add a value to the current (or KSP default) maximum action range based on the following: -- 0.625m => 0. -- 1.250m => 1. -- 2.500m => 2. -- 3.750m => 3. -- 5.000m => 4. Multiply the sum by the coefficient specified in Settings.cfg (default: 1.0). ####################### Thanks to -- @IgorZ for KSPDev Utils & Release Tools which are used by this mod. -- the fellowship of the KSP community that is the greatest I've ever seen. For all the mods, non-dying enthusiasm, support and inspiration. And gameplay features! Dude... -- and obviously... @SQUAD and the dev team for making the greatest game of all time! ####################### LICENSE The mod code is licensed under the MIT license. ####################### A bit of history here. I thought of or tried a few approaches. Like patching events (KSPEvents) with MM configs, but no - it seems it is unable to. That's fine, but right now I'm at that stage of my career when I'm literally unable to perform maintenance or repair (Kerbalism) my new 3.75m habitation modules. I could even create pull-requests that fix the problem with a few lines of code but... there are many other mods that introduce more EVA interaction with parts. The code is very, very simple. As this is my first mod and my first experience with C#, I would greatly appreciate any advices, feedback and criticism. No, seriously. This mod could even be a great mistake if I've missed another similar one - just tell me! This may be further buffed with CKAN metadata and AVC compatibility when (if) it passes fellow kerbanauts review.

@Shadowmage, I've found a bug: Modular Heat Shield upgrades are not visible in the tech tree. I've debugged the problem and filed a pull request on Github. Please have a look when you have time. And as always, thank you for this great mod!

Hey guys. Q1: Is it intended that the Station Parts Extension Redux' Greenhouse fully grows crops in 5 days and yields 3 food? I mean... I really like the model but its really unconvenient to stop warp every 5 days while flying to Jool to harvest 3 food. Its okay, I know I can alter the config files. Q2: Is there a way to automate the harvesting process without need to switch to the craft and harvest it manually? Thanks in advance! And thank you dear Sir for maintaining, supporting and (taking part in?) creating this awesome mod!

Congratulations Shadowmage! No pressure, mods update to 1.8 when they do. Thanks for the awesome mod you have made!

Yeah thanks for pointing that out! I've read your comment here and I'm still thinking whether this is the right solution (for me). You see, if RT gets disabled then I have to get back to using CommNet. And that means that satellites become dead. I don't want to play without connectivity. One of possible solutions is to remove the DLL, play without connectivity for a while until fix is out, then install RT again. Thanks anyways, good idea!

I can confirm this. After having like 5 fps on my base and removing the RT mod, it became 10fps+ RT spams a lot of these: Mods installed: It seems I'll have to completely remove the mod (although I was playing with it for years). I mean come on, double FPS boost is probably worth it. *sigh* goodbye, satellites, rovers, landers and other unmanned guys! *makes a save* Oh and.. playing with: RemoteTech 1.9.3 on KSP 1.7.3 and latest Galileo's Planet Pack (might have an issue with this) Anyways this mod is damn great!

So I was arguing with this guy... telling him something trying to explain things. And then he suddenly typed. All in caps: KSP TWPO WUIT?! (Translated from Russian, orthographically correct.) As an admin of a big Russian fan community, I think I speak for every Russian KSP fan: WAIT REALLY?! FREAKING YES!!! KERBAL SPACE PROGRAM TWO! Oh my gawd... Pinch me coz I'm definitely sleeping! No really, I had this exact feeling: I'm definitely sleeping. Can't be. Omg. Then an avalanche of emotions fell through, described mostly in beautiful Russian obscene language I can't post here. You got me. Colonies. INTERSTELLAR FLIGHT... Parts-rich spacecraft... Omg. Thank you guys. YOU MADE MY DAY. And week. And more. Live long and prosper! And HUGE thanks to Squad for the original game!

Thank you both @Padishar for creating and @linuxgurugamer for maintaining this awesome creation! A long time ago I was keeping it installed but I had a very old comp with 8 gigs of RAM. Never had any significant performance boost but meh my comp was really old (DDR 2, Xeon 5460 (quad core generation)) so I never expected much from both KSP and MemGraph. Now I have new hardware and so I gave it a try again. After a few attempts, I have finally set it up: with heap padding of 8192* it greatly boosts KSP performance by minimizing GC stuttering. Before it literally happened every few seconds for, well, a few seconds. Like I got a 5sec freeze every 5sec. Now it only happens every 30 or 60 seconds. So now my setup with over 100 mods and a huge base is much more playable! Thank you guys. KSP Community is freaking awesome! * for 32 gigs onboard, a 16 gig heap setup crashes the game. Will experiment more. 12 could probably be ok.

Jeez... NOW I am ashamed! Haha. Yeah right, I used diameter instead of radius... *sigh* Thank you much for your great answer and very quick reaction! Mr. Kraken, bless this dude and this mod for us please! Oh did you already do it? Okay then, but do it again please! For more reliability..

Hello, @Shadowmage! Firstly, let me thank you for your great work on SSTU - I've been really enjoying the mod for a while, its a pure awesomeness. And all those PBR textures... jeez, its cool as hell! *drools* I have a question. Lets say I have a standard MFT-A 2.5m x2.0 lightweight tank filled with LH2: Then the volume of this tank is 5 * π * 2.5^2 ≈ 98.17 m^3 (Notice that the menu says its volume is 24.5 m^3 and its usable volume is 20,8 m^3.) Now as we have mass and volume we can calculate LH2 density: m / V = 1475kg / 98.17 m^3 ≈ 14.025 kg/m^3 Google says the density of Liquid Hydrogen is something around 70.8 kg/m^3 that is almost 5 times greater. If we consider the told volume (20.8 m^3) then the calculations are correct and the resulting density will be 70.91 kg/m^3. I have also looked into the CRP config - it defines LqdHydrogen density as density = 0.00007085000 which seems to be correct. Does SSTU divide the resulting volume by 5 just to match stock LF and LOX? Because it fills itself with stock resources correctly. But it seems like a strange solution as it completely breaks the usage of LH2 and other resources. My SSTU version is 0.39.149 (KSP is 1.3.1). Thanks!

Windows restricts usage of quotation marks in filenames so yes KSP can't create a craft file with it. You also cannot name your craft 'con' (without apostrophes) as Windows forbids to use that word as a file or directory name. About launch failures.. I think its normal. Its like you've just started your rocket career - its obvious your rockets will fail over and over again. Thats my opinion. I've had many failures too during early career stage. Also 25 reliability is very low (with default BARIS settings). My parts are mostly 80 and failures are now much less often. Even so something with reliability 60 does fail sometimes.

I believe its just a part of a name. But I'm not sure... No, its not a different mod. Its GPP that renames kerbals.

Ok, I've found it under %APPDATA%. I've reuploaded it to Google Drive and the link remains the same. https://drive.google.com/file/d/1KmlA_2tx_YonmaRUxoVP1bCe0AqOek5T/view?usp=sharing I believe it only remains them once. I didn't play it much though. The reason to rename is that it replaces Kerbin with Gael so it also renames kerbalnauts to Gaeleans instead of Kermans so it makes sense.

I've just checked - yeah, output.log seems to be obsolete. I believe it persisted through the copying process. I have like 6 KSP installs. Two of them are for testing (like for this case when I needed pure stock). But still it is from the correct directory. It seems KSP didn't refresh it at all since the last.. crash I think? And ksp.log is ok. Is it enough for you? Or should I do something else to produce more logs?

Um sure output.log: https://drive.google.com/file/d/1KmlA_2tx_YonmaRUxoVP1bCe0AqOek5T/view?usp=sharing ksp.log: https://drive.google.com/file/d/1J68ogFuojvW0Go57lokUGGhnpo1Cd25R/view?usp=sharing

hello, @garwel! Firstly, thanks for the awesome mod! Now I have a bug here. It seems KerbalHealth is not fully compatible with Galileo's Planet Pack. The reason might be is that GPP renames kerbalnauts in such a way that their second name becomes Gaelean instead of Kerman. I tried KerbalHealth in a pure stock install (well ok, with KER installed) and reproduced the steps by adding another kerbalnaut into the vessel - everything seems to be ok. I get the following once I add more than one kerbalnaut into the ship in the VAB: (Notice that I also tested this on a pure stock vessel - Kerbal X.) It seems that the default kerbalnaut (the one that is always put into a fresh vessel loaded in VAB just like Jeb) does NOT cause the bug. In my case it's Galileo Gaelean (see screenshot above). Every other one does cause the bug. You'd probably also want a screenshot of my kerbalnauts (those are added by GPP by default): And just in case you're interested in mods I have installed then here is the list: Thats all. ps: oh and I have a quick question here. Is it compatible with other stars? For example, GPP adds one more star that is included in the star system - it has a very high orbit though. Its just like an another celestial body in the system but it is a star. Will it provide radiation once a vessel is close to it? Im asking this because its not a planet - I know ppl have already asked about adding radiation to gas giants for example. But what about a star? Also Kopernicus treats it like a proper star now. Solar panels work, heating works, sunflares work. Thank you and have a great day!

I hope I didn't miss something essential in exploring the following issue as there's too much beer in me. Anyways. I wanted to add support for SSTU solar panels. As some of you may notice, its a popular mod. I use it too. So... after trying some configs inserted directly into \DangIt\ModuleManager\Entropy\Solar.cfg (I've simply replaced ModuleDeployableSolarPanel with SSTUSolarPanelDeployable for testing purposes), I got the following stuff: KSP.log: That one made me to look up the source. I'm not familiar with MM syntax neither with MM config files. But as far as I researched any module declared with MODULE { } inherits its parents' fields (as, for example, the ModuleDeployableSolarPanel.isTracking one). So isn't is safer to change the parametrization to return this.part.Modules.OfType<ModuleSolarReliability>().First().isTracking; ? PS: and as always.. Thank you @Ippo for DangIt! and @Coffeeman for Entropy and @linuxgurugamer for maintaining this mod! KSP really lacks of random failures. Not sure if it's nice to call all of you for thanks but oh well.

@OHara thanks for your help. I've also tested a few parts - added my conclusion to the original post. Btw, in both cases of testing (Mk3 and Mk2 variants) cockpits were root parts.