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

[steve_v]

On 8/18/2020 at 9:41 AM, Lisias said:

with 600MB of log, it's hard to upload this monumental pile of bad news to to any service (even by zipping it).

Less so with a halfway-decent compression format. xz and zstd both consistently hit 5-6% on KSP logfiles for me, and I'd expect even better if that 600MB log is mostly spamming the same NRE (and even better again if using lrzip). Repeated short text fragments are basically decompression bombs anyway.
35-40MB compressed is still annoying, but it's quite suitable for any old filesharing site.

ED. Yeah, just grabbed a 120MB KSP.log I had laying around and fed it to lrzip... 3.19MB compressed.
 

Edited August 23, 2020 by steve_v

[Lisias]

3 hours ago, steve_v said:

Less so with a halfway-decent compression format. xz and zstd both consistently hit 5-6% on KSP logfiles for me, and I'd expect even better if that 600MB log is mostly spamming the same NRE (and even better again if using lrzip). Repeated short text fragments are basically decompression bombs anyway.
35-40MB compressed is still annoying, but it's quite suitable for any old filesharing site.

ED. Yeah, just grabbed a 120MB KSP.log I had laying around and fed it to lrzip... 3.19MB compressed.

The hard part will be teach the end user about them. They manage to know ZIP files, and that's it. We are the tech savvy guys, not them.

The need for a pre-analysis tool is, indeed, gaining relevance IMHO. "here, fire this tool and send me whatever if spit off". If the thing is integrated to CKAN, better yet.

[TranceaddicT]

53 minutes ago, Lisias said:

 manage to know

That's doing a LOT of heavily lifting.

I know a thing or two about compression but, I can honestly say it's still blackbox theory even to me.

[Lisias]

12 minutes ago, TranceaddicT said:

That's doing a LOT of heavily lifting.

I know a thing or two about compression but, I can honestly say it's still blackbox theory even to me.

It's not THAT hard. It's pattern recognition and applied statistics with a bit of "code" (using the cryptography meaning of the word). 

The really hard part is the pattern recognition.Some of these new ones makes Huffman looks like child's play.

[TranceaddicT]

1 hour ago, Lisias said:

It's not THAT hard. It's pattern recognition and applied statistics with a bit of "code" (using the cryptography meaning of the word). 

The really hard part is the pattern recognition.Some of these new ones makes Huffman looks like child's play.

Yeah, THAT just went over the head of 99.8% of end-users.

[steve_v]

7 hours ago, Lisias said:

The hard part will be teach the end user about them.

Well, xz is just LZMA and so is 7zip, so results should be similar. Converting people to 7zip is pretty much a public service anyway, is it not?

I'm not convinced that "download and run this tool, post results" is that much easier for the unwashed than "download and install 7zip, compress log", and it's sure more work for whoever gets to write the (cross-platform) preprocessor in the first place.

Off topic: Here's some benchmarks on lrzip, a tool specifically designed for compressing source code. Results are impressive to say the least.

Edited August 24, 2020 by steve_v

[Lisias]

2 hours ago, steve_v said:

I'm not convinced that "download and run this tool, post results" is that much easier for the unwashed than "download and install 7zip, compress log", and it's sure more work for whoever gets to write the (cross-platform) preprocessor in the first place.

C# and CKAN integration appears to be the way.

More reliable than a KSP add'on, as now and then I still manage to simply crash the whole shebang.

[steve_v]

9 hours ago, Lisias said:

C# and CKAN integration appears to be the way.

Integration into CKAN would work either way.

Where to put it isn't really the problem as I see it, more: Bags not going anywhere near coding a log analyser intelligent enough to be properly useful, they've been tried before, and they always suck.
A simple "X plugin is barfing some NREs" might be marginally useful, but then we already have ExceptionDetector. 
For more complicated cases, sooner or later you're going to run into one that requires you to backtrack way up the log to that tiny innocuous looking warning that made everything explode... How ya gonna reliably automate it? How much context do you include? What about unholy interactions where your first clue is a perfectly normal looking info line?

