Cooper42

No, they use their own module. Create your own MM patch .cfg file and paste in the below and this should change them to work like stock (not tested): //This patches the Tarsier Space Technoplogies Science Hard Drives to function using the same system as the Squad Science Container //Find all parts that have the TST Science Drive module @PART[*]:HAS[@MODULE[TSTScienceHardDrive]]:AFTER[TarsierSpaceTech] { //Remove the science drive module -MODULE[TSTScienceHardDrive] { } //Add the Squad science container module MODULE { name = ModuleScienceContainer reviewActionName = #autoLOC_502201 //#autoLOC_502201 = Review Stored Data storeActionName = #autoLOC_502202 //#autoLOC_502202 = Store Experiments evaOnlyStorage = True // i.e. can nearby regular vessels also do this, or EVA only storageRange = 1.3 canBeTransferredToInVessel = True canTransferInVessel = True showStatus = True } }

I'm trimming down some mods where I only use a handful of parts, but the mods come with dozens of assets. What I want to know, in order to reduce how much KSP is loading, is whether: (a) Are .mu files in GameData folders loaded, even if no part .cfg file refers to them? (b) If the answer to (a) is yes, then, are texture files loaded if no .mu file references them? It's easiest just to write a MM file to remove parts I don't use, but that won't help with load times if they are loaded anyway. If that's the case, renaming /mu files is also fairly easy. But I'd rather not have to import dozens of .mu files to work out what materials they use to know what texture files to rename and which to keep if I don't have to...

Is there any way to change where the images are saved if "save to file" is checked? Is this in a config file somewhere or is it hard-coded?

Minmus will cross Kerbin's equatorial plane twice in one orbit; at the ascending and descending nodes for the planet. This is a useful time to leave Minmus orbit, if the plan is to rendezvous with something in an equatorial orbit of Kerbin. I've searched, but I can't find a list of times that Minmus passes its own ascending and descending nodes. Or even just the first time (i.e. UT + hh:mm.ss) from which I could calculate the rest... Does anyone know if this information has been calculated anywhere? Alternatively: I think this can be calculated from the velocity, Arg. of Pe. and Mean Anomaly at UT zero (both of which are on the wiki). If it's not already been posted somewhere, I may sit down later and try to work it out, so any pointers on doing this would also be welcome.

This works, thanks. As long as the UI in the difficulty settings isn't touched after making the changes in the persistent.sfs file, this seems to work.

Request: Could the 'maximum' vacation time please be extended beyond 100 days, and the maximum % be extended beyond 100%. Suggestion: 300% maximum, up to 1000 days max. I don't use KCT, but I am currently running a career where I only launch once every 20 days. Even with the current maximums, such a schedule means the mod has almost no impact. It would be nice, for example, if I send Kerbals on 100+ days / multi-year missions that they get taken off 'active duty' for a substantial period of time afterwards.

Okay, thanks. After a bit more searching and a refresh on some orbital mechanics I once knew, but have since forgotten after I stopped playing KSP for some time, I've found the calculation steps. I'm putting it here in case anyone else comes across this, trying to work out the same thing. Step-by-step to calculate the longest possible period of time in darkness for an elliptical orbit with the Ap directly above the pole of a body. All values in meters, seconds and radians. Need to know the following: Ap = Apoapsis altitude Pe = Periapsis altitude R = radius of planet (check the KSP wiki) GM = Standard gravitational parameter (check the KSP wiki) Calculate: Ra = Ellipse radius at Ap Ra = Ap + R Rp = Ellipse radius at Pe Rp = Pe + R a = semi-major axis a = = Rp + Ra / 2 b = semi-minor axis b = = sqrt(Rp * Ra) e = eccentricity e = = sqrt(1 - (b/a)^2) F = distance between centre of the ellipse (C) and the focal point / the planetary body (F1) F = = sqrt(a^2 - b^2) Now, presuming that the penumbra of the planet is a cylinder that extends infinitely behind the planet (which is a close enough approximation) we now have enough to use some basic trigonometry to work out the eccentric anomaly, as shown on this diagram from Wikipedia: E1 = Eccentric anomaly as satellite enters the penumbra E2 = Eccentric anomaly as satellite leaves the penumbra E1 = = arccos((F + R) / a) E2 = = arccos((F - R) / a) M = Mean anomaly M = = E - e * sin(E) Calculate M1 and M2 for E1 and E2 respectively ΔM = M2 - M1 n = mean motion n = = sqrt(GM / a^3) Finally Δt = Time to travel between E1 and E2 (Which is the time spent in darkness) Δt = = ΔM/n Note that this time in darkness won't be experienced every orbit. Example. For an orbit around Kerbin, with Ap above one pole of 60,000km and a Pe above the other pole of 120km Δt = 809.4 seconds (As I type this out, I'm sure there's almost certainly a quicker / more efficient way of doing this, but my doctorate is in a social science, so cobbling this together will do for me!) The orbital darkness period for a circular orbit of 120km Ap / Pe is 640.51s Which is, thankfully, quite a bit different than that which I calculated: Which is good, it means I didn't waste all that time when there was a good enough easy estimation! Although, this is a highly eccentric orbit. For less eccentric orbits, calculating the orbital darkness time for an equatorial orbit with Pe & Ap = Pe of intended orbit, and then add a bit for good measure, would be close enough. Useful sources: https://space.stackexchange.com/a/23129 https://en.wikipedia.org/wiki/Eccentric_anomaly and, as always: http://www.braeunig.us/space/orbmech.htm

