From RO_Squad_Pods.cfg, we see the following amounts of ElectricCharge:

Mk1: 48.6k
Mk1-2: 12.24k
LanderCabinSmall: 43.2k
mk2LanderCabin: 72k

No other pods come with electric charge at all (which is notable, because it means they need additional batteries to perform life support functions).

While it's easy enough to add batteries, the Mk1-2 pod (3 person) contains much less ElectricCharge resource than the Mk1 pod (1 person). With three times the people, I'd expect it to carry more. :)

(I also have to seem a craft in VAB where the Mk1-2 has no electric charge at all, but I'm not sure if that's related to RO at all; I'm still investigating.)

Many thanks!

~ pjf

The mass as shown in the parts list is correct, but when you actually use one, its mass is too low.

Screenshot: http://i.imgur.com/L0Ferxz.jpg

The MOL Cargo bay is cool. I can stick stuff in it and have it nicely shielded away. However it seems to have two open/close controls, either of which toggles the bay doors, and they can be inconsistent (one showing open, one showing closed). It looks like it should only have one, since either button opens both bay doors.

The stackable MOL cargo bays don't appear to be functional. I can add them, but the end-caps don't seem to contain the extra nodes needed to allow equipment to be stacked inside them.

It could actually be FASA issues, rather than RO, but I seem to recall RO replacing door animations at least (which may explain the double open/close buttons).

When you first place a 0.3m RC Stack Chute, the top and bottom nodes are incorrect. There will be a gap above and below the chute can.

If you open the action group editor, cycle the chute size up then back down and click apply, the nodes will now be correct.

Technically, CO2 scrubbing with lithium hydroxide produces water:

2LiOH + CO2 → Li2CO3 + H2O

The TACLS scrubbers in RO use this reaction.

While it's true that lithium carbonate isn't very soluble in water, I can't find any record of crew drinking the water from the CO2 scrubber, because doing so would probably cause them to seriously chill out due to its pharmacological effects. I believe this is undesirable in manned space flight.

I'd suggest the scrubbers produce waste-water rather than water.

I'm fairly certain that the FASA Agena flight pack is not supposed to have the Bell engine built in. If you look at the original FASA part it has only the RCS, and if you look at pictures of the real Agena it is very clear that the Bell engine attaches to the bottom of the flight pack.

Otherwise stupid Unity will spike between control points because Unity.

Like the title says...as appropriate of course.

when playing with FASA, i noticed i could not properly build a SATURN V, for various reasons. starting with the apollo CSM: the parachute attach node is offset, and the deployed parachute model appears, as if the parachute was deployed inside the VAB; the launch escape system has wrong attachment node position, the heatshield is not available on the editor(no shielding on the capsule itself either)
the CSM separator is not there, the main fuel tank for the CSM is also not there. did not check for the actual CSM rocket engine. the apollo floats added on the new FASA are not configured for RO.
I might have missed something, this was all i was able to notice when playing around with the parts.

Hey Nathan,

Apologies for opening a ticket here; I'm loathe to add to the already enormous KSP forum threads with something which I'm sure can be closed off very quickly.

I'm using RPL with an older version of RealismOverhaul (5.1), and I'm about to do an update dance for all my mods. I noticed that I'm using FASA 3.86, and I know I installed that version for a reason, but it looks like I didn't record that in my GameData commit log¹.

Was an older version of RO (or RPL) incompatible with newer 4.xx versions of FASA, or am I simply second-guessing myself here?

Many thanks for all your incredible work; you're one of the heroes of the KSP modding community.

~ Paul

¹ Using git to manage installed KSP mods is pretty much the best thing ever.

The scaling for the Almaz station solar panels in my pack is incorrect. When I made the panels I made them too large so I had to scale them down by 10% from 0.80 to 0.70 so for RO they should not be scaled to 1 but 0.90 otherwise they will be too large and clip into the side of the station.

almaz_pan_l
almaz_pan_r

@advicedawgg
@Felger

I have repeatedly observed the FASA Apollo and Gemini pods rolling over and gyrating during reentry, causing them to burn up. This happens reguardless of whether or not the pods are in descent mode.

After some further testing I was able to narrow the problem down the pods have either incorrect masses, broken aerodynamics , or both.

STEPS:
1.Load a bare bones RO+RSS setup
2.Create a craft with a 30m procedural SRB
3.Launch
4.Watch as SRB starts to overheat at ~10s
5.Watch as SRB explodes at ~50s

THEORY:
It's probably caused by...
*Temperature limit for all parts is now 800, unless specified otherwise.
from the R7 changelog, seeing as it explodes at about 800.

The ASET ALCOR part is showing up with a mass of only 132kg, making it absurdly light, despite the RO configs setting it to a mass of 2.6 tons (as it should be).

Look at.

Should be ~150t, is about 110t. And there's some errors in volume vs TANK.

Universal Storage is a set of gorgeous parts, including a fuel cell, which I very much want to use with RO.

Changes required:

• Update the oxygen, hydrogen, and fuel cell wedges to contain LOX and LH2 rather than plain 'oxygen' and 'hydrogen'. (LOX/LH2 is already mentioned in the part descriptions.)
• Adjust the fuel cell to take realistic inputs and give realistic outputs and give realistic outputs. (Potentially just by scaling the values we currently have for the Apollo service modle.)
• Adjust the Elektron (water splitter) appropriately. (I haven't looked at this at all.)
• Figure out what to do for users who wish to warm LOX into breathable O2.
• See if I've missed any parts.

I know that Paul has been using this table (which he prepared, because he's awesome) to figure out various conversions, so I suspect that for storage a lot of the values will be close to what we need. I also know the fuel cell is based upon the Apollo era ones and has a "real" output of about 528W (let's say about 0.5EC/sec).

For converting LOX into O2, I suggest we add that functionality to the cores (scaffolding) itself. This means any existing designs are still suitable for O2 life support, without adding actions to oodles of parts.

RV-025 and RV-050 can be configured for monoprop, but their larger RV-105 cousin can't. I'm guessing we'd like these to be consistent. :)

Also, I'm just throwing bugs up here as I find them, I don't want you to feel pressured to fix them or anything.

Keep doing amazing work!

<3 Paul

@pjf did calculations, and they're way off my original guesstimate values. See KSP-RO/RP-1#103 for details.

Part LazTekPulseJetNacelle

Please check (whoever has time) pressure-fed engines, and make sure their Engine Ignitor defines (both inside and outside CONFIG nodes) have that marked properly.

RealismOverhaul versions always used to start with a v.

As of RO7, they don't. Consequently we index them, but the comparison algorithm (which is enshrined in the spec, and won't change no matter how many capital letters Felger uses) believes that 7.0.0 is older than v6.x.x, because it's missing its 'v'.

I've manually tweaked this in CKAN-meta, but this is a humble request release tags start with a v in future. :)

Many thanks,

~ Paul

How should alternators be handled? Were (are) the avionics and the payload always battery powered, or did (do) pump-fed engines hook into the main circuits with their generators?
I would guess with pressure-fed engines (which lack generators to run the pumps) no alternator should be simulated, but for pump-fed engines...?

Just leaving an issue here so there's a link between RO and TACLS.
Here's TaranisElsu's post: taraniselsu/TacLifeSupport#24

https://github.com/KSP-RO/RealismOverhaul/blob/master/RealismOverhaul/RO_SuggestedMods/Squad/RO_Squad_Engines.cfg#L2204

Nozzle diameter supposed to be ~1.1-1.2m, currently ~0.15m. Missing % for scale, possibly for others?

The magnetic pull causes severe enough vessel bounce that zeroing out velocity for a successful dock is hindered.

I have been doing some work on getting the Luna E1-A to scale, functional, and accurate.

I have modifications for the r7_vostok_blok_e_lunar and r7_vostok_blok_e_vernier parts, which don't appear to have any corrections yet.

Should I add these edits to the end of a logical RO_SuggestedMods/RaiderNick file, like the RO_RN_R-7_Tanks.cfg one, or create a file of my own?

reported on irc by user ceta, verified by me (fresh RO, up-to-date FASA) to be a real problem.

Someone needs to go through all six and compare to known info and fix the issues. The propellant volumes do not appear correct, at least on first glance.

Closes #182 and #183

Mods that don't come bundled with a .dll get run after mods which do, meaning that :FOR[RealismOverhaul] MM stanzas we expect to run after early-alphabet mods may not.

Right now, this is causing pain with the AIES antennae, which don't have their config applied at all, and never have. It almost certainly is going to be the ause of some weirdness with FASA parts, for the same reason.

It seems that it would make sense to create a :FOR[RealismFixups], which runs during MM's non-dll run. This means we don't have to use :FINAL, and mods which alter RO can choose to run :AFTER[RealismFixups] if they have need to do so.

For reference, here's the MM run order for my current install, demonstrating the problem:

~/.config/unity3d/Squad/Kerbal Space Program$ ack "\[ModuleManager\] Applying" Player.log | perl -nE'say $1 if /(:(?:BEFORE|FOR|AFTER)\[[^]]+\])/i' | uniq
:FOR[AJE]
:AFTER[AJE]
:FOR[CrossFeedEnabler]
:FOR[DMagic]
:AFTER[DMagic]
:FOR[DeadlyReentry]
:FOR[EngineGroupContoller]
:FOR[FerramAerospaceResearch]
:AFTER[MechJeb2]
:FOR[pWings]
:FOR[ProceduralParts]
:AFTER[ProceduralParts]
:FOR[RealChute]
:AFTER[RealChute]
:FOR[RealismOverhaul]
:FOR[RealFuels]
:AFTER[RealFuels]
:FOR[RealSolarSystem]
:BEFORE[RealismOverhaul]
:FOR[RealismOverhaul]
:AFTER[RealismOverhaul]
:FOR[RemoteTech]
:AFTER[RemoteTech]
:FOR[TacLifeSupport]
:AFTER[TACLifeSupport]
:FOR[Karbonite]
:FOR[KolonyTools]
:AFTER[KolonyTools]
:FOR[kOS]
:FOR[FilterExtension]
:FOR[RP-0]
:FOR[RSSTextures]
:AFTER[RSSTextures]
:FOR[RVE]
:FOR[RO-RCS]
:FOR[RealPlume]
:FOR[HotRockets]
:FOR[MKS]
:FOR[OKS]
:AFTER[AIES_Aerospace]
:AFTER[FASA]
:FOR[AJE]
:AFTER[AJE]
:FOR[CrossFeedEnabler]
:FOR[DMagic]
:AFTER[DMagic]
:FOR[DeadlyReentry]
:FOR[EngineGroupContoller]
:FOR[FerramAerospaceResearch]
:AFTER[MechJeb2]
:FOR[pWings]
:FOR[ProceduralParts]
:AFTER[ProceduralParts]
:FOR[RealChute]
:AFTER[RealChute]
:FOR[RealismOverhaul]
:FOR[RealFuels]
:AFTER[RealFuels]
:FOR[RealSolarSystem]
:BEFORE[RealismOverhaul]
:FOR[RealismOverhaul]
:AFTER[RealismOverhaul]
:FOR[RemoteTech]
:AFTER[RemoteTech]
:FOR[TacLifeSupport]
:AFTER[TACLifeSupport]
:FOR[Karbonite]
:FOR[KolonyTools]
:AFTER[KolonyTools]
:FOR[kOS]
:FOR[FilterExtension]
:FOR[RP-0]
:FOR[RSSTextures]
:AFTER[RSSTextures]
:FOR[RVE]
:FOR[RO-RCS]
:FOR[RealPlume]
:FOR[HotRockets]
:FOR[MKS]
:FOR[OKS]
:AFTER[AIES_Aerospace]
:AFTER[FASA]

Relates to sarbian/ModuleManager#28 .
Causing pain to KSP-RO/RP-1#135 .

Right now both the sasModule and advSasModule provide the same
torque (0.5), but at different rates (100W and 500W). The 1kW
asasmodule1-2 provides twice the torque (1.0) and appears balanced.

If we're going to have torque depend purely on EC consumption, then
sasModule should provide much less torque than it currently does
(0.1 vs 0.5). I would suggest that as advances to reactions wheels are
made, the torque-per-watt would improve, so one could use:

• sasModule, 100W for 0.1 torque
• advSasModule, 500W for 0.55 torque (10% improvement over base)
• asasmodule1-2, 1kW for 1.2 torque (20% improvement over base)

But I'm really not bothered if the EC consumption is linear.

Right now there's a lot of variability in Universal Storage wedge capacities. A water tank can hold 100 litres, an LF10 unpressurised tank can hold 40, and a pressurised tank (including dedicated oxygen and hydrogen tanks) 32.

A quad-core with four wedges is 1.25m diameter, and 40cm high, so 100 litres for a water tank is sensible, giving us 400l with four water wedges. Procedural tanks would give us 491 litres of capacity at 100% utilisation, so with water we're seeing 81% utilisation. Hexacores would have 600l, at 84% utilisation. I haven't tested octocores, but imagine they'd be about the same. 81% utilisation feels balanced; a player would have reason to use a US hub when storing water, because it gives them extra flexibility.

However if we're storing oxygen or hydrogen, then a quadcore drops to a mere 26% utilisation of the space it occupies. But you might argue that a spacecraft's cost is in weight, not size. That may be true, in which case a quad-core of oxygen weighs twice as much as a service module tank holding the same amount. I think a penalty is appropriate for the flexibility offered, but twice the weight and only 26% utilisation feels like players aren't given a reason to use the US wedges at all for storing resources. (They still make sense for science experiments and converters.)

I'd like to raise all the tanks to a flat 80l for pressurised tanks, and 90l for unpressurised, giving us 65% to 73% utilisation, and an appropriately lower weight overhead.

I'm happy with any of the following responses:

1. Yes.
2. This belongs in RP-0. We're trying to do game balance there.
3. This means parts will hold more than their models suggest, so no.

~ pjf

The default settings change this to 800, which isn't enough to tolerate having certain engines attached to it. The old default of 3600 is probably appropriate for a part like this (just a hunk of metal).

Just upgraded RO to 6.0a3, and alas one of my vessels won't load because it's missing the 4m.Heatshield part.

In 5.2.1 this was in RealismOverhaul/Parts/4M_HeatShield.cfg, but I'm guessing it slipped between the seats when the directory layout was changed for 6.0. ;)

This may have nothing to do with RO.

I've managed to get a MOL Science lab (FASAGeminiMOLSci) into orbit. But not only does it have no right-click menu, but right-clicking on it seems to then remove my ability to right-click on anything unless I change scenes to the space centre and back.

I know it's supposed to act as a mobile processing lab, but with a buggy right-click menu that's not working too well. I can't spot anything in RO that might cause this, but thought I should check first before I go hunting down how to submit FASA bug reports.

(Possible cause could be that it contains two ModuleScienceContainers, or this could be something completely different instead!)

Many thanks,

~ pjf

It seems deeply wrong to me. The quoted specific impulse is better than current gas-generator kerolox engines (!), let alone contemporary ethalox engines. My guess is that it's approximately 100s too high all round. I have not been able to find an accurate citation for the XLR11's specific impulse, but I do know that it was underexpanded at sea level which should tell you just how much of a dog it was. Thus something like 180/220 seems about right.

More an issue of organization than anything else, but...

https://github.com/KSP-RO/RealismOverhaul/blob/master/RealismOverhaul/RO_SuggestedMods/FASA/RO_FASA_Other.cfg#L265

Jeb tells me it got pretty messy in there last flight. :)