If I'm looking for a problem I'd rather get the whole file any day. IME nothing really beats grep, awk, a mk1 eyeball and a well caffeinated brain. You're going to want the whole log file eventually, why not just ask for it to begin with?

[Lisias]

4 hours ago, steve_v said:

A simple "X plugin is barfing some NREs" might be marginally useful, but then we already have ExceptionDetector. 
For more complicated cases, sooner or later you're going to run into one that requires you to backtrack way up the log to that tiny innocuous looking warning that made everything explode... How ya gonna reliably automate it? How much context do you include? What about unholy interactions where your first clue is a perfectly normal looking info line?

You don't need to solve 100% of the problems with the tool - going Pareto, if the tool is able to manage 80% of the problems and just send me the whole shebang on the remaining 20%, it will save me a huge amount of work.

Most of the problems on TweakScale nowadays are still the same from 12 months ago - bad patching by the same add'ons that didn't was (or can't be) fixed - it's essentially `grep this`, `grep that`, if both cames with something, you have this problem and need to do this to solve it.

 

4 hours ago, steve_v said:

If I'm looking for a problem I'd rather get the whole file any day. IME nothing really beats grep, awk, a mk1 eyeball and a well caffeinated brain. You're going to want the whole log file eventually, why not just ask for it to begin with?

For diagnosing new problems, without the slightest doubt. But once the problem is proper diagnosed, and once it's detected that the problem is recurrent (and almost everything here is recurrent, as it appears), going hand to hand with these is wasting time.

Edited August 24, 2020 by Lisias
Kinda of typo

[Lisias]

Announce.

Github [Some tool] decided to bite me in the SAS, adding a configuration that automatically translated EoL between UNIX and Windows. And did that on a DLL. #facePalm.

The 0.0.4.4 only fixes the 666_ModuleManagerWatchDog.dll , the affected one. It should affect only manual installers, as CKAN was told to ignore this.

The whole history is on TweakScale thread, where the bork was detected.

Edited August 28, 2020 by Lisias
It was not github. Still hunting the ****

[boribori]

A tiny issue, I think.
I have several versions and combinations of KSP + mods in as many different folders. I link KSP_linux (I'm on linux, obviously) to the one I'm currently using, like this:

:~/Games/KSP> ls -lF|grep KSP
 KSP_linux -> KSP_linux_1.10.1_LRTR_RF//
 KSP_linux_1.10.1_LRTR_RF/
 KSP_linux_1.10.1_LRTR_RF.tar.bz2
 KSP_linux_1.10.1_LRTR_RR/
 KSP_linux_1.10.1_old_LRTR_RF/
 KSP_linux_1.10.1_RO_K/
 KSP_linux_1.10.1_test/
 KSP_linux_1.7.3/
 KSP_linux_1.9.1/

So when I run KSP by following the link it gives me a scary warning that KSP-recall is installed in the wrong folder: in KSP_linux_1.10.1_LRTR_RF instead of KSP_linux and that bad things might happen to my savegame.

1. I assume nothing bad will actually happen since it is actually installed in the correct folder. Am I correct?
2. Is it possible to get rid of the warning in cases like this if it is actually safe?

Thanks!

[Lisias]

On 10/3/2020 at 5:07 PM, boribori said:

A tiny issue, I think.
I have several versions and combinations of KSP + mods in as many different folders. I link KSP_linux (I'm on linux, obviously) to the one I'm currently using, like this:

:~/Games/KSP> ls -lF|grep KSP
 KSP_linux -> KSP_linux_1.10.1_LRTR_RF//
 KSP_linux_1.10.1_LRTR_RF/
 KSP_linux_1.10.1_LRTR_RF.tar.bz2
 KSP_linux_1.10.1_LRTR_RR/
 KSP_linux_1.10.1_old_LRTR_RF/
 KSP_linux_1.10.1_RO_K/
 KSP_linux_1.10.1_test/
 KSP_linux_1.7.3/
 KSP_linux_1.9.1/

So when I run KSP by following the link it gives me a scary warning that KSP-recall is installed in the wrong folder: in KSP_linux_1.10.1_LRTR_RF instead of KSP_linux and that bad things might happen to my savegame.

1. I assume nothing bad will actually happen since it is actually installed in the correct folder. Am I correct?
2. Is it possible to get rid of the warning in cases like this if it is actually safe?

Thanks!

These UNIX guys, always freaking up our clever stunts....  

Here is the story: in order to guarantee instalment integrity, there're some features on a thingy called KSPe that checks things and bark on the user when something is wrong. However, in order to be really sure (and to enforce KSP policies of not allowing direct access to outside of the KSP root directory), I resolve dots and double-dots and make sure nothing leaks to outside (of course, the developer can give the finger to it and do things his/her way, but so he/she wave up the KSPe facilities and that's it).

Problem - our friendly guys of mono runtime decided it's a good idea to resolve the links and symlinks of the main executable, and so the KSP rootpath given to me is not the same you used to launch the game, and this bit me in the SAS magnificently.

I solved this problem using a hell of a stunt, but the stunt works. Thanks @steve_v for it.

In a way or another, there's an experimental build of the KSPe.Light for KSP Recall on this post with this fixed. It will be distributed on the next Recall release, but until there you can shove that thing on the Recall's Plugin folder, making sure it's replacing the older DLL.

I don't remember if I handled specifically your Use Case, however - I remember tackling down the problems using symlinks inside the KSP root (Steve's Use Case) - I'm not sure if that stunt will work for your case. If not, ping me here and I will rework the stunt for you.

Let me know if it works too, so I can update the "documentation".

 

Edited October 17, 2023 by Lisias
Tyops, as usulla...

[boribori]

11 hours ago, Lisias said:

These UNIX guys, always fscking up our clever stunts....  

Here is the story: in order to guarantee instalment integrity, there're some features on a thingy called KSPe that checks things and bark on the user when something is wrong. However, in order to be really sure (and to enforce KSP policies of not allowing direct access to outside of the KSP root directory), I resolve dots and double-dots and make sure nothing leaks to outside (of course, the developer can give the finger to it and do things his/her way, but so he/she wave up the KSPe facilities and that's it).

