TweakScale Companion Program - 2025.2.7.0

[Lisias]

On 10/8/2024 at 6:59 AM, BSS_Snag said:

o7

----- POST EDIT-----
Ping! @Lisias
Started up the backup instance with waterfall 0.10.1 and the above release
VAB and checking the parts that triggered the error spam in the console
And no error now, even scaled up and down the Prometheus srb nosecone in question, and tried it with a similar part as well from BDB again.
The change you have made "seems" to have worked some magic but of course logs are here

Good news, so! I had detected some not so good news from my side involving the last release of Waterfall, but apparently it's related to my rig and not to any code.

Other than the glitch I had reported on the Waterfall thread, I didn't found anything cheesy on my side neither.

I didn't made any magic, though. Just rewrote the code that detects Waterfall, everything else remained the same.

Anyway, I'm promoting this release to.. "Release" now.

[Lisias]

Announce!

New release 2024.10.09.0 for the TweakScale Companion ÜberPaket with everything (and the kitchen's sink) included for the lazy installers !!

Updates the Companions:

• Frameworks to 0.4.0.5

See the project's main page to details.

Your attention please

• Completely remove all the previous contents in the GameData/TweakScaleCompanion directory, or you will trigger some FATALities on TweakScale's Sanity Checks!
• This thingy needs TweakScale v2.4.7 or superior to work

Download here or in the OP.

Also available on CurseForge and SpaceDock. (by night) [edit: nah... they are there already!]

 

Edited October 9, 2024 by Lisias
All your distribution channels are belong to us!!

[Lisias]

NOTAM

Waterfall 0.10.0.0, recently published, removed a type from the Assembly that I as relying to identify it and, so, this release broke TweakScale. Big thanks to @BSS_Snag for reporting it!

I reworked the TweskScale Compantion for Frameworks, the subcomponent responsible for dealing with Waterfal, and published a new released last Wednsday - on GitHub, CurseForge and SpaceDock.

Unfortunately, CKAN until this moment failed to index the new release, and this is the reason fir some TweakScale users getting some problems when Waterfall is installed.

Until there, I have to ask to all CKAN users to manually update the Companion to the newest (currently Release 2024.10.09.0 ), or at very least the Frameworks to 0.4.0.5.

I'm working with the CKAN team to have this sorted out. My apologies.

=== == = POST EDIT = == ===

Problem located and fixed. Creating releases in a rush at lunch time is, usually, not the wisest of the ideas.

Note to my future self: http://status.ksp-ckan.space/

Edited October 11, 2024 by Lisias
POST EDIT

[Cossus]

Hello everybody and the author,

today I've spoiled my JNSQ KSP mods assembly, luckily I'm on the very start. After updating of actual mods and fine-tuning the game, mostly in graphical part, I've noticed massive fps drops in the VAB after adding some engines to the craft. I've found that some problems with Waterfall/TweakScale may cause this drop, so I've replaced "Frameworks" folder in Tweak Scale with the freshest one, which caused crash less than in 1 minute after I've started KSPx64.exe. Reverting this doesn't help! An old "Frameworks" folder now has reproduced the same crash. I've then updated the whole TweakScale Companion (including Frameworks), and just in case re-installed TweakScale, KspE with all dependencies and so on... nothing changes. It seems that my problem is close to this one... I've also tried to find whether any error in log became fatal despite it wasn't during previous succesful load and removed (separately) KAX, Contract Configurator and its dependent mods, UmbraSpaceTechnologoies folder, but the crash has persisted. So I now may only asc for help on this forum, with GameData folder screenshot and KSP log attached.

I've also made like-a-new copy of KSP via copying of every folder from the old one but GameData (except Squad, SquadExpansion) and a pair of others which the game doesn't need. Then I've installed all the mods but the least two from the link (Crash to desktop with version 2023.03.28.3 #6) above, and despite the game started succesfully, I've seen a bit warning sings on the loading screen. Caution, the log is very large.

Edited Monday at 07:44 AM by Cossus
Moderator request to upload logs on an outer source

[Vanamonde]

2 hours ago, Cossus said:

Hello everybody and the author,

today I've spoiled my JNSQ KSP mods assembly, hopefully I'm on the very start. After updating of actual mods and fine-tuning the game, mostly in graphical part, I've noticed massive fps drops in the VAB after adding some engines to the craft. I've found that some problems with Waterfall/TweakScale may cause this drop, so I've replaced "Frameworks" folder in Tweak Scale with the freshest one, which caused crash less than in 1 minute after I've started KSPx64.exe. Reverting this doesn't help! An old "Frameworks" folder now has reproduced the same crash. I've then updated the whole TweakScale Companion (including Frameworks), and just in case re-installed TweakScale, KspE with all dependencies and so on... nothing changes. It seems that my problem is close to this one... I've also tried to find whether any error in log became fatal despite it wasn't during previous succesful load and removed (separately) KAX, Contract Configurator and its dependent mods, UmbraSpaceTechnologoies folder, but the crash has persisted. So I now may only asc for help on this forum, with GameData folder screenshot and KSP log attached:

[snip]

I've also made like-a-new copy of KSP via copying of every folder from the old one but GameData (except Squad, SquadExpansion) and a pair of others which the game doesn't need. Than I've installed all the mods but the least two from the link (Crash to desktop with version 2023.03.28.3 #6) above, and despite the game started succesfully, I've seen a bit warning sings on the loading screen. The log is too large, I don't want to attach it.

Hello new person and welcome to the forum. Unfortunately, files as large as that log cause problems and we've had to remove it from your post. Please upload it to a file sharing service and copy the link they provide here. 

[Cossus]

4 hours ago, Vanamonde said:

Hello new person and welcome to the forum. Unfortunately, files as large as that log cause problems and we've had to remove it from your post. Please upload it to a file sharing service and copy the link they provide here. 

Yes, it was a bit laggy... Done!

Edited Monday at 07:32 AM by Cossus

[Lisias]

21 hours ago, Cossus said:

Yes, it was a bit laggy... Done!

Hi! Can you please fire up KSP again, reproduce the problem, then quit KSP and then send me the resulting KSP.log on a new share, not matter the size of the file (I have tools to handle it)?

I didn't found anything obviously wrong  on it - other that you having Harmony installed without anything else that would use it, but this should not be a factor.

I'm reproducing your test rig on my machine to give it a try and see what I find in the mean time.

--- POST EDIT ---

In time, are you running KSP from a SSD or NVME drive?

Edited Tuesday at 04:31 AM by Lisias
POST EDIT

[Cossus]

9 hours ago, Lisias said:

Hi! Can you please fire up KSP again, reproduce the problem, then quit KSP and then send me the resulting KSP.log on a new share, not matter the size of the file (I have tools to handle it)?

I didn't found anything obviously wrong  on it - other that you having Harmony installed without anything else that would use it, but this should not be a factor.

I'm reproducing your test rig on my machine to give it a try and see what I find in the mean time.

Thank you for a quick reply,

I've edited my first post to include logs on Google.Drive, but anyway, just in case, here are the two fresh logs obtained just now:

the first, from my over-modded JNSQ mod assembly, with quick crash

and

the second, from the succesfully loaded almost vanilla minimally modded game. But I saw orange warnings about "...19x" at the upper right corner of loading screen at the start before any pictures are emerging. Here it is the mod list from the second assembly, but I suspect that files in some other folder (because I've simply copied the first game assembly without GameData*) or in AppData folder may cause these warnings:

000_Harmony; 999_KSP-Recall; 000_KSPe; ModuleManager; ModuleManagerWatchDog; Squad; SquadExpansion; TweakScale; TweakScale Companion; 000_KSPe.dll; 001_KSPe.dll; 666_ModuleManagerWatchDog.dll; 999_Scale_Redist.dll; ModuleManager.dll

*also emptied "saves", "Logs" and "PluginData" folders, with subsequent copying in the latter of ModuleManagerWatchDog.cfg as it recommended in installation instructions

---------------------

UPD: Yes, I'm launching KSP from SSD and it's the only hard drive on my notebook (which is from Asus Zenbook series).

Edited Tuesday at 07:22 AM by Cossus

[Lisias]

8 hours ago, Cossus said:

I've edited my first post to include logs on Google.Drive, but anyway, just in case, here are the two fresh logs obtained just now:

the first, from my over-modded JNSQ mod assembly, with quick crash

Yep, sudden death. The last lines are:

[LOG 01:03:03.827] [TweakScale.WatchDog] Version 2.4.8.8 /L
[LOG 01:03:03.827] [TweakScaleCompanion.Frameworks] Version 0.4.0.5 /L BETA
[LOG 01:03:03.860] [TweakScaleCompanion.Frameworks] TweakScalerTestFlightCore Version 0.4.0.5 /L BETA is loaded.
[LOG 01:03:03.860] [TweakScaleCompanion.FS] Version 1.3.0.1 /L
[LOG 01:03:03.862] [TweakScaleCompanion.KIAS] Version 1.1.0.0 /L
[LOG 01:03:03.900] [TweakScaleCompanion.PKMC] Version 2.2.1.1 /L
[LOG 01:03:03.934] [Universal Storage] Version UniversalStorage2, Version=4.0.1.3, Culture=neutral, PublicKeyToken=null

It's weird because the Frameworks were initialized without crashes - anything fishy involving it should had prevented FS, KIAS and PKMC from being initialized.

The last thing logged successfully was Universal Storage. I don't think it's involved, it just was the last one being able to log something.

The second log appears to confirm the problem may not be exactly the FrameWorks:

[LOG 01:03:33.809] [TweakScale.WatchDog] Version 2.4.8.8 /L
[LOG 01:03:33.809] [TweakScaleCompanion.Frameworks] Version 0.4.0.5 /L BETA
[LOG 01:03:33.833] [TweakScaleCompanion.Frameworks] TweakScalerTestFlightCore Version 0.4.0.5 /L BETA is loaded.
[LOG 01:03:33.833] [TweakScaleCompanion.FS] Version 1.3.0.1 /L
[LOG 01:03:33.858] [TweakScaleCompanion.KIAS] Version 1.1.0.0 /L
[LOG 01:03:33.887] [TweakScaleCompanion.PKMC] Version 2.2.1.1 /L
[LOG 01:03:34.085] Load(Audio): Squad/Alarms/Sounds/Classic
[LOG 01:03:34.224] [ModuleManager] INFO: Calling KSPe.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 01:03:34.236] [ModuleManager] INFO: Calling KSP-Recall.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 01:03:34.239] [ModuleManager] INFO: Calling KSPe.Unity.2019.ModuleManagerSupport.ModuleManagerAddToModList()

