atomontage

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.

KSP Version: 1.3.1.1891 (Windows 7 x64), fresh install, fresh sandbox savegame. I keep this particular KSP install for such testing only. Mods / Add-Ons: All Stock Description: if there is a long enough part inside a cargohold that consists of two shorter ones, then drag is applied to the payload. (I think its because the game thinks that payload part is clipping through the cargobay. Although visually it is only clipping through its front or its back as it is longer than the cargobay.) I also think the problem is known. But I'm not sure. Also I'd like to know if it's gonna be fixed or not. The reason I'm reporting this is because there are many modded parts that are longer than the longest cargobay available. Fuel tanks for example. It also limits how one should attach their payload inside cargobays. UPD: not every part bugs. Incomplete list of parts which I've tested (yes = causes the bug): - FL-T800 Fuel Tank: yes - Modular Girder Segment XL: no - M-Beam 200 I-Beam: no - Mk1 Cockpit: yes - Orange Tank: yes - RT-10 Hammer Solid Fuel Booster: yes (omg i've ignited it inside my cargobay.. omg.. oh nevermind it didnt explode) As a lil' bonus I've also tested the situation when a small part is placed between two cargobays. It didn't bug at all (tested with 2x FL-T200 Fuel Tank). Steps to Replicate: 1) Create a plane with two connected short cargobays so they make a longer one together. 2) Put a long enough part inside - its length must be longer than one of the short cargobays. Example: two connected Mk3 Cargo Bays CRG-50 and an Orange Tank inside. 3) Attach additional parts like a Cockpit, landing gears and an engine (if the payload isnt a fuel tank - then attach a fuel tank too of course). 4) Launch the craft. 5) Make aero forces visible in parts' gui menu through the debug menu. 6) Open the payload right-click menu. 7) Accelerate and watch its drag. Result: The payload's drag isn't zero although it must be as it is fully enclosed. Fixes/Workarounds: - attach the payload differently (if there are multiple crafts or parts as a payload); - use different nodes; - use the largest cargobay available; - don't put larger parts inside Other Notes/Pictures/Log Files: Both Mk3 and Mk2 cargobays have this problem. I believe its an internal technical logic problem, not a bug. Its just how the game calculates drag. But still it is a problem. Craft files: Mk2: https://www.dropbox.com/s/kk4h6y8h4alamx0/Bugged Mk2.craft?dl=0 Mk3: https://www.dropbox.com/s/fe4zaluf436nniq/Bugged Mk3.craft?dl=0 Screenshots (the right part-menu reflects the payload on both screenshots): Thank you Squad for making one of the best games! No sarcasm involved. Bugs happen. (I believe there is no need to include logfiles. Will attach if Im wrong.)

Found an easy-to-fix bug. Well I think it is easy to fix. Engines incorrectly calculate their thrust upon copying (if set to be with 2 or more chambers). I've created a github issue as well. Posting here so ppl will not have to worry if they encounter it. (Tested on pure KSP 1.3.1. All info included in the issue.) Thank you for this great mod! Love it. I wish DangIt! properly recognized many SSTU parts, but its a known DangIt! issue I think to not recognize procedural stuff.