FlowerChild

Good news: Apparently this has been confirmed by Squad as a bug, and they are aware of it, despite the "Not a bug" in this thread title

... I just have to utter a brief chuckle about that one message immediately following the other there Bugs do exist. No matter how much we love the game, denying them because we all wanted the release to be perfect doesn't help anyone, Squad included.

I personally don't really care whether it's a barn or what have you, but there's a big gaping hole in the career progression where another level of buildings is obviously supposed to go. For example, you jump from like 18 tons launch limit up to something like 140, making it totally irrelevant for that stage of the game. Same with part counts on the VAB upgrades.

Final shouldn't be necessary as their aren't other ModuleManager patches being applied here. The changes are straight to the original .cfg files. I believe Final only affects the order in which patches are loaded, not how they're applied to the original files.

I think those complaints are mostly originating from the "strap a science Jr." crowd, that aren't used to having to be concerned with COM on reentry vehicles. There's a very real underlying problem to it as well, that's unfortunately getting obfuscated by the above complaints when it gets misinterpreted as being the same thing. It isn't exactly nose-first either. It tends to veer off at about a 45 degree angle to the direction of travel, and is stable there. Problem is, that means the pod itself is well in the shockwave

Try it dead stick (no control input). Yes, if you have sufficient power for your reaction wheels, you can fight the way it veers off all the way down. That really shouldn't be how this works.

No, seriously, it's a bug not expected behavior. Read over the thread I linked and you'll see what I mean. I'm familiar with both FAR and DRE. This isn't the same thing. People attaching Science Jr. to the bottom of their pods, yes, I agree, that should cause problems. Mk1 command pods constantly veering off course with only a heatshield attached? That's something else, and it's also easily fixed by enabling physics on the shields.

Yeah, that's what I was wondering, thanks Was implied by your first message, but just wanted to be certain the offset was behaving as expected and not locked into a coordinate system, which would clearly indicate it is a bug. It may still be regardless mind you.

It's not just the science Jr., which I think is arguably reasonable behavior. Just a plain capsule with only a heatshield will do it. Related bug thread here, and so far our only official response seems to be having it labeled as "not a bug": http://forum.kerbalspaceprogram.com/threads/116839-Heat-shield-seems-to-be-treated-as-having-0-mass

I lost two pilots in my career game due to heatshields producing some kind of weird phantom force that veers them off course. I've since found a workaround through modifying the related .cfg files, but given you can't play more than a few launches into career mode without rockets blowing up for reasons beyond your control, I'd say even that alone is very close to being a showstopper, and not something that new players will have any idea how to resolve. There are other issues as well of course, and ones that likely would have come out very quickly in testing, as they have today. As I said above, I think this is likely the best release of KSP yet. Really like it, and if it wasn't called 1.0, I'd be unlikely to object too strenuously. However, it definitely does have problems, and ones that even a moderate amount of testing would have quickly revealed.

Yup, I agree. That's why I was asking that, as whether or not it's operating in local or absolute terms may give some indication as to whether it's intentional or a bug. Will test it myself on my next launch which I'm just about to perform

My pleasure. I hope it helps people out I'm not 100% convinced that's the actual problem btw, as your direction of travel still seems *slightly* offset with physics turned on in a way that I'm not entirely certain is intentional. At the very least, it does however sufficiently mask the problem to serve as a good workaround until we get a more official solution.

Best of luck. Don't get me wrong, there's some great stuff in here, and if it weren't called 1.0 it would likely be the best release yet. Let's just say we weren't wrong about it being rush job that didn't undergo sufficient testing though.

Don't speak too soon man. If you're anything like me (and I suspect you are), I suspect it's only going to take an hour or two of play before you start seeing some rather major problems and your blood pressure begins to rise

Did the offset rotate with your roll at least?

There you go: @PART[HeatShield*] { @PhysicsSignificance = 0 } You will of course need ModuleManager installed for this to work, which can be found here: http://forum.kerbalspaceprogram.com/threads/55219 Install MM, drop the above into a .cfg file in your GameData directory, and you should be good to go.

As an aside, you can also do this with a single change: @PART[HeatShield*] { @PhysicsSignificance = 0 } You will of course need ModuleManager installed for this to work, which can be found here: http://forum.kerbalspaceprogram.com/threads/55219 Install MM, drop the above into a .cfg file in your GameData directory, and you should be good to go. I'm really hoping that they didn't all go on vacation or something, under the assumption that 1.0 would be a bug free release.

That's really interesting, and I did not know that. Thanks I would assume then the slight offset is intended, but without physics applied it becomes WAY too dominant due to the COM remaining too high. I'm also not certain the offset moves as your roll though. Will test that out. I haven't tested in game, but looking at the .cfg files, I would assume they all have this problem, as physics is turned off for each of them.

There is definitely a bug involved here. There's a lot of discussion going on about it in this thread: http://forum.kerbalspaceprogram.com/threads/116895-One-way-stock-1-0-heat-shielding-is-a-bit-unfair-versus-old-DRE-mod-s-heat-sheilding Where I also presented what seems to be a temporary workaround: Which seems to largely fix it. Could a moderator please remove the "Not a bug" label from this thread? It definitely is one, and it's a rather significant problem, especially if you're playing with reentry heat turned up and thus need a 1.25m shield on a Mk1 command pod to survive reentry. Without the above fix, it will constantly veer out of the airflow and your capsule will most certainly explode without heavy and constant control input to compensate (assuming you have enough battery power left to operate your reaction wheels).

If you open the debug menu with alt-f12, look at the physics tab, and select reentry heating, there's a couple of options for displaying it, either as text in the right click part menu, or graphically (although I find the graphic display is too ambiguous to really be useful). And yes, not having it display in some way by default is a pretty huge oversight, and I'm not saying otherwise. The above is at least a workaround until it's corrected though.

Except it's been labeled as "not a bug"

Yup, that's exactly what I saw, and it's consistent with what I saw of the problematic behavior before turning physics on for the part, just less amplified. Like I mentioned above, I think turning on physics may just minimize the problem, but not actually be correcting it. Will try playing around with some of the other values, this in particular looks suspicious to me: jettisonDirection = 0 0 1 Which seems to imply that "down" on the model is along the z axis, as opposed to this: CoLOffset = 0.0, -0.15, 0.0 Which seems to imply it's along the y axis. Not entirely certain, but the above looks fishy to me.

NathanKell can probably give a much more detailed answer on this given his experience with DRE, but my understanding is that ablation is not just a matter of heat, but of airflow causing the shield to slowly rip away, which is what dissipates it. I think without that airflow the shield will stay intact, and ablation won't actually occur. Again...no expert here, and I may be wrong as a result, but that was my understanding of it.

BTW: Did you happen to notice a *slight* horizontal offset to your trajectory on the way down? I'm wondering if this actually has to do with the center of lift, rather than it being physicsless, with the COM offset due to turning physics on just overwhelming that and causing you not to veer off so severely. It's needed on 120% heat settings, which is what I'm playing on. The Mk1 doesn't have an integrated shield in stock. But that's not how ablative shields work in the consensus reality, hence his point.

As a follow up, having changed the above value I was able to dead-stick reenter no problem with a 1.25m heatshield attached directly to the bottom of a Mk1 command pod, apoapsis around 100Km, periapsis of 30Km, 120% heat setting. The tumbling appears to be related to the heatshield (which you don't have attached in those screens), not the pod itself.