sal_vager

That might be an artefact of the resource module, all the fuel tanks and other resource containers also track the max amount, but of course you can't restore ablator, at least not yet.

To make the heatshield stay at its normal colour with a reduced ablator you'd need to track the difference between a new variable, call it "user_set_ablator" maybe, and zero. It'd mean tweaked heat shields would turn black much sooner, or even instantly if players are really cutting back on mass, some might not consider that realistic, after all they may assume they are removing material from the back, not making the heat shield material itself more susceptible to heat. Trying to fix that with a separate zero value for the shader would mean the heat shields could have zero ablator and still look okay, that'd be confusing. As a rough indicator of remaining ablator the discolouration works well enough, and the thought of pre-burnt heat shields is hilarious.

Of course, it's done

Hmm, maybe something like this. Make a new text file in Gedit or similar, and add this, changing the path to your copy of KSP. #! /bin/sh cd "/home/yourusernam/.steam/steamapps/common/Kerbal Space Program/" mono ckan.exe Save it and make it executable, you can do this in the right click menu for the file as well. To "install" another copy of KSP just copy your KSP folder anywhere you like in your home folder and it'll work, I have put mine in /home/me/games/KSP The /usr folder is roughly equivalent to C:\Program Files, but it's best left alone and only stuff you install via the package manager will go there.

What will you do with this information?

None at all. Though Squad doesn't want to break old saves.

Try disabling FAR flight assist.

... It's a feature! But seriously, the effect is a shader set to the difference between the current and total ablator value, and in that sense it's working as intended, please make a feedback request on the tracker if you feel this should be changed.

DYJ is open to this idea, if the curseforge tags are what you want I think he'd oblige.

It's probably a pre-1.0 design, as today you wouldn't want to make a craft with 909's on the first stage, the reason is that engine thrust is affected by air pressure now, where before it was ISP. The Terrier is intended for use in a vacuum and is optimised for such, using it at sea level results in a massive loss in thrust. You're going to have to swap them for other engines.

Hi Trigger1112, can you also provide your dxdiag log, thank you.

Some ion engine types use a grid to accelerate the ions, but this is damaged over time due to electrons colliding with it.

Hi rammyspeed, are you using any compatibility modes or performance enhancing software? Also please try the KSP.exe directly. And please make a dxdiag report (start, run, type dxdiag), pop it on pastebin.com for us. Also check the Nvidia site for newer drivers.

It looks like your nose wheels are far too far back, I find if they are too near the center of mass the craft wants to tilt over them, as your thrust is above the wheel pivot point (the contact with ground), it acts like a seesaw. Also your rear wheels don't look straight, maybe try fitting them to the bottom edge of the fuselage sections then offsetting them to their current position, as they look just slightly twisted.

It's a proof of concept, you can add more wheels to support the sides if needed, and you can use retracting wheels for the top, though if you are re-entering inverted with a heavy payload you'd plan for this and have your cargo doors open downwards. Also, this thread is not for discussion of bugs, please stay on topic here and post to the proper forum regarding support issues.

There's usually enough air for a first stage to use winglets, but I was sure one of the stock SRB's did used to gimbal, if only by 0.5 degrees.

Go to the effected vessel, hold the modifier key and press x to reset trim, see if that solves the issue.

Oh pants that would be my fault, I have Claws fixes installed and they use module manager, and module manager tells KSP to use its own tech tree file. This is easy to fix though, just open your persistent.sfs, do a control+f search for techtree, and change "GameData/ModuleManager.TechTree" to "GameData/Squad/Resources/TechTree.cfg" That'll fix it.

The error log alone isn't very useful, especially truncated like this, all it's saying is that no memory was available to the program and it tried to write to 00000000, which is null and shouldn't happen. Please upload your full error log, output log, ksp log and dxdiag log to a file share site and post the link here. You can find more info on these file in the support stickies.

We all know we can secure our cargo by putting a strut from the end of our payload to the bay wall, usually one single strut is enough and as it's in the bay it isn't adding to drag. That's only good for taking cargo up though, as you can't place struts in space (unless you mod). So when we have an object we want to recover from orbit we're faced with a problem, we can't fit a strut and the docking clamp is not strong enough, so the payload sags and sticks out the bottom of our cargo bay. This doesn't look very nice. But, wheels are separate parts, so a small wheel in the floor of the bay will act as a stop, preventing the payload from moving through it. This works best with the LV05 and LV-01, for best results the wheels should be placed on another part, such as an I-beam which is attached to whatever you have capping your cargobay, or just offset inwards from that other part, this trick doesn't work if the wheels are attached to the bay itself. Yep that's a full orange tank on a dinky docking port, it's still supported even if the bay is closed and reopened, if the wheel was attached to the cargobay it'd lose it's ability to support the Jumbo-64 when the cargobay was closed.

Their purpose is to provide a protective shell from the airstream for non-aerodynamic and heat intolerant payloads.

Gentlemen, I and I am sure many others would like the Science labs to be a place of debate on topics from all the sciences, even speculative technology, instead of a forum of dismissive argument and "not invented hear" syndrome. So I will ask you all to stay on topic and consider AngelLestat's premise, and not to be upset when ones own views are challenged.

It does not look like this has been reported to the bug tracker yet, well done Nori on catching this, please create a bug report here with your findings, you can find info on making reports here. If you don't already have a tracker account you may need to PM Ted to have one activated.

Nevar forget!

Be careful as the airbrakes produce some drag when closed (it has a drag cube after all), editing the CoLOffset or CoPOffset could have unintended results as they do not move with animated parts. Also, the aero overlay is inaccurate, don't rely on it.