Could you explain more please? As I would assume the same as Rhomphaia You say the worst case scenario for darkness time doesn't change based upon inclination. But, if the Ap is directly above a pole, how could that lead to a situation where the Ap is directly opposite the sun, through the planet's centre?

Yeah, I realise that, I'm just looking for a way to calculate the worst-case scenario to allow for maximum up-time. But the worst case scenario for a highly eccentric polar orbit will still be much less than the same eccentricity but equatorial.

Breaking ground deployed science parts benefit from both scientists and engineers, so there's a need for a landing command pod / module larger than the Mk2 Lander Can. Sure, I can use the Mk1-3 command pod, but it's very heavy for this role. Can anyone suggest a mod that includes a 3-crew lander can? The 'Tethys' from Near Future, a 3-crew pod designed to be used with small radial mounted rockets, is the closest. But it's even heavier than the Mk1-3, without any of the utility of the stock landing cans. I have ReStock, B9, USI, Stockalike Stations, and a bunch of others, and I was surprised to see that this niche isn't filled by one of these. Any ideas if there's something out there?

The Wiki has the equations for orbital darkness time: https://wiki.kerbalspaceprogram.com/wiki/Orbit_darkness_time And there are a number of calculators, spreadsheets & mods out there that calculate this. However, all are based upon the presumption of an equatorial orbit (or low inclination orbit). Are there any thoughts on how to calculate this for highly inclined & eccentric orbits? I'm planning a number of polar orbit, high Ap, high eccentricity communications relays for RemoteTech. I realise KSP doesn't calculate ec use for on rails craft, but I'd like to have some idea for when building to aim for some kind of plausibility. However, an equatorial orbit with a high Ap would need >70k batteries!... There's a post from 2016 by 'Hamsterjam' regarding the general case on the Wiki talk pages, but the link is long dead: : https://wiki.kerbalspaceprogram.com/wiki/Talk:Orbit_darkness_time#What_about_eccentric_polar_orbits.3F I can find no more information on how to begin calculating this, and all the tools, spreadsheets and mods use the formula that presumes an equatorial orbit...

Is this likely to work with 1.4.x? I'm going through the process of removing some older parts mods & replacing them so I can eventually update my KSP version. Being able to use this for my 1.4.x game whilst I wait for a couple of other mods to update would be great!

I'm currently using Ship Manifest / Connected Living Space. As this is the only mod which I can find that allows for easy transfer of science experiment results between science containers, command pods etc. within a vessel, without needing to EVA and do this manually. But, that's all I need this mod for, so am wondering if anyone knows of a mod that can do this, without everything else that ship manifest / CLS adds?

WI'm planning some large, high part-count, space stations. For Mun & Minmus specifically. I want them low enough that regular trips to the surface for large ships don't have high dV requirements, but, ideally, not so low that my FPS gets tanked by having both high part-count ships and the higher-detail planet terrain kicking in. At certain orbital altitudes the terrain of a planet becomes more detailed, as the procedural terrain (PQS; 'Procedural Quadtree Sphere') fades-in. At higher orbits, just the scaled space is rendered. But, despite lots of searching, this is all I could find in an old thread about it: What is not fully answered in that thread is at what altitudes, for what planets, does the 'noticeable performance impact' of PQS stop, as that is 'turned off completely'. Does anyone know where I might find this information?

There is an issue with Mk2Expansion when installing with CKAN. As reported here:

The orbital darkness calculator I've been using for ages is down: http://www.prism.gatech.edu/~bnichols8/projects/kspdarkness/main.shtml Does anyone know of any website or tool that does the same? I can do this by hand, there's half-decent instructions on the wiki, but it's fairly laborious.

Okay, first version of the tool to calculate hab / multiplier: https://docs.google.com/spreadsheets/d/1jKZmfTO7y3rbAxDKcnhO2PH7fvvtJrceVwzyLpgq4ec/edit?usp=sharing Not trialled it much, so very certainly needs some tweaking, but I'm not gonna get to work on it for a few days, so thrown out here for comments / suggestions

