NathanKell

If you actually post the whole output log (NOT ksp.log) then we could actually look at the errors. This is especially important since I have been unable to replicate any problem with this and RSS v7.2's dll. WololoW: you replace the existing BA copy of RSS's dll with the new one (do not get all of RSS, only take the dll from the archive and replace your existing dll) and things should work as they are intended to (i.e. as they did on .23.5).

NEAR and FAR are not the same thing; that's kinda the point. As the OP points out, these wings do support FAR, have supported FAR for over a year, and in that time there have not been posts talking about how they break with FAR.

If you're not willing to do a little work to get a problem solved, why do you expect the modder to do *all* the work to get the problem solved?

While I have used neither and therefore cannot offer help, I *can* move this to the Modelling subforum where those who *do* use both those programs are more likely to notice. Away!

Post your complete output log. That will say exactly what caused the error. Odds are it's KSP Windows x64 just being itself. Windows x64 is extremely crash-prone and the stack trace will lie at times.* Your best bet is linux x64, or Windows 32bit. *i.e. it will claim that a kerbal in the VAB crew caused an exception which caused a CTD, which is obviously bogus.

No, it's not usually called a gravity turn. It might be on these forums (aided and abetted by MJ calling what it does a gravity turn), but it's not. A gravity turn is "pitch over a degree or so 500m off the pad, let gravity do the rest.*" Neither MJ nor modern rockets fly gravity turns; they fly pitch programs, i.e. they constantly control the rocket and try to keep it at desired pitch. MJ does not do an optimal job of it, which leads to the problems you describe. *which gravity will do: consider that each second the rocket adds speed both up and sideways, and air resistance subtracts from both, but gravity subtracts only from up. Thus your velocity vector will get "pulled" downwards, and air resistance will, if your craft is statically stable, keep your craft aligned with the velocity vector. Then the rocket will add a bit less up and a bit more sideways, and the cycle will continue, eventually ending in (a) you leaving the atmosphere or ( you heading straight down. Also, apologies if you *do* know the difference. I just see *so* many people describe a hands-on flight as a gravity turn, and it's both annoying and, more to the point, actively unhelpful (especially in RSS).

Let TaranisElsu be the judge of that re: logs, please.

SLS core stage *is* overpowered as upper stages go. That's the problem with stage-and-a-half design, unless your sustainer has a remarkably low TWR it's going to be overpowered for traditional ascents. What you'd want to do, I think, is yeah, loft high while on boosters (maybe to apogee of ~150km?) then pitch over and burn as near horizontal as possible. By the time you hit apogee it should be around 200km? I would suggest turn shape of maybe 60 (70?), and turn end of 170km? maybe 180? Final angle 0, obvs.

Well, if you call "rewriting chunks of Unity's particle system" only "refinement of existing functionality" (SomeScreen, I mean. HotRockets wouldn't work without SmokeScreen to fix all the many problems in the particle system and allow new functionality.)

Bothersome: I see no reason why any of the stuff you mentioned is impossible to add if you're willing to edit RT2's code JMac: Very informative post: thanks! And sounds like you have some *very* useful info for a recoding of RT2's range and handling code... FinnishGameBox: a 100x100km orbit is still inside the atmosphere, and 4000m/s is way too low. Sounds like an install issue. Woopert: you need to turn sufficiently shallowly that MJ does not exceed the desired apogee on the ascent. Or you can temporarily set the "orbit altitude" thingie to higher than you like, and circularize at a lower altitude on the way down (as many modern LVs do). In either case I expect the problem is your upper stage has too high a TWR. PaidLeber: That won't fix the issue, since the issue is that there are places in Squad's code where Kerbin is hardcoded, for example the "recovery" button you get when landed or splashed; that is hardcoded to check that body.name == "Kerbin" or it won't appear.

Yes, that's definitely allowed, as long as (per the terms of the license) the derivative work is itself shared under an open (derivatives allowed) license.

Also note that the latest RSS v7.2 does allow full, specific camera editing

Yep. The moon is inclined 5-6 degrees from the ecliptic. As, indeed, is the mun in RSS. (The ecliptic isn't flat-across-your-screen in RSS)

It's dependent on orientation too, so try messing with the rotation around the thrust axis of the gimbal transform.

No, TR, like ATM, will default to (a) compressing all textures and ( making them not-readable by code, all to save memory. So you need a special cfg for it (just like for ATM) to tell it to leave kerbin1 readable. (and any other textures that need to remain readable)

Even if you don't *include* the DLL, you can certainly include the settings and then ask people to download Space Shuttle Engines... (not that I think dtobi would refuse)

You can also check the surfaceheight of the PQS of the body you're near. I.e. vessel.mainbody.pqsController.GetSurfaceHeight( some_pos_in_worldspace ) Note that you should verify pqsController is not null first (Jool doesn't have one).

Alshain: You were using the structural fairings (which don't have a decoupler) instead of the fairings from the aerodynamics menu.

CDK: I suggest checking the title of the thread Woopert: Thanks for an excellent report! Alas I have no particular help other than guessing that what the problem is is that, even though you have 2GB of memory on your graphics card, you still have too much on it. Does the problem go away if, say, you remove KW Rocketry and a few other texture-heavy mods?

p3asant: most of the realism mods are sufficiently distinct ("this one modifies heating", "this one changes planets," "this one alters aerodynamics") that it generally isn't an issue... Playful1510: I have now bolded the part of the OP that says that.

I gave up and used a vertex color map. Probably your best bet will be to change the vHeightMax and then lower the endstart and endend of the sand, then change both the starts and ends of the other stuff. You can get a full dump of all bodies' stock parameters here.

HoneyFox: ensure that BoulderCo.cfg in your ATM configs folder has exceptions for both /Clouds/ and /Atmosphere/, as well as ensuring Texture Replacer has an exception for the texture.

On the Rework branch, I now have working integration of JSBSim prop code. Right now there are only a few propeller engines that work (the Packard V-1650-9 in particular is the best to try things with) but it's so awesome to finally have a Mustang that performs correctly.

If you right-click on a part in the editor part list, it will show you the information on the modules it has on the right. Check and see if a heat shield is listed; if it has one, one will be listed. The infobox on the left shows max temperature of the part.

Actually, until I implement a version of ModuleEngineConfigs that allows for rescaling, RealFuels *itself* disables engine scaling. It's not Realism Overhaul at fault. As of the next RF, RF itself will bundle the tweakscale API so there won't be version conflicts anymore.