Crater

In the SDHI Service Module Pack Edit: Rats, beaten to the post while finding the linkie

Here's a config for the FusTek station parts from Sumghai. Mostly the ai gets them right, but the docking ports and one of the end caps need to be made passable, so... @PART[KarmonyEndRing*]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[IACBM_125m*]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[IACBM_25m*]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } (the wildcards are to cope with the 0.4x devel version as well as the 0.35 release)

Crash to desktop at the end of loading is most commonly caused by out of memory - especially if you just added a big mod such as Interstellar. Do you use any texture memory reduction method, such as Active Texture Management?

Well, now I know what I'll be doing tonight - redesigning my LKO station... and I've only spent 11 launches on it so far Ah well.... I've already had some thoughts on what I could have done better... now I have an excuse to implement them!

Another (very minor) bug report for next time you're updating this awesome pack. In the config files for three of the parts (tele_experimentLow0, tele_experimentMid0, tele_experimentHigh0), a semicolon has snuck onto the end of the valueScale parameter of the TelescopeExperiment module. This is causing an invalid floating point number error in the logs when they load, and it isn't clear whether it just stops parsing at that point, or whether it just fails to set the value completely. Like I said, minor

It is undoubtedly less flexible, and a good example to cite of when it breaks down would be in a closed system where you recycle everything, and you're emptying a vessel for deorbiting and destruction - you wouldn't want CO2/waste/wastewater on it either, but that's when you turn off auto pumping and use TAC Fuel Balancer instead. And yeah, I was thinking about the simplest to code and simplest UI that covered 90% (or more) of the cases. As for how to implement it, I haven't looked at the code either, but just think of it as transferring a negative quantity of resource each pumping cycle, so you could store +1 or -1 as the directional state for each resource, and then just use it as a multiplier. (But I'll shut up now, it's not for me to declare how to do it, unless I'm prepared to submit a patch )

I was considering this exact problem last night while lying in bed, (yeah, okay, I know).... and what I thought up was... what about if you could configure that for certain resources, the pump direction was always inverted. So a if you set a tank at level 7 and pump-on, it will always fill attached oxygen containers, but always drain attached CO2 containers (whether it is this tank or the containing tank that needs to have pumping on is a separate question). Then all that you would need would be a one-stop config screen where you could say which resources were inverted, and leave the per-tank stuff entirely alone. (And yeah, I've been waiting until you put this up in the correct thread before replying).

The Smart A.S.S. module Surface mode allows you to specify a heading, pitch, and roll, so you can use that to gradually lower the pitch from 90, while keeping the wings level. Once you get high enough and over enough, you can switch to orbital mode and use prograde, but be aware at launch that there is a big difference between surface prograde and orbital prograde.

I think that would be a very useful extension, though it does also imply that it would be necessary to explicitly close the hatch before decoupling, or face a sudden shortness of breath for your crew. I'm not even sure if you can disable undocking from a mod, though...

ModuleManager is your friend. This adds storage to command pods according to their crew capacity. @PART[*]:HAS[#CrewCapacity[1],!MODULE[KASModuleContainer]] { MODULE { name = KASModuleContainer maxSize = 10 } } @PART[*]:HAS[#CrewCapacity[2],!MODULE[KASModuleContainer]] { MODULE { name = KASModuleContainer maxSize = 20 } } @PART[*]:HAS[#CrewCapacity[3],!MODULE[KASModuleContainer]] { MODULE { name = KASModuleContainer maxSize = 30 } } @PART[*]:HAS[#CrewCapacity[4],!MODULE[KASModuleContainer]] { MODULE { name = KASModuleContainer maxSize = 40 } } @PART[*]:HAS[#CrewCapacity[5],!MODULE[KASModuleContainer]] { MODULE { name = KASModuleContainer maxSize = 50 } } @PART[*]:HAS[#CrewCapacity[6],!MODULE[KASModuleContainer]] { MODULE { name = KASModuleContainer maxSize = 60 } }

I guess my difficulty when it comes to the idea that you can't radially attach a docking port or corridor to a hab or pod is that I now have an image of Jeb strolling across the VAB floor with an angle grinder dangling from one had, muttering something about wanting an easier route to the snack storage bay in the adjoining module. And I just can't imagine how you would stop him

Somnambulist has done some cylindrified ones - http://forum.kerbalspaceprogram.com/threads/66479-23-Somnambulic-Aerospace-Life-Support-Parts-0-0-1-%2818-Jan%29

Yes, exactly that. Also, what some part providers do, to mitigate against the log errors you mentioned above, is that they provide their parts with stock (or must-have mod) configurations, and then also provice ModuleManager configs of their own that a player can include if they have the appropriate mod, or remove if they don't want the log errors. It also means that players can contribute a ModuleManager config for a parts pack for CLS, then other users can include that one. Lastly, it also gathers all the appropriate defaults that you provide into a simple easy to edit place, so if anyone disagrees with your decisions, (reasons of immersion, etc.), they can trivially tweak the file to be just how they like, without having to worry that your thoughts on heatshield hatches have been hardcoded.

Lol, beautiful looking part, but I can hear my computer crying just from the thought of it

Works fine with it here (which I why I offered the alternative suggestion above). I have this, and I use the aggressive ATM to keep memory down, and I've not seen any issues with any of the parts (yet )

Nothing much to add from a suggestion perspective, since everything I thought up as I read through the thread has already been said, but I definitely want to add another voice in support of this being an excellent idea for a mod!

If you are still having problems with 6S Stowage Parts, can I ask if you have renamed the installation folder? I just wonder if you've created something like GameData\Nothke\ and put a folder in there for each of his mods? Because if you do that, then the game can't find the models unless you also edit the part config files to reflect the new paths.

Sure you can Food, water and oxygen are all transferable around just like fuel, so you'll just need to have nice big tanks for them on your station (mine hold about 21 Kerman-years worth when totally full), and shift them around when you dock a craft.

I've seen one report that issues with some versions of RemoteTech caused problems with these opening, though I don't use RT myself, so can't confirm if it still happens. Also, it's worth checking your other mods to make sure they're all up to date.

Sadly, that's a stock game issue with how fuel flow works for different fuel types. There is no way you can build differently to make it work the way you want. However, there is a rather excellent mod that will do exactly what you are looking for - the Goodspeed Automatic Fuel Pump, which you can find in http://forum.kerbalspaceprogram.com/threads/67163-0-23-Goodspeed-Automatic-Fuel-Pump-v1-29-1 . Basically, you can tell the little tank on the miner to automatically pump fuel to other connected vessels whenever they dock, and it is as simple as that. You can even have multiple priority levels, so your drill will auto-pump into your tankers, which will auto-pump into your orbital fuel depot, which will auto-pump into any other craft that dock there.

My bad - I'd missed an update. The thread says that 3.0 is still the current version, so I hadn't seen that 3.01 had been silently released on SpacePort with the extra .dll removed. So apologies to Navyfish, who has indeed fixed it, though I still think that is the cause of requimrar's reported error.

I think that it is telling you that you have a copy of Toolbar.dll installed in the wrong place. This is most likely because you have Navyfish's Docking Port Alignment Indicator, the current version of which incorrectly ships with a (now old) version of the Toolbar.dll file within its own folder tree. The fix is simple - delete the file at GameData/NavyFish/Plugins/Toolbar.dll since the only one you need is the current and correct one in 000_Toolbar/Toolbar.dll

Any anyway, if they were separate vessels, only the actually focussed one would scan.

Sadly, I can save you the bother, by telling you that kethane scanners on a single vessel are all considered to be at the center of mass of the vessel when determining what hex they are scanning. In other words, no matter how big your ship, it will only ever scan one hex at a time. This has been discussed and tried a few times over in the kethane thread, and Majiir has explained that it will never succeed with the way Kethane (currently) operates. Personally, I once my SCANsat maps are fully covered, I just turn on Kethane's debug mode and "simulate" complete scanning.

Around the whole thing, so basically, put PART { on its own as the first line of the file, the all the original contents, then } on a line of its own as the last line of the file.