Do you know how to fetch the Player. log? You will find instructions on the Spoiler in the TweakScale's OP. Or below, for convenience:

Quote

When asked, the KSP.log and output_txt log from Unity.

• See this article for instructions.
• The Player.log changed location:
  • On MacOS
    • For KSP < 1.8, they are on ~/Library/Logs/Unity
    • On KSP >=1.8, you will find the Player.log on ~/Library/Logs/Squad/KSP/
  • On Windows
    • On KSP >=1.8, you will find the Player.log on C:\Users\<USERNAME>\AppData\LocalLow\Squad\KSP\
  • On Linux
    • On KSP >=1.8, you will find the Player.log on ~/.config/unity3d/Squad/KSP/

I'm going to need this file this time, and hopping the process had crashed "nicely", i.e., flushing the open files.

There's also a file called "error.log" in C:/Users/<your-login-on-windows>/AppData/Local/Temp/Squad/Kerbal Space Program/Crashes. I'm afraid I'm going to need this one too.

It may be related to lack of memory, besides you having 16G what should be enough for what you are trying to load - but without these two files, I can only guess, and this is not enough.

[Cossus]

6 hours ago, Lisias said:

It's weird because the Frameworks were initialized without crashes - anything fishy involving it should had prevented FS, KIAS and PKMC from being initialized.