Thanks for the links @mcortez and @DStaal. I've started to reverse-engineering the habitation part of that spreadsheet to take Mass & Volume and produce habitation & multiplier guides. Really basic question: A 1.25m radial part is named as such because it has a 1.25m radius, right? Not 1.25m diameter... Less basic question: Does anyone know of any mod which can show the volume of a part? Edit: I'll start with cylindrical parts, because at least I can get the height for a single part from the VAB...

Habitation calculations? I've got a bunch of mods installed, many of which include support for USI-LS habitation values, some which don't. But, going through them, the values are all over the place. Some objects are loosely in line with similar parts from RoverDude, or the changes to stock that USI-LS makes, some not at all. The habitation multiplier value varies widely for similar parts. The ratio between electric charge / s and habitation multiplier varies widely too. In addition, the habitation module seems to include calculations based 'Kerbal months'. However, the base line habitation-per-seat has since been changed to 7 days, not a month as it used to be, which seems to mean that some habitation modules add a comparably huge amount of hab time for the space they provide. So, I'm planning on going through my mods and creating custom USI-LS habitation support patches (and I'll offer these to mod authors if they want them). But to do so, I'd like to get some sense of what calculations are behind how USI-LS modifies stock parts and the various USI parts which include habitation and hab multipliers. Obviously it's not straightforwardly based upon part volume or crew space, given things like cupolas rightly add more hab multiplier. But some sense of how to set baseline kerbal months get decided, and then work out a reasonable hab multiplier and elec / second use would be really helpful.

