NathanKell

Hancer: First, no need to apologize! (Highly) pressurized tanks aren't required for storable propellants per se; there have been plenty of pump-fed storable stages (Agena, everything Glushko/Chelomei ever made [Proton etc], and so forth) and there have been pressure-fed kerolox stage proposed, and even flown now and then. It is true, however, that most pressure-fed engines run off storables. (Note: not all storable propellants are hypergolic, and not all hypergolics are storable...) As to what tank type to use: Default is your average not-highly-pressurized tank type. Use it for pump-fed stages that don't need long term insulation (i.e. S-IVB, despite being a hydrolox stage, should be modeled as this.) Cryogenic: A modern highly-insulated tank, like Delta IV core and DCSS use. Balloon: The type of tank Atlas used. The tank *is* the structure, and for that reason must always be kept under pressure. It's more fragile (this isn't really modeled in KSP, though it should have a higher failure chance [in Dangit] and take muuuuch longer to roll out [in KCT]) but much more mass-efficient. BalloonCryo: What Centaur uses. Same as Balloon, but with heavy insulation. ServiceModule: Highly-pressurized (can be used with pressure-fed engines). It also lets you store life support supplies and ElectricCharge. Includes the same level of insulation as a cryo tank. Use this for RCS tanks. Fuselage: Like the above, but heavier. Used for planes. Structural: Like Default, but heavier. Used for planes. Xenon (I think this is still a type?): used for Xenon (surprise). If you mouse over your engine, EI will tell you if it's pressure-fed, by the way, in case the part description does not. So generally you will want Default (or Cryogenic if your lower stage is hydrolox), followed by either default or cryo if your upper stage is pump-fed, or SM if it's pressure-fed. The tanks you use for your spacecraft should probably be all SM (since it'll need RCS, batteries, and possibly a some large pressure-fed tankage for an orbital maneuvering engine). Regarding settling propellants, you need to first provide some acceleration, then wait a bit for things to settle if they haven't yet. If you use solids to ullage, you probably can light your engine while the solids are burning; if you use RCS, you might have to wait a bit. Regarding what propellants to choose, Starman4308 already covered it pretty well. Just to add, a very efficient combination is a decently-efficient core with some solid boosters. The boosters will give you high thrust down low (when it matters most) and if they burn out fast you won't over-G later. The thing to remember is that it might well be worth trading a lower-efficiency (in terms of Isp) first minute for minimizing gravity losses. Barring that (where it might make sense to use a hydrolox core), kerolox is pretty much always going to be your best choice; it's more efficient than storables without the density or thrust limitations of hydrolox. For upper stages, however, hydrolox rules. For orbital stages, by contrast, pressure-fed storables are the way to go, since you don't have to worry about boiloff or a low limit to restarts.

Due to how mass-inefficient stock tanks and engines are, it turns out in 6.4x Kerbin you pretty much end up with real life payload fractions, or maybe a bit better. magico13: that's great to hear! Looking forward to it very much.

Your problem is not KIDS. Your problem is that Kerbin is 1/3 the radius of our Moon. FAR to Real Life adjusted means that you should have a similar payload fraction as real life rockets do (it accounts for both the size of Kerbin, and the fact that KSP engines and tanks are heavier than in real life). Well, also your problem is that sounding rocket != orbital rocket. Going straight up takes comparatively little delta V; orbital velocity is mostly sideways velocity. This is an Aerbee Hi, an early sounding rocket: This is a Thor-Able (later Thor-Delta, later Delta) LV, which places in orbit a lower payload at a lower altitude than the Aerobee Hi lofts. (Note the people standing around the base of it.) What was your payload btw? If we consider payload to be effectively nothing, then your mass ratio will be quite high (3:1) which yields considerable delta v, 10.8 * Isp. For unadjusted 370s Isp, that means almost 4000m/s.

somnambulist: I'll try reproducing that. Lack said there were a few parts that didn't start with SXT, so maybe that's the problem.

Add RSSROConfig = true to all the parts that have correct stats for RO. Stuff in the RealismOverhaul folder are patches for parts that *aren't* built for RO.

This intrigues me, poor impoverished post-student that I am. :]

Having searched this time (woo!) I want to add some belated support for a rollout mechanic. We've been considering how to change rescue missions for Realism Overhaul career mode, and one of the sticking points is that, even if you have another capsule and LV "on hand" as it were (in VAB storage), there still should be the final integration check / rollout / fueling / checkout delay.

