Starwaster

My experience with it is that it's been a very intermittent phenomenon. I've definitely experienced what you're talking about but fortunately it's been rare for me. MJ doesn't even try to turn the ship when it happens. Sometimes aborting then re-executing the command breaks it out of its funk. If it's a maneuver node sometimes I have to re-create the node. It might also have been responsible for a failed launch attempt where I left the room, came back 3 minutes later to see that instead of approaching orbit, I was at 3km and heading nose first into the ocean.... One of these days I'll get around to scouring my log. Or maybe I'll take a look at yours and see if I can find anything to report back with.

Are those nullrefs happening in events? (i.e. GameEvent events) If so, I've noticed that those tend to call the same event multiple times with only one having valid data.

So what happens if I uninstall a mod whose textures ATM was caching? Is it still loading the cache files? Should I be deleting those?

It's because that shield's CoM isn't in the shield itself (which issue was pointed out a few posts ago) So in essence it's moving the vessel's CoM closer to the shield's CoM. It'll be fixed next time I update. (which I'm not sure when that's going to be, probably when I take this set of updates out of beta + any bug fixes that might have gone in)

Just as a point of interest: IRL, the SOI of a body depends not just on that body's gravitational influence but on the gravitational influence of other bodies around it (namely the parent body). So close in to the sun, the SOI of planets like Mercury, Venus, Earth or Mars are smaller in comparison to a shrimp like Pluto where even though it's mass is very low, there's nothing else around there to influence it and it has a larger SOI than Earth. (for example) Edit: I think that with a 2 body system that at the edge of the SOI, the gravitational attraction should be about equal to the attraction of the main body? I'm not 100% and I never really paid attention to what it is in KSP but I think that's how it is IRL. Anyone want to chime in on that?

It's a known issue and it's caused by the fact that the GUI tries to parse the number on the fly as you type it. 1. doesn't make sense to it and it truncates the decimal. To work around it, put the cursor in front of whatever number is there and then enter the decimal. (or 'dot') So if a 1 is there it becomes 0.1 It can be a really bad idea to do this during an actual reentry if you're not careful because very low numbers can be dangerous, such as in the density exponent. (low numbers mean lots of heat at higher altitudes) I've thought about different ways to handle it but because it's more of a nuisance than a real show stopping bug, it just doesn't seem to me to be worth the effort in dealing with it.

Click on the Deadly Reentry icon in the toolbar. Then click 'Open Debugging Menu' and look for FX Density exp. It's probably set to 0.75. Increase it. Don't increase it past 1.

You should include log files with reports like that. It can be difficult for a modder to troubleshoot based on a description alone. If you're not sure where your log file is (and you do have one even if you didn't crash): http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-READ-FIRST

Because the KSO is not the US Space Shuttle. This is wrong. Unless you have deliberately disabled logging, KSP (actually Unity) always creates a log file. Always. If you do not know where your log files are, see this thread: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-READ-FIRST Note that ksp.log does not count. It does not contain a full log. The log files preferred contain more detailed errors.

That sounds familiar. IIRC you have them pointing the wrong way. They're very temperamental.

Sorry, jettison was the wrong word for me to use. I should have said decouple. There's a decouple button and it can also be decoupled by staging. The jettison button has to do with the fairing and it works the same as an engine fairing. (which for all practical purposes means that you very rarely, if ever, need it) BTW: Anyone using the alternate heating model setting might want to go check the crew g-force settings. I must have used the Hard presets as a template because I've just noticed that warning level and kill levels are half what they would be in Default. So if you were finding that your crew were turning into a thin red paste when you least expected it.... well, that's why.

Why do you have the docking port though? The shield can be jettisoned

But it's fun!

