NathanKell

Occlusion isn't quite as naive as subtracting area alone. Instead it subtracts the weighted occluded area from the weighted total area, as you've found. Consider the nosecone adapter. it has has (.625/2)^2 pi flat-plate area, and another .29pi m^2 of highly sloped area (say Cd of 0.15). That's a weighted sum of .15625pi m^2. Adding a .625m nosecone will occlude from the former area only, so it's now 0 + (.29pi * 0.15) = 0.0586pi m^2 effective area.

It's because as you go lower, the flux increases and the temperature increases, so the loss rate would be higher...but it's also multiplied by the remaining quantity of ablator, so the more you lose the slower you lose. Those balance.

I've seen this sort of issue before. I wonder if it's EC being STAGED that does it? Try commenting this line: https://github.com/KSP-RO/RP-0/blob/da756859bddcd03c08bc026a7293cf07d3d20f0e/GameData/RP-0/ElectricityFlow.cfg#L3

Make sure you have the current versions of *both* RealFuels and SolverEngines.

I'm not trying to pick a fight. At the start I was just trying to clear up some confusion, and in general making the point that a 6 inch cylinder made of one part probe (Explorer) and, halfway down, one part solid motor (Baby Sergeant--the picture shows them combined), is very different from a 12 inch cylinder with big fins and big liquid fuel tanks (WAC), is very different from a 36in diameter guided missile (Corporal). Besides, we already have an Explorer and a Baby Sergeant. Now, that's not at all to say you can't use a WAC however you like, same with all the other parts. That's the beauty of KSP. But there's no reason to make sacrifices you don't have to make, in your terminology.

Look at the thread title. Does it say 1.0.4?

GigaG: RP-0 requires Ven's, and SXT. FASA is also somewhat supported. There also are a few KW and AIES engines placed. chrisl: For you and anyone else reporting "high" temperatures. Turn on the thermal data display, and see what the temperature actually is. Do not trust the gauges and the skin highlighting, they have a major bug that I finally tracked down (they compare current skin temperature vs max internal temperature). That's not an issue in stock, but in RO we set pod internal max temperatures rather low, so a skin temperature of 500 (very possible during launch) is right at the max internal temperature and thus you get a red gauge...but the max skin temperature is 2000.

Sharkman Briton: Welcome to reality. RSS is the real solar system. That means you can use real life delta V maps. For example this one. Or the wikipedia page.

Correction: STAGE_PRIORITY_FLOW flows from anywhere on the vessel, same as ALL_VESSEL, it just preferentially draws from parts in earlier stages (so, e.g. if your initial stage has monoprop, and your upper stage has monoprop, and your payload has monoprop, RCS thrusters everywhere on the ship will first draw from the initial stage and suck it dry, then move on to the upper stage, and finally the payload).

Jet nozzles don't tend to mass over a ton. That usually involves an engine.

Sorry, Randazzo, that's not at all correct. Ablator loss in units = lossConst * e^(lossExp / part.skinTemperature) * ablatorResource.amount, clamped to 0 if part.skinTemperature is less than ablationThreshold. The cooling flux is then just the loss in units * density * resource.hsp * pyrolysisLoss What's actually going on here is an interesting fact about reentry, which is that the convective transfer coefficient is a function of the square root of density, while drag is a (linear) function of density. That means that, until you hit turbulent flow*, a steeper reentry has a higher peak flux but a lower heat load. This doesn't mean a lot at KSP scale, but in RSS it means that if your shield can take a high instantaneous flux, and your payload can take the Gs, it's better to go steep. *When you hit turbulent flow, the convective coefficient spikes up. The switch from laminar to turbulent is a function of (density * velocity) so if you're still going fast down low (which you will be, the steeper your reentry) you can hit it. That never ends well (and it's what leads to the general rule that the heat load of a reentry is similar across all entry angles). For example, Mercury had a very steep ballistic reentry (the reentry orbit was around 320km x -200km, after 170m/s retrofire from a 150x250km original orbit) to minimize heat loading on the capsule. EDIT: You can grab AeroGUI, it has a convective flux counter (hit alt-I, then click thermal, and reset the counter just prior to atmospheric interface, then compare total loads from different reentries). http://forum.kerbalspaceprogram.com/threads/117141-1-0-AeroGUI-v1-0-28-Apr

chrisl: Use the tracking station to switch launch sites. That setting in KCT is for Kerbal Konstructs launch sites, which aren't for RSS right now. Sharkman Briton: http://forum.kerbalspaceprogram.com/threads/131023-1-0-x-SMURFF-Simple-Mass-adjUstments-for-Real-ish-Fuel-mass-Fractions

