NathanKell

karamazovnew: Love what you're doing! Now, some notes: Everything old is new again! Originally there were separate proc parts for each type, but then we went to "one part, one part only" because woo procedural. But as you found out, it's very hard to balance things that way unless you do more coding for RF (or proc parts) to change other part stats on type change. Regarding baseCost: it works like basemass, so you can also do baseCost = 10 * volume to get a per-volume basecost in a tank definition. Balloon tanks should be more expensive: there's less material, but it's machined to a much higher standard and it must be watched like a hawk; you can't just leave one lying around untended or it may spring a leak and collapse under its own weight. And yes, in real life balloon tanks are generally too weak to mount solid boosters on (Atlas IIAS is an exception) but in KSP that also prevents you from adding verniers, RCS, antennas, etc., which is probably a net minus to realism and to fun, so...alas. But if you think that's worth the trade, go with it! Regarding pressurization: in flight all tanks, no matter what, are kept pressurized (yes, even 'Default' and 'Cryo'--though those only to about 2atm of pressure, compared to up to a hundred for a ServiceModule tank, say). But when tanks are just sittin' in a shed, minding their own business, only balloon tanks need to be kept pressurized even then; the reason other tanks are kept pressurized is to make feeding the engine easier, not because they'll collapse without it!

celem: Comments like that make my day! Very much of what I hoped from RP-0 is that it will lead you to confront--and conquer--similar design challenges to those faced in real life, and to teach you the RO tricks of the trade as opposed to KSP ones: careful TWR management rather than moar boosters, using aero to control your flight, etc. The other big cause of the early dead spot is our inability to mod the building upgrade settings. But hop on the Realism Overhaul IRC channel and we may be able to make a workaround for you. chrisl: update SXT.

sarbian, you're the best I had wondered about that, and that's right kind of you.