The last thing logged successfully was Universal Storage. I don't think it's involved, it just was the last one being able to log something.

It worth noting that when I temporarily removed some mods from GameData, the number of last lines in KSP log might vary a bit, as well as its size, from 160 to 165 kb. One time the line about Universal storage was last but one, so I think you're right and the reason of the crash is somewhere else but in the last lines of the log...

6 hours ago, Lisias said:

Do you know how to fetch the Player. log? You will find instructions on the Spoiler in the TweakScale's OP. Or below, for convenience:

I'm going to need this file this time, and hopping the process had crashed "nicely", i.e., flushing the open files.

There's also a file called "error.log" in C:/Users/<your-login-on-windows>/AppData/Local/Temp/Squad/Kerbal Space Program/Crashes. I'm afraid I'm going to need this one too.

Fetched player and error logs from the fresh crash.

6 hours ago, Lisias said:

It may be related to lack of memory, besides you having 16G what should be enough for what you are trying to load - but without these two files, I can only guess, and this is not enough.

I've just in case checked free space on SDD (70+ GB), size of the swap file (55 GB) and examined whether anything will change after temporal removing of the one of the largest mod folder (BDB) in GameData, the answer is no.

[Lisias]

1 hour ago, Cossus said:

It worth noting that when I temporarily removed some mods from GameData, the number of last lines in KSP log might vary a bit, as well as its size, from 160 to 165 kb. One time the line about Universal storage was last but one, so I think you're right and the reason of the crash is somewhere else but in the last lines of the log...