• Constelacion -> J-2X
• Fix 1kn and 0.5kn thrusters to obey propellant thrust scaling (and the AIES one to be 2kN base since 2 nozzles). That means call it 1kN class, maybe? Since with NTO/AZ50 it'll be more like 2kN...
• Give the above (generic thrusters) EngineIgnitor configs; pressure-fed unlimited-restart ullage=false.
• Backport VSR engines
• Add LR-105-3
• Port over VSR-engine changes (to SquadEngines) to other same-config engines
• mea culpa: CECE should be an RL10 alt config, not a new part.
• RLA Kingfisher -> Bell 8xxx engine/Agena engine (was CECE)
• RLA Albatross -> VINCI (was J-2)
• KW Globe X-10S "Thor II" SRB -> 5-seg Shuttle SRB (was UA-1207)
• Set AIES Exper to RL-60 (was RL-10B-2)

Regarding the generic thrusters: Right now, RCS configs (check out an RCS module) have differing thrust and Isp based on what propellant mixture is used; coldgas has low thrust and Isp, hydrazine is decent, and storable hypergolics are quite good indeed. The "generic thruster" parts, however, only increase Isp based on propellant change, not thrust. They should be scaled in thrust as well, like RCS.

Per Tahvohck: https://github.com/NathanKell/RealismOverhaul/blob/master/RealismOverhaul/RO_RSSROConfig.cfg#L124

