net-lisias-ksp / ksp-recall Goto Github PK

Due a typo when uploading the thing into SpaceDock, I need to bump the version to 0.2 to prevent playing havoc on CKAN.

See this post on Forum for more info.

Is this TS?
What is it?
Why is it there?

I ask because KSP_Recall does this ...

[LOG 14:35:15.411] [KSP_Recall] INFO: Removing Resourceful support for kerbalEVA () due this part is not supported..
[LOG 14:35:15.411] [KSP_Recall] INFO: Removing Resourceful support for kerbalEVAfemale () due this part is not supported..
[LOG 14:35:15.411] [KSP_Recall] INFO: Removing Resourceful support for kerbalEVAVintage () due this part is not supported..
[LOG 14:35:15.411] [KSP_Recall] INFO: Removing Resourceful support for kerbalEVAfemaleVintage () due this part is not supported..
[LOG 14:35:15.411] [KSP_Recall] INFO: Removing Resourceful support for kerbalEVAFuture () due this part is not supported..
[LOG 14:35:15.411] [KSP_Recall] INFO: Removing Resourceful support for kerbalEVAfemaleFuture () due this part is not supported..

But, kerbalEVA* still has this ...

	MODULE
	{
		name = Resourceful
		active = True
	}

What am I missing?

General Support Issue.

For things that do not deserve (at least, yet) an Issue.

after installing this mod, the start up loading freezes. i removed it and things work again.
tried twice.

Fellow Kerbonaut ttr reported some problems on his rig on TweakScale's thread.

Apparently we have a toe-stomping-fest with DeepFreeze:

[LOG 15:37:04.951] [KSP-Recall-AttachedOnEditor] TRACE: OnAwake <NO VESSEL>-CRY-0300Freezer(Clone):FFF6DA6C
[LOG 15:37:04.952] DeepFreezer OnDestroy
[EXC 15:37:04.954] NullReferenceException: Object reference not set to an instance of an object
        DF.DeepFreezer.OnDestroy () (at <72233efaa3ee4936a15201f98fac7b68>:0)
        UnityEngine.DebugLogHandler:LogException(Exception, Object)
        ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
        UnityEngine.Object:DestroyImmediate(Object)
        PartLoader:StripComponent(GameObject)
        PartLoader:CreatePartIcon(GameObject, Single&)
        PartLoader:ParsePart(UrlConfig, ConfigNode)
        <CompileParts>d__56:MoveNext()
        UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
[LOG 15:37:04.964] [KSP-Recall-Refunding] TRACE: OnDestroy CRY-0300Freezer(Clone):0

Further investigate this.

2022.04.09 - tweakscale - KSP.log.zip

Fellow Kerbonaut DasSkelett advised that KSP-Recall should be tagged as a requirement for TweakScale on CKAN, but CKAN don't sort KSP versions - so this would make Recall being installed on everything, including where it is not needed.

Update Recall to allow being installed on anything without peskying the user about - I coded a lot of safeties anyway, and they are working. There's no need for this anymore:

This can be a problem if I'm using something specific for KSP >= 1.8 somewhere - is so, throw the pride through the window and use Reflection. It's too soon to allow KSPe's custom DLL loading to be used by the Mainstream at this moment.

Fellow Kerbonaut Galland1998 reported an issue about Procedural Parts when TweakScale is installed (here and here):

If a procedural part is the initial root part added to a craft then the attach nodes are offset from the part. If you add another of the same procedural part than the attach nods are in the proper place. If you make the second procedural part the root part and delete the original procedural part the attach nodes stay where they are supposed to be.

In the second case if the initial root part placed in the VAB is not a procedural part all of the nodes are where they are supposed to be and if you add a procedural part then the added procedural part has its nodes exactly where they are supposed to be.

RO/RP-1 messes with the base part scales compared to stock KSP so I am not sure if that has something to do with it. It is just strange that it only seems to impact an initial root part from the procedural parts mod.

Didn't understood what happened.

Trying to figure it out.

Second layer surface attached parts are being moved to the center of the attached part.. :(

Problem happening:

Detail of the mishap (zooming into the affected parts):

What the craft intended to be:

It's a mishap on the KSPs OnCopy handling, but I need to check it on KSP < 1.9 to be sure.

Fellow Kerbonaut hugoraider is being screwed by what appears to be a misbehaviour triggered by an unholy interaction between KSP-Recall and (probably) B9PS.

The problems happens only when merging an existent craft into the current one. The misbehaviour is remarkably similar to what happens when AttachedOnEditor is needed but it's absent:

Craft file: Vega 3.craft.zip

This craft needs:

• Bluedog DB
• Conformal Decals
• New Tantares
• Tantares
• Tantares LV
• Tantares SAF
• Tantares SP
• Gemstone LV (not sure)

Most dependencies weren't installed (on purpose). Only Shabby (and 0Harmony), due Conformal Decals, were installed while reproducing the problem as below:

What more or less matches the screen shot provided by the user.

Mission: Search and Destroy (the bug)

See TweakScale/TweakScale#256 for the reason.

Exceptions similar to this show up several times in my log, looks like whenever something tries to do a save. Not sure if this is caused by KSP-Recall or not, this started happening when I grabbed latest updates for my modlist, including updates to: Stockalike Station Parts Expansion Redux, KSP Community Fixes, Kopernicus Planetary System Modifier, and Space Dust.

[EXC 09:15:11.811] ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <9577ac7a62ef43179789031239ba8798>:0)
System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <9577ac7a62ef43179789031239ba8798>:0)
KSP_Recall.AttachedOnEditor.AttachedOnEditor.SaveTo (ConfigNode node) (at :0)
KSP_Recall.AttachedOnEditor.AttachedOnEditor.OnSave (ConfigNode node) (at :0)
PartModule.Save (ConfigNode node) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
ProtoPartModuleSnapshot..ctor (PartModule module) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
ProtoPartSnapshot..ctor (Part PartRef, ProtoVessel protoVessel, System.Boolean preCreate) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
ProtoPartSnapshot..ctor (Part PartRef, ProtoVessel protoVessel) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
ProtoVessel..ctor (Vessel VesselRef, System.Boolean preCreate) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
ProtoVessel..ctor (Vessel VesselRef) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
Vessel.BackupVessel () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
FlightState..ctor () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
Game.Updated (GameScenes startSceneOverride) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
Game.Updated () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
QuickSaveLoad.doSave (System.String filename, System.String screenMsg) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
QuickSaveLoad.quickSave (System.Boolean saveAs) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
QuickSaveLoad.Update () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

KSP.log

Fellow Kerbonaut GoAhead's Space Agency is being stollen by a bug somewhat related to refunding.

See:

• https://forum.kerbalspaceprogram.com/index.php?/topic/192048-143/&do=findComment&comment=4235189
• https://forum.kerbalspaceprogram.com/index.php?/topic/192048-143/&do=findComment&comment=4236149
• https://forum.kerbalspaceprogram.com/index.php?/topic/192048-143/&do=findComment&comment=4236935
• https://forum.kerbalspaceprogram.com/index.php?/topic/173818-181-1122-ksp-interstellar-extended-1295-release-thread/&do=findComment&comment=4240759

Due the mishap described on KSP-ModularManagement/ModuleManagerWatchDog#3, refresh the WatchDog DLL using the original DLL package.

DO NOT USE the building toolchain. "Esta porcaria tá cagada".

Fellow Kerbonaut Krazy1 reported that the Refunding meta-resource is being jettisoned by the Ore Tanks:

Well, he's right. It's really happening. However, this is a bug on the ModuleFuelJettison.

I made this patch:

@PART[LargeTank]:FINAL
{
	RESOURCE
	{
		name = Ablator
		amount = 1500
		maxAmount = 1500
	}
	RESOURCE
	{
		name = ElectricCharge
		amount = 1500
		maxAmount = 1500
	}
}

Fired up KSP and made this test:

Launched it and then jettisoned the Ore Tank contents:

Expanded detail:

So, nope. It's not Recall's fault. Our fellow Kerbonaut found another bug on KSP, this time on ModuleFuelJettison. :)

Extend the AttachedOnEditor downto 1.4.3.

Fellow Kerbonauts Mircea The Young and Aussie Toad Tool found a missed Use Case for AttachedOnEditor: SubAssemblies are being screwed up on use!

This is also happening when merging crafts (see report 3 below).

Reports:

• 1
• 2
• 3

As the tittle says.

Idk maybe the current version works for 1.12.5, but it's listed as incompatible on CKAN.

If it's an issue on CKAN's end, is it possible to mark it as compatible there?

As the tittle says

EDIT:

KSP 1.11 needs an specialised version of Driftless, that would act only on Yaw, as the drift itself is fixed on it.

KSP 1.12 too.

Enumerate all the Glitches of the Serenity's PartModules in order to cook a fix or workaround on Recall.

Fellow Kerbonaut Kor reported on Forum:

I'm playing 1.12.3 with JNSQ and Tweakscale but otherwise a pretty minimally modded setup. I'm running into a problem with stackable cargo parts (struts, fuel ducts, small solar panels, etc.)

• If such a part is launched in a cargo container, it remains stackable until placed "in the world." Then it is no longer stackable.

• If such a part is launched as part of a craft, it immediately becomes non-stackable.

Testing revealed the problem is unrelated to JNSQ and/or TweakScale, I could reproduce the problem on Stock.

Further information about the M.O. and possible causes are Work In Progress.

Felllow Kerbonaut ss8913 reported that KSP-Recall (almost sure ChillingOut) is screwing up KSPIE engines:

so I updated this last night... haven't updated or installed anything else since, and now all my KSPIE engines instantly overheat my craft as soon as activated, and instantly cool off as soon as I throttle down - stock engines don't do that.. I've been playing every night this week and this just started happening when I installed the latest version of this mod from CKAN... any ideas/known issue?

Check what's happening and fix it.

just installed newest version on KSP 1.12.5 via CKAN
Module Manager throws 2 errors on load:

Error - node name does not have balanced brackets (or a space - if so replace with ?):
999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[![MODULE[ModuleB9PartSwitch],!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale]

Error - node name does not have balanced brackets (or a space - if so replace with ?):
999_KSP-Recall/patches/resourceful/@PART[*]:HAS[![MODULE[ModuleB9PartSwitch],!MODULE[ModuleCargoPart],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-RESOURCEFUL]

fixed respectivly =>

@PART[*]:HAS[!MODULE[ModuleB9PartSwitch],!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale]

@PART[*]:HAS[!MODULE[ModuleB9PartSwitch],!MODULE[ModuleCargoPart],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-RESOURCEFUL]

Fellow Kerbonaut DY_ZBX realized something interesting about merging crafts:

I did the following operations.
Re-created and saved both crafts, but still had the same problem as in the video. And I also used Craft Manager at the same time.

When I don't modify the parent part, though, the problem doesn't seem to arise.

Sounds like something missing on AtttachedOnEditor - this may be related with the original problem incepted by ModulePartVariant that was failing to initialise on some circunstaces and was bruteforced on KSP 1.4.3

MAS is peskying about Refunding.

See the following Forum posts:

• First analysis of the log.
• Where I finally understood the problem

A probable solution is to update MaxAmount to be equal to Amount when updating the Refunding.

EDIT: I was wrong on my forum posts about MAS - it's not trying to handle hidden resources, it's calculating the current mass of a PART and, so, it needs to take hidden resources into account.

On Forum, Fellow Kerbonaut Anth12 commented about how DockingPorts were handled on KSP < 1.12, and how they are done now:

1.11 and all previous versions crafts with docking ports and excluding robotics would snap back into position on timewarp/reloading scene.

This doesn't happen in 1.12, the video in my bug report shows the test craft (with 1 docking port) giving a little each time timewarp is disengaged.

In my opinion 1.12 is broken unless they give us at least a docking port variant that is using the old code.

Consider how KSP-Recall could help on this issue. KSP 1.12.2 is going to stay around for some time, as it appears.

Somehow I screwed up something when merging crafts.

[EDIT]: NOPE. It's a new (old) bug on KSP Editor, since 1.4.x

Consider this craft:

Now, let's merge it with itself :

And save it with a different name:

Note the gap between the two subassemblies:

This misbehaviour is consistent downto KSP 1.4.3 - so it's something on me for sure.

Now things start to get instesting:

On TweakScale 2.4.6.25 (the current mainstream latest), by detaching the lower half of the craft and attaching it again, we still get the gap. By saving the craft and loading it again, this misbehaviour doesn't changes.

On TweakScale 2.5 beta (latest), detaching and reattaching the thing doesn't solves the problem, but if you save the craft and load it again, by trying the stunt, you get things tight again!

This confirms that TweakScale is the source of the problem, with KSP-Recall just doing what its being told to do. We fix TweakScale, we have this problem solved.

As the title says, update the KSPe.Light for https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/21

use 2.4.0.4 as base, unless it's proven that this issue also fixes the problem that forced me to rollback TweakScale/TweakScale#216 on TweakScale!

Easting your own dog-food is the ultimate QAS tool. :)

That's the thing: the code that closed TweakScale/TweakScale#219 reopened TweakScale/TweakScale#129. But with a catch: only on editing mode.

So, we have three different situations on KSP's guts that affects the nodes of a variant part:

1) OnCopy (#219)
2) While Editing (#139)
3) OnLoad (detected while troubleshooting TweakScale/TweakScale#219).

EDIT: WRONG. The problem is happening only on Editor, and on PartModule.OnStart.

Apparently the code that fixed TweakScale/TweakScale#219 is related to OnLoad too. But it regressed TweakScale/TweakScale#139.

EDIT: That code fixed TweakScale/TweakScale#219 by pure accident. The regression on TweakScale/TweakScale#139 happened due colateral effects induced by TweakScale/TweakScale#219 that fixed a problem that happens only on Editor, and then screw up things on Flight.

Problem: if I put that code back to fix TweakScale/TweakScale#139, I screw up OnCopy and OnLoad. Clearly, there's something inside KSP that it's out of control, suggesting that Fellow Kerbonaut darthgently was not wrong on suggesting that the problem was KSP and that I didn't, in fact screwed up.

Launch this craft with Recall installed.

See hell breaking loose over the poor Garbage Collector's head.

(There's also a memory leak happening on 3rd parties, completely unrelated to Recall)

I think I missed a use case on KSP-Recall, as I had to partially redo a small fraction of an older "gambiarra" I did there.

It can be something fishy on TweakScale's code, but yet it worths to check and recheck this use-case because the whole purpose of KSP-Recall is to allow the fix to work for everybody.

The Kerbal will die because it's "too cold". It only seems to occur right when exiting the pod if the Kerbal isn't wearing a helmet, or when removing the helmet while still holding on to the hatch.

There seems to be nothing in the log that sheds light on why this happens, but I'm confident it is caused by Recall 2.0.3 (obtained from CKAN). I can reproduce with this mod and nothing else. Removing Recall from my otherwise heavily modded setup makes the bug go away.

Fellow Kerbonaut Krazy1 reported a bug on Forum.

Then when I recovered, it gave me over :funds:160K for a :funds:120K ship. Using latest version. Nothing on the ship was modded. I have TweakScale installed but everything was stock size. KSP 1.11.2.

Second test: big rocket in VAB::funds:425792 and recovered :funds:468823... which listed 96607 for Refunding. So that just does not add up at all. This rocket did have a few Tweaked parts.

(The first problem was fixed on commit eecabb1 )

S&D the damn bug.

Well, I will probably never fix this one, but I will leave this here in order to remember.

Long time ago, KSP 1.8.0 broke the UI_ScaleEdit, UI_FloatEdit and UI_FloatRange (that I'm aware) due something missing on the prefab.

Now and then some user asks for it (as this one) - why they would want to run 1.8.0 is beyound me, as it was terribly buggy and I'm not aware of anything that works on 1.8.0 that it's not working on 1.8.1.

But yet, it would be "nice" to have Recall fixing this one just for the sake of completude.

as the title says

Geez, I completely forgot about this!!!

Fellow Kerbonaut Azic Minar suggested a Panic Button to halt the Death Spin problem that plagues sometimes pieces of crafts after crashing:

You are two steps from writing code that can stop the death spins by pressing a side bar button

Well… Do it! :)

Oukey. I found a Monkey Patching on KSP, and this freaking thing is screwing with me.

On 2022's Hallowing (more specifically, the weekend following it), my DLLs on A+ got screwed by the following problem:

ERR 12:27:47.935] Exception handling event onGameSceneSwitchRequested in class Startup:System.NullReferenceException: Object reference not set to an instance of an object
  at AirplanePlus.MonkeyPatching.Execute () [0x00000] in <filename unknown>:0
  at AirplanePlus.Startup.OnGameSceneSwitchRequested (FromToAction`2 data) [0x00000] in <filename unknown>:0
  at EventData`1[GameEvents+FromToAction`2[GameScenes,GameScenes]].Fire (FromToAction`2 data) [0x00000] in <filename unknown>:0

[EXC 12:27:47.941] NullReferenceException: Object reference not set to an instance of an object
        AirplanePlus.MonkeyPatching.Execute ()
        AirplanePlus.Startup.OnGameSceneSwitchRequested (FromToAction`2 data)
        EventData`1[GameEvents+FromToAction`2[GameScenes,GameScenes]].Fire (FromToAction`2 data)
        UnityEngine.DebugLogHandler:LogException(Exception, Object)
        KSPe.Util.Log.UnityLogDecorator:UnityEngine.ILogHandler.LogException(Exception, Object)
        ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
        UnityEngine.Debug:LogException(Exception)
        EventData`1:Fire(FromToAction`2)
        HighLogic:SetLoadSceneEventsAndFlags(GameScenes, Boolean)
        HighLogic:LoadScene(GameScenes)
        <SetupSystem>c__Iterator0:MoveNext()
        UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
[LOG 12:27:47.942] [HighLogic]: =========================== Scene Change : From LOADING to MAINMENU =====================

That AirplanePlus.MonkeyPatching thingy? Not mine, don't have the slighest idea from what deepness of Hell this crapness came. I can only say that this prevented me from working on the DLL for the whole weekend.

As long the clock marked midnight of Monday, the problem goes away.

I can only infer this was some kind of Easter Egg that some jerk though it could be a good idea to have hardcoded inside KSP without telling anyone about.

Also on Forum

I'm still thinking if I want to mess with this crap.

As the tittle says.

Overworlf ticket: https://support.overwolf.com/en/support/tickets/94843

Tried updating to 1.9 since most mods behave reasonably on updates nowadays. Began noticing some parts drifting each time I loaded my craft (either in flight or VAB). Seems any parts that have been tweaked start to wander when loading.

Also noticed that when copying a part that had been altered, the new part retained the correct appearance and size, but was given the default values for the original part. (FL-T400 tank scaled to 3.75 has almost 2k LOx, copy has 360). Tweakscale seems to be applying itself at the wrong time or somehow affecting the "assembly order" upon load in. The most interesting fact is that if I load a craft and a part wanders, then reload the same craft without saving, the part will have wandered farther than before.

I am using other mods such as mechjeb, but afaik none would be interfering with TS or craft loading. Hope I have been of some service, TS has been very nice to me, would like to return the favor.

On 1.12.x, Tourists can't keep their inventory!

Once you launch a craft with a fully equipped Tourist, their inventory became empty and you loose the equipment.

You can equip them after launch, but if you recover them you will loose the equipment the same.

I don't have the slighest idea about the reason - Recall don't tell Tourists from Crew, so I'm betting that something else may be stomping Recall's toes. But I have to register this somewhere, so here we are.

I would be less worried if the problem were affecting everybody, and not only tourists.

Fellow Kerbonaut firethorn6 have a misbehaviour on his rig - as from KSP 1.11.x, the refunding at vessels recover is borked!

Evidencest:

A MK1 Pod and a Flea scaled to 2.8M (as anything bigger would not be allowed to launch on a early career). 2848 Funds.

I launched and immediately recovered it, to get the full refund:

• 588
• 1304
• 12
• 944

And this totalled 2848 Funds. So it's working, at least on KSP 1.4.5.

So I redid the test on 1.7.3:

And it works too. Right now I cleared something wrong on TweakScale, now I need to check if something changed on KSP itself, perhaps on 1.8.1?

Nops. Worked fine. Just for the sake of completude, I did the test on KSP 1.10.1:

And again fine.

Well, gone to KSP 1.11.1 (lots of thing changed on this one, perhaps?)

Bingo. It's something on KSP 1.11.1. :( Interesting enough, the cost of the vessel is now 2883 (probably due the new Inventory system)

KSP 1.12.0 will need Refunding.

See:

https://forum.kerbalspaceprogram.com/index.php?/topic/207045-tweakscale-crew-bug/#comment-4097632

I'm a beginner at KSP mods, and KSP in general. I'm having some trouble following the installation instructions in INSTALL.md for the 0.3.0.0 zip package. Here's the excerpt I'm looking at.

• REMOVE ANY OLD VERSIONS OF THE PRODUCT BEFORE INSTALLING, including any other fork:
  • Delete <KSP_ROOT>/GameData/999_KSP-Recall
• Extract the package's GameData/ folder into your KSP's as follows:
  • <PACKAGE>/GameData/000_KSP-Recall/* --> <KSP_ROOT>/GameData/000_KSP-Recall
    • Overwrite any preexisting file.

And then it says this folder structure must be present.

<KSP_ROOT>
  [GameData]
  	[000_KSP-Recall]

But in the zip file package, there's a 999_KSP-Recall folder, not 000_KSP-Recall. It specifically says to delete 999 one. Where do I get the 000 one? Should I rename the folder from the zip?

Well, not a surprise. :)

To implement a fix for this, so TweakScale (and any other add'on that changes Attachment Nodes) can operate on KSP 1.9

Bleh. :(

This is a follow up from issue #21

TL;DR : Refunding was creating and destroying the fake Resource under demand. This was triggering a nasty bug on Unity's GC under heavy load, since this crappy excuse of a Game Engine is using spinlocks to halt the threads when the GC is working. This completely trashes the whole system: 8 threads waiting a spinlock and an i7 with 4 cores and 8 hyper-threads just gets down on its knees in pain.

Empirical tests pinpoint the this.part.Resources as the culprit by the memory leak.

Some users reported problems on updating to Recall 0.2.2.4.

Random exceptions while gaming are killing the current thread, with various and nasty consequences - from buttons that cease to respond, to graphical items not being drawn, vessels that don't respond to commands, and so goes on.

This is the report for my findings on GoAHead, as he reported that reverting back to 0.2.2.3 solved the problem for him.

My goal on this report is to determine if the problem that affected GoAHead is due the race condition that was mitigated on #45 .

The source material for the research was provided on Forum here but will not be fully copied to this Issue as all that data can potentially have sensitive information.

He provided a ModList with 284 Add'Ons : Modpack.ckan.zip .

However 108 were not installable by CKAN under default command line options.

So I split the thing into two ModLists:

• Installable (with 175 Add'Ons), that CKAN successfully installed on my test bed:
  • GoAHead-KSP1123-Instalable.Modpack.ckan.zip
• Not Installable (with 108 Add'Ons) that were not installed by CKAN, and it will be used later as the test progresses.
  • GoAHead-KSP1123-NOT-Instalable.Modpack.ckan.zip

Test Script:

• I will try first to create a new empty savegame and see if I can reproduce the problem easily with the Installable add'ons.
• If I fail, I will try to load the provided savegame and just let crafts be removed as the needed add'ons (if any) are not present, and then I will try to reproduce the problem.
• If I still fail, I will start to install the Add'Ons from the 'not installable' ModList somehow, and try again.