Yep. This time, we managed to got something new before crashing, Contract Configurator

[TweakScale.WatchDog] Version 2.4.8.8 /L
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScaleCompanion.Frameworks] Version 0.4.0.5 /L BETA
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScaleCompanion.Frameworks] TweakScalerTestFlightCore Version 0.4.0.5 /L BETA is loaded.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScaleCompanion.FS] Version 1.3.0.1 /L
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScaleCompanion.KIAS] Version 1.1.0.0 /L
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScaleCompanion.PKMC] Version 2.2.1.1 /L
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[Universal Storage] Version UniversalStorage2, Version=4.0.1.3, Culture=neutral, PublicKeyToken=null
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[DEBUG] ContractConfigurator.Util.TipLoader: Adding custom loading tips
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

 

1 hour ago, Cossus said:

Fetched player and error logs from the fresh crash.

I've just in case checked free space on SDD (70+ GB), size of the swap file (55 GB) and examined whether anything will change after temporal removing of the one of the largest mod folder (BDB) in GameData, the answer is no.

Humm, yeah... You got bitten by a Memory Allocation Error:

57% physical memory in use.
16136 MB physical memory [6796 MB free].
4010 MB process peak paging file [4010 MB used].
2514 MB process peak working set [2514 MB used].
System Commit Total/Limit/Peak: 19577MB/71472MB/66079MB
System Physical Total/Available: 16136MB/6796MB
System Process Count: 271
System Thread Count: 5427
System Handle Count: 172631
Disk space data for 'C:\Users\75BD~1\AppData\Local\Temp\Squad\Kerbal Space Program\Crashes\Crash_2025-02-04_133913935\': 82391502848 bytes free of 510560374784 total.

Read from location 0000000000000000 caused an access violation.

Context:
RDI:    0x000001be14ea02b0  RSI: 0x0000000000000001  RAX:   0x0000000000000000
RBX:    0x000001be152fe410  RCX: 0x000001be152fe458  RDX:   0x0000000000000000
RIP:    0x00007ff9c9bbfaa4  RBP: 0x0000008239aac100  SegCs: 0x0000000000000033
EFlags: 0x0000000000010206  RSP: 0x0000008239aac000  SegSs: 0x000000000000002b
R8:     0x000001be14ea0270  R9:  0xffffffffbb1e5178  R10:   0x0000000000000000
R11:    0x0000000000000000  R12: 0x0000000000000000  R13:   0x0000000000000000
R14:    0x0000000000000000  R15: 0x0000000000000000

However... You still had about 75GB of free space in your disk, but your swapfile is really big and Windows almost surely trew the towel on this. Since you didn't installed KerbalKonstructs,  I think we found another similar case but involving another add'on.

Spoiler

I'm going to be sore in the morning....

I'm (almost) reproduced your rig in my test bed, I'm going to give this a shot by night. Let's see how MacOS handle this.

[Cossus]

3 hours ago, Lisias said:

However... You still had about 75GB of free space in your disk, but your swapfile is really big and Windows almost surely trew the towel on this. Since you didn't installed KerbalKonstructs,  I think we found another similar case but involving another add'on.

I've found that my trash bin is totally full and removed everything. After that and reload, it becomes 152 GB of free space on the disk. But I still have the same crash, here it is a fragment of the error log like above, but with actual numbers:

Spoiler

Kerbal Space Program by Squad [version: Unity 2019.4.18f1_3310a4d4f880]

UnityPlayer.dll caused an Access Violation (0xc0000005)
  in module UnityPlayer.dll at 0033:c42cfaa4.