And it's even added as a new resource (!).

Should be NTO, that's what NTO is.

Rothank sez: An issue: Squad RCS 4-way thrusters have the same amount of thrust on all versions (full, 1/2, 1/4) even though i have (double checked) RO_RCS_config and moduleRCSFX.
I just did a fresh, RSS+RO+RP-0 (+essentials) with no additional mods. Same thing happened on my old install.

Shouldn't it, per description, have a larger tank?

Ran into a rather irritating issue when designing sounding rockets in RP-0. Unfortunately, I'm not 100% sure where the problem lies; it's not there with just Procedural Parts/Module Manager/TweakScale, but there with the RO set of mods from CKAN (dependencies only, no suggested/recommended).

Seems like the pSRB mass resets to its default value upon loading a craft (for launchpad mass calculations, not right-click menu), and doesn't change back to the "correct" value without replacing the pSRB entirely. To reproduce, install RO + pParts, start new career, build new ship, start with command module, add pSRB, try to increase radius (shrinks to 0.200m), note mass (1.0t for me, ~860kg for the pod + ~140kg for the pSRB), save, load the craft you just saved, look at the mass (4.8t, same masses when right-clicking, but adds up to something way bigger).

Also seems something's funky with the mass calculations when having a pSRB as root. Making a "ship" with just a pSRB, then shrinking the radius to 0.200m makes the mass go from 6.7t to 3.9t in the info window, yet the right-click menu shows a wet mass of 139.2kg. Saving/reloading this doesn't seem to change anything.

