[1.4.3 <= KSP <= 1.12.5] KSP Recall - 0.5.0.2- 2024-0521

[Lisias]

News from the Front V

Well… I did, indeed, forgot to do something on AttachedOnEditor , but this early morning I realised I may had found a yet new weirdness on KSP's Editor!

First, where I had err: I forgot to update the part's current position when saving the craft - so, as you edit the craft, dully changing the part position, once the craft is loaded the AttachedOnEditor would try to fix it using unduly, old values. (sigh).

The following images will depict the problem and the fix:

Spoiler

Problem:


After fixed:

 

More information: https://github.com/net-lisias-ksp/KSP-Recall/issues/34#issuecomment-1034198729

However, this doesn't explains why I was getting screwed up on SubAssemblies, Load for Merge or Alt+Click Duplicates!

I found a light at the end of the tunnel (let's hope it doesn't "Pewee" on me!) when I tried the following test:

From the same craft, 3 out of 4 Alt+Click duplicates worked fine. It was found that the Stack Separator, when used as root of the duplicate, is the trigger for the misbehaviour.

Yet more weird, the Decoupler, another part with nearly the same characteristics as the Stack Separator, is working fine.

The difference between the Decoupler and the Separator is that the Decoupler has Variants (and, so, was patched with AttachedOnEditor) . I tried another test using a non-variant as root, and it worked.

As it appears, I may had found another KSP bug, or perhaps I had triggered a problem on a less than ideal workaround ("gambiarra") from Squad trying to "fix" something else.

Since AttachedOnEditor is working fine on all the other parts (I currently trying to figure out what parts, besides the Stack Separators, are triggering the problem in order to find a pattern), it's definitively not a bug on it. Had I made a major mistake on it, it would be screwing up everything, not only this weird, marginal use case - I'm not even patching the Stack Separators with it.

By night I will do some regressions tests with previous TweakScale releases to rule out any TweakScale interference on the process, and then I will issue a new KSP-Recall release with the (minor) fix I have at hands now. It will not fix the Stack Separator weirdness, but it still fix something.

At least we have a viable workaround until I understand what's happening and do a proper fix.

[Lisias]

ANNOUNCE

KSP Recall 0.2.1.4 is on the Wild, featuring:

• Implements a missing use case, handled on #34
• Works the issues:
  • #34 NEW Misbehaviour on KSP introduced by AttachedOnEditor

A bug on KSP was discovered, affecting the Editor since KSP 1.9, where some parts trigger a weird misbehaviour when set as the root of a SubAssembly.

This misbehaviour happens when loading a Craft for Merge, when loading a SubAssembly from the SubAssembly palette, and when copying subtrees of a craft using Alt+Click. EDIT: When Add'Ons that change the parts position are installed!

The current workaround is to avoid the situation where these parts end up being the root of the SubAssembly. See the KNOWN ISSUES file for details, or the following links:

• Got a bug with a subassembly here on Forum
• Issue #34 on GitHub

About the Future

Recent events on KSP-Recall's issue tracker suggests that it may be a good idea to retake KSP-Recall development - at least, for the most serious bugs on KSP.

At the very least, KSP-Recall will serve as Diagnosing tool and Fix/Workaround test bench - even by not being able (due legal reasons) to implement the fixes on a more transparent way, KSP-Recall appears to be the place where the way for better fixes can be paved.

Spoiler

Unfortunately, Judgment and Diagnosing skills are relatively scarce nowadays - perhaps scarcer than programming skills...

— — — — — 

---

This Release will be published using the following Schedule:

• GitHub, reaching manual installers and users of KSP-AVC first. Right now.
• CurseForge. Right now.
• SpaceDock (and CKAN users) Right now

I updated everything at once as this is a minor update on an already proven workaround.

Edited February 12, 2022 by Lisias
EDIT

[Kalalicious]

This would be awesome!  I use a lot of subassemblies and some had this issue, so I'll be very happy if this helps solve that problem (also good to know about the work around I hadn't caught before).

Thanks for your work!

[Lisias]

7 hours ago, Kalalicious said:

This would be awesome!  I use a lot of subassemblies and some had this issue, so I'll be very happy if this helps solve that problem (also good to know about the work around I hadn't caught before).

Just a small addendum: when I published the Announce, I was a bit in a hurry because I had some RL duties to cope - and I ended up not writing it correctly.

The bug on Editor is only noticeable when using Add'Ons that change the part's position (as TweakScale), since Editor by some reason I can only speculate is shoving back default values on the craft once you load it on the Editor, bluntly ignoring whatever is the value on the craft file at this moment.

