Krakensbane vs. TR-38-D Size 3 Decoupler

[Geschosskopf]

When the 3.75m parts 1st came out, the TR-38-D stack decoupler had a problem with Krakensbane.  If  you staged it while your ship had an orbital velocity < ~800m/s (say in Munar orbit), the decoupler and whatever parts were below it would get some velocity applied to them very different from the remaining part of the ship.  This usually resulted in the decoupler slamming into the rest of the ship at high velocity, destroying whatever it hit (usually the engine of the upper stage).  Back in those ancient days, the workaround was to change the value of the part's PhysicsSignificance (or some such variable).  This value was either 0 or 1 (I forget which) and the fix was to change this value to its opposite.  This fix was soon incorporated into the stock cfg file and everything was cool.

Anyway, now it's years later in 1.3.1 and I'm again experiencing this same problem with the TR-38-D.  NOT 100% of the time, but about 50/50  And only with the TR-38-D and a few mod decouplers, but not the smaller stock stack decouplers.  So I looked in the TR-38-D's current part cfg file and noticed there's no longer a PhysicsSignificance line.  In fact, this line is no longer in any part cfg file that I could find.

So.....

1.  Is anybody else having this problem?

2.  How do you fix it these days?

Thanks.

 

Edited November 18, 2017 by Geschosskopf

[bewing]

I'll try to test this. I never use TR38D's on my Mun rockets.

 

[Geschosskopf]

1 hour ago, bewing said:

I'll try to test this. I never use TR38D's on my Mun rockets.

Thanks.  I was also the 1st to notice this the 1st time back several years ago.  Apparently few folks use 3.75m landers    I use them a lot for building large colonies, training many recruits at once, and/or lifting lots of fuel from a base.

Anyway, the Krakensbane issue is that when you stage the TR-38-D at a low enough orbital speed, the staged parts suddenly lose their orbital velocity.  So if you stage with the ship still facing retrograde, such as during or after a capture or de-orbit burn, the upper stage slams into the dropped stage at its full orbital velocity.  If you stage pointing radially or up/down, sometimes there's a collision, sometimes you get lucky.  If you stage with the ship pointing prograde, usually you'll be OK but the dropped stage appears to vanish instantly as you leave it behind with your orbital velocity.

The annoying thing is, I don't have this happening 100% of the time.  I built a test ship in a (Stock + HyperEdit) install that consisted of a stack small fuel tanks and decouplers of all sizes and teleported it to Mun.  The TR-38-D had the Krakensbane problem the first 3 times I did the test, but not the last 3.  None of the other stack decouplers ever had the problem.

I started doing this test because I first encountered the problem with a mod decoupler in a heavily modded install.  Once I recognized what was happening, I tried the TR-38-D in that game and also got the Krakensbane issue with it.  This modded game is in Alternis Kerbol so that's why I tried it in the stock game, to see if it was a Kopernicus issue.  The 1st 3 times I tried the TR-38-D in the stock game, it had the Krakensbane issue, but then stopped having it.  So I really don't know what's going on.

[Geschosskopf]

Upon further experimentation in the stock game, I've noticed the following things:

• Whether or not the Krakensbane kicks in on the TR-38-D is dependent on ship mass.  If you have just a bunch of decouplers and/or minimal fuel tanks with them, then it probably won't happen.  But if you have a real ship, with mass appropriate to actually do something, then Krakensbane kicks in every time.
• When Krakensbane happens, the dropped booster suddenly goes to 19m/s orbital velocity, and magically hangs in space at the same altitude as before, despite its low velocity.
• This hanging in space of the staged booster continues until the booster hits something.  If any parts of the booster survive the collision, they fall to the surface as you'd expect things to with their combination of altitude and low velocity.

I'll post some pics in a while (going out to supper).  Sadly, this run did not create an output_log file.

[steuben]

what masses were you working with?

[Geschosskopf]

4 hours ago, steuben said:

what masses were you working with?

Well, in my modded game, which used a mod decoupler, the upper stage was about 19 tons and the jettisoned booster was about 10 tons I think.

In the stock game, I don't know---no mods to tot it up for me and too lazy to add it up myself.  But you can see in the pics below what I was dealing with.

So here's a stock test ship that has decent mass.  This one has the Krakensbane kick in every time when the TR-38-D is staged with an orbital velocity < about 800m/s.  All tanks are full. 

 

I teleported this to a 100km Munar orbit, where the orbital velocity is ~460m/s.  Then I pointed it retrograde so that when the lower stage stops in place due to Krakensbane, the upper stage will slam into it at about 460m/s.

 

Such collisions make pretty explosions.

 

These explosions result for many collisions between parts.  Of the upper stage, only the pod and sometimes 1 or 2 of the parts immediately below it survive.

 

In the pic above, note that the pod has slowed to 200m/s.  However, it's not falling, it's maintaining altitude still at about 100km, despite not having enough velocity.