Error occurred at 2025-02-04_224300.
C:\GOG Games\Kerbal Space Program\KSP_x64.exe, run by Илья.

44% physical memory in use.
16136 MB physical memory [8909 MB free].
4062 MB process peak paging file [4061 MB used].
2567 MB process peak working set [2566 MB used].
System Commit Total/Limit/Peak: 13696MB/19080MB/16425MB
System Physical Total/Available: 16136MB/8909MB
System Process Count: 249
System Thread Count: 3483
System Handle Count: 119181
Disk space data for 'C:\Users\75BD~1\AppData\Local\Temp\Squad\Kerbal Space Program\Crashes\Crash_2025-02-04_194255867\': 163609546752 bytes free of 510560374784 total.

Read from location 0000000000000000 caused an access violation.

Context:
RDI:    0x000002b4103aee80  RSI: 0x0000000000000001  RAX:   0x0000000000000000
RBX:    0x000002b414ea09b0  RCX: 0x000002b414ea09f8  RDX:   0x0000000000000000
RIP:    0x00007ff8c42cfaa4  RBP: 0x000000ed561fbd30  SegCs: 0x0000000000000033
EFlags: 0x0000000000010202  RSP: 0x000000ed561fbc30  SegSs: 0x000000000000002b
R8:     0x000002b4103aee40  R9:  0xffffffffbfcd65a8  R10:   0x0000000000000000
R11:    0x0000000000000000  R12: 0x0000000000000000  R13:   0x0000000000000000
R14:    0x0000000000000000  R15: 0x0000000000000000

 

Edited Tuesday at 07:50 PM by Cossus

[Lisias]

7 minutes ago, Cossus said:

I've found that my trash bin is totally full and removed everything. After that and reload, it becomes 152 GB of free space on the disk. But I still have the same crash, here it is a fragment of the error log like above, but with actual numbers:

I have good news, and bad news.

The good news, I managed to reproduce the problem on MacOS, and using only a subset of the add'ons you are using, so we already ruled out a bunch.

The bad news: I don't have the faintest idea, yet, about how in hell this is happening.  My rig is like yours, 16GB RAM, and I had trimmed all the graphics settings to the bare minimum, and still, the process died.

To avoid derailing this thread with something that (at least until this moment) is unrelated, I will publish my findings on the link below.

https://github.com/orgs/KSP-ModularManagement/discussions/4

If you have a github account, feel free to post there. Otherwise, oh well... Post your questions here anyway.

(I'm currently writing a report about what I got until this moment)

[Cossus]

14 minutes ago, Lisias said:

I have good news, and bad news.

The good news, I managed to reproduce the problem on MacOS, and using only a subset of the add'ons you are using, so we already ruled out a bunch.

The bad news: I don't have the faintest idea, yet, about how in hell this is happening.  My rig is like yours, 16GB RAM, and I had trimmed all the graphics settings to the bare minimum, and still, the process died.

To avoid derailing this thread with something that (at least until this moment) is unrelated, I will publish my findings on the link below.

https://github.com/orgs/KSP-ModularManagement/discussions/4

If you have a github account, feel free to post there. Otherwise, oh well... Post your questions here anyway.

(I'm currently writing a report about what I got until this moment)

OK, thanks a lot! So now I'll just wait and see which problem(s) and/or solution(s) you will find!

[Lisias]

On 2/4/2025 at 5:18 PM, Cossus said:

OK, thanks a lot! So now I'll just wait and see which problem(s) and/or solution(s) you will find!

Well, at very least I'm pretty sure about who does not is the problem.

Ruled out a lot of add'ons, including TweakScale, Companion, Recall and all my othet jazz that I found in your Logs. At very worst, the TSCo.Frameworks was caught on a crossfire, but even that is not certain by now - whoever had dragged TSCo into the crash, could by its turn only getting caught by something else by its turn. Edit: Something is inducing SystemHeat to a bork, and then everything goes down trough the tubes due other reasons!

In a way or another, I'm zeroing gradually into the crash's cause(s). Stay tuned on the link I posted above,

Edited Wednesday at 10:17 PM by Lisias
Down trough the tubes!

[Lisias]

On 2/4/2025 at 5:18 PM, Cossus said:

OK, thanks a lot! So now I'll just wait and see which problem(s) and/or solution(s) you will find!

Just a follow up. Some add'ons you use were updated yesterday, and once I updated the test bed, the crash ceased to exist.

Something is, however, still inducing SystemHeat to kill the loading thread.

Since the landscape is now changed, I'm restarting the test session, focusing only on SystemHeat this time.

[Cossus]

5 hours ago, Lisias said:

Something is, however, still inducing SystemHeat to kill the loading thread.

Probably a noob question, but if you're using only my partial assembly, maybe it includes Kerbalism and SystemHeat, but not zKerbalismSystemHeat? Can this cause problems with loading thread (a problem which I still havent's seen on my PC)? 

UPD: I've also checked manually which of mods from my assembly have updated past few days, but without re-intstalling them, here they are:

- Cryogenic engines with all its lots of GameData folders...

- JNSQ  volumetrics

- Kerbal Joint Reinforcement

- Near Future Launch Vehicles

- Near Future Spacecraft 

- Rational Resources

Edited Thursday at 08:03 AM by Cossus

[Lisias]

15 hours ago, Cossus said:

Probably a noob question, but if you're using only my partial assembly, maybe it includes Kerbalism and SystemHeat, but not zKerbalismSystemHeat? Can this cause problems with loading thread (a problem which I still havent's seen on my PC)?

