Decouplers stuck on boosters, errors when switching vessels or using quit menu.

[DaveTSG]

Hi folks,

I've got a bunch of mods installed, and only recently (two days ago) installed RT. I developed a rocket booster with my first LKO comms satellite on top, protected by procedural fairings.

The design is something like this:

satellite
small decoupler
fairing base
1.25 to 2.5m structural adapter
2.5 to 3.75m structural adapter
TR-38-D 3.75m decoupler
5m heat shield
booster with landing stuffs

The idea being that the upper-most decoupler releases the satellite (which works fine), I then switch to the satellite and deliver it to its final orbit (all good there). My problem lies when I switch back to the booster so I can land and recover it.

First thing I do is I lower my periapse to 30km, then I use the flight computer to point prograde (because my heat shield is at the top, not the bottom).

I have done the following a few different ways, but the end result is that both the 3.75m decoupler, and the heat shield (regardless of whether I use the Deadly Re-entry heatshields or the B9 heatshields or whatever)... the decouplers don't decouple. The flight computer shows the same command ("decoupling"), and if I try to cancel the command, the flight computer adds a new command "cancel command" and it just keeps repeating the "decouple" command. I get the decoupling cloud of gas as if it actually did decouple, but regardless, the 1.25 to 2.5 and 2.5 to 3.75m structural adapters remain attached to the booster, so the heat shield isn't exposed.

I also tried designing it slightly differently, and had just the heat shield. But then when I get to landing, I send the command to decouple the heat shield (so that the landing legs can extend out), but then I get the same issue where the heat-shield itself won't decouple.

Once I try to decouple anything, because it keeps repeating the same decouple command, any new commands entered are queued but never carried out, so I essentially lose all control of the vessel.

Issue two which may be related... after switching between vessels (this is at random, not necessarily between the booster and satellite, but can be between different satellites in my comms network), at random KSP stops allowing me to switch between vessels. I can press the 'Switch To' button in the map view, but nothing happens. Further, if I press the Escape key and press 'Space Center', or 'Quit', again, nothing happens.

I believe this to be an RT issue because uninstalling RT and doing the same without the RT parts has no issue at all. The issue first appeared when I installed RT, and having later uninstalled it, the issue no longer happens.

I'm running KSP v0.90 on OS X, RT v1.6.0.

Full mod list:

Blizzy's Toolbar
Active Texture Management
B9 Aerospace
Better Buoyancy
Contract Configurator (with RT contracts)
Custom Biomes
Deadly Re-entry
FAR
Fusebox
Kerbal Attachment System
Kerbal Engineer
KSP AVC
MechJeb
Mission Controller
Navyfish's Docking Port Alignment Indicator
Procedural Fairings
RCS Build Aid
Real Chute
RemoteTech
SCANSat
Stage Recovery
TAC Fuel Balancer
Tweak Scale
Kerbal Alarm Clock
KSP Interstellar
Module Manager v2.5.8

Attached is a screenshot showing what it looks like when something tries to decouple.

I have compressed my KSP.log, player.log and persistent.sfs files into a ZIP file, here: https://dl.dropboxusercontent.com/u/4446393/logs.zip

Thanks in advance for any help you can give.
--Dave.

[Peppie84]

Hi @DaveTSG ,
thanks for your detailed report. I think this is a problem thrown from the ContractConfigurator.

@jrossignol here the informations:
http://pastebin.com/3ACTHz2h

and i also found an exception thrown by RemoteTech while saving a TargetCommand:
http://pastebin.com/nNBtDViq

[DaveTSG]

Thanks, @Peppie23 .

Unfortunately, I'm a bit of a noob (I've been playing KSP for years, but have no idea about coding).

Do you mean that Contract Configurator, the separate mod, is the issue? Or is it the RT-specific contract files for Contract Configurator?

(Do I need to report this to CC devs?)

Thanks again. :)
Dave

[jrossignol]

Thanks @Peppie23. @DaveTSG : I've raised this over on the ContractConfigurator GitHub (see issue #104). I'll try to get a fix out ASAP.

[DaveTSG]

Thanks folks for your work and speedy fix.

I can confirm that the decouplers are working perfectly now under the exact same situation using RT v1.6.1:

(also, adding those wings helped control the descent. :P )

That said, though, during the descent I needed to change a few queued commands and, when I tried to cancel them, I got a "cancel command" command in the flight computer, and nothing happened, and I lost control of the craft. I should have had full control of the craft as it was connected to my relay network...

Bit of a pity, 'cause it did the full re-entry and descent perfectly. Then just before touch-down, I needed to change the booster's orientation so it would land properly, rather than sideways on the side of a hill. (I had a good connection to my comms network). So yeah, lost that booster due to tipping over upon landing. Otherwise, picture-perfect descent.

I mean, there was some rapid unscheduled disassembly of some air brakes, but nothing fatal:

So here's exactly what happened, and I only mention it because it is similar to the decoupler issue.

1. Re-enter atmosphere.
2. RealChute parachutes pre-armed automatically pre-deploy at 6km ASL and deploy at 3km ASL.
3. Timed action group decouples heat shield and lowers landing legs.

At this point, the landing legs failed to lower, but the heat shield did decouple. I suspect the landing leg issue was because I hadn't properly programmed them into the action groups, I'll check that later.

After decoupling, focus switches from the active booster (which has a probe core on it) to the heat shield itself (which doesn't have any probes), so I have to switch manually back to the booster.

1. Manually lower landing legs using the default KSP button near the altimeter.
2. I then wanted to cancel the GRD+ SRF mode that I had previously set for re-entry. So I pressed the X button next to the Hold SRF Prograde command in the flight computer and then up came the 'Cancelling a command' command, and I lost complete control of everything.

(I needed to do that because one of my four radial parachutes didn't survive re-entry, so it was falling slightly away from straight-down, and I wanted to have it point straight down so it would land properly)
(I also tried instead manually entering in custom pitch/roll/heading values but the same thing happened)

Thanks again.
Dave
Logs, save file: https://dl.dropboxusercontent.com/u/4446393/logs2.zip

[Peppie84]

Hi @DaveTSG ,

i can see the problem but it's not reproducible for me. I need more informations after this:

After decoupling, focus switches from the active booster (which has a probe core on it) to the heat shield itself (which doesn't have any probes), so I have to switch manually back to the booster.

After decoupling you switched to the heat shield? why? Was the flight computer still open?

[DaveTSG]

Sorry, I mean when I decoupled the heat shield, KSP switched to the heat shield by itself - I certainly didn't do that intentionally.

The flight computer did not appear when that happened, IIRC.

[DaveTSG]

Ohh, wait. I think I know why it switched to the heat shield.

In the VAB, the heat shield sits between the booster and the satellite itself. i.e. the heatshield is above the booster.

Ergo, the heat shield is the parent part for the entire booster. So when you decouple it, it doesn't switch to the heat shield specifically, it just stays with the heat shield, instead of switching to the booster.

Either way, there is still the problem of loss of control once I do switch back to the booster.

A temporary work-around should be if I just keep the heat shield attached (or I could 'control from here' on the booster probe prior to decoupling the heat shield). I'll try that later. If I don't advise, assume that work-around worked.

[Peppie84]

Or the heat shield is the root part.

But maybe i can reproduce this issue while i've a signal delay > 1m,
canceling the active command, switch to the space center and back to the
vessel.

The problem here is that the cancel command for the active flight mode has
no reference to a command object. If we save the flight computer by
switching or leaving the vessel we try to look through the command queue to
find the command you want to cancel and save the index from the queue of
this command. But for the active flight mode we can't save an index and
this is the problem while loading the flight computer if you come back.

I'll look for this and your first error later today ;-)
Am 20.01.2015 07:04 schrieb "DaveTSG" notifications@github.com:

Ohh, wait. I think I know why it switched to the heat shield.

In the VAB, the heat shield sits between the booster and the satellite
itself. i.e. the heatshield is above the booster.

Ergo, the heat shield is the parent part for the entire booster. So when
you decouple it, it doesn't switch to the heat shield specifically, it just
stays with the heat shield, instead of switching to the booster.

Either way, there is still the problem of loss of control once I do switch
back to the booster.

A temporary work-around should be if I just keep the heat shield attached
(or I could 'control from here' on the booster probe prior to decoupling
the heat shield). I'll try that later. If I don't advise, assume that
work-around worked.

—
Reply to this email directly or view it on GitHub
#311 (comment)
.

[Peppie84]

Hi @DaveTSG,

can you please try to reproduce your issue with this version:
https://github.com/RemoteTechnologiesGroup/RemoteTech/releases/tag/build-master-245

the root cause of this problem is maybe #313

[Peppie84]

btw. the issue from my first comment is also fixed with this new version

[DaveTSG]

I'll give that new version a go shortly. Thanks. :)

[DaveTSG]

Ok, so got into orbit, decoupled the satellite, switched back to the rocket, pressed the SRF GRD+ button. Rocket starts spinning around but never actually gets to prograde, just keeps whirling around at random.

So I deleted that command from the flight computer and used MechJeb to point prograde instead. Once the rocket was pointing prograde, I then disabled MJ and re-enabled SRF GRD+ in the flight computer, and it held the rocket stable.

Anyway, so I then warped to re-entry, and then the rocket needed to rotate back to facing prograde. Again, RT couldn't stabilise it, so I used MJ instead to get it facing prograde, then disabled MJ and re-enabled RT to hold prograde.

During the re-entry, RT lost control again, despite the vehicle being identical to previous iterations... the only change has been the RT builds. (In previous re-entries, control was perfect).

Due to the spinning during re-entry, the rocket overheated and was destroyed before reaching the point when the heat shield would normally decouple.

So I reloaded back to my save just prior to re-entry and decoupled the heat shield using my action group manually (rather than setting the timer) - i.e. I decoupled the heat shield in space.

KSP seemed to switch focus to the heat shield for the blink of an eye, and then instantly switched back to the rocket itself.

After that, when entering commands into the flight computer for the rocket itself, I got the same issue, with commands being ignored:

Logs/saves: https://dl.dropboxusercontent.com/u/4446393/logs3.zip

Sorry this is turning out to be a more involved issue than expected...

Thanks again,
Dave

[Peppie84]

thanks Dave. So I have to take another look to this issue ^^

[Peppie84]

Would it possible to do a cross test with v1.5.2 ?

I See really bad exception from RemoteTech on your log.

[EXC 13:59:00.851] KeyNotFoundException: The given key was not present in the dictionary.
System.Collections.Generic.Dictionary2[System.Guid,System.Collections.Generic.List1[RemoteTech.SimpleTypes.NetworkLink`1[RemoteTech.ISatellite]]].get_Item (Guid key)
RemoteTech.NetworkManager.UpdateGraph (ISatellite a)
RemoteTech.NetworkManager.OnPhysicsUpdate ()
RemoteTech.RTCore.FixedUpdate ()

and

[EXC 14:04:00.389] ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
System.Collections.Generic.List1[RemoteTech.ISignalProcessor].get_Item (Int32 index) RemoteTech.VesselSatellite.get_SignalProcessor () RemoteTech.VesselSatellite.get_Visible () RemoteTech.NetworkRenderer.CheckVisibility (RemoteTech.SimpleTypes.BidirectionalEdge1 edge)
System.Linq.Enumerable+c__Iterator1D1[RemoteTech.SimpleTypes.BidirectionalEdge1[RemoteTech.ISatellite]].MoveNext ()
System.Collections.Generic.List1[RemoteTech.SimpleTypes.BidirectionalEdge1[RemoteTech.ISatellite]].AddEnumerable (IEnumerable1 enumerable) System.Collections.Generic.List1[RemoteTech.SimpleTypes.BidirectionalEdge1[RemoteTech.ISatellite]]..ctor (IEnumerable1 collection)
System.Linq.Enumerable.ToList[BidirectionalEdge1](IEnumerable1 source)
RemoteTech.NetworkRenderer.UpdateNetworkEdges ()
RemoteTech.NetworkRenderer.OnPreCull ()

and i want to know if this issue comes from 1.6 or is an old one.

[DaveTSG]

Ok, installed v1.5.2. I seemed to have full control the whole way down this time, including after decoupling of the heat shield.

Unfortunately, the parachutes didn't deploy this time for some reason, despite being armed. I don't know if that's a RealChute issue, or somehow RT is affecting RealChute? But decoupling seems to have worked otherwise.

That said, holding to surface prograde using the flight computer was still unstable and couldn't control the booster, even when in space when it should have been able to. I had MechJeb hold prograde during the full EDL instead, and it was very stable the whole way down... until hydrobraking due to parachute failure.

Logs: https://dl.dropboxusercontent.com/u/4446393/logs4.zip

[Peppie84]

hmm ok so it's an issue in 1.6. Thanks for testings. My biggest problem is that i can't reproduce this issue :'( i would like to use your save file but you use too much mods :/ Do you get this issue only by deorbiting this vessel ?

[DaveTSG]

It happens whenever I decouple the heatshield or any of the stock decouplers used on this particular design (regardless of trajectory - I have tested it during launch, when in orbit, and when on a re-entry trajectory, both in space and within Kerbin's atmosphere). I haven't noticed it on any other designs as yet. This particular design has flown five missions now and I have had the same issue on all five missions.

(Would it help if I zipped up my GameData folder so you have absolutely everything exactly the way I have it?)

[Peppie84]

Still no luck to reproduce even if i decouple heat shields.
How big is your GameData ? ~2Gb? ☺️

Edit: I'll try to install your mod list via ckan

[Peppie84]

oh yeah that's weird. After one hour downloading and one hour activeManager-caching i'm on the track to get this issue. thx for reporting. Btw. the timer stops counting down, and thats the problem why your commands stack into the queue and will not proceed properly.

[Peppie84]

@DaveTSG i got the "error"/problem. The flight computer is bound to a unique vessel id given from ksp. After decoupling ksp gives you a new unique id. Are you sure that the heat shield or the decoupler are not the root part of this vessel? You can "fix" that when you close the open flight computer after decoupling and open a "new" one, than you can control your vessel without any problems.

I can't make any fix for this. Maybe we can change that the flight computer is bound directly to it's probe-Core but not atm. The changes would be too huge and i don't know if this would be a good idea.

Sorry for this confusion.
btw. i can reproduce this error on every version of remoteTech.

[DaveTSG]

"Are you sure that the heat shield or the decoupler are not the root part of this vessel?"
Yes, it is the root part.

"You can "fix" that when you close the open flight computer after decoupling and open a "new" one, than you can control your vessel without any problems."
Cool, I'll give that a go. Thanks for the work-around. :)

"I can reproduce this error on every version of remoteTech."
At least it's not just in my head. ;)

Thanks again for your researching the problem and offering a work-around. I appreciate your spending the time.