• Content count

  • Joined

  • Last visited

Community Reputation

23 Excellent

About chrisl

  • Rank
    Sr. Spacecraft Engineer
  1. I do manual docking as well, but I have Docking Port Alignment Indicator mod which helps a great deal. I'm using the KSP 1.2.2 compatible version of SSTU, but I have pulled the assets from the latest version just to be sure. I've noticed that the RD-180 (SSTU-SC-ENG-RD-180) is turned 90 degrees compared to the Pyrios engine mount. Is there any way to rotate the graphic for the engine in the cfg file so the Pyrios mount will work? Or a way to rotate the Pyrios engine mount for this one engine?
  2. It would be complicated. I get that. But the advantage is using the same part to represent various station components. You could have a one component with low initial mass, little to no crew accommodations but very high storage capacity (i.e., the Zarya module of the ISS) and another component with high mass (to reflect it having a lot of extra equipment) and decent accommodations but little storage (like Kvant-2 from Mir). Both Zarya and Kvant-2 are based on the same design and both have similar launch masses. Zarya, however, has an 8t dry mass versus the Kvant-2 with around 17t.
  3. @Shadowmage, I've been thinking about this for the last couple days but have been hesitant to post about it figuring it's possible you've already thought about doing this and ruled it out due to the difficulty involved. But it's been rattling around in my head and I need to get it out so..... You mentioned a few posts back that fuel tanks are basically simply because all their available volume is basically used for fuel. Crew components like space stations, on the other hand, are more complicated because the available volume isn't all used for one thing. So that got me thinking. There are basically 4 things that use a station parts volume: Crew Tube, Equipment, Habitation and Storage. I figure, for the most part, everything you might find in a space station will fit into one of those four areas. The "Crew Tube" is easy. You'd have a "shaft" of empty space running down the length of the station part so that crew could move from one end of the part to another, and access most everything in the part. The "Crew Tube" would have a "static" diameter set in the cfg file just like the top/core/bottom diameter of the part. So as an example, if we look at SSTU-ST-COS-M* with a 4.5m diameter and 6.1m length, we'd have 72.38 m3 of usable volume (91.23 from the part - 18.85 for a 2m diameter x 6m long "Crew Tube" leaves 72.38 m3). It would also have a bass mass of a similarly sized, service module style fuel tank and a 0 CrewCapacity. The last three (Equipment, Habitation and Storage) would be set in game as you're building the part You'd use a slider for Equipment which represents everything from lab equipment, control stations, guidance computers, exercise equipment, etc. For every kg of equipment you add with the slider, you use up some portion of the usable volume (0.005 m3 / kg, for example). You'd also use a slider for Habitation which represents sleeping "quarters", living space, lavatories, dining space, etc. This slider would add CrewCapacity in exchange for usable volume. For every CrewCapacity you add to the part, you use up 5m3 (for example) of usable space. Whatever usable space is left after setting the Equipment and Habitation sliders would be Storage (i.e., fuel, life support supplies, etc). In this way you could use the same part to recreate the Unity, Harmony and Tranquility modules of the ISS. All are basically the same size but each had very different internal setups. Unity is basically all equipment with some storage. Harmony has crew "quarters" with some equipment and some storage. Tranquility as some habitation space with a fair bit of equipment but lots of storage. You could also use the same parts to recreate Mir and ISS components like Kvant-2 from Mir which had lots of equipment and Zarya from ISS which had lots of storage. I'm assuming the hardest part would be getting the two sliders to work together. If you set the Equipment slider to 100%, you couldn't have any Habitation space, for example. *I'm using basically real world scaled parts. I'm assuming you would have started there, then scaled things down for Kerbal size. I'm also assuming that 0.1m is used for the "skin" of the module. So if SSTU-ST-COS-M has 4.5m diameter x 6.1m length dimensions, then volume would be calculated based on a 4.4m diameter x 6.0m length. Finally, I'm basing my measurements on the core part with no caps. Any caps you add would follow the same rules as the core but it was simpler to example this way.
  4. I've only looked at them in the VAB so far. It shows the mass changing when you inflate but not he volume. I'll put one in orbit and test it out.
  5. @Shadowmage, with the inflatable habitat modules, is there any way to have the volume availability change when inflated?
  6. What I'm hoping to do is create a single command that will pull the volume figure on every CAP that we find in a part. @CAP,* { %volume = #$@SSTU_MODEL[#name]/volume$ } So if there are five CAP in a particular part, it would grab the name of each, look for the SSTU_MODEL with the same name, and return the volume of that part.
  7. Is there a way to search for an external part using the name of the module in the part you're currently working in? For example: SSTU_MODEL { name = Adapter-2-1-Short volume = 10 . } PART { . MODULE { . CAP { name = Adapter-2-1-Short volume = #$SSTU_MODEL[#name]/volume$ } } } I keep getting errors but I'm not sure if they are because what I trying to do is not possible or if I simply have a syntax or formatting error.
  8. Since I'm basing it off real life parts (Kvant-2, Kristall, Spektr & Priroda) I'm not exactly sure how much dV they should have. Considering the numbers I can find only allow for about 2.5t worth of supplies and fuel (35% of which would be used for 90 days worth of life support), I'm guessing they won't have much dV. Maybe around 250. The dry mass I'm aiming for would be 17t with a launch mass of around 19.5t.
  9. There is a Volume listed in the SSTU_MODEL for Adapter-2-1-Short (in \SSTU\Data\ModelData\ModelData-MFT-Adapters.cfg). It's currently set to 27. EDIT: Oh. You can't adjust the SSTU_MODEL volume for a CAP like you can for a CORE (inside SSTUModularStationCore). You can only specify a new volume, right? I should point out, I do have a KSP test install with just SSTU. I get the same values there for mass and volume as I do with my RO test install when leave SSTUVolumeContainer instead of replacing it with ModuleFuelTanks. But I do understand what you're saying. It's too bad though. RO is awesome and SSTU is awesome.
  10. Using that I get volume of 8.36kL and 9.446t dry mass. Admittedly, that does add up to about 19.6t launch mass with just fuel but that's closer to 1890dV and leaves no room for life support. With 150 days of life support (50 days for three crew), I end up with about 1056dV and a launch mass of 17.67t (just shy of 5.5t of fuel). But if the dry mass of the Mir modules is supposed to be around 17t, and launch mass is around 19.5t, I should only have 2.5t of fuel and life support. If I remove ModuleFuelTanks and put SSTUVolumeContainer back in, the volume and mass still don't add up. Dry mass results in 10.674 (15.471 with fuel) and volume results in 9720L which seems like a lot of space for life support. But at least this helps me figure out what I need to do. So, for example, I could add something like: @CAP[Adapter-2-1-Short] { @volume *= .5 } That would reduce the volume of that adapter by half? The reason I'd want to do this is, I'm assuming that the top and bottom adapters are adding all of their available volume. For example, in an earlier set of tests, I found that the Adapter-2-1-Short was adding around 17.8kL (with SSTUVolumeContainer) to my available volume. Considering the core gives 9.72kL (with SSTUVolumeContainer), that seemed like an excessive increase.
  11. Looking at Mir, all the TKS derived components look to have a diameter of around 4.35m, a launch mass of around 19.5t and dry mass ranging from 17t-18.5t depending on the module (according to Right now I'm basically just trying to setup the DOS parts as "generic" for use as Mir components. So I'm shooting for 4.35m diameter, 17t dry mass and 19.5t launch mass (though I know the solar panel I use will slightly alter the masses). I'm using the following to setup the size: @MODULE[SSTUModularStationCore] { @currentTopDock = Mount-None @currentBottomDock = Mount-None @topDiameter *= 1.74 @coreDiameter *= 1.74 @bottomDiameter *= 1.74 %useAdapterMass = false %useAdapterVolume = false %useAdapterCost = false @CORE[*] { @volume = 1.74 @mass = 1.74 } @SOLAR,* { @POSITION,0 { @position[*] *= 1.74 //rotation = 0, 180, 0 &scale = 1, 1, 1 @scale[*] *= 1.74 } @POSITION,1 { @position[*] *= 1.74 //rotation = 0, 0, 0 &scale = 1, 1, 1 @scale[*] *= 1.74 } } } From what I can see, this is resulting in the SSTU-ST-DOS-TKS (which I've just been using to test with) to have a topDiameter = 3.2625 and a core and bottomDiameter = 4.35. So the size is right. Setting the Core mass to 1.74 only results in a dry mass of 9.603t. And setting Core volume to 1.74 results in an available volume of 7.88kL. So it looks like I need to use Core mass = ~3.0 and Core volume = <1.0. As a separate question, if I use the useAdapterMass, useAdapterVolume, and useAdapterCost flags as you mentioned earlier, is there any way to adjust the mass and/or volume of the top and bottom components without altering the actual SSTU_MODEL?
  12. Oh, cool. I may give this a try even if it messes with delta-v and life support configurations. I'll just have to pay attention to those when I change things around. Now I just need to understand how mass and volume are being calculated. I know it has something to do with topDiameter, coreDiameter & bottomDiameter (or maybe just one) multiplied by the core mass and core volume. I'm just not sure how exactly the diameters are being used to generate mass and volume. No worries. I'm expecting that.
  13. I'm playing RO/RSS/RP-0 with SSTU so SSTUVolumeContainer is replaced by ModuleFuelTanks from RealFuels. So that may explain what I'm running into. Alternatively, it could be because I'm still using SSTU (which I think is the last one compatible with KSP 1.2.2). But I've noticed something. If I use SSTU-SC-TANK-MFT-A to create a tank, the dry mass and total volume change if I add a nose or mount. But if I use a space station part and change the top or bottom of it, the dry mass and total volume doesn't seem to be effected
  14. I'm still using an older version since I'm still on KSP 1.2.2 but that explains that. Thank you.
  15. When using a space station part (like SSTU-ST-DOS-COM), you can specify a top and bottom docking port. How does SSTUModularStationCore know how to set each docking ports nodeType?