NathanKell

PP is (loosely) derived from Stretchy, and I'm somewhat involved helping swamp_ig with integration and some other stuff. What I meant was that I was working on a patch RPL can use to change diameter limits, like how RPL has its own custom limits for Stretchy. What I'm looking at right now is a limit of, starting from TL0: 3m 5m 8m 12m infinity (TL4) Your limitation should usually be engine, not tank size. While no rocket wider than 2m was built at TL0, that didn't really mean they *couldn't*.

Pretty much. I mean, if you try launching with a U or U+ engine or something, you're gonna have a bad time. But the difference in SL and Vac Isp for even an L+ engine is not so severe (mostly because pressure falloff is exponential in atmosphere) that you're best lumping it in with "extra stuff to worry about" rather than trying to calculate some interpolation between vacuum and atmospheric dV.

Or you could, y'know, read the thread, and find out that they "last too long" because of an issue in KSP's code where the mass of air is counted in the fuel flow equation for Isp, therefore an engine with a 1:16 fuel:air ratio (as stock KSP jets have) will have effectively 16x the Isp it should, since jet Isp in real life does not include airflow (since, y'know, it's not fuel).

Uh, no, the most important parameter is ballistic coefficient, since that's (one of) the things that's messed up in stock KSP, and that's why trying to use real masses with not-real surface area will break. Also, check my post at the end of the last page, you might have missed it.

I'm referring only to vacuum dV. I thought I was making that clear; 9.5km/sec vacuum dV will be enough to deal with nozzle and pressure losses. The problem here is that the amount of dV required is itself a function of drag losses, which vary greatly (Saturn V: 100m/s. A 10-ton rocket? Probably 500+m/s, especially if you have high TWR to limit gravity losses). Well, that's one problem. The other problem is that your Isp is a function of pressure, which varies with altitude, but your time at various altitudes is a function of TWR (which varies) and flight path. And, added to that, different engines have different ratios between sea level and vacuum Isp. Basically, you're *probably* safe in assuming you'll lose 2-400m/s to nozzle and pressure losses (aka firing engine in atmosphere), but that's greatly dependent on your ascent profile and how comparatively inefficient your first-stage engine is at sea level compared to vacuum (If you're using solid boosters, with little difference in SL and vacuum performance and a high TWR, you might be safe with only 100m/s; if you're using an L+ lower stage and a shallow ascent profile, closer to 400+). Basically, there's really complex and expensive software to model this sort of thing. The "good enough" Silverbird LV Performance calculator basically ignores that complexity, relying more on TWR.

9.5km/sec includes nozzle and air-pressure losses. If you don't include that, you only need about 9km/sec. MechJeb does do that. Well, it gives you stats; you have to provide the graph. Open the custom window editor, create a new window (I called mine Ascent Stats, it's on the lower left). Add those values to it, noting that drag will only consider non-FAR objects; to get your actual drag once you've completed your ascent, take your expended delta-V and subtract from it your current surface velocity, gravity losses, steering losses, and stock-drag losses; the remainder will be FAR-drag losses.

Update news: I've finally got generation and caching of wrapped scaledspace meshes working.

SFC is given for static thrust, usually.

I thought I had that corrected, but I may not have released the version of RO that fixes it. But the new version of PF should be safe (and you can totally use it with RO).

Northstar1989: Wow, it would really help if you actually read all the opening posts, maybe even (gasp) tried stuff out, and didn't jump to (wrong) conclusions. Had you done so, you would have seen that RO supports a *ton* of mod parts; that the 0.5m/1m/etc refers to *node* sizes, not part sizes (the Saturn V 5-engine part is in fact 10m in diameter); that far from not supporting them, Realism Overhaul requires StretchyTanks or Procedural Parts so you can have propellant tanks exactly the size you wish; and so forth. Further, you would have found that rather than using some simplistic scaling algorithm, RO gives solar panels exactly the W/M^2 they should have (based on a judgment about their technology level), that the RealEngines version of engine configs gives engines real performance (looks like an F-1? Has the stats of an F-1), that RO scales the Mk1 pod into the Mercury it resembles, down to its mass, battery capacity (and use rate in watts), etc., and so forth.

Um, pretty sure I've been using max *static* thrust, dry/wet.

Have a problem? Check the FAQ!

Might be worth looking into the math of DXT1, how the compression actually works.

O Nerd: That would be incredibly useful. I absolutely would do that. Before you make it, say, send me a list of the steps so I can cross-check with you?

Sorry, just wanted to let you know we're investigating...

1. I thought Kerbtown was fixed? (See last few pages of thread; OP's outdated). 2. Very cool stuff! I'd kindly ask you at least keep the old IVAs around if you plan to add RPM support, since some of us (well, >=1 of us, i.e. me) play in 50s-60s mode before glass cockpits.

Kerbtown is MIT now. https://github.com/HubsElectrical/KerbTown/blob/master/LICENSE That's how HoneyFox was able to fix it (and release). However, since razcheck hasn't been around (except to update the license on GIT) the OP is seriously outdated. And yes, adding PQSCities is super-easy.

Sounds like. FAR had this issue for a couple of novapunch chutes too, IIRC.

Combined with this http://forum.kerbalspaceprogram.com/threads/80638-0-23-5-Part-Angle-Display-View-and-set-accurate-angles-for-parts-in-editor and the world becomes a bright and shiny place!

Amazing and so very necessary! Planemakers around the world salute you!

That should be fine (just be careful you don't run the module *on* the prefab, else everything will be changed when you run it again to find the defaults). But yeah, I thought you *would* be writing a cfg for each part, so having in the confignode some part-specific numbers would be ok. But if you're wildcarding...

White Owl: I would dearly love such a thing.

keizerdoc: yep, bad install. You didn't follow install directions. You need to extract the zip to your GameData folder, which will create a DeadlyReentry folder in the GameData folder. That's it. Don't do anything more or less.

For ease of programming (and avoiding issues) it might make sense for those blocks to be TWEAK { PARAM { name = mass exponent = 2.5 orig = 12.0 } MODULE { name = ModuleEngines PARAM { name = maxThrust exponent = 2.0 orig = 60.0 } } } This is what RF does; it saves you having to worry about whether you safely recorded the original value or not if you force the user to supply it

Working on diameter limits