tjsnh: Right. Because this totally looks like the bottom half (the top half is the probe, not the motor) of this: I'm just not seeing it, beyond "both are cylinders that are smaller than 5ft in diameter" OTmikhail: Neat! The Baby Sergeant was derived from, as its name implies, the MGM-29 Sergeant tactical missile (which replaced the Corporal, but did not derive from it; the Sergeant was a solid fuel missile). Don't forget the Recruit! (Corporal was related to Private in that Private tested the fin stabilization to be used; Recruit, Sergeant (aka Castor), Baby Sergeant, etc, were all the fruit of the first big round of military solids birthed from JPL.)

Then you've already done your part and needn't worry a bit!

Personally I make a symlink from, say, (repo for RP-0)/GameData/RP-0 to KSP/GameData/RP-0, so changes appear in GameData but the excess repo stuff does not. Note that RP-0, and perhaps some other mods but RP-0 seems most relevant has a build script. Run make from the repo root if you change tree.yml any; that will generate the (git-ignored) Tree.cfg that actually is used by KSP. Also worth mentioning that most mods don't include built dlls in their repos, so you may have to build from source, depending on what you want to do (for my stuff, RO, RSS, and most others do have dlls in git, but RealFuels does not). Oh! Almost forgot. There is an easier way for making small changes. Open the target repo in your web browser, and be logged into your Github account. Browse to the file you want to edit. Click the pencil icon (upper right corner of the file display) and you can make changes in the web editor. When done, type in a commit message (and, if >30char, an extended commit message in the big box below). Then click "Suggest Change". Then keep click the green boxes to actually make a pull request (there's at least one more, on the next screen; there might be a third, I don't recall). If you want to add more changes to that PR, open *your* fork of the repo (that was just created by the steps above) and go to the branch that has the changes (patch-1 if it's the first time, else patch-something). Then edit the files same as above, but choose "commit directly" when committing. Your PR will automatically update.

As I mentioned in PM, if all you want is engine ignitions, not the change to real tank volumes and real propellant types, then use Engine Ignitor (the mod), not RealFuels.

Wait, what? Explorer 1 was placed atop a tub of solid rocket kick motors, and that placed atop a Redstone, which is like a straight-sided, 2x scale V-2. Nothing to do with the Corporal, which was an early Army ballistic missile which, AFAIK, no one has modeled, and also has nothing to do with the WAC Corporal, which is the thing that was put atop some V-2s in Project Bumper (as Bumper-WAC). (The WAC was, broadly, a test of the engine propellants used in the Corporal, but that's about it--totally different scale, unguided, etc.) Juno I carrying Explorer 1 (note Explorer 1 is 6.25in in diameter) Bumper-WAC (note, WAC Corporal has a tank diameter of 12in) Corporal missile:

Lack: per ferram's tests you already fixed it, looks like--you did rebuild the AJ10 collider in 22.x, right?

RealPlume uses SmokeScreen particles anyway, not PARTICLE_PREFAB.

Ven's Stock Revamp is a good example of this, everything fits in the original sizes but the bells are sane.

It's also worth noting that the square-cube law plays into this. The heavier the rocket, the lower (surface area) / mass ratio it has (usually). That means that while the force of drag scales linearly with area, the *deceleration* imparted by drag scales with the 2/3 power of mass. Simple example: 10 ton rocket, 1m diameter (Vanguard). Frontal area of .25pi, so let's say drag of 25pi newtons. Deceleration = 25pi / 10 = 2.5pi m/s. 2800 ton rocket, 10m diameter (Saturn V). Frontal area of 25pi, so let's say drag of 2500pi newtons. Deceleration 2500pi / 2800 = 0.8928pi m/s. And note that's not even a fair comparison, because the Saturn V's volume was mostly LH2/LOX, at 1/3 the density of kerolox...(and was thus rather larger for its mass.)

M@. Either you don't have Module Manager (unlikely), you don't have the correct current version (it's 2.6.9, get it here https://ksp.sarbian.com/jenkins/job/ModuleManager/lastSuccessfulBuild/artifact/ModuleManager-2.6.9.zip ), or your KSP is in a location that's protected (i.e Program Files). Move the Kerbal Space Program folder somewhere else, like C:\Games\Kerbal Space Program. shoe7ess: The OP describes how to play in OpenGL mode. Do that and your RAM problems will be greatly diminished.

They use either bladder tanks (to separate the propellant from the pressurant) or funky surface-tension based things that keep propellant near the feedlines.

Yep. Although I thought that issue had been fixed, post about it in the CKAN thread?

Made an issue on the repo.