Yes, Ferram Aerospace Research is pretty much considered a required mod for RSS. The only other part mod I would suggest your not wanting to miss would be Procedural Fairings, as you will definitely want to fair payloads and use the procedural interstage. Oh, and you need Active Texture Management (even in basic, non-aggressive form, so no loss in visual quality) because the stock texture loaders have some pretty bad bugs. Other than that, you might want to look into some (no-memory-required) build aids, like RCS Build Aid, Editor Extensions, and Part Angle Display. Dragon01: You have already driven one friend of mine from modding KSP. Please do not start up on this thread too.

You also need way more vertical tail. Well, maybe not need, but it would be very helpful. Especially at high speed, [large] vertical tails become very important for stability. Consider how large (compared to wing area) the X-15's vertical tails are; it operates in the same velocity regime as KSP spaceplanes.

Steam installs both the 32bit and 64bit KSP clients. Unless you specifically elect to use the 64bit executable, you are playing in 32bit KSP (had you been using the 64bit executable, you would not have seen an RSS status window ). You might try selectively upgrading your textures, if, once KSP is loaded, your memory usage is under 3GB; if not, you are probably stuck with the 2048s, sorry.

PQS is what the planetary terrain is. Stock KSP. PQS cache caches built quads.

As you wish.

Or blender, which many, many modders here use (and there are many tutorials for), and is free open source software.

No, there is not. Please don't assume vindictiveness where there is none, and where he has already posted upthread.

You might be interested in the shield rewrite I did then. It uses the real formula Goozeman posted many months ago. Will try when I get home.

First, I'd like to take this opportunity to offer a very big and very public "Thank you!" to RedAV8R for all the excellent work he has put in to Realism Overhaul. He has taken it from a few scattered patches and guesstimated values to pretty much a total conversion, and with painstaking and equisite detail. We can only hope that future contributions to RO may live up to that standard. To those who wish to thank him, and wish him well, saying so by PM is never amiss. To those who wish to contribute, have already offered to, thank you so much! Felger has (right above this post) written an excellent guide to how to get started. It may take a day or two to get a new thread set up. For now you can get the latest release from RO's repository (note that a few days ago, well before this happened, the repo moved out from my personal github account to the KSP-RO group).

Yeah, the problem isn't that it should be easily destroyable, the problem is that dissipation isn't connected to loss rate, so your loss rate will be constant no matter what dissipation you set. If I were you (I'm not though!) I'd add a second loss rate curve (that serves as a multiplier) based on part temperature, and use a constant for dissipation.

Oh my word yes! Felger and I were *literally* just talking about how we really need an IUS, and how hard it is to make one via MODEL nodes, and how we really ought to request one, and presto! Thanks a jillion! Looking great.

Not true. Moving this to it. (Note the description for General Add-on Affairs: "A general discussion place for talk of all add-ons, and the place to request them.")

anonish, my understanding is that taniwha got around that limitation of the assembly loader by tagging his (internal) classes with the version number.

Awesome! Glad it's working.

Github is great, a lot of us use the Releases system. As to mbms: no, the flow chart is this: 1. Does it have a 1 for that flag? If yes, go to 5. If no, go to 2. 2. Does it have an alpha channel? If yes, go to 3; if no, go to 4. 3. Compress to DXT5. Done. 4. Compress to DXT1. Done. 5. Leave uncompressed. Done. Since formats other than MBM don't have the flag, step 1 is skipped, the process starts at step 2. However, there is a bug in the TGA loader; it goes to step 5 immediately no matter what (ATM fixes this bug). This means that no TGA files will be compressed to DXT on load unless ATM is installed. Finally, as of .25, there is a big bug in the stock TGA loader; certain images under certain circumstances will simply fail to be loaded, and a white (untextured) object will result. This is a highly dangerous bug, and TGA should not be considered a viable format until it is fixed or unless the user has ATM installed.

EVE you can safely convert all textures that don't need to be kept readable (which AFAIK is everything except the cloud masks). RSS...yeah, that needs changes RSS-side although see the last couple pages of the thread for where one can use DDS textures (essentially, for everything but heightmaps).

Sounds most intriguing! Will try when I get home. Question: do you mean to increase dissipation rate (not loss rate)? That means that a heatshield will make you invulnerable, so long as ablative holds out, and ablative loss rate does not increase when dissipation increases, it's independent.

It may well not support a variable Compressor Pressure Ratio. Been a while since I tried X-Plane...