Finally, reloading a craft seems to allow one to bypass the tech tree size limits; not sure if this issue is related, though, so I can open a new one if it's unrelated to the above.

SOP to leave the "Manufacturer = " out of configs to allow credit to original designers

Do the title.

Right now it has none. It should have infinite ignites in all configs (it's basically an RCS thruster) but it should certainly require a pressurized tank.

After FASA was working again with KSP 0.90 and RO 7.0.6, I was unable to rebuild my Saturn V. With the current configs, the Lunar Module Adapter Base & Fairing (or the node positions within) seem to have incorrect dimensions. If the LM Base is connected to the Aerojet-10 of the CSM, the resulting space cannot be filled by the LM Adapter Fairing, i.e. the Fairing Walls are to short and there is a large gap wherein the Aerojet-10 is still fully visible. In the original FASA, the bottom and top node of the Aerojet-10 coincide, but the RO configs changed that.

There is a chance that I just didn't get the correct build order, but I think this is broken.

As of now, the electricity requirements of space station segments and other similar parts are vastly underestimated by TAC LS, because it calculates on a per-person basis and consequently doesn't take volume into account. As an example, the BA330 module currently consumes 0.56 EC for LS + CO2 scrubbers, and 0 EC for avionics, whereas Felger calculated on the basis of his ISS data that it should be around 18 EC for LS + scrubbers + avionics. We need to decide on a solution to this problem.

Another related issue (probably an oversight) is that many crewed modules (including even stock Mk1 and Mk1-2 pods) lack ModuleCommand electricity consumption (which is supposed to model avionics).

Actual behaviour: The Realchute stack (RC_stack in RealismOverhaul/RO_RealChute.cfg) has top and bottom nodes which aren't on the surface of the compoent itself, causing it to 'hover' when placed in an actual stack.

Expected behaviour: Attachment nodes are on the surface of the part itself.

Steps to reproduce: Select the RC_stack part in the VAB and attach it to a part. (I'm using just an okto2 and the stack chute, and there's a very noticable gap.)

Note: I haven't tried RealChute without RO, so this could be stock behaviour.

Mod loadout:

KSP found at /home/pjf/.steam/steam/SteamApps/common/Kerbal Space Program

KSP Version: 0.25.0

Installed Modules:

✓ AGExt 1.24a
✓ AJE 1.6.4
✓ AlternateResourcePanel 2.6.1.0
✓ Chatterer 0.7.1
✓ CIT-Util 1.0.4-unofficial
✓ CommunityResourcePack 0.2.3
✓ CommunityTechTree 1.1
✓ CrossFeedEnabler v3.1
✓ CustomBiomes 1.6.8
✓ CustomBiomes-Data-RSS v8.3
✓ DDSLoader 1.7.0.0
✓ DeadlyReentry v6.2.1
✓ DMagicOrbitalScience 0.9.0.2
✓ DogeCoinFlag 1.02
✓ EngineIgnitor-Unofficial-Repack 3.4.1.1
✓ EVE-Overhaul-Core 0.0.2014.11.25
✓ FerramAerospaceResearch v0.14.4
✓ FinalFrontier 0.5.9-177
✓ FinePrint 0.59
✓ FirespitterCore 7.0.5398.27328
✓ HotRockets 7.25
✓ InfernalRobotics 0.19.2
✓ Karbonite 0.4.4
✓ KAS 0.4.9
✓ KerbalAlarmClock v3.0.5.0
✓ KerbalConstructionTime 1.0.3
✓ KerbalJointReinforcement v2.4.4
✓ kOS 0.15.3.0
✓ KronalVesselViewer 0.0.4_0.25
✓ MechJeb2 2.4.0
✓ ModuleManager 2.5.1
✓ ModuleRCSFX v3.3
✓ NathanKell-RVE-Haxx 0.0.2014.11.25
✓ ORSX 0.1.3
✓ PartCatalog 3.0_RC8
✓ PlanetShine 0.2.2
✓ PreciseNode 1.1.1
✓ ProceduralDynamics 0.9.1
✓ ProceduralFairings v3.10
✓ ProceduralParts v0.9.20
✓ RealChute 1.2.6
✓ RealFuels rf-v8.1-really-v8.2-pre
✓ RealismOverhaul v7.0.2
✓ RealSolarSystem v8.3
✓ RemoteTech v1.5.1
✓ RemoteTech-Config-RSS 0.0
✓ RP-0 v0.13
✓ RSSTextures4096 DDS-1.0
✓ SCANsat v8.0
✓ ScienceAlert 1.8rc1
✓ Service-Compartments-6S 1.2
✓ ShipManifest 0.25.0_3.3.2b
✓ StageRecovery 1.5.1
✓ SXT 18.6
✓ TACLS v0.10.1
✓ TACLS-Config-RealismOverhaul v7.0.2
✓ TechManager 1.5
✓ Toolbar 1.7.7
↑ TweakScale v1.44
✓ UKS 0.21.3
✓ UniversalStorage 0.9.4
✓ UniversalStorage-KAS 0.9.0.14
✓ UniversalStorage-TAC 0.9.2.7
✓ USITools 0.2.4

Legend: ✓ - Up to date. ✗ - Incompatible. ↑ - Upgradable. ? - Unknown