NathanKell

Noctis: known issue, sorry. Fixes gratefully accepted, however (asmi fixed Baikonur...) Just mess around with the params in the cfg, and use reorientFinalAngle if they end up default orientation not East. That said, do try it on High detail first. That can help. Kitspace: RSS is breaking during load for some reason. Please follow the guide in the READ FIRST sticky in Modded Install Support regarding posting logs. Note that each texture pack linked in the OP *does* contain all planets. Nori: with RO fuel choices are actually not so extreme, since each engine (with *very* few exceptions) will only accept one fuel mixture anyway. All you have to do is pick your engine, just like always. (RCS, you do get choices, but N2O4/MMH or N2O4/Aerozine is pretty much always best if you can get it, or hydrazine if you want a monopropellant.) Starwaster: The Comic Sans! It burns!

Sure! Scaled space is used whenever you're far enough from a planet. That's controlled by the scaled space fader PQSMod (PQS fades out, scaled space fades in). You can see it happen at something like 30-40km in stock KSP I believe. Note that Jool doesn't have a PQS, just a scaled space mesh. Basically, it replaces the dynamic PQS with a static mesh (hence the need to, on load, make that mesh fit the PQS terrain) which has a diffuse and a normal map. These maps should be pregenerated (hence the 1GB of PNGs that RSS ships...). Usually you'll want to tweak them by hand anyway, but for a base RSS allows you to export the maps based on the PQS itself if you want (using, presumably, the same function call that Squad uses before hand-retouching). maxHeight just lets you specify how to convert meters-above-sea-level (or above-reference-point) to shade-of-gray. I.e. any height >= this, will be white. You really never ever want to do map export in real time; it's really, really slow. You want to export it ahead of time and ship the image.

If you want to be systematic, use this: https://github.com/ferram4/KSPExceptionThrower That will make x64 crash on demand, more or less (when above threshold). Although: it's just the source, it needs to be compiled. Unlike ferram, he usually puts the dll in git too.

Thanks, I'll try that way--decouplers and not, on an all-solid rocket.

One more note on the TGA / PNG front. Taverius reminded me of the loader bug in KSP: unless you have ATM, TGAs don't get compressed. So if you're not using ATM, your memory usage with all TGA converted to PNG (which does get compressed) will be *way* lower. Might this go some way to explaining the difference?

The problem isn't from vessel acceleration, except from a LES (but that's such short duration). The problem is reentry. It's totally possible to do 30G reentries that last an appreciable amount of time.

Yeah, we do have the code to make decently realistic engine performance.

You can also check this section of the RSS codebase; it's more similar to what Kopernicus does, with the exception that Kopernicus creates a fresh mesh and I clone Jool's mesh. There's two things going on here (well, in that link only 1 gets done; look further down for 2). 1. Creating scaled-space geometry (i.e. "wrapping" the scaled space mesh to the PQS-generated heights 2. Creating scaled-space textures (i.e. map-making, rendering a diffuse and a normal for the body's terrain) You need to clamp vertex heights if oceans are involved (in 1), and you need to make all below-sea-level pixels ocean-colored rather than normally-colored (in 2).

Found it. Dunno if it works in .24 though.

Um, which bug? Is there a leak, or is it the "TGAs don't get compressed" bug that ATM fixes?

Welcome to the forum! There is a mod that does this, but...I'm sorry to say I don't remeber its name. A forum search should turn it up though.

Hey, awesome! And welcome to the forums!

If you google "learn C#" or "C# tutorials" you should find a bunch.

Since B9 v5.0 changed to making its *own* effects, odds are the hotrockets patch (and the config code in AJE that depends on it) doesn't work anymore.

Ah. It's because with RO, the idea of getting a series of parts that match size is pretty much out the window. If your capsule is 2m wide, you can bet your bottom dollar that your LV is *not* going to be 2m wide. Well, you *might* be able to launch the Mk1 pod on a 2m-wide 2-stage staged combustion storable propellant rocket, but odds are you'll want 3m diameter. For that reason, and because only Procedural Parts supports all the various tank types (balloon, service module, etc), it has been the operating assumption that people will just use PP tanks; I don't even *have* any stock tanks in my install, I deleted them to save RAM. Also, it's not that the pods are rescaled; they're not made larger just because, they're made larger so they are the same size as their real-life analogs, the Mercury capsule and the Apollo Block II capsule. If there were a stock 2.5m Soyuz capsule, it would be scaled *down* The tanks, by contrast, have no real world analog parts, and thus have no reason to be rescaled.

Rothank: Alas, I was afraid of that. Reproducibility is the key; I have yet to actually see the bug myself. It's very hard to fix what you can't cause. Yes, prices are coming soon, but sooner than that used to be since I have them working for RF (more or less).

But KSP linux x64 works. The question is "is the issues KSP x64 has been having on Windows a Unity-side or KSP-side issue?" Padishar: yeah, it's indeed likely not simple in terms of fix. And especially with obfuscated stack traces, all we can do is speculate.

Sounds like the B9 cfg that AJE has needs to be updated for B9 v5, maybe? Then again, IIRC so does hotrockets.

The download has not been updated to use the current, correct RSS dll then. The dll it is shipping with was made for .23.5.

Well, if you want fully realistically-performing piston engines I suggest my fork of AJE, soon to become its own mod. I'll also be using some neat parts by nli2work, and you can use KAX's radial. RF doesn't have those textures for pwings; Reaching for the Clouds does.

Maybe broken or multiple ModuleManager dlls?

tater, I kinda figured it was a matter of time until I saw you here.

Locked. asmi, let me know if you want this open again!

Center mark? Not sure what you mean.

metaphor: dang, thought we fixed that. I know ferram wrote an atmosphere patch for RSS, but it must only change the (forthcoming) DRE atmosphere data, not the FAR data. Thanks! camlost, ThorBeorn: thanks for the report. I will check when I get home. It *used* to work, so I'm unsure what's broken. MaxP: If you remove the BoulderCo folder, you have removed all the cloud textures. So I would not recommend doing that. Motokid600: This is an EVE config designed for RSS. I also plan to look into what was done to improve the terrain in 6.4x Kerbol, and do it for RSS. Hattivat: those are truly excellent helpful posts! Thanks! Kitspace: You might want to look at the RSS wiki, linked in the OP. It has two tutorials from Ferram, one for building a rocket and one for flying it, and one from me regarding using MechJeb to fly ascents. Many modern rockets *do* finish their burn after their original apogee; it's not uncommon or bad. Likely your upper stage(s) has too much thrust. A TWR that starts at 0.9 (vacuum TWR) is a *high* thrust upper stage. Centaur on Atlas V has more like a 0.4 TWR (maybe even 0.3). I don't recommend that for LEO--Atlas V is optimized for GTO missions--but it gives you an idea. If you're launching a traditional 2-stage LV, then you want to use the first stage to establish the correct apogee--200km for a parking orbit, higher for longterm LEO orbiting--and burn the second stage to establish orbital velocity at or after that apogee. The best way to do that is to make your second stage's burn time around a minute longer than what "time to apoapsis" is when you start firing it, and burn it more or less completely horizontal, only burning +pitch when time-to-apoapsis goes below 20 seconds or so as Hattivat says.