(launching the craft directly on Runway or Launch Pad works fine, it's an Editor only problem - and it happens only at loading the craft to memory, saving it is OK).

However, since AttachedOnEditor is now overruling whatever is happening on Editor since KSP 1.9, some collateral effects are happening: SOME parts (not all, just some - I'm trying to figure out a pattern on this mess), when used as root of a SubAssembly (being it loaded from the SubAssembly Menu, or loaded from a craft file using Merge, or even by Alt+Click on a subtree) is misplacing badly the part attached to it when this part has Variants.

It's not known at this time if this is an unexpected side effect of AttachedOnEditor (possible, but I'm scratching my head for weeks trying to find a reason for this), or if something broke on Editor when something was added on KSP 1.9 and the blunt overwrite was the way they found to mask the problem (somewhat more likely, as it appears to be a flaw on initialising SubAssemblies once they are loaded - but I bashing my SAS trying to figure out a way to prove that).

The way I originally wrote the Announce was implying that the problem could be noticed on a pure Stock installation - to tell you the true, I just didn't tried to do so on a vanilla installment.

Well… Back to the workbench. I have promises to keep and miles to go before I sleep!  

Edited February 12, 2022 by Lisias
Hit "save" too soon.

[Krazy1]

Sorry KSP is breaking your testes... 

[Lisias]

11 minutes ago, Krazy1 said:

Sorry KSP is breaking your testes... 

Well… If KSP would be working fine, I would had no need for such tests!

(To tell you the true, it would be no need for KSP-Recall at all! )

[Lisias]

News from the Front VI

Ha! I think I nailed it!!! (famous last words… )

I (think) I finally nailed the Modus Operandi of the problem!

It manifests when the root part of a subtree/subassmbly doesn't have variants, but the parts attached to it does.

If the root part has variants, the problem doesn't happens no matter what.

If the root part doesn't have variants, but the parts attached to it neither, so the problem doesn't manifest itself neither.

Things get screwed up only when the root part of the subassembly does not have variants, but the parts attached to it does.

Pretty odd, if you ask me...

By analysing the source code from TweakScale being victim of this problem, I think that what's happening is that the attachment points are not being correctly initialised, and so when TweakScale tries to attachedPart.transform.Translate() them, things goes down trough the tubes.

Apparently the solution will be to save also the part's attachment points on the AttachedOnEditor stunt, and apply it on all parts (not only parts with Variants, as it's being done now).

For further information: https://github.com/net-lisias-ksp/KSP-Recall/issues/34

[Jacke]

Bon courage!

I hope you track down a fix to include soon.  Personally, I don't think I'll be using Tweakscale, but from my casual following of this issue, I'm thinking it could still come up.

[Lisias]

ANNOUNCE

KSP Recall 0.2.2.0 Pre-Release is on the Wild, featuring:

• Implements a missing use case, handled on #34
• Works the issues:
  • #34 NEW Misbehaviour on KSP introduced by AttachedOnEditor

I finally nailed the problem!