Yep! I had listed every add'on I had installed (even cooked a CKAN file to rebuild the test bed), and later listed exactly the ones I was deleting between the sessions.

But then CKAN auto-updated (or I clicked something without being aware?), the problem vanished and I wrongly concluded it was the last batch - but perhaps it was some of the still left there that got updated... And then I had to start from scratch.

But after rebuilding the test bed, the crash was no more - so the update really changed things.

From that point, Real Life™ and Day Job© conspired to keep me away from KSP, so things got behind a lot on this.

I will rest now (really need some), and I will go back to this later. The crash itself may had been solved, but something is still screwing SystemHeat's life.

https://github.com/orgs/KSP-ModularManagement/discussions/4

Edited Thursday at 10:22 PM by Lisias
Yeah, tyops... But, hey, I'm wasted today... (due RL and DJ issues!!!! :D)

[Cossus]

7 minutes ago, Lisias said:

Yep! I had listed every add'on I had installed (even cooked a CKAN file to rebuild the test bed), and later listed exactly the ones I was deleting between the sessions.

But then CKAN auto-updated (or I clicked something without being aware?), the problem vanished and I wrongly concluded it was the last batch - but perhaps it was some of the still left there that got updated... And then I had to start from scratch.

But after rebuilding the test bed, the crash wasn't no more - so the update really changed things.

From that point, Real Life™ and Day Job© conspired to keep me away from KSP, so things got behind a lot on this.

I will rest now (really need some), and I will go back to this later. The crash itself may had been solved, but something is still screwing SystemHeat's life.

https://github.com/orgs/KSP-ModularManagement/discussions/4

Lisias,

Thanks a lot for trying to solve my mods assembly problem! After some simple actions it has just vanished for me as well... I really apologize I took up so much of your time, but I think it's really unexpected for everybody who is playing KSP that the cause of the crash (which is still enigmatic for me) is somewhere out of GameData folder. What exactly I made:

0. Updated all the mods from my previous message, with no result (crash).

1. Installed a fresh vanilla game from setup files (not via simple copying, true installation) and succesfully ran it.

2. Copied the whole GameData folder (also Music and Playlists folders...) from the "crashing" copy of the game to the fresh one.

3. Succesfully launched it, changed the settings to make them like previous, exit the game, copied the folder with JNSQ save in the saves folder.

4. Succesfully launched  the game again, loaded the save, checked whether two my rovers on Mun and Minmus working allright, and whether their surrounding is eyecandy. Than switched into VAB, opened a craft with the engines (there are lots of such engines, of course...) caused initial FPS glitch, removed them and mounted again, with no FPS drops. Launched the rocket to ensure that I have beautiful Waterfall engine plumes.

5. Reloaded the game again two or three times to be sure that the crash is no more happens.

I don't know whether you want to know the root causes of this problem at all costs, but if yes, I'll keep the "crashing" copy of the game intact for some time, I may also upload any folders and/or files in it if you're interested in. I can also upload KSP log and Player log from the last succesfull launch of the game, they are unexpectedly huge, about 500 MB...

