[0.23.5] Realism Overhaul: ROv5.2 + Modlist for RSS 6/30/14

[jrandom]

Check out the fuel cell in the Gemini service module in FASA.cfg

I'll take a look! I'm going to actually fly some missions with life support the way it is in this version (barring any horrible inaccuracies should they be found -- I'll fix those right away), but after that I'll look into the fuel cells, plant/algae-based recyclers, and some kind of method for growing food.

Regarding pod electricity: note that the ~4kWh figure for Apollo is because it had massive fuel cells. Mercury, for example, had 13.5kWh (48600EC) in batteries. So (while I'm sorry to say this) you might be better served hand-rolling the battery capacity for each pod. MM really needs a "is this value < this" check, then you could detect unchanged pods.

Second, that 2kW figure I quoted is for Apollo with all its guidance and comms; Soyuz makes do on less than 1.3kW from solar panels, and Mercury used only a bit over 500W.

Hrm. I'm not personally trying to replicate historical spaceflights so I was just trying to aim for a sort of realistic average. I could always add some module or tag that the generic electric charge .cfg could ignore, but it would still require the hand-crafted pod energy requirements to include this tag so they'd be skipped by the generic one.

As it stands right now, each pod gets a base rate of 0.5 kW for control systems/heat/whatever, an additional 0.1666666 kW per Kerbal, a TACLS base rate of 0.5 kW, and a TACLS additional 0.1666666 kW per Kerbal. I kept life support usage separate to better allow for replacement values or other life support mods.

These numbers were chosen to converge on 2 kW for the three-kerbal Mk1-2 rescale. I can very easily alter any of the pod values on a per-crew-capacity basis, but the TACLS ones are global no matter how many kerbals can fit in the pod.

Any ideas on what a better "average" set of values might be? And if we want to decide on some kind of naming scheme for tags so that generalized-settings .cfgs can ignore them, now'd be the time to do that. Something like "HasElectricChargeSettings" or what not.

Also, in FAR, incompressibleRearAttachDrag should be 0.01

Added that to my set of configs yesterday.

Finally, regarding the pFairing rings. Are you using my modified masses? I use less than cubic scaling, and a smaller original mass anyway, since the masses don't seem to follow real fairing/base/interstage masses that well.

Nope. That was my first foray into modding and didn't even consider the mass issue. I may have shrugged and though "meh, close enough" but now I know better 'round you fellahs. If you get me more correct numbers for what they should mass, I'll update my file.

[NathanKell]

jrandom: I meant in terms of it using LH2 and LOx, so no need to add more resources. Frankly, I'm not sure _anything_ uses GH2 (except boiloff-driven thrusters, but better to treat it as LH2 IMO, and futz with the Isp).

Regarding electricity. The issue is that your pods will last ~3 hours for the Mk1-2, and less than that for the Mk1. That's kinda frightening. Especially since even the 2.5m battery is only like 64,000 charge, which is only another 8 or so hours for the Mk1-2.

Regarding FAR: Yes, it's in, but it's 0.1 in your zip, not 0.01

Re: masses etc. Welcome to the world of modding

I have to do more research into fairing mass, but as a geusstimate...well, just use the same mass for your new rings I did for mine? Or maybe 90% mine? (Since they're lower-profile).

[jrandom]

jrandom: I meant in terms of it using LH2 and LOx, so no need to add more resources. Frankly, I'm not sure _anything_ uses GH2 (except boiloff-driven thrusters, but better to treat it as LH2 IMO, and futz with the Isp).

That'll certainly be easier. I'm reading up on how to get lightwave models into Unity. I fear I am a lost cause now -- configs just aren't enough anymore, I have to make shapes!

Regarding electricity. The issue is that your pods will last ~3 hours for the Mk1-2, and less than that for the Mk1. That's kinda frightening. Especially since even the 2.5m battery is only like 64,000 charge, which is only another 8 or so hours for the Mk1-2.

This quite readily illustrates just how little I know about real-world spacecraft, of which I am ashamed. If we go with the notion that specialized configs for pods can be ignored, what should I be aiming for (in a generalized sense) for power usage and in-pod battery capacity?

Regarding FAR: Yes, it's in, but it's 0.1 in your zip, not 0.01

Yikes! What about sonicRearAdditionalAttachDrag? Should that stay at 0.2 or be altered as well?

Re: masses etc. Welcome to the world of modding

I have to do more research into fairing mass, but as a geusstimate...well, just use the same mass for your new rings I did for mine? Or maybe 90% mine? (Since they're lower-profile).

I'll run with the 90% value, since that seems like a good starting point.

Say, I notice you've got some extra stuff in your pFairings.cfg -- stageOffset, childStageOffset, and a module called ModuleDecouple. Looks like they're adding properties as opposed to modifying existing ones. Should I add these to the fairing ring bases as well?

Wait... there doesn't appear to be re-scaling in here! Is that in a different file?

Edit: Nevermind, I found the rescaled parts.

Edited December 16, 2013 by jrandom

[ferram4]

sonicRearAdditionalDrag should be 0.2. Everything else is correct. That is all.

[jrandom]

Cool! Now I just need sane electricity usage and battery capacity numbers!

[NathanKell]

That'll certainly be easier. I'm reading up on how to get lightwave models into Unity. I fear I am a lost cause now -- configs just aren't enough anymore, I have to make shapes!

Heh.

This quite readily illustrates just how little I know about real-world spacecraft, of which I am ashamed. If we go with the notion that specialized configs for pods can be ignored, what should I be aiming for (in a generalized sense) for power usage and in-pod battery capacity?

Eh, they vary so much! Hard to keep track of them all, let alone balance.

I mean, the Apollo Command Module only had ~4kWh of batteries. But with the SM detached, the current draw was doubtless far less than 2kW.

I would recommend a base capacity of ~24,000 and then about 12h of charge (EC/sec used, total, * 43200). Avionics for the smaller pods should be substantially less, like maybe only 0.1EC/s for the 1-person pods. This should yield about a day's endurance for 1-person pods, and somewhere around 14 hours for the 3-person.

I'll run with the 90% value, since that seems like a good starting point.

Say, I notice you've got some extra stuff in your pFairings.cfg -- stageOffset, childStageOffset, and a module called ModuleDecouple. Looks like they're adding properties as opposed to modifying existing ones. Should I add these to the fairing ring bases as well?

Wait... there doesn't appear to be re-scaling in here! Is that in a different file?

Edit: Nevermind, I found the rescaled parts.

Those are because I added decouplers to them.

[jrandom]

Lessee... so a base rate of 0.1 kW for 1-kerbal pods and still 0.5 kW for 3-kerbal pods? Maybe flatten out at 0.5 so it doesn't scale linearly for larger pods?

How about the per-kerbal usage? I can scale that as well, so long as I have some sample points. Really, the 0.16666 came from just filling in the remainder when making the Mk1-2 hit 1kW for non-life-support power usage -- 0.5 kW base and then divide the remaining 0.5 kW by three. Total guesswork. I can always make batteries larger so the in-pod resources will last for a day, but after that I still need realistic consumption rates.

Hrm. Okay, so I need *targets*. Not considering life support:

• 1-Kerbal Command Pod: 0.1 kW base, ? kW per kerbal
  
• 3-Kerbal Command Pod: 0.5 kW base, 0.16666 kW per kerbal?
  
• 6-kerbal crew cabin, non-command: ? base, ? per kerbal
  

If I can get these three sample points, I can extrapolate the rest.

The base and per-kerbal life support rates do not include running recyclers (those have their own individual settings). It sounds like maybe my base rate of 0.5 kW and per-kerbal rate of 0.16666 kW is too high? By how much? Since it's not customizable on a per-pod basis, I need to know what a good sort of average would be. Something that still has a realistic feel to it.

Again, I'll work on making these configs ignore anything with some special tag I have yet to determine, so that historical players can easily have their own realism settings without fear that mine will override them.

[eggrobin]

The life support consumption includes the carbon scrubbers (which are assumed to be regenerative in TAC).

You should probably rescale the EvaElectricityConsumptionRate in TAC too. For reference: the Orlan spacesuit consumes ~54 W, A7L consumed ~48 W. 50 W seems to be a nice round number.

Regarding LOX/LH2: the point is not so much their state (O2 and H2 seem to always be stored as liquids for fuel cells), but the separation of the life support and propellant circuits. I have found no instances where LOX/LH2 used for life support was also used for propulsion. While it may be useful to use O2 and H2 from electrolysis as a propellant (there could be a converter for that), you don't want the Apollo fuel cells to start using up the propellant from the S-IVB.

We already have a separate Oxygen resource for life support oxygen, so having a separate Hydrogen resource doesn't seem too outlandish. We don't really care about the physical state of the life support resources.

This allows for accurate modeling of the Apollo life support system: the same Oxygen supply is used for breathing and power/water production. The Hydrogen and Oxygen used to power the fuel cells is completely separate from the LiquidH2 and LiquidOxygen used to propel the spacecraft. (They are all liquids, but the point isn't really the state they are in, we only care about their intended use.)

This is also how the STS life support system worked.

For fancier mission profiles such as sending electrolysers to Mars in order to produce LH2 and LOX to go back, a converter from Hydrogen and Oxygen (the life support stuff) to LiquidH2 and LiquidOxygen (the propellants) could be used. Whether we call that a liquefaction unit, a glorified pump or an atomic cat remains to be seen.

As far as methane goes, unless we want to model pyrolysis, we can get away with modeling the Sabatier reaction as a the following kind of converter:

CarbonDioxide (LS) + Hydrogen (LS) --> LqdMethane (MFS) + Water (LS).

The correct amounts are left as an exercise to the reader.

Edited December 16, 2013 by eggrobin

[jrandom]

The correct amounts are left as an exercise to the reader.

You just want me to do math!

cries

The issue I see here with Oxygen and Hydrogen being used in life support is that right now we've got Oxygen at 300kg/m^3 -- highly compressed, but still a gas. A fuel cell is going to use the liquid form which means a completely different density, ala. LiquidOxygen. The only way to keep things separate would be to add LifeSupportLiquidO2 and LifeSupportLiquidH2 as new resources, and I'm not sure this is the correct road to go down. The compromise might have to be the fuel cell running off of the current LiquidH2 and LiquidOxygen fuels.

I'll work on the EVA power numbers after work today.

I'll read up on what I can for generalized pod power consumption, but any and every recommendation I get from all of you in the thread helps. I've got a few small samples from NathanKell, so that's a start.

[eggrobin]

The issue I see here with Oxygen and Hydrogen being used in life support is that right now we've got Oxygen at 300kg/m^3 -- highly compressed, but still a gas. A fuel cell is going to use the liquid form which means a completely different density, ala. LiquidOxygen. The only way to keep things separate would be to add LifeSupportLiquidO2 and LifeSupportLiquidH2 as new resources, and I'm not sure this is the correct road to go down. The compromise might have to be the fuel cell running off of the current LiquidH2 and LiquidOxygen fuels.

Technically, the fuel cells use gases (the stuff is just stored as a liquid, see the SM2A-03-Block II-(1) Apollo Operations Handbook, page 2.6-21/2.6-22: the O2 and H2 go through a preheater before reaching the fuel cells (or the CM)). In many life support systems (e.g. Apollo, STS), the O2 used for breathing is also stored as a liquid, so we might as well argue to replace Oxygen with LiquidOxygen altogether.

The density of resources in KSP is not fixed however, so we could have denser 'cryogenic' tanks for Hydrogen and Oxygen (LS) as well as the normal ones. If having different densities for the same resource is a problem, we can just assume everything to be liquid.

Having one resource per physical state is problematic anyway: the density depends on the temperature and pressure of storage. I think the dichotomy here really is the circuit the O2/H2 is in (life support vs. propulsion) rather than the physical state.

[jrandom]

Right now in TAC the life-support resources have their in-game 'density' setting set to the number of kilograms used per day, which actually makes it easier to have different densities -- just put more or less in the tank! The 'utilization' factor in MFS v4 should (in theory) allow full flexibility, but I don't know if it's possible to have more than one tank definition hold the same kind of resource. If it does, that would easily allow for both gaseous and liquid storage of life-support oxygen and hydrogen.

[eggrobin]

That's what I meant.

I think for now, we can just go with Oxygen and Hydrogen for life support, LiquidOxygen and LiquidH2 for propulsion, and we can decide what they are when we define a tank.

The biggest challenge remains the naming of the life support to propellant converter.

[eggrobin]

I made a model for an electrolyser (https://drive.google.com/folderview?id=0B4y-shYXMH9BcEhsUWNyLXpXZEU&usp=sharing, you'll want to use a scale and rescalefactor of 1.125 in the TACLS Water Splitter cfg to get the result above):

Javascript is disabled. View full album

It somehow looks awkward though, should I try to put a couple of carter panels so that the rocket looks more continuous? I tried to stay away from the 'textured cylinder' look, as there are going to be a lot of recyclers: electrolyser, Sabatier reactor, Bosch reactor, fuel cell, water recovery system, etc. It would be difficult to come up with convincing and distinctive textures for all of these (how do you make texture for a Sabatier reactor that distinguishes it from a Bosch reactor?).

As far as licensing goes,

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

[Scripto23]

That's a really nice looking part, nice change of pace from bland cylinders. It would be a shame to hide it under panels, but I can see how some people would like the smooth and continuous look. Maybe you could size it so that it would fit in one of those 6S Service Compartment Tubes (or similar) for the people who want the smooth look, but still retain the option of having the cool part for people like me who build service modules that are hidden by fairings at launch, then exposed in space.

[jrandom]

By default the electrolyser in my configs is only 1-meter wide, so when I integrate the part and scale it, it should hide away nicely. Actually, I think maybe we could use that part for all the recyclers? Maybe have different-color textures to visually tell them apart?

[eggrobin]

It should be fairly easy to retexture this for the other recyclers, but I intend to just change the model a bit for the fuel cells (they should be quite similar, but with only one loop (cell -> O2+H2O -> centrifuge -> O2 -> cell) and H2 pressure being maintained on the other electrode).

The other recyclers should probably look quite different in order to make sense; I need to think about that.

[SFJackBauer]

RealEngines 0.2

Uploaded a new config for RealEngines. Changes:

- Increased engine masses by 50% to account for thrust structure mass

- Added Tech Level 0 config so that engines now work with thrust curve from MFS

- Decreased upper/orbital engines sea-level Isp to properly account for the vacuum-optimized nozzle flow separation at sea level and low exit pressure

- Fixed relationship between vacuum and sea-level thrust for all engines

- Added a few more engines from NovaPunch

Updated engine list, download link and instructions on my signature, or this post.

[jrandom]

It should be fairly easy to retexture this for the other recyclers, but I intend to just change the model a bit for the fuel cells (they should be quite similar, but with only one loop (cell -> O2+H2O -> centrifuge -> O2 -> cell) and H2 pressure being maintained on the other electrode).

The other recyclers should probably look quite different in order to make sense; I need to think about that.

I'll hold off on integrating 'em until you've settled on the best shapes.

[AbeS]

@SFJackBauer I don't know why but the names of the engines aren't changing, and some KW and AIES engines (most of them) have floating attaching nodes with really tiny engines, do you know why would that be? I will check if there is any another rescaling .cfg or something somewhere

[jrandom]

The next iteration of command and crew pod energy usage .cfgs is up. EVA power had to be added to the list of "set in the TACLS UI at KSC" values since I can't alter it automatically.

I split command pods and crew modules up into two separate configs. The crew modules use less non-life-support power . I figured that was appropriate considering they can't be used to control a ship. Life support remains at 0.5 kW base + 0.1666666 kW per kerbal. Battery capacity is set to 24000 base + 12 hours extra charge.

[NathanKell]

AbeS: Sounds like you have multiple engine configs. Make sure the newest RealEngines is the only engines file you have (no RftSEngines.cfg or Engines.cfg in any folder under GameData)

[AbeS]

I did make sure I didn't, it's really weird

[SFJackBauer]

I did make sure I didn't, it's really weird

Yeah its weird. If you look into KSP.log or KSP_Data\output_log.txt there should be two lines where ModuleManager modifies the engine, for example the KW Maverick-V:

[ModuleManager] Applying node RealEngines/real_engines_rescale/@PART[KW2mengineMaverickV] to KWRocketry/Parts/Engines/2mMaverickV/part/KW2mengineMaverickV
[ModuleManager] Applying node RealEngines/real_engines_stats/@PART[KW2mengineMaverickV] to KWRocketry/Parts/Engines/2mMaverickV/part/KW2mengineMaverickV

If there are any other lines beginning with ModuleManager modifying that part, then its a conflict. If the lines do not appear in the log, that's another issue.

[AbeS]

There are only two lines like the ones you say per engine, really weird stuff I'll probably do a clean install of KSP all mods in 0.23 I guess I may have a mess somewhere

[SpoF]

I actually had the same problem as AbeS, did a manual fix in the files, seems like you use a % instead of the @ ? At least replacing that helped me in some cases where rescaleFactor was in the original part.cfg. Also had to adjust some nodes, as they were ****ed up too on all the engines that didn't have rescaleFactor in the original .cfg