Problem - our friendly guys of mono runtime decided it's a good idea to resolve the links and symlinks of the main executable, and so the KSP rootpath given to me is not the same you used to launch the game, and this bit me in the SAS magnificently.

I solved this problem using a hell of a stunt, but the stunt works. Thanks @steve_v for it.

In a way or another, there's an experimental build of the KSPe.Light for KSP Recall on this post with this fixed. It will be distributed on the next Recall release, but until there you can shove that thing on the Recall's Plugin folder, making sure it's replacing the older DLL.

I don't remember if I handled specifically your Use Case, however - I remember tackling down the problems using symlinks inside the KSP root (Steve's Use Case) - I'm not sure if that stunt will work for your case. If not, ping me here and I will rework the stunt for you.

Let me know if it works too, so I can update the "documentation".

 

Unfortunately I still get the warning:

I forgot to mention I'm on 1.10.1 since most things for 1.8 and 1.9 seem to work fine on 1.10 anyway.

But maybe I also did something else wrong:

KSPe.Light.Recall.dll from KSPe-Issue-6.zip was the same date as the one I had already installed. I did overwrite it anyway. 000_KSPe.dll was new and I placed it in GameData. I ignored the KAX and TweakScale folders since I don't have those installed.

I see this in the Player.log: FileNotFoundException: The path GameData/000_KSPAPIExtensions/Plugins/PluginData doesn't resolve to a valid DLL search path!

