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

[Lisias]

1 hour ago, Krazy1 said:

It seems like it's particular to certain craft. That one (and a derivative) are the only ones I could find that do it in the editor. 

trouble plane

Ouch! Thank you sir, you nailed the problem!

I don't really remember this, but github does!  The very first two beta releases of Refunding was using the default definition for isVisible (I always misundertand it with hidden, I'm getting old…), being it a true value, and I only fixed it on 0.0.7.6 .

So this is the reason I could not reproduce the problem here, it's ages since I used the last buggy release, and I don't play too much on KSP >= 1.8 - so I didn't saved any of the test crafts as they were all disposable.

Oukey, manually editing the resouce's isVisible to false will solve the problem on your crafts. Perhaps I should write a workaround on Refunding itself? I think this would be a little hostile, as someone could have a good reason to make this visible in the future...

[Krazy1]

Alrighty. I can go through it manually. It's pretty minor anyway. I've been using that career save for about 9 months... got 247 contracts done and I haven't even been to a CB outside Kerbin yet. 

[Lisias]

(whoops - double post)

Edited September 10, 2021 by Lisias
double post.

[Lisias]

ANNOUNCE

KSP Recall 0.2.0.6 is on the Wild, featuring:

Fixes for the already published fixes:

• #26 Kerbal going on EVA on Kerbin without helmet instantly dies
• #25 ChillingOut apparently is screwing up KSPIE

Both issues were related to the same feature, ChillingOut, besides having different causes. In both cases, less than ideal implementations ended up causing undesired collateral effects.

Thanks to @ss8913 and @rawhide_k for their reports.

About the Future

Given the current state of affairs on Forum, I think the best line of action for KSP-Recall is to stop pursuing work-arounds for KSP 1.12.x and let others do the job.

So I decided that no KSP 1.12.x specific bugs will be handled by KSP-Recall as it’s becoming increasingly harder to diagnose and code fixes relying only on Clean Room Design approaches, and recent events suggest that trying different methods can be legally risky (even by, at least in theory, being perfectly legal on USA, Europe and most other countries). 

The current Workarounds will be actively maintained and eventual workarounds for KSP versions up to 1.11.2 (including very old ones, as 1.2.2 and 1.3.1 - I’m still playing on 1.7.3!!) can be considered - mainly because these codebases are very well known already and there’s no one else considering supporting them.

There’re alternatives for KSP-Recall available on Forum for KSP 1.12.x users, so this is not exactly a settle back - it can be even an improvement, as some of the alternatives are willing to go trought paths I’m not.

As usual, anything going wrong or weird can still be reported here: if it’s something on KSP-Recall, it will be fixed. If it affects some older KSP version still in use, we can study a workaround or perhaps a fix (these versions will not change for sure anymore!).

For problems on KSP 1.12.x, at least some preliminary diagnosing can be carry out, making easier for some third-party to code a fix. But no implementation will be carried out.

— — — — — 

---

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

The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Edited September 10, 2021 by Lisias
KSP-Recall 0.2.0.6 in on the wild. All distributions channels are updated.

[dlrk]

@Lisias The scale_redist.dll distributed with FAR seems to be triggering Watchdog. Should that be happening?

[Lisias]

3 hours ago, dlrk said:

@Lisias The scale_redist.dll distributed with FAR seems to be triggering Watchdog. Should that be happening?

Yes. There can be only one.

Delete all redundant DLLs, leave only the 999_Scale_Redist.dll one on GameData.

[dlrk]

48 minutes ago, Lisias said:

Yes. There can be only one.

Delete all redundant DLLs, leave only the 999_Scale_Redist.dll one on GameData.

What if I don't have TweakScale?

[Lisias]

4 hours ago, dlrk said:

What if I don't have TweakScale?

Some others add'ons have hard dependencies on Scale_Redist to support TweakScale, besides having no hard dependencies on TweakScale itself. It was the way it was found to allow TweakScale to be optional at that time.