Neither FAR nor NEAR make the atmosphere less dense. They do give parts sane Coefficients of Drag (stock's are too high by at least an order of magnitude, even aside from all that mass=drag stuff). Effectively that makes stock feel like soup and FAR/NEAR feel slippery, but it's not due to a density change.

Sorry, I've been offline for over a week.

I would suggest posting in the Realism Overhaul discussion thread for maximum exposure. Also: Here is a tutorial for using Mechjeb with RO.

That's because in .90, part clipping was made "allowed" across the board. See, back in the day, the "part clipping" option did two things: 1. It ignored part colliders when placing parts; otherwise you couldn't easily (yes, there were bugs/workarounds) clip one part into another. 2. It allowed you to use an attach node more than once. In .90, colliders were disabled across the board, so (1) is now the default (and unchangeable) behavior. Now the toggle only does (2).

That's magnified in KSP. It's nearly impossible (though not 100% impossible, of course!) to get an efficient single-burn-to-orbit in KSP because the ascent is so short comparatively. Much easier on realer scales. You might consider trying 64K for example. For normal sizes, your best bet is an efficient turn that ends up at, like, 75km x 20km. That should lead to anywhere between 20 (if you nail it) and 200m/s (if it's more like 75 x -20) to circularize at apoapsis, which is fine.

I haven't done this myself, but using TOT or another one of those trajectory tools is your best bet. Also, Check out metaphor's trip.

Sorry, been offline basically since last Saturday and still a bit busy. Glad to see the various RFers here to quite accurately predict my reactions. Northstar: I have no objection to supporting LqdCO2, that sounds fine. Regarding pressurization, I'd be shocked if non-SM tanks have higher pressures than 2atm; I know the Saturn V's S-IC LOX tank had a pressure of about 25psia (just shy of 2atm, 29.4psia). I have no problem with consolidating on single "active fuel" and "used fuel" resources for NTRs. I can't promise how soon I'll be able to pitch in, btw, though I will do my best and/or delegate to others if I can't.

KSP calculates price as follows (no, really): Final cost of part = initial cost of part ('cost' in the cfg) -(for each resource)[res.maxAmount - res.Amount * res.costPerUnit] So if you have all resources completely full, the final cost is exactly the cost specified in the cfg. For RealFuels-enabled parts, the full cost of the maxAmount of each resource is added, however, in addition to a per-liter cost, so it's suggested that for non proc parts you cost your parts as the 'dry' cost, and set the per-base-volume cost to 0.

Sorry, I brushed over the OP's calculations. Let me try to address them now. First, the 9.82 thing was mentioned, so let's fix that: 225000 / (800 * 9.82) = 28.64053 Volumetric flow rate is undefined however, since we don't know the volume of a KSP fuel unit. All we know is the mass ratio, which since air and fuel have the same "density" (aka tons per KSP unit) will be the same as the volumetric ratio. So we know there's 1.79kg/sec mass flow of fuel. (We know in real units volumetric flow is 1.79 / 0.81 = 2.21 liters/sec flow rate for fuel, and if we assume based on various factors discussed elsewhere that 1 KSP unit is five liters, that means we should expect 1.79/.81/5 = 0.442 units/sec of Kerosene, or 0.358 units/sec of 1kg/liter LiquidFuel.) That said, OP's conclusion--that like in real life jets should only count fuel flow towards specific impulse, and that specific impulse should then be raised to realistic levels--I agree with entirely. So Laie, I don't think there's anything different from the original way this was phrased, just pointing out that merely correcting the "air calculated towards Isp" bug would make jets not efficient enough, and thus once that is done jet Isp should be raised. Because (800 * 16 = ) 12,800s is not "too little" by any stretch of the imagination. OhioBob: as above, while the "air counted for Isp" bug has been discussed before, few have gone into the calculations as much as you, nor emphasized the need to increase Isp once that issue is fixed. I salute you!

Yes, all the non-part mods that RO recommends, or even suggests, are supported by RP-0. It's just the various *part packs* that RO supports that aren't supported by RP-0 yet (with some exceptions).

AvGas should stick around, since AJE (the airbreather companion to RF, let's say) uses it, but I highly recommend hiding the other ones Stockalike RF doesn't use. Hiding them i.e. -RESOURCE_DEFINTION[resname] {} and @TANK_DEFINITION[*] { -TANK[resname] {} } will cause no problems.

A suggestion: the SXT tinyprop be modeled as the Continental IO-550, which is what the part says it is, rather than a PT6. That would also give us an actual light-plane engine.

jsimmons, it's also worth noting that the heightmap you feed to KSP is just the heightmap for the VertexHieghtMap PQSMod, not the final "height map" used for the planet (which isn't a height "map" at all, since most of it is purely procedural). This, however, is the final product (i.e. the combination of the original heightmap and all the other PQSMods), and thus not the best thing at all to feed in at the source unless you want all the procedural effects to be doubled, basically. To pass a heightmap to KSP, you are limited to 8192x4096 and 8bit. To go beyond that you would need to write a custom heightmap PQSMod, and in particular something other than MapSO to use for it (please, please, please).

RF best F. (Amongst other things, it force-corrects g0 to 9.80665f ) I also am keeping my fingers crossed on this one. And, Renegade, the MM code is not that bad, you can use regular expressions to get the Isps involved (shorn of their x values), divide, then re-add the x-value (0 or 1). You can even use the sum of the LF and Air ratios as the divisor.

Mach 0.4 at sea level is 311mph, yes. A bit fast for takeoff, even though it appears to "only" be ~140m/s.

Nertea: I'm certainly fine with CRP listing as many resources as possible. Indeed, since the resources the game supports aren't displayed (and have only a negligible impact on lookup time) there's little reason not to include as much as possible. Gases at STP does mean that you will be faced with tens of thousands of units even for a small probe (which RF is fine with, but...). I also would throw out the suggestion of also standardizing existing resources; with MM to up resource amounts on parts as necessary, there's no need to even keep stock resources at 5L/unit, and certainly if one uses, say, MFT, many reasons not to do that. Certainly keeping gases at 5L/unit is not a good idea, IMO, and as mentioned something RF would have to undo itself. (To be clear, RF exists to mess with stock, and under no circumstances will not mess with stock. ) Given that resources have only one density per, I don't think we can get away without doing things like Methane and LqdMethane, especially since in RF terms one will be subject to boiloff and one won't. Starwaster: in the end, nothing should change for users of RF. The difference will be that RF will depend on CRP, but will make whatever changes are necessary if, say, CRP goes with 5L/unit gases.

The atmsophere shader is...kinda poor. What it's set to be RSS is about as good as it can get without mods. I suggest you check out RVE.

Please make an issue on the repo so I don't forget to fix.

Addendum: also delete the RSSTextures folder. That's where your earth textures are hiding.

That's what I was warning about above, yes.

On jets you missed (3), which is that the jets don't care about current atmospheric density, whereas in reality thrust is proportional to both velocity and to density (in fact, thrust is closely proportional to Q, although taking compressibility into account).

The only other wrinkle, is--how are you defining gases? RF expects STP and then the pressurization is defined in the TANK definition, rather than assuming, say, Oxygen is already at 200atm. This leads to low density (and high numbers of units) but allows tanks to have different pressurizations.