[Lisias]

3 minutes ago, Cossus said:

I can also upload KSP log and Player log from the last succesfull launch of the game, they are unexpectedly huge, about 500 MB...

What in.... Kraken's name!

Yes, zip this huge monster and publish it. There's something still fishy in your log, this is way abnormal!

 

[Cossus]

10 minutes ago, Lisias said:

What in.... Kraken's name!

Yes, zip this huge monster and publish it. There's something still fishy in your log, this is way abnormal!

 

Here it is.

[Lisias]

4 hours ago, Cossus said:

Here it is.

My fault. You don't have the KSPe.cfg in your PluginData, and so KSPe used defaults.

[LOG 00:54:15.968] [KSPe.Globals] INFO: KSPe.cfg does not exists. Using defaults.

By some reason, MM logging is defaulting to TRACE level, instead of INFO that should be the default. And TRACE is incredibly verbose (essentially, MM logs every single decision it takes while patching - there're about 3,645,852 TRACE entries in your log.

My apologies.

Copy the PluginData/KSPe.cfg from the KSPe zip package into your local <ksp-root>/PluginData , or just edit a text file with the following contents and save it there (using KSPe.cfg name, of course):

KSPe
{
	DebugMode = False
	Log
	{
		ThreadSafe = False
		LogLevel = 3
	}
	LOCAL
	{
		ModuleManager
		{
			DebugMode = False
			Log
			{
				ThreadSafe = False
				LogLevel = 3
			}
		}
		TweakScale
		{
			DebugMode = False
			Log
			{
				ThreadSafe = False
				LogLevel = 3
			}
		}
	}
}

This will shut up MM's TRACE until I fix this thing on the weekend.

https://github.com/KSP-ModularManagement/ModuleManager/issues/35

[Cossus]

2 hours ago, Lisias said:

My fault. You don't have the KSPe.cfg in your PluginData, and so KSPe used defaults.

[LOG 00:54:15.968] [KSPe.Globals] INFO: KSPe.cfg does not exists. Using defaults.

By some reason, MM logging is defaulting to TRACE level, instead of INFO that should be the default. And TRACE is incredibly verbose (essentially, MM logs every single decision it takes while patching - there're about 3,645,852 TRACE entries in your log.

Not yours, in fact. I kept in mind that KSPe is one of a few mods requiring from user some actions beyond GameData during installation, but I just wanted to keep as many folders as possible in a stock form. Now I have a fresh KSP log... and it is still huge. Despite the strings on the loading screen differ at this time, they were without ":FOR" (there is also no string from the quote above in the log). After launching the game, I also loaded the save and ensure that there is no FPS glitch while mounting certain engines in the VAB. 

[Lisias]

4 hours ago, Cossus said:

Not yours, in fact. I kept in mind that KSPe is one of a few mods requiring from user some actions beyond GameData during installation, but I just wanted to keep as many folders as possible in a stock form. Now I have a fresh KSP log... and it is still huge. Despite the strings on the loading screen differ at this time, they were without ":FOR" (there is also no string from the quote above in the log).  

MM have an interesting feature: when it loads the last successful patching from the ConfigCache, it copies the logs generated on that session to the KSP.log simulating what would happen (approximately) if the patching would had been done instead of loading from ConfigCache.

Since your last successful ConfigCache was created using TRACE, this is what will be copied into KSP.log until you regenerate the ConfigCache.

Delete the ConfigCache (on PluginData/ModuleManager)  and the new MMPatch.log will be smaller, and then future KSP boots will have it instead 

[Cossus]

2 hours ago, Lisias said:

MM have an interesting feature: when it loads the last successful patching from the ConfigCache, it copies the logs generated on that session to the KSP.log simulating what would happen (approximately) if the patching would had been done instead of loading from ConfigCache.

Since your last successful ConfigCache was created using TRACE, this is what will be copied into KSP.log until you regenerate the ConfigCache.

Delete the ConfigCache (on PluginData/ModuleManager)  and the new MMPatch.log will be smaller, and then future KSP boots will have it instead 

After deleting MMPatch in C:\GOG Games\KSP_Test\PluginData\ModuleManager, nothing has changed, and new 400 MB KSP log was recorded along with new 300 MB MMPatch, when I succesfully launched the game, loaded the save and then exit.