This is what happening (or, at least, it's the best explanation I have for the bug until this moment):

On KSP 1.9.x, the positions of the Attachment Nodes of the part stopped from being read from the craft file by the vanilla part support (i.e., without the ModulePartVariant), and started to be correctly initialised only when ModulePartVariant is present on the part. If the initialisation is made by ModulePartVariant or by something else could not be determined until this moment.

So the solution was, in essence, the same applied by the Radial Positioning (that perhaps should be suffering from the same problem?): just save the positions on a custom module on the craft file and reapply them when needed. What was done.

However… The current workaround properly fixes the issue, but only on newly created SubAssemblies. I'm currently bashing my SAS out trying to figure a way to salvage SubAssemblies made with previous versions of KSP-Recall (or without it).

I didn't found a way to salvage these SubAssemblies yet - I don't even know if this would be possible at this moment (but didn't tried too hard, to tell you true).

See the KNOWN ISSUES file for details, or the following links:

• Got a bug with a subassembly here on Forum
• Issue #34 on GitHub

— — — — — 

---

This Release will be published using the following Schedule:

• GitHub, reaching manual installers and users of KSP-AVC first. Right now.
• CurseForge. Will NOT be published.
• SpaceDock (and CKAN users). Will NOT be published.

This is a beta release intended to be used by early adopters willing to help me with the issue.

Edited February 14, 2022 by Lisias
tyop! Surprised?

[eightiesboi]

To anyone who uses Oh Scrap with Tweakscale, I recommend you add the following to the "DontLeak.cfg" file in the OhScrap/Patches directory:

OHSCRAP_RESOURCE_BLACKLIST
{
	name = RefundingForKSP111x
}

Otherwise, you may find that you have a failure of a module and that your RefundingForKSP111x resource will try to leak. It has absolutely no effect other than to block the failure from doing anything. 

We now return you to your regularly scheduled exploding.

[Lisias]

ANNOUNCE

KSP Recall 0.2.2.1 is on the Wild, featuring:

• Formally closes issues:
  • #35 AttachedOnEditor is not working for SubAssemblies.
  • #34 NEW Misbehaviour on KSP introduced by AttachedOnEditor

A new problem was found, affecting Editor since KSP 1.9, where some parts are triggering a strange misbehaviour when you Alt+Click a part for a duplicate, when Loading a craft for Merge or when loading a SubAssembly.

It was determined that when Parts without ModulePartVariant is the root of the SubAssembly, the parts attached to it must have the ModulePartVariantotherwise the problem will be triggered.

• I realised that the problem is that the Positions on the Attachment Nodes are not being initialised by the vanilla Parts - apparently the initialisation was moved to the ModulePartVariant module.
  • This may be the reason Squad choose to shove prefab back into the craft when loading it from the Editor, as apparently they didn't were able to pinpoint the cause of the misbehaviour...

Problem: I solved the problem for SubAssemblies and Craft files saved after installing the newest Release of KSP-Recall, but didn't managed to cook a way to salvage the pre-existent ones.
- Currently, there's no other alternative but to redo your SubAssemblies. I failed to find a viable automated process for salvaging them.

See the KNOWN ISSUES file for details, or the following links:

• Got a bug with a subassembly here on Forum
• Issue #34 on GitHub

— — — — — 

---

This Release will be published using the following Schedule:

• GitHub, reaching manual installers and users of KSP-AVC first. Right now.
• CurseForge. Right Now.
• SpaceDock (and CKAN users). Right Now.

I was called to duty before publishing the release on SpaceDock, sorry. As long as I solve the RL problem, I will update SpaceDock - but experience taught me to do not be optimistic about these things.

Edited February 20, 2022 by Lisias
All Distribution Channels are belong to us.

[eightiesboi]

Hey @Lisias!

I am getting a crash to desktop. I absolutely *do not* know if KSP Recall is the culprit, but this first happened immediately after I updated to 0.2.2.1. I reverted to the earlier version, but the crash still happens.

Symptoms: Start a new instance of KSP, enter VAB, select vessel, hit Load, crash to desktop (no dialog box--just straight out to Windows). 

Modded install, KSP 1.12.3.

Logs: https://1drv.ms/u/s!AoyHZiRU1jT-z5E-LX0fTndBGknuww?e=7sYeTE

Any suggestions you have would be helpful. Going to bed now (it's getting close to midnight and I'm old), so excuse me if you ping back and I don't respond.

[Lisias]

3 minutes ago, eightiesboi said:

Hey @Lisias!

I am getting a crash to desktop. I absolutely *do not* know if KSP Recall is the culprit, but this first happened immediately after I updated to 0.2.2.1. I reverted to the earlier version, but the crash still happens.

Symptoms: Start a new instance of KSP, enter VAB, select vessel, hit Load, crash to desktop (no dialog box--just straight out to Windows). 

Modded install, KSP 1.12.3.

Logs: https://1drv.ms/u/s!AoyHZiRU1jT-z5E-LX0fTndBGknuww?e=7sYeTE

Any suggestions you have would be helpful. Going to bed now (it's getting close to midnight and I'm old), so excuse me if you ping back and I don't respond.

Geezzz…. Something else was also updated, or perhaps installed.

I checked your KSP.log and Player.log and they are… well.. "clean". No exceptions, no crash dumps - whatever happened on your rig, just shut down instantly the KSP process without the slightest chance of logging anything. So, it doesn't appears to be a crash exactly, but something force-killing the process.

The last lines logged on the KSP.log were:

Spoiler

[LOG 23:01:26.416] [EngineModuleWrapper] INFO: Stock Engine found on part cryoengine-compsognathus-1, engine cryoengine-compsognathus-1!
[LOG 23:01:26.827] Autogen thumbnail for E:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../Ships/@thumbs/VAB/LFT1_2T.pn
[LOG 23:01:28.218] [ScrapYard] Copied tracker. Recovered 1 times with id 859462580
[LOG 23:01:28.294] [ScrapYard] Copied tracker. Recovered 3 times with id 3432020899
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 1 times with id 3432020899
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 3 times with id 298265526
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 3 times with id 4054242149
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 3 times with id 4292894171
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 3 times with id 3657462136
[LOG 23:01:28.307] [ScrapYard] Copied tracker. Recovered 1 times with id 1916438633
[LOG 23:01:28.308] [ScrapYard] Copied tracker. Recovered 3 times with id 1228427659
[LOG 23:01:28.308] [ScrapYard] Copied tracker. Recovered 3 times with id 2000392283
[LOG 23:01:28.308] [ScrapYard] Copied tracker. Recovered 3 times with id 4034333615
[LOG 23:01:28.308] [ScrapYard] Copied tracker. Recovered 3 times with id 3473693344

And on the Player.log:

Spoiler

Autogen thumbnail for E:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../Ships/@thumbs/VAB/LFT1_2T.png (Stock) from E:/P
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 859462580
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 3432020899
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 3432020899
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 298265526
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 4054242149
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 4292894171
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 3657462136
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 1916438633
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 1228427659
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 2000392283
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 4034333615
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 3473693344
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 3613371646
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 1768359143
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

And then suddenly everything is silence on both logs. No error messages, no nothing. I doubt ScrapYard are involved on the mess, I'm betting it's only an innocent bystander being caught by the problem.

These sudden deaths are usually caused by memory exhaustion - something else on your rig asked for memory, Windows didn't found any free memory and then killed something to free memory - this is a last resource measure, usually done when things are so screwed that the alternative would be restarting the computer (what happens when the killing spree hits something that causes a dead lock).

Your GPU has 6GB of VRAM, what's not bad, but both KSP and most used add'ons are upscaling the textures and the VRAM consuption is raising fast, so perhaps something else was updated that ended being the straw that broke the camel's back.

But I'm guessing, there's nothing on your logs that suggests any probable cause for this CTB.

I suggest you install some kind of GPU monitoring and keep an eye on CPU and GPU memory consumption while loading KSP. You may also need to check the Window's Application Event Log. See this link for how to check it (it's a MS SQL Server link, but an Application is an Application - just look for KSP ou Kerbal Space Program insted).

[Lisias]

(moving from the original thread to prevent polluting it)

20 hours ago, king of nowhere said:

Those manual struts I placed will get deleted by the kraken on reloading the ship, so once I started placing them, I can't stop until I am in jool's orbit

Hi, @king of nowhere! I was not aware of that bug...

Could you please fill me about it? I already had a somewhat vicious bug about AutoStruts diagnosed, and I would like to learn more about this one before trying to tackle it down. Perhaps I could reuse the same "fix", saving a bit of trouble on maintenance on the long run!

Cheers!

[eightiesboi]

6 hours ago, Lisias said:

Geezzz…. Something else was also updated, or perhaps installed.

I checked your KSP.log and Player.log and they are… well.. "clean". No exceptions, no crash dumps - whatever happened on your rig, just shut down instantly the KSP process without the slightest chance of logging anything. So, it doesn't appears to be a crash exactly, but something force-killing the process.

The last lines logged on the KSP.log were:

  Reveal hidden contents

 

[LOG 23:01:26.416] [EngineModuleWrapper] INFO: Stock Engine found on part cryoengine-compsognathus-1, engine cryoengine-compsognathus-1!
[LOG 23:01:26.827] Autogen thumbnail for E:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../Ships/@thumbs/VAB/LFT1_2T.pn
[LOG 23:01:28.218] [ScrapYard] Copied tracker. Recovered 1 times with id 859462580
[LOG 23:01:28.294] [ScrapYard] Copied tracker. Recovered 3 times with id 3432020899
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 1 times with id 3432020899
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 3 times with id 298265526
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 3 times with id 4054242149
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 3 times with id 4292894171
[LOG 23:01:28.295] [ScrapYard] Copied tracker. Recovered 3 times with id 3657462136
[LOG 23:01:28.307] [ScrapYard] Copied tracker. Recovered 1 times with id 1916438633
[LOG 23:01:28.308] [ScrapYard] Copied tracker. Recovered 3 times with id 1228427659
[LOG 23:01:28.308] [ScrapYard] Copied tracker. Recovered 3 times with id 2000392283
[LOG 23:01:28.308] [ScrapYard] Copied tracker. Recovered 3 times with id 4034333615
[LOG 23:01:28.308] [ScrapYard] Copied tracker. Recovered 3 times with id 3473693344

 

And on the Player.log:

  Reveal hidden contents

Autogen thumbnail for E:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../Ships/@thumbs/VAB/LFT1_2T.png (Stock) from E:/P
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 859462580
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 3432020899
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 3432020899
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 298265526
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 4054242149
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 4292894171
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 3657462136
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 1916438633
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 1228427659
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 2000392283
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 4034333615
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 3 times with id 3473693344
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 3613371646
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[ScrapYard] Copied tracker. Recovered 1 times with id 1768359143
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

And then suddenly everything is silence on both logs. No error messages, no nothing. I doubt ScrapYard are involved on the mess, I'm betting it's only an innocent bystander being caught by the problem.

These sudden deaths are usually caused by memory exhaustion - something else on your rig asked for memory, Windows didn't found any free memory and then killed something to free memory - this is a last resource measure, usually done when things are so screwed that the alternative would be restarting the computer (what happens when the killing spree hits something that causes a dead lock).

Your GPU has 6GB of VRAM, what's not bad, but both KSP and most used add'ons are upscaling the textures and the VRAM consuption is raising fast, so perhaps something else was updated that ended being the straw that broke the camel's back.

But I'm guessing, there's nothing on your logs that suggests any probable cause for this CTB.

I suggest you install some kind of GPU monitoring and keep an eye on CPU and GPU memory consumption while loading KSP. You may also need to check the Window's Application Event Log. See this link for how to check it (it's a MS SQL Server link, but an Application is an Application - just look for KSP ou Kerbal Space Program insted).