Full log: https://drive.google.com/file/d/1zispgEhIB_YKvWMRVw7OABD_k-jhoJNV/view?usp=sharing

But it's not a big deal, it seems to work anyway, at least the drift part and that's why I installed it. I haven't tested it a lot yet, but don't put too much effort in it for the few of us who use links. (Is it only Mac and Linux, I thought windows could also do links?)

 

 

Edited October 4, 2020 by boribori

[Lisias]

4 minutes ago, boribori said:

Unfortunately I still get the warning:

I forgot to mention I'm on 1.10.1 since most things for 1.8 and 1.9 seem to work fine on 1.10 anyway.

But maybe I also did something else wrong:

KSPe.Light.Recall.dll from KSPe-Issue-6.zip was the same date as the one I had already installed. I did overwrite it anyway. 000_KSPe.dll was new and I placed it in GameData. I ignored the KAX and TweakScale folders since I don't have those installed.

Humm... So I already had updated Recall with it (getting old... ). So, yeah, I need to tackle down  your Use Case specifically.

 

5 minutes ago, boribori said:

I see this in the Player.log: FileNotFoundException: The path GameData/000_KSPAPIExtensions/Plugins/PluginData doesn't resolve to a valid DLL search path!

Full log: https://drive.google.com/file/d/1zispgEhIB_YKvWMRVw7OABD_k-jhoJNV/view?usp=sharing

The KSP.log is way better for diagnosing things, could you send me this one, please?