Small suggestion: The 'lock bays' option (or however it's written) doesn't make it clear that this serves to seal the bays and can't be unlocked in-flight. I kinda guessed what this meant, but I did just create a test ship to make sure this was the function and it wasn't doing something else. Maybe something clearer, if a little more verbose, might be in order? Something like "Seal payload bay during flight" as an on / off toggle?

Really useful mod, thanks. This should certainly be a recommended mod for RemoteTech. As you are planning on adding antenna info, a “stable max range”. The other thing that “Visual RemoteTech Planner” https://ryohpops.github.io/kspRemoteTechPlanner/ does is calculate night time period and battery power required. This would be a really useful addition in the VAB, if that’s at all possible.

It must have got lost then, the reason I wrote that patch was because I couldn't find the KIS parts in the Containers category! As for a US category, given that US uses the same, unique, manufacturer for all parts means the build menu in an otherwise unmodded game can be used to show only US parts, without the need for another dependency.

Another small Module Manager patch, this time for Community Category Kit. (Which is a dependency for KIS/KAS, which some parts require) US2_CCK.cfg // This config file adds support for the default categories added by Community Category Kit and KIS // // EVA @PART[USEVAX]:NEEDS[KIS]:AFTER[UniversalStorage2] // Only for KIS: KIS adds the cck-eva-items tag, which is not a CCK default. TAC, which is the other :NEED for EVAX, does not. { @tags ^= :^: cck-eva-items } // // Containers @PART[USKASRadial]:NEEDS[KIS]:AFTER[UniversalStorage2] { @tags ^= :^: cck-containers } @PART[USKASWedge]:NEEDS[KIS]:AFTER[UniversalStorage2] { @tags ^= :^: cck-containers } // ///Life Support @PART[USFoodWedge]:NEEDS[CCK]:AFTER[UniversalStorage2] { @tags ^= :^: cck-lifesupport } @PART[USWaterWedge]:NEEDS[CCK]:AFTER[UniversalStorage2] { @tags ^= :^: cck-lifesupport } @PART[USSabatier]:NEEDS[CCK]:AFTER[UniversalStorage2] { @tags ^= :^: cck-lifesupport } @PART[USWaterPurifier]:NEEDS[CCK]:AFTER[UniversalStorage2] { @tags ^= :^: cck-lifesupport } @PART[USCarbonDioxideWedge]:NEEDS[CCK]:AFTER[UniversalStorage2] { @tags ^= :^: cck-lifesupport } @PART[USSolidWasteWedge]:NEEDS[CCK]:AFTER[UniversalStorage2] { @tags ^= :^: cck-lifesupport } Also: With the science update on its way, please consider a Universal Storage version of the 'Science Box' (Experiment Storage Unit). It'd be a great option for those smaller US payload bays so that probe landers with lower-end probes (which can't collect science) could send just a smaller top-part back into orbit and Kerbin, rather than dragging heavy Material Bays all the way there and back...

Thanks for a wonderful mod, Universal Storage was already one of my top faves, and this is just a great revision. Can't wait to see the new science parts. I have done a first pass for a Community Tech Tree patch. In order to avoid arbitrary/personal decisions, I've given priority to authors of supported mods for where they place similar parts. However, this may mean changes that seem odd. e.g. Kerbalism's support for CTT means a bunch of separate US2 Processor parts, which have functions of the Chemical Plant, get dumped together in recycling. I use USI-LS myself, so I would encourage feedback from those using Kerbalism as to whether this makes sense by staying in a similar place as the Chemical Plant or whether the default locations for US2 are better? I can't see support for CTT with TAC or Snacks on their GitHub repos. Please do let me know if I'm wrong, I don't know these mods well. I've made small number of other changes. Personal preference ones are noted as such and at the top for easy removal. I can't see any other obvious uses for the tech nodes which CTT adds. The only other thing that might be worth considering is dropping the tier level on some parts, given CTT adds more nodes (e.g. the Hex core might be better one tier down). But I've not played with US2 enough to tell whether it's worth it. Note for any future changes. If the @PART section in the Module Manager section at the bottom of any part.cfg file changes the TechRequired, then the entrance in the CTT patch file will need an :AFTER switch for US2. US2_CTT.cfg //This config file adjusts the tech required to match Community Tech Tree // //NOTE: The first two part entries are not actually directly CTT related and are more personal preferences. // //Electrical // Battery Wedge moved to Advanced Electronics in order to avoid unlocking >200 capacity at an earlier tech level. @PART[USBatteryWedge]:NEEDS[CommunityTechTree] { @TechRequired = advElectrics } // Guidance Computer moved to Unmanned Tech for kOS. kOS doesn't have CTT support, but this is to avoid unlocking a larger Disk Space at an earlier tier. @PART[USGuidanceComputer]:NEEDS[CommunityTechTree&kOS] { @TechRequired = unmannedTech } // //Utility // KAS/KIS doesn't actually support CTT. But Storage Tech seems an obvious place to put these storage parts. Storage Tech is also the same tier / cost as the default Space Exploration @PART[USKASRadial]:NEEDS[CommunityTechTree] { @TechRequired = storageTech } @PART[USKASWedge]:NEEDS[CommunityTechTree] { @TechRequired = storageTech } // //Fuel // Storage Tech is where Kerbalism places the similar capacity radial tanks which hold gases // Note: This now separates these from the Fuel Cell Wedge in the Tech Tree and may be an undesired change. @PART[USOxygenWedge]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = storageTech } @PART[USHydrogenWedge]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = storageTech } // //Lifesupport // Food Wedge and Water Wedge placed in the respective tech nodes for comparable parts in Kerbalism & USI support CTT @PART[USFoodWedge]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = storageTech } @PART[USFoodWedge]:NEEDS[CommunityTechTree&USILifeSupport] { @TechRequired = enhancedSurvivability } @PART[USWaterWedge]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = storageTech } // //Processors // Kerbalism places the all-encompassing 'Chemical Plant' in recycling. Comparable US Wedges moved to reflect this. @PART[USElektron]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = recycling } @PART[USSabatier]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = recycling } @PART[USWaterPurifier]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = recycling } // Water Purifier acts as Recycler for USI-LS @PART[USWaterPurifier]:NEEDS[CommunityTechTree&USILifeSupport]:AFTER[UniversalStorage2] { @TechRequired = recycling } // //Waste // Waste Wedges placed in Storage Tech in line with similar items for Kerbalism @PART[USCarbonDioxideWedge]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = storageTech } @PART[USGreyWaterWedge]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = storageTech } @PART[USSolidWasteWedge]:NEEDS[CommunityTechTree&Kerbalism] { @TechRequired = storageTech } // Grey Water Wedge (Fertilizer) & Solid Waste Wedge (Mulch) placed in Hydroponics for USI-LS as per how USI-LS patches for CTT @PART[USGreyWaterWedge]:NEEDS[CommunityTechTree&USILifeSupport] { @TechRequired = hydroponics } @PART[USSolidWasteWedge]:NEEDS[CommunityTechTree&USILifeSupport] { @TechRequired = hydroponics } //

I think I've spotted an error in GreyWaterWedge.cfg // Module Manager // Contains @PART code for Module Manager, things that cannot be placed in within PART{} /+ //Kerbalism @PART[USGreyWaterWedge]:NEEDS[USILifeSupport] { @tags = #autoLOC_US_US_GreyWaterWedgeKerbalism_Tags //Universal Storage Wedge Fertilizer USI Life Support } I'm assuming: @PART[USGreyWaterWedge]:NEEDS[USILifeSupport] Should be @PART[USGreyWaterWedge]:NEEDS[Kerbalism] In that section. (I can't see a GitHub for this mod, else I'd post a pull request there rather than filling the forums)