Can you give me an example then of a craft that this happens with? Because it doesn't happen to me with stock aero using any of the test vehicles that I've tested with. (preferably stock + DRE parts if it's a craft file. Or a picture of it in the VAB so I can recreate it in stock)

That looks like something I was experimenting with that wasn't supposed to go in. It is deliberate though and the reason is that drag is exerted from a part's center of gravity. That's why a single part will always maintain orientation regardless of where its CoM is. So the purpose was to try to move the drag point for the part closer to the vehicle's (as a whole) center of mass and it works in stock KSP. Are you using FAR or NEAR? (I'd guess NEAR since I don't see a FAR menu item in your toolbar?)

That's imaginary. They impart the same amount of torque and attraction as any other docking port. The answer is to not come in at an angle. If you're perfectly straight then you don't run the risk of wobbling. There's two kinds of attractive force that comes into play BTW. And they are both configurable in the part with default values of 2. (so if the docking port config doesn't specify, then it's 2) acquireForce acquireTorque It's the second one that is responsible for the wobbling. because it's trying to tug the ports into alignment. Logically if they're both acting at the same time then you might as well be doubling the force involve.

Multiple convex meshes can be used to approximate concave meshes. It's more efficient than a concave mesh. Which leads back to the original question. Concave collision meshes are possible. It's not like there's a hard and fast rule preventing it. It's inefficient and can lead to unwanted collision issues. I've also read but not confirmed that collisions between two concave meshes can't be handled. At all.

It also has the side effect of causing certain of PF's parts to decouple that wouldn't normally decouple. It's the only thing I can think of that would cause the fuselage parts (which aren't supposed to decouple) to do that.

No, definitely I will not do that.

Oops a couple things, there's some debug items that show up in the part context menus. I forgot to disable those. Other thing is it actually might not be incurring as much drag as it should.

Yes, long load times and even freezes are not unheard of. However, the items that ATM has processed prior to the freeze do not have to be repeated. Those are now cached. So if it looks like it hangs then just restart. Each time it will have less work to do and will be less likely to freeze.

Given upcoming KSP 1.0 changes to aerodynamics, I have no idea where this mod will be going in the coming months or even if it will survive KSP 1.0 So, I've been sitting on some changes and experiments that I'm going to make available today: Stock Drag Fix version 1.2 (EXPERIMENTAL) maximum_drag and minimum_drag are now modified based on part diameter and/or length. unused drag models in stock KSP are now put to use. (CONIC and CYLINDRICAL) Nose cones, some crew capsules are set to CONIC. Any non-CONIC part that can have its length clearly determined via Module Manager config is set to CYLINDRICAL Mass compensation mechanism changed. Part mass is discarded in favor of total vehicle mass. Vehicle mass is cached and recalculated each physics frame. Drag now changes based on vehicle orientation. This WILL break MechJeb landing calculations for the same reasons that FAR breaks them. Mach drag modifier in. (using static SL speed of sound. Yes I know this is wrong) Stock cargo bays (Mk2, Mk3) and KW Rocketry's petal adapter now shield parts contained from drag. This will also affect Deadly Reentry: Parts thus shielded will be recognized as shielded by DRE. KSO cargo bays and other will be added later where possible. https://github.com/Starwaster/StockDragFix/releases/tag/1.2

Maybe someone is. Don't forget that Squad is not just a company that makes a computer game called Kerbal Space Program. There's a parent company which had nothing to do with computer software. They're a marketing company (http://squad.com.mx/) Maybe they have some issues with how things are being handled.

Kerbal Joint Reinforcement.

Create a file in your GameData folder named BaconChutes.cfg Copy and paste the following into that file. Then, serve and enjoy. I mean, start up the game. MATERIAL { name = Bacon description = Bacon, while an incredibly tasty meat candy, is completely useless as a parachute being too fragile to withstand deployment forces. DO NOT USE AS A PARACHUTE. areaDensity = 0.0005 dragCoefficient = 0.05 areaCost = 0.1 } You will now be able to create chutes made out of bacon! They look just like real parachutes due to the magic of Kerbal engineering. (read: I was too lazy to make a bacon texture) Note however that they tend to be heavier than ordinary chutes being thicker and a little denser. They are also near useless as parachutes because the bacon tends to stretch, deform and tear. Your Kerbals will probably not survive using this chute. Well, at least the recovery crews however will not have to worry about sharing the chutes with the crew. Finally, the cost per chute is outrageous. It's very difficult to keep enough bacon in stock to make new chutes out of it because the Kerbals keep eating it all. The cost of increased inventory security is therefore factored into the cost of each chute. Also the cost of constantly having to procure more bacon as the security guards keep eating the stock.