With the TweakScale Companion Program, at least in theory, the Scale_Redist is redundant - but yet, there're some 3rd parties add'ons relying on Scale_Redist out there, so it's here to stay.

If you don't have TweakScale installed, the WatchDog will not bother you - it will just ignore this check. But on the exact instant you install TweakScale, then the WatchDog will bark on duplicates (as well the location and the exact name of the 999_Scale_Redist.dll file).

ERRATA: The WatchDog will not bother you if you don't have any of the known clients of Scale_Redist installed (TweakScale is only one of them - it may be the provider of the service, but from the point of view of the WatchDog, it's just one of the known Client of Scale_Redist).

The current list of known clients for Scale_Redist is available here.

ADDENDUM: You are not required to have WatchDog installed, other than pesky you about known potential problems, it doesn't add any feature needed by TweakScale (or anything else). You can safely remove the file WatchDogForScaleRedist.dll from GameData/ModuleManagerWatchdog/Plugins/ .  This will kill the feature for good, no side effects - [other than having the potential problems due uncontrolled DLLs on your rig]...

Edited September 12, 2021 by Lisias
ADDENDUM to the ADDENDUM

[MD5Ray01]

So, I was trying to uninstall both this and Tweakscale at the same time (because I don't need either at the moment), and I've noticed that when I try to launch craft I've built since I installed it, they have Modules missing and thus can't be loaded (Refunding and Tweakscale).  What can I do to remove those modules from my craft parts?

[Lisias]

11 hours ago, MD5Ray01 said:

So, I was trying to uninstall both this and Tweakscale at the same time (because I don't need either at the moment), and I've noticed that when I try to launch craft I've built since I installed it, they have Modules missing and thus can't be loaded (Refunding and Tweakscale).  What can I do to remove those modules from my craft parts?

Just ignore the messages, as you would do by uninstalling any other add'on (as b9-ps, KIS, Atmospheric AutoPilot, etc).

Keep in mind that, as any other add'on, if the craft you are loading uses it that part will be defaulted, and your craft will be mangled - just don't save the craft if that happens, and nothing will be lost.

On a side note, on the latest releases from TweakScale a new feature will avoid these pesky messages in the future, as only parts really using TweakScale will cause some problems if you uninstall TweakScale and then try to load a craft made with it.

[The Beaver]

On 9/8/2021 at 6:16 PM, Lisias said:

There’re alternatives for KSP-Recall available on Forum for KSP 1.12.x users, so this is not exactly a settle back - it can be even an improvement, as some of the alternatives are willing to go trought paths I’m not.

So if I'm always using the most recent version I should use the alternatives?  Any chance you could shoot me a link in a msg or something to the alternatives (if you have time of course)?  Apparently I suck at searching lol.

Thanks I've used your mods for ages!

Beaver

Edited September 18, 2021 by The Beaver

[Lisias]

5 hours ago, The Beaver said:

So if I'm always using the most recent version I should use the alternatives?  Any chance you could shoot me a link in a msg or something to the alternatives (if you have time of course)? 

If you are on KSP 1.12.2, you should probably install the alternatives too - they are complementary, not mutually exclusive.

[Giancarlo Kerman]

If I may ask, what are these alternatives?

 

[Lisias]

NOTAM

KSP 1.12.3 was just released. The thingy is being downloaded right now, and I will test it in the early morning tomorrow.

KSP-Recall needs to be (re)validated, and in the mean time some fixes may misbehave - so, just to err on the safe side, if you use KSP-Recall and wants to check KSP 1.12.3 before me, please keep backups of everything. Just to err on the safe side - that rectangular pieces of paper happens after all.

— post edit --

METAR

KSP-Recall is still needed on KSP 1.12.3 - none of the KSP 1.12.2 bugs handled by KSP-Recall were fixed.

The fix that KSP 1.12.3 was meant to implement is considered insufficient. It's better than nothing, not doubt, but not better than what we had before (at least for the Docking Ports) - so besides the net gain being positive (due another fix that apparently is solid and I expect will make my life easier on TweakScale and DOE), it's somewhat disappointing IMHO.

Given the current status quo, I think that it will be us, Add'On Authors, who will really tackle down the problems. Given the expected timeframe for KSP2 being released, I think it's unlikely that new bug fixes will be released by Squad - granted, one is allowed to hope.

Edited December 14, 2021 by Lisias
METAR

[Lisias]

ANNOUNCE

KSP Recall 0.2.1.0 is on the Wild, featuring:

Fixes:

• #32 Correctly handle KSP 1.9 (and later) borking while loading Crafts on Editor with scaled Variants

A new module, AttachedOnEditor, was created to work around a (pretty old by this time) yet another KSP bug that was screwing up the surface attached parts when loading crafts on the Editor (loading on the Runway, Launchpad or flying crafts were - thanks God - not affected) since KSP 1.9, and that was incorrectly (and badly) worked around on TweakScale.

Thanks to @Krazy1 for the report!

— — — — — 

---

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 released.
• SpaceDock (and CKAN users). Will not be released.

The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishap - I'm running against the clock on Day Job, I'm trying to avoid working the entire holidays!  

Edited December 21, 2021 by Lisias
Distribution aborted. Use 0.2.1.1 instead,

[LTQ90]

11 minutes ago, Lisias said:

I'm trying to avoid working the entire holidays!  

you may not working at all in holidays  or maybe it s  time to change the def of this word.

Wish you the best !

[Lisias]

METAR

Uh… I borked the last release, I let a old binary leak into the distribution. (sigh)

Please delete the file <GameData>/999_KSP-Recall/Plugins/KSPRecall.dll (it's dated way older than the other DLLs) for while.

I will issue a new Release in the next few hours, with this mishap fixed - as soon as I manage to understand why my building tools failed on this.

— — POST EDIT --

WORST! I think I found the reason KSP squandered the OnStart method - someone tried to fix what appears to be a OnCopy mishap by brute force!!!

Details on https://github.com/net-lisias-ksp/KSP-Recall/issues/34

If I understood correctly, the Parts Position are not being echoed on the Copied Parts. So someone decided to shove it back on everything (being a copy or not) before OnStarting the part. (sigh)

— — POST EDIT — — 

It was detected that the problem happens from KSP 1.10 to newer.

The original misbehaviour WAS FIXED for KSP 1.9.1. Ladies and gentleman, we have a NEW KSP problem to cope with.

Edited December 21, 2021 by Lisias
METAR³

[Lisias]

ANNOUNCE

KSP Recall 0.2.1.1 0.2.1.2 0.2.1.3 is on the Wild, featuring:

Changes:

• 0.2.1.3
  • Implements a missing Use Case from Issue #32, handled on #34
  • Lifts the ban for KSP >= 1.10, the thing is known to work on everything since KSP 1.9
  • Works the issues:
    • #34 NEW Misbehaviour on KSP introduced by AttachedOnEditor
• 0.2.1.2
  • Rework Issue #32, handling OnCopy too.
• 0.2.1.1
  • The fix from 0.2.1.0 ended up working fine only on KSP 1.9.x .
    • On KSP 1.10.x and newer, a new misbehaviour (probably related, but not sure at this point) was detected. This is Research In Progress right now.
  • This release locks the current work around to KSP 1.9.x, and leaves KSP >= 1.10.0 unfixed for now, as the collateral effect ended up worsening the problem on newer KSPs.

Known Issues:

The first time a craft file is loaded after installing KSP-Recall, the surface attachment problem still happens. This is due the UpgradePipeline breaking the expected chain of events where the workaround is applied.

Once you fix the craft and save it, it will stay fixed.

I think it may be possible to work around the Upgrade Pipeline and save the work of the initial fix, but this is something I will need some time to tackle down, and I already spent all the time I could for now (more, to tell you the true).

With a bit of luck, this will be handled before the New Year's day.

All users still using 0.2.1.0 are urged to download this release ASAP, as it will prevent you some teeth grinding. Completely remove the old files before applying the update. Sorry, this thingy ended up bitting me where I was not looking.

— — — — — 

---

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.

The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with a new eventual mishap - I'm running against the clock on Day Job, I'm trying to avoid working (too much, as it's a fact by now that I will work a bit) the entire holidays!  

Edited January 22, 2022 by Lisias
Release 0.2.1.3. All Distribution Channels are belongs to us.

[glibbo]

Thank you for your unfaltering resolve on this mod, and for all you do for the game, have a great weekend, hopefully......

[Lisias]

News from the Front

I finally understood the problem on SubAssemblies (if it will solve Merging Crafts is currently Work In Progress) - I was chasing my tail on this one, the solution I was pursuing was impossible (because the problem was completely unrelated to the way I was trying it!!).

I'm currently testing the SubAssembly solution to see if I didn't created any undesired collateral effect, then I will check merging crafts to see if I got lucky and they were the same problem.

I will spend the next 2 days fooling around with my test beds to see if I get something (unlikely, exploratory testing was never one of my strong skills  ) and then I will release a new Recall version.

https://github.com/net-lisias-ksp/KSP-Recall/issues/35

Please note that, besides TweakScale being the most notoriously affected Add'On, this problem affects ANYTHING that tries to change the attachment too.

Cheers!

— — POST EDIT — — 

Two days I said? HA!!!

 

Edited January 21, 2022 by Lisias
psot edit

[Lisias]

News from the Front II

Well…. Things are slightly trickier than I thought. Currently, I can't fix an issue without opening another one that, once fixed, reopen the former. Obviously, I'm missing something: 

Not being enough, I ended up doing some regressions tests for other KSP problems and found something very.. interesting… (Forum Rules prevents me to use the term I'm thinking right now!  ): do you know that problem with the new Docking Module? Yeah, that one that created a lot of collateral effects, that ended up in drama!

This is the thing: the problem was misdiagnosed! It's not related to the ModuleDockingNode, it's something that changed on KSP guts while dealing with part's deformation, and it affects everything - the PartModule itself, and not only the ModuleDockingNode or even the Robotics! And, perhaps (but this is more a educated guess than a hypotheses by now) this is the reason we have the borks during the Merge/SubAssembly but not during the OnLoads - I think that some code that "fixed" a collateral effect of the change may be screwing me up on the Merge/SubAssembly phase. [EDIT: not exactly. the problem is happening since KSP 1.2.0. See this post for more details.]

And the problem is, essentially, that KSP is persisting the changes on the part's current position and rotation every time the craft itself is changed - as undocking, having a part destroyed and perhaps more. My guess is that something was done on the onVesselStandardModification  handler (or similar), and then something broke on the editing time (perhaps by unduly reuse of code), and then someone "marretou"  a half baked workaround on the Editor to counter-act the "marretada". [EDIT: everytime, but not everywhere - the problem only happens when you have AutoStruts activated!!]

If I'm right (and the tests until know appears to confirm I am), there's no point on trying to workaround only a few triggers for the problem (as the ModuleDockingNode). We need a fix or workaround to the very PartModule itself.

The changed happened probably on KSP 1.8.0 (I just tested downto 1.8.1), and it still happens on KSP 1.12.3 even with the Squad's fix for the DockingModuleNode.  [EDIT: It started on KSP 1.2.0, the very first release with the AutoStrut feature].

And by hitting stage:

Spoiler

On a side note, KSP 1.7.3 is the last KSP version where things is working fine on the matter:

Full report: https://github.com/net-lisias-ksp/KSP-Recall/issues/27 , including the craft files used for the tests.

What I will do now is currently RiP (Research in Progress): I'm trying to figure out if this is affecting me somehow on the current issue at hands - my current working theory is that the Merge/SubAssembly code is blindly reapplying the Prefab values on the craft outside the cannonical life cycle of the part, I probably "hit the sweet spot" by accident when I closed #35 and now trying to extend the fix for the Merge, I lost it and need to find another sweet spot.

A trial and error effort, unfortunately… 

— — POST EDIT — — 

Some corrections were made on the text above. Look for [EDIT: yada yada yada]

Edited January 26, 2022 by Lisias
POST EDIT

[zer0Kerbal]

*ouch*

so it sounds like the only way to fix this is 1.12.4?

[Lisias]

6 hours ago, zer0Kerbal said:

so it sounds like the only way to fix this is 1.12.4?

Frankly? I think it will take up to 1.12.8 or 1.12.9 until everything is tight again. Once you fix this problem correctly, all the changes made since 1.8.1 that are relying on the existence of the problem will break on their turn, and then they need to be fixed, and so on.

I'm afraid the faster and "safe" way is to go back to 1.7.3 and restart from there.

Edited January 22, 2022 by Lisias
Hit Save too soon.

[Lisias]

News from the Front III

I NAILED IT!!!

I **FINALLY** managed to reproduce deterministically and intentionally the problem on a clean KSP install , ruling out any influence from KSP-Recall or TweskScale (or anything else!!!) on the matter!!

https://github.com/net-lisias-ksp/KSP-Recall/issues/27#issuecomment-1021553526

The source of the problem is the use of the Grand-Parent AutoStrut! it's not clear at this time if the problem is specific from the Grand-Parent or if it affects every or at least another Auto-Strut. It was not determined neither if this affects every part or just some - I will further investigate the matter as time allows (let's hope for this night!).

Cheers!!

— — POST EDIT — — 

On a very interesting twist of fate, it was determined that the initial KSP Release where the problem happens is KSP 1.2.0, the very first release to ever have Auto-Struts. The conclusion is that we have this problem bugging us since the beginning of times.  

Well… It makes things easier to diagnose, if I choose to pursue a workaround for this one. By now, I only know what and where, but I still need to figure out WHY it happens. Time will tell.

Edited January 26, 2022 by Lisias
POST EDIT

[Lisias]

News from the Front IV

Well, I ended up wasting time and efforts (and some mood on useless altercations) on an unrelated KSP bug (that I wrongly suspected could be related somehow) and ended up forgetting that KSP is not the only source for bugs around here.

When I fixed the KSP's Editor bug on attachments while loading crafts with tweakscaled parts (with variants), I didn't realised something very important: the life cycle of a part is slightly different on initialisation when loaded from a file than when loaded from a subassembly (or by a merge). I focused on fixing things for the Craft Loading, but didn't took any measure on checking if the thing would work the same on subassemblies.

Well… Apparently I should have.

When I fixed the problem for Loading Craft, I ended up screwing up the SubAssembly and the Merge. As we use to say around here, "O que é remédio para o pato pode matar o marreco envenenado".

The reason I was unable to pinpoint the problem until now was bias. I spent too much time handling people blaming TweakScale for the problem, but I also was biased blaming KSP for a problem that Recall was already fixed, without being aware that the fix could be injecting collateral effects when called outside the Editor's Craft loading cycle. Not exactly a surprise, as I was rushing to fix a nasty problem on a very critical feature of KSP - and called it a day when I accomplished it.

Still, it's a bit embarrassing to tell you the true.

I have hard evidence about the module causing this problem - but removing the module would bring back the Craft Load problem, so I was caught between a rock and a hard place. But at least now I'm sure about the source of the misbehaviour, so all I need to do now is to understand the differences on the part's life cycle when loading a craft from when loading it from a subassembly (or for merge) so I can do whatever I need to do to prevent the SubAssembly and Merge from being screwed up by the Load fix.

You can follow this on https://github.com/net-lisias-ksp/KSP-Recall/issues/34 .

Edited February 8, 2022 by Lisias
Whoops… grammars again!²