What you got was my safety belt against loading DLLs outside the KSP root (KSPe can selectively load DLLs too - so ensuring it's something inside KSP is important to keep things safest as possible to the user).

[boribori]

3 minutes ago, Lisias said:

The KSP.log is way better for diagnosing things, could you send me this one, please?

https://drive.google.com/file/d/1tz70DA10woS1VUt-3P32MKXHdFekTUUV/view?usp=sharing

BTW, I don't have GameData/000_KSPAPIExtensions

[Lisias]

20 minutes ago, boribori said:

https://drive.google.com/file/d/1tz70DA10woS1VUt-3P32MKXHdFekTUUV/view?usp=sharing

Not that I had any doubt, but yeah, even Module Manager is being fooled about your symlink!

[LOG 11:03:33.944] [ModuleManager] version 4.1.4.0 at /home/boris/Games/KSP/KSP_linux_1.10.1_LRTR_RF/GameData/ModuleManager.4.1.4.dll won the election against Version 4.1.4.0 /home/boris/Games/KSP/KSP_linux/GameData/ModuleManager.4.1.4.dll

It thinks the same DLL are two different ones. This also means that KSP is loading it twice... #facePalm

I still didn't found time to write my own AssemblyResolver (what would solve some problems on KSP), so MM will have to wait.

In the mean time, I reopened the Issue #6 to handle your case. I had burn some midnight oil, so I'm a bit tired now - but I will tackle down your problem after resting a little.

Cheers.

Edited October 4, 2020 by Lisias
Tyops! But you already knew it.

[Lisias]

@boribori, I had built new (debugging) binaries and I need you to test the thing on your installment.

Check this post on the github, download the new zip file and use the DLL you need. Fire KSP up, see what happens, and then please report me what you got. Please publish the KSP.log either way, this is a Fishing Expedition by now.

 

[boribori]

24 minutes ago, Lisias said:

@boribori, I had built new (debugging) binaries and I need you to test the thing on your installment.

Check this post on the github, download the new zip file and use the DLL you need. Fire KSP up, see what happens, and then please report me what you got. Please publish the KSP.log either way, this is a Fishing Expedition by now.

 

Still the same. I replied with the log on github.
I forgot to ask: Looking at what it's doing I assume it cannot be a mod incompatibility, right? Or should I try it on a clean stock install?
And should we keep it here or on github?

[Lisias]

1 hour ago, boribori said:

Still the same. I replied with the log on github.
I forgot to ask: Looking at what it's doing I assume it cannot be a mod incompatibility, right? Or should I try it on a clean stock install?
And should we keep it here or on github?

It's not a mod compatibility, it's Microsoft insanity.

Testing it on a clean install will only mask the problem, please keep testing on the current installment.

I prefer to keep these one on github, as we will need to exchange a lot of files and this is way more convenient on github.

I will post the conclusion here once I manage to fix this damn microsoftian idiocy.

[Lisias]

METAR

KSP 1.11.0 arrived and the need for Driftless :NEEDS  to be reevaluated. Currently, Driftless is installed on anything equal or bigger than 1.8.0, so it will be installed on 1.11.0 too, being needed or not. I don't thing this will cause any collateral effect, but just in case, please use S.A.V.E. (just in case).

Resourceful will not affect 1.11, it only installs itself on KSP 1.9.x.

Please report anything weird.

 

[Lisias]

METAR

I found some time to test KSP Recall's Driftless on KSP 1.11.

TL;DR:  KSP-Recall Driftless is not needed on KSP 1.11, but it's still useful on borderline situations. I will not prevent it from installing itself on KSP 1.11.

WITHOUT Driftless:

WITH Driftless:

 

On the other hand, since Drfitless can still be useful on KSP 1.11, I think it is a good idea to further investigate if there's a way to still act when the physics engine is overloaded.

Moar screenshots (but not necessarily more info) on Issue #10.

Edited December 18, 2020 by Lisias
Forgot to format the tittle...

[Lisias]

ANNOUNCE

KSP Recall 0.0.5.0 in on the Wild, featuring:

• Better coping with KSP 1.11

Driftless is not needed on KSP 1.11, and my findings suggests it's undesired on it. So it will not install itself on KSP 1.11.x and above.

There're, however, some opportunities for improvement  - some research is needed, however, to understand how "Anchoring" works and how to enhance it without breaking it.

Good Luck!  

---

This Release will be published using the following Schedule:

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

Edited December 20, 2020 by Lisias
All distribution channels up to date.

[Lisias]

ANNOUNCE

KSP Recall 0.0.6.0 BETA in on the Wild, featuring:

• Preliminary attempt to overcome the new bug on launching from KSP 1.11
• Check the following posts for more information:
  • KAX
  • Impossible Innovations.
  • OPT Legacy.
• KSP Recall 0.0.6.0 APPARENTLY fixes this, but I don't know if I'm injecting collateral effects on the Physics Engine. PROCEED WITH CAUTION, this stunt can end up being worse than the problem!
  • Currently it's way agressive injecting the fix on everything. A smarter way to inject the fix only on the needing parts are something still to be done!

A new module, ChillingOut, was introduced for KSP 1.11, to fix that weird problem on launching crafts with some old meshes.

World Stabiliser is still needed.

Early adopters are advised to backup the game before installing. Please report any weird effect - I really don't know if I'm doing everything right.

Good Luck!  

---

This Release will be published using the following Schedule:

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

Edited January 6, 2021 by Lisias
World Stabiliser is still needed.

[Lisias]

On a side node, some recent insights about the myriad of problems infecting the new KSP releases suggests that the meshes are not the problem as I was thinking.

Spoiler

 

And that may be the reason for my bitter failure on reworking the meshes some time ago - no matter what I was doing on the mesh, the Jumping Jack Effect was happening and happening again. What hints that the problem may not be on the mesh.

My guess is that World Stabiliser worked around an initialisation failure on the PartModule that happened in the past - but instead of trying to zeroing into the source of the problem, World Stabiliser implemented a procedure that by some reason "jumped" over the problem. It's like the Vessel Mover being able to overcome the heat problem the 0.0.6.0 of KSP Recall appears to be fixing.

We may be chasing ghosts for years, as it appears...

[Craze]

When the game is closed, the symmetry and angle settings are permanently reset to not set (by default, "X" and "C"). Can this be fixed?