With this same ship, if you point it prograde and then stage the TR-38-D, the booster separates cleanly and instantly vanishes because it stops in place while the camera follows the upper stage at 460m/s.  If you switch back to the lower stage, it's maintaining altitude at 19m/s.

 

Here's a lighter test craft.  This one has 1 each of every type of stock decoupler, only the smallest tanks of each side (all full), and a probe core.  Each decoupler is in a stage by itself, starting with the 3 radial ones, then the TR-38-D, then the 2.5, 1.25, and 0.,625m stack decouplers in that order.

 

With this craft in a 100km Munar orbit, Krakensbane almost never happens..  When it happens, it's only the TR-38-D, never any of the others.  With this ship, the TR-38-D is decoupling only itself--no parts below it.  In the pic below, I had the craft turned prograde and staged everything so all the jettisoned parts would like up neatly.  If Krakensbane had happened, the TR-38-D would not be visible because it would have been left behind at 460m/s by the reset of the craft.

 

Edited November 19, 2017 by Geschosskopf

[bewing]

Trying it in stock with various-sized amusing ships. No luck getting a repro yet.

 

[Geschosskopf]

9 hours ago, bewing said:

Trying it in stock with various-sized amusing ships. No luck getting a repro yet.

Have you tried a copy of the ship I was using?

Anyway, whether you can reproduce it or not, I need to fix it in my own games (both clean stock and modded).  What's happening to me is that the TR-38-D is acting like it's physicsless, just like it did years ago.  

• Old bug report from 2014
• Old bug report from 2016

Problem is, these days there's no long a PhysicsSignificance line in the cfg file.  And supposedly there are no "physicsless" parts anymore, or so I heard.  But it seems to me that the old "physicsless" code is still in there somewhere, and has somehow been turned on even in my clean stock game.  I'm wondering if there's a setting somewhere in some game-level config file that's somehow gotten changed on my end and allowed this "obsolete" behavior to resurface.  Any clue where I might find something like that?

 

[Geschosskopf]

10 hours ago, bewing said:

Trying it in stock with various-sized amusing ships. No luck getting a repro yet.

 

Here's the stock ship I'm using:  https://www.dropbox.com/s/q2zssq8ap50rmai/Test Krakensbane.craft?dl=0

I even tried adding a PhysicsSignificance = 0 line to the TR-38-D's config file.  This had no effect at all.  Didn't cause any errors on loading, didn't stop Krakensbane from destroying the ship when staged in Munar orbit with velocity < 800m/s.  Above 800m/s the decoupler works fine.

[Plusck]

24 minutes ago, Geschosskopf said:

Here's the stock ship I'm using:  https://www.dropbox.com/s/q2zssq8ap50rmai/Test Krakensbane.craft?dl=0

I even tried adding a PhysicsSignificance = 0 line to the TR-38-D's config file.  This had no effect at all.  Didn't cause any errors on loading, didn't stop Krakensbane from destroying the ship when staged in Munar orbit with velocity < 800m/s.  Above 800m/s the decoupler works fine.

I tried your ship. OSX 1.3.1. Used stock cheats to "hyperedit" to a 100k then 20k Munar orbit in sandbox (medium). Tried going orbital, suborbital, escape orbital, prograde and retrograde... no dice. The ship worked just like it looked like it should...

Maybe a quicksave of your ship just prior to a successful reproduction on your end... mods permitting. Though the failure to reproduce in stock tends to suggest that some mod somewhere is causing this.

Edited November 19, 2017 by Plusck

[Geschosskopf]

1 minute ago, Plusck said:

I tried your ship. OSX 1.3.1. Used stock cheats to "hyperedit" to a 100k then 20k Munar orbit in sandbox (medium). Tried going orbital, suborbital, escape orbital, prograde and retrograde... no dice. The ship worked just like it looked like it should...

Thanks.

This more or less confirms my suspicion that something weird happened on my end, causing the old physics-less behavior to resurface.  Any ideas how to fix that?  I'm asking this question over in the tech support forum, too.

[Geschosskopf]

47 minutes ago, Plusck said:

Maybe a quicksave of your ship just prior to a successful reproduction on your end... mods permitting. Though the failure to reproduce in stock tends to suggest that some mod somewhere is causing this.

Here's the whole save folder from my stock game.

https://www.dropbox.com/sh/kq9t8vf3y8nk5v0/AABeT2D7fqMBPdw12pzfSwJla?dl=0

AFAIK the only mod that's ever been in this install is HyperEdit.  I deleted all local content from Steam and downloaded the game from scratch, then copied it to a separate folder so I'd always have a clean copy of 1.3.1.

And here's a quicksave of my test ship on the pad.

https://www.dropbox.com/s/ry8th6oa7y9n6ws/Test Ship on Pad - quicksave.sfs?dl=0

 

Edited November 19, 2017 by Geschosskopf

[Plusck]

1 hour ago, Geschosskopf said:

Here's the whole save folder from my stock game.

https://www.dropbox.com/sh/kq9t8vf3y8nk5v0/AABeT2D7fqMBPdw12pzfSwJla?dl=0

AFAIK the only mod that's ever been in this install is HyperEdit.  I deleted all local content from Steam and downloaded the game from scratch, then copied it to a separate folder so I'd always have a clean copy of 1.3.1.

And here's a quicksave of my test ship on the pad.

https://www.dropbox.com/s/ry8th6oa7y9n6ws/Test Ship on Pad - quicksave.sfs?dl=0

 

ok, well, no more success in getting the bug to work there.

I meant, rather, a quicksave with your ship in position in Munar orbit, in a situation where, if you stage immediately, the bug will appear. It is very odd that you're getting this on a clean, clean install.

I've only used HyperEdit to place ships on the surface a couple of times. I've often used it to put ships into different orbits, but now stock cheats let you do exactly the same thing I haven't felt the need to download it. The only mod I have installed is KER.

Sorry if I can't be much help here. Happy to test anything you want to throw out there, but so far all I can do is give hints about what it isn't.

edit: For examples, things it isn't: MacOS X 10.11 (El Capitan), Mac Pro with Radeon 5770 graphics card, running stock 1.3.1 + KER.
That old bug report talking about graphics card is interesting.
Also what is interesting is that the first report in that crash pic is the 7200 fuel tank (the white one) crashing into the 2.5=>3.75m adapter (near the top of the stack). In other words, the "debris" assembly is superimposed on the remainder of the ship before the game realises what is happening. Ejected fuel tank hits adapter, ejected separatron his upper stage separatron, ejected engine hits upper stage engine, adapter hits solar panels...

Edited November 19, 2017 by Plusck

[bewing]

No luck with me, either, trying your ship. So the only thing I can think of is a slightly corrupted game. Have you done a file verification from steam yet?

 

[Geschosskopf]

3 hours ago, bewing said:

No luck with me, either, trying your ship. So the only thing I can think of is a slightly corrupted game. Have you done a file verification from steam yet?

 

Nope.   Didn't know that was possible.  How you do that?

[bewing]

7 minutes ago, Geschosskopf said:

Nope.   Didn't know that was possible.  How you do that?

In your Library/Games, right click on Kerbal Space Program. In the menu, select Properties. Choose the Local Files tab, and click the "Verify Integrity" button. It'll instantly redownload any corrupted game files.

[Geschosskopf]

OK, all figured.  Thanks for the help, folks!

[boccelounge]

On 11/20/2017 at 1:35 PM, Geschosskopf said:

OK, all figured.  Thanks for the help, folks!

If I may ask, how did you resolve the issue?  Was the "Verify Integrity" check sufficient?  And if so, did the PhysicsSignificance value change in the .cfg file?

I ask because 1) this was an interesting question/conversation, and I'd like to read the end of the story, and 2) I've seen a different-but-similar problem myself that I also suspected was related to PhysicsSignificance.

Your explanation appreciated...

Edited November 24, 2017 by boccelounge

[Geschosskopf]

6 hours ago, boccelounge said:

If I may ask, how did you resolve the issue?  Was the "Verify Integrity" check sufficient?  And if so, did the PhysicsSignificance value change in the .cfg file?

I ask because 1) this was an interesting question/conversation, and I'd like to read the end of the story, and 2) I've seen a different-but-similar problem myself that I also suspected was related to PhysicsSignificance.

Your explanation appreciated...

The integrity check turned up a couple of files but that had no effect.

Adding a PhysicsSignificance line to the decoupler had no effect.

The problem was caused by HyperEdit.   I forget who figured this out but it wasn't me.  Anyway, if you use HyperEdit to go from the ground at Kerbin directly to low orbit of another planet, the whole ship will be shown as "landed".  Essentially no orbital velocity, unable to create maneuver nodes, but maintaining altitude.  If you HyperEdit directly to a high enough orbit, the ship as a whole will act like it's in space normally, and you can then HyperEdit it down to the low orbit you intended.  But even if the ship as a whole is "in space", when you drop a booster, that booster becomes "landed".  Thus, it has essentially zero orbital velocity and the rest of the ship, which isn't "landed", slams into it at orbital velocity.

So, this HyperEdit bug created symptoms exactly the same as the old Krakensbane issue, but was from a totally different cause.  Krakensbane was a red herring.

The moral to the story is:

• Use the stock orbit cheat (which I didn't know existed until now) instead of HyperEdit
• If you use HyperEdit, make the trip in 2 step:  Ground at Kerbin --> orbiting Kerbin --> orbiting other planets.  This seems to avoid the "landed" problem.