I hadn't even considered death by memory exhaustion. It's a likely suspect. I'll go interrogate my video card and DRAM. Thanks for taking a look!

[king of nowhere]

7 hours ago, Lisias said:

(moving from the original thread to prevent polluting it)

Hi, @king of nowhere! I was not aware of that bug...

Could you please fill me about it? I already had a somewhat vicious bug about AutoStruts diagnosed, and I would like to learn more about this one before trying to tackle it down. Perhaps I could reuse the same "fix", saving a bit of trouble on maintenance on the long run!

Cheers!

I spend a few more words on it in the dedicated mission report, part 14

and i don't have much to add. I lace the struts, then i go to the tracking station, i come back, and the struts are deleted. they are still there, but they are not connecting anything; see pictures in the mission report, it's a lot easier than describing it.

however, as long as i don't leave physical range, those struts are holding, so i could place them and launch the mission immediately.

i am playing caveman in that save, so i cannot send astronauts in eva; bill was launched from the surface inside a cargo bay, and once i send him back into the ship, i can't get him out again. but in a normal career you can always send your engineer out to place the struts again.

 

[eightiesboi]

1 hour ago, eightiesboi said:

I hadn't even considered death by memory exhaustion. It's a likely suspect. I'll go interrogate my video card and DRAM. Thanks for taking a look!

Hey @Lisias,

I ran some more tests this morning. VRAM goes to 99% while loading, then drops down between 90-95% and stays pegged there like one of my cats waiting for her brother to walk away from his food dish. RAM was rather high at 71% (I've got 32 GB), but it occurred to me I haven't restarted my computer in about two weeks. (Keep in mind that until last night, my KSP install was pretty solid, no strange crashes, etc). After restarting, RAM stayed around 30-35%. So far so good. Loaded up KSP, entered the VAB, selected a craft. crashed to desktop.  

Tried again. Loaded up KSP, entered the VAB, selected a DIFFERENT craft. Crashed to desktop.

Decided to get creative. Copied my KSP installation, loaded up KSP, entered the VAB, selected the original craft, crashed to desktop--but that's okay, I was just verifying the problem existed.

Removed Tweakscale and KSP-Recall. Loaded KSP. Entered VAB. Selected craft. No crash. Everything seemed fine.

Added Tweakscale and KSP-Recall back. Loaded, Entered, Selected, Crashed.

hmmmm... this could be a coincidence, so I repeated the experiment, got the same results.

I then removed Oh Scrap and tried loading (with Tweakscale installed): Success!

I then reinstalled Oh Scrap and repeated the original experiment with all mods loaded (still with Tweakscale): Success! 

I went back to my "real" install, and I uninstalled and reinstalled TS, KSPR, and OHS. Success! However, I *did* note that there was a stack overflow exception. No crash though.

At this point, I'm working with 1 of 3 possibilities:

1. An interaction involving Tweakscale, KSP-Recall, and/or Oh, Scrap (and possibly another mod) were causing the issue.

2. Tweakscale and/or KSP-Recall are innocent bystanders and something else is causing this. I don't think it's an out of memory error, but it still could be possible.

3. You secretly hate me and you're part of the global conspiracy to keep my Kerbals from space!

At this point, I am up and running again. I added additional logs to the link I shared above, in case you are interested or to help out your conspiracy against Jeb and me, but otherwise I think I'm good. Pinging @zer0Kerbal just in case this comes up again later.

[kcs123]

14 minutes ago, eightiesboi said:

At this point, I'm working with 1 of 3 possibilities:
1. An interaction involving Tweakscale, KSP-Recall, and/or Oh, Scrap (and possibly another mod) were causing the issue.

2. Tweakscale and/or KSP-Recall are innocent bystanders and something else is causing this. I don't think it's an out of memory error, but it still could be possible.

3. You secretly hate me and you're part of the global conspiracy to keep my Kerbals from space!

I thnk it is safe to exclude option #3, however, have you considered possible cause:

4. You were having some leftovers from previous install that is not obvious at first. Deleting whole mod folders and installing it again fixed it.

You would not be first and most probably not last KSP player thati is hit with that.

[eightiesboi]

16 minutes ago, kcs123 said:

I thnk it is safe to exclude option #3, however, have you considered possible cause:

4. You were having some leftovers from previous install that is not obvious at first. Deleting whole mod folders and installing it again fixed it.

You would not be first and most probably not last KSP player thati is hit with that.

You only want me to exclude option #3 because you too are part of the conspiracy. Roswell! Roswell!

But seriously, I don't think option 4 is likely.  I had taken a break from KSP for about a year, and my current install is completely clean (as in, I deleted my entire KSP directory from Steam and then downloaded a fresh 1.12.3 install. I first experienced the problem when I updated KSP-Recall via CKAN, so it is possible that something was left over from the update; this, however, is why I pinged Lisias here and not in the TS forum.

I *do* maintain a series of test and archival installs, so I could try to replicate everything step by step, but unless ZK or Lisias would like me to, I'd rather not. (I actually only finally deleted my .25 and .90 installs from my archive at the end of last year.)

[Lisias]

4 hours ago, king of nowhere said:

I lace the struts, then i go to the tracking station, i come back, and the struts are deleted. they are still there, but they are not connecting anything; see pictures in the mission report, it's a lot easier than describing it.

Yep, found it. Looks like some data needed to the strut is not being saved (into the protovessel?) once they are instanced at runtime. The struts are already giving me a run for the money on TweakScale (I need to find a way to adjust their attachment on two different parts when something scales), so I have some familiarity on how they works. I think you should be experience similar problems with the Fuel Duct.

You mentioned that "auto-strut is not working" - you are meaning that auto-strut is dead on the water, or that it works but not enough to be useful on this problem?

 

4 hours ago, eightiesboi said:

I went back to my "real" install, and I uninstalled and reinstalled TS, KSPR, and OHS. Success! However, I *did* note that there was a stack overflow exception. No crash though.

Wow… That was unexpected. Do you have the KSP.log with that stack overflow?[edit: yes, he does. Found it!  ]

 

4 hours ago, eightiesboi said:

1. An interaction involving Tweakscale, KSP-Recall, and/or Oh, Scrap (and possibly another mod) were causing the issue.

I agree. About the Stack Overflow, I found this:

[LOG 10:23:10.122] [ScrapYard] Copied tracker. Recovered 1 times with id 1768359143
[EXC 10:23:10.604] StackOverflowException: The requested operation caused a stack overflow.
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
		<yada yada yada>

However, and this is where things can get messy, I once got a nasty situation like this on TweakScale due a bug on B9PS that was forgetting to remove itself from a GameEvents.<something> callback hook. So everytime you switch Scenes, all B9PS modules hooked there would stay there referencing modules from parts that were being garbage collected as time goes by (everything is destroyed on scenes switch), and posteriorly the new instanced modules would be added back, and so we have a set of zombies wasting CPU running dry and a set of healthy modules trying to do its business while competing for the CPU. And then you change scenes again, and the previously healthy modules became zombies while a new set is added to the GameEvents.<something>, and now we have 2 sets of zombies screwing up the life of the one set of healthy modules. And so goes on.

As time goes by, with you switching between Flight and Editor and back to Flight and then to Tracking and back to Flight, etc, all that zombies eating memory and trying to do something on dead data not only wastes memory and CPU, but eventually can induce healthy 3rd party modules to bork (it was what was happening on TS - a zombie B9PS sent a rescale event to TweakScale mentioning an instance of a part that was garbage collected, and TweakScale borked on the process relentlessly).

There's a good chance we have something like this again - and since KSPR and TweakScale are two of the most nosy add'ons available (I shove these modules on everybody and everything), they are usually involved in such kind of mess - worst, both TS and KSPR would help playing havoc if you feed them with zombie data, and that would explain why things start to happen sooner when these 2 are installed.

Spoiler

Remember Sagan: Absence of evidence is not evidence of absence!

By removing KSPR and TweakScale, you didn't prove the problem has gone away - you may only delayed it to a point where it would not be detected on the same timeframe they were happening before, you have a pretty decent amount of memory to be filled before things go south...

Your CTB apparently was due the main memory exhaustion - this incredibly convoluted mess can reach a critical point where memory is consumed faster than Windows was being able to harvest from the free memory pool (as time goes by, the memory pool became fragmented and the routine to find suitable memory blocks - or to defragment enough blocks to make one - starts to take some time).

Thank you for your report, sir! You made a hell of a (good) bug report!

I will try reproduce it on my rig and I will come back to you!

Cheers!

Edited February 20, 2022 by Lisias
brute force post merging.

[eightiesboi]

4 minutes ago, Lisias said:

Wow… That was unexpected. Do you have the KSP.log with that stack overflow?[edit: yes, he does. Found it!  ]

 

A agree. About the Stack Overflow, I found this:

[LOG 10:23:10.122] [ScrapYard] Copied tracker. Recovered 1 times with id 1768359143
[EXC 10:23:10.604] StackOverflowException: The requested operation caused a stack overflow.
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
        VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32
		<yada yada yada>

However, and this is where things can get messy, I once got a nasty situation like this on TweakScale due a bug on B9PS that was forgetting to remove itself from a GameEvents.<something> callback hook. So everytime you switch Scenes, all B9PS modules hooked there would stay there referencing modules from parts that were being garbage collected as time goes by (everything is destroyed on scenes switch), and posteriorly the new instanced modules would be added back, and so we have a set of zombies wasting CPU running dry and a set of healthy modules trying to do its business while competing for the CPU. And then you change scenes again, and the previously healthy modules became zombies while a new set is added to the GameEvents.<something>, and now we have 2 sets of zombies screwing up the life of the one set of healthy modules. And so goes on.

As time goes by, with you switching between Flight and Editor and back to Flight and then to Tracking and back to Flight, etc, all that zombies eating memory and trying to do something on dead data not only wastes memory and CPU, but eventually can induce healthy 3rd party modules to bork (it was what was happening on TS - a zombie B9PS sent a rescale event to TweakScale mentioning an instance of a part that was garbage collected, and TweakScale borked on the process relentlessly).

There's a good chance we have something like this again - and since KSPR and TweakScale are two os the most nosy add'ons available (I shove these modules over everybody and everything), they are usually involved in such kind of mess - worst, both TS and KSPR would help playing havoc if you feed them with zombie data, and that would explain why things start to happen sooner when these 2 are installed.

  Reveal hidden contents

Remember Sagan: Absence of evidence is not evidence of absence!

By removing KSPR and TweakScale, you didn't prove the problem has gone away - you may only delayed it to a point where it would not be detected on the same timeframe they were happening before, you have a pretty decent amount of memory to be filled before things go south...

Your CTB apparently was due the main memory exhaustion - this incredibly convoluted mess can reach a critical point where memory is consumed faster than Windows was being able to harvest from the free memory pool (as time goes by, the memory pool became fragmented and the routine to find suitable memory blocks - or to defragment enough blocks to make one - starts to take some time).

Thank you for your report, sir! You made a hell of a (good) bug report!

I will try reproduce it on my rig and I will come back to you!

Cheers!

You're welcome and I'm sorry. 

Let me know how I can help. Note that in all of the latest runs, I literally loaded the game and went from the main screen to the VAB. I did not switch scenes otherwise. But I am here to help and cause problems... er, help and FIX problems. 

[king of nowhere]

1 hour ago, Lisias said:

Yep, found it. Looks like some data needed to the strut is not being saved (into the protovessel?) once they are instanced at runtime. The struts are already giving me a run for the money on TweakScale (I need to find a way to adjust their attachment on two different parts when something scales), so I have some familiarity on how they works. I think you should be experience similar problems with the Fuel Duct.

You mentioned that "auto-strut is not working" - you are meaning that auto-strut is dead on the water, or that it works but not enough to be useful on this problem?

for some reason, autostrutting is not crossing any docking port, as shown in the picture below with autostruts visible (shown by the option on the alt-f12 menu)

this is very weird and probably caused by the caveman nature of the mission, where there is no "heaviest part". autostrutting to root or grandparent apparently has no effectwhatsoever. this may be caused by the ship's complexity

it seems to be a specific case for this ship, probably caused by its complexity (it ended up at 900 parts, with well over 100 modules connected by docking ports). on smaller crafts, struts worked fine. Even on this craft, after I shed most of the fuel tanks, a few struts remained on reloading - while others got deleted.

 

Edited February 21, 2022 by king of nowhere

[Krazy1]

9 hours ago, king of nowhere said:

I lace the struts, then i go to the tracking station, i come back, and the struts are deleted. they are still there, but they are not connecting anything

I have had some struts  do this after installing them in EVA construction (I'm on KSP 1.12.3 now) but most of them work fine. The ones I've seen that detach when reloading had very little clearance as they passed by an object. You know how sometimes you place a strut in the VAB and it appears to barely clear something between the strut connectors and it "snaps back" when you try to attach it? I think something like this is happening, at least in my case. It seems like it needs more clearance around the struts when loading the ship than it did when placing the them initially.  Also in my case they were placed across docking ports - some OK, some detached.

[Krazy1]

Lisias you said you're a masochist on the DOE thread so I want to "help" 

I've had a really annoying bug that causes fuel flow to break every time after undocking certain ships. Fuel transfer and engines that attached to that same branch stop working. KML actually identifies the problem "part not attached to parent part" but I have to edit it manually, like this:

Spoiler

I believe it has always happened with truss parts. I'll try to make a test craft to demonstrate.

But in the meantime... I just found a weird problem with ALT-click copy. I copied the probe at the left to the center and the core "trunk" parts are not rotated (you can barely see the "octo 2" labels in the 2nd picture) but the branch parts are all rotated 180 deg. I'm guessing this is a Recall issue...? I have v0.2.2.1 installed.  Also the copy in the air is angled oddly. 

Spoiler

I restarted KSP... and it's different! Now the solar panels are not rotated  

I completely rebuilt the probe and same result, except the copy in the air is not angled.

Welp... hope that's plenty of pain for you. Thanks!

EDIT: here's another example of Alt-click copy not right... wheels on small hardpoints offset:

Spoiler

 

Edited February 21, 2022 by Krazy1
another Alt-click example

[Lisias]

3 hours ago, Krazy1 said:

Lisias you said you're a masochist on the DOE thread so I want to "help" 

Innumerable non-Forum compliant jokes passed through my mind right now…

 

3 hours ago, Krazy1 said:

I've had a really annoying bug that causes fuel flow to break every time after undocking certain ships. Fuel transfer and engines that attached to that same branch stop working. KML actually identifies the problem "part not attached to parent part" but I have to edit it manually

I believe it has always happened with truss parts. I'll try to make a test craft to demonstrate.

Humm… I think you found a problem those trigger is very similar (if not the same) as the autostruts problem… I detected that when you change the craft on flight (and undocking is a really big change on the craft), something screws up the craft by shoving over the original positions and rotations the current ones, and since parts under stress deforms, changes on the craft mangles the original values and the craft is deformed for good.

Apparently we have a new misbehaviour happening at the same time.

Originally I was planning to handle the autostruts on a module dedicated to it, but perhaps I should build a module dedicated to preserving the craft from unattended changes, being it the autostruts and now this new one...

 

3 hours ago, Krazy1 said:

But in the meantime... I just found a weird problem with ALT-click copy. I copied the probe at the left to the center and the core "trunk" parts are not rotated (you can barely see the "octo 2" labels in the 2nd picture) but the branch parts are all rotated 180 deg. I'm guessing this is a Recall issue...? I have v0.2.2.1 installed.  Also the copy in the air is angled oddly. 

<cut>

I restarted KSP... and it's different! Now the solar panels are not rotated  

Kraaap… The attachment's rotation of the part is also being screwed up, not only the position. I should had suspected something like that would happen. Damn, I will need to release yet another version of the AttachedOnEditor stunt, and people affected would have to rebuilt the SubAssemblies again.

 

3 hours ago, Krazy1 said:

EDIT: here's another example of Alt-click copy not right... wheels on small hardpoints offset:

But these ones should be working… humm… The wheels are mirrored, right? In a way or another, send me this craft so I can take a look on it - it's the faster and safer way to check what's happening (now that I know what's happening).

Cheers!

Edited February 21, 2022 by Lisias
tyops! tyops! tyops everywhere!