[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.8 - 2024-1117

[Krazy1]

Hi @Lisias I found your antics in the drag debugging log on Github quite amusing. Thanks for your efforts.

I got a binder error when loading 1.11 with TS 2.4.4.4 and other mods:

[ERR 16:04:39.270] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[ERR 16:04:39.280] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

KSP log

I quit at the main menu because I saw this error in orange when it loaded. No error when I removed TS.

[Lisias]

2 hours ago, Krazy1 said:

Hi @Lisias I found your antics in the drag debugging log on Github quite amusing. Thanks for your efforts.

Some of these days, I will start to stream these diggings. But I need to open an account on some pr0n site, because on YouTube I will be banned for sure (I swear as a pirate on a sinking ship...)

 

2 hours ago, Krazy1 said:

I got a binder error when loading 1.11 with TS 2.4.4.4 and other mods:

[ERR 16:04:39.270] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[ERR 16:04:39.280] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

 

That is not an error, or better, it's an error but on  KSP's Assembly Resolver.

Every time you ASK the Resolver for an Assembly, it prints this line if the Aseembly was not loaded yet, even if it finds it and load it later.

So what's happening is that TweakScale is asking the Assmbly Resolver if it knows about the TestFlightCore. The Resolver answer "No" to TweakScale and so TweakScale do its business without TestFlightCore. The problem is that the Loader written by Squad always prints that message when asked for an Assembly that does not exists, and not only when you try to load that absent Assembly.

And that's one of the reasons I choose to write my own Assembly Resolver on KSPe. Look on the logs KSPe spits while electively loading DLLs:

[LOG 12:30:06.329] [AddonLoader]: Instantiating addon 'Startup' from assembly 'KSPe'
[LOG 12:30:07.205] [KSPe Binder] Hooked.
[ERR 12:30:07.210] ADDON BINDER: Cannot resolve assembly: KSPe.Unity.2019

[LOG 12:30:07.212] [KSPe Binder] Looking for KSPe.Unity.2019.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.212] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.Unity.2019.dll.
[LOG 12:30:07.213] [KSPe.Unity2019] Version 2.2.2.1 /L
[ERR 12:30:07.222] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.111

[LOG 12:30:07.226] [KSPe Binder] Looking for KSPe.KSP.111.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.226] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.111.dll.
[LOG 12:30:07.227] [KSPe.KSP111] Version 2.2.2.1 /L
[ERR 12:30:07.227] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.110

[LOG 12:30:07.228] [KSPe Binder] Looking for KSPe.KSP.110.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.228] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.110.dll.
[LOG 12:30:07.229] [KSPe.KSP110] Version 2.2.2.1 /L
[ERR 12:30:07.229] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.19

[LOG 12:30:07.230] [KSPe Binder] Looking for KSPe.KSP.19.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.230] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.19.dll.
[LOG 12:30:07.231] [KSPe.KSP19] Version 2.2.2.1 /L
[ERR 12:30:07.231] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.18

[LOG 12:30:07.232] [KSPe Binder] Looking for KSPe.KSP.18.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.232] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.18.dll.
[LOG 12:30:07.232] [KSPe.KSP18] Version 2.2.2.1 /L
[ERR 12:30:07.233] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.17

Pretty cluttered, uh? Now lets edit it and get rid of the wrongly emiited errors:

[LOG 12:30:06.329] [AddonLoader]: Instantiating addon 'Startup' from assembly 'KSPe'
[LOG 12:30:07.205] [KSPe Binder] Hooked.
[LOG 12:30:07.212] [KSPe Binder] Looking for KSPe.Unity.2019.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.212] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.Unity.2019.dll.
[LOG 12:30:07.213] [KSPe.Unity2019] Version 2.2.2.1 /L
[LOG 12:30:07.226] [KSPe Binder] Looking for KSPe.KSP.111.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.226] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.111.dll.
[LOG 12:30:07.227] [KSPe.KSP111] Version 2.2.2.1 /L
[LOG 12:30:07.228] [KSPe Binder] Looking for KSPe.KSP.110.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.228] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.110.dll.
[LOG 12:30:07.229] [KSPe.KSP110] Version 2.2.2.1 /L
[LOG 12:30:07.230] [KSPe Binder] Looking for KSPe.KSP.19.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.230] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.19.dll.
[LOG 12:30:07.231] [KSPe.KSP19] Version 2.2.2.1 /L
[LOG 12:30:07.232] [KSPe Binder] Looking for KSPe.KSP.18.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData...
[LOG 12:30:07.232] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.18.dll.
[LOG 12:30:07.232] [KSPe.KSP18] Version 2.2.2.1 /L

See how things make a lot of more sense now?

The guy/gal that wrote the KSP's Assembly Resolver got a serious "brain fart"  on the job, he/she never considered the hypothesis of someone ASKING if an Assembly is loaded or not, so he/she just spit an ERROR every time someone mention an absent Assembly, no matter the caller is just asking if it exists or if it's, indeed, trying to load it.

You can safely ignore these messages. They are bogus.

(and I can only imagine the headaches a lot of add'on's authors got on this issue, it was one of my first issues on TweakScale)

Edited January 10, 2021 by Lisias
uh.. tyops! =P

[Krazy1]

27 minutes ago, Lisias said:

(I swear as a pirate on a sinking ship...)

I'd like to see this - but only because you are so surprised when everything works perfectly and you can't believe it. Maybe I can stop some swearing:

You said TestFlightCode but the log says TestFlightCore. Hope the typo was only in the forum.  

Thanks for the explanation.  Sounds like it should be a WRN not ERR.

 

[Lisias]

58 minutes ago, Krazy1 said:

I'd like to see this - but only because you are so surprised when everything works perfectly and you can't believe it.

Optimism is a luxury I can't afford on my life.  

We build software on a quicksand. Anything moves unexpectedly, and your code is swallowed down. A typo on a config, the order in which two consecutive events happens, anything like this can bork your code beautifully. (I know of disasters that happened because one part of the code assumed that Event B always come after Event A, and then after a code revision of something else, Event B came first and the FSM got into a inconsistent state and the inputs went ignored, as the breaks).

This "Jack Sparrow" way of doing things is a way to cope with frustration and stress. It works.

(and Murphy was a prophet)

 

58 minutes ago, Krazy1 said:

You said TestFlightCode but the log says TestFlightCore. Hope the typo was only in the forum.  

Yeah, it was a typo on the post only. The logs would be printing "Code" instead of "Core" if not.

I had a hell of a week, and when I get too much time under-sleeping, my dyslexia kicks in for some days.

 

58 minutes ago, Krazy1 said:

Thanks for the explanation.  Sounds like it should be a WRN not ERR.

Ideally, not even a warning IMHO. Someone asking if something exists should not had any kind of attention.

On the code in question from TweakScale:

            tfInterface = Type.GetType("TestFlightCore.TestFlightInterface, TestFlightCore", false);

The second operand, 'false', says to GetType to do not throw errors if the Assembly is not found, returning a NULL instead. So I'm aware that the Assembly may not exist, and I will handle the mishap by checking the tfInterface against null before using it:

        private void updateTestFlight()
        {
            if (null == tfInterface) return;

The GetType without the second parameter (or giving a true on it) will raise an exception with a full stack trace, so an entry on the log when someone asks if something exists appears to be useless to me.

Edited January 10, 2021 by Lisias
Tyop. yep, time to sleep.

[eberkain]

i am getting imbalanced aero surfaces that are placed with symmetry, need to do more testing, but its late and been dealing with sick kid all day. 

 

[Lisias]

9 hours ago, eberkain said:

i am getting imbalanced aero surfaces that are placed with symmetry, need to do more testing, but its late and been dealing with sick kid all day. 

 

I'm assuming you are on KSP 1.11.0 and that you scaled up the control surfaces. I made some test runs and published the results on the Issue #92 (general support issue) from TweakScale's github, but the TL;DR follows:

The behaviour exists, and it's consistent most of the time. Scaling up not always made it evident:

But scaling down made it more visible:

However, this is happening on ALL Control Surfaces, including the unscaled ones (where TweakScale disables itself to save some CPU):

Note how the Big-S Spaceplane Tail Fin is behaving differently. Exactly like the Av-R8 ones.

To be absolutely sure, I removed TweakScale and tried that same test from last image again:

Since TweakScale was removed from the installment, there's no way TweakScale could be causing this,

This probably is not even a bug, it may be something on how KSP handles the Control Surfaces - it should be handling each lifting surface independently, and so when the second Control Surface kicks in, it has way less work to do as the first one did almost all the heavy lifting. (pun not intended! )

I hope your kid gets well soon. Cheers!

Edited January 10, 2021 by Lisias
forgot something... =P

[eberkain]

Oh wow, thank you for looking into that.  You go above and beyond.  

His covid test was negative, so just got to work through whatever it is.  

 

[OnlyLightMatters]

Thanks to Tweakscale 2.4.4.x, a 10m ship with a 10m engine plate & 10m structural tube.

This a study for a Duna Lander with Kerbalism. A *lot* of parts are hidden in the structural tube. For only 4 people because of Kerbalism the kerbals need space to avoid going crazy.

 

[Krazy1]

On 1/9/2021 at 10:41 PM, Lisias said:

This probably is not even a bug, it may be something on how KSP handles the Control Surfaces

Sorry for getting off topic but did that ship pictured roll massively after the last screenshot? I always wondered why my boosters with 3 fins have a terrible yaw-roll  coupling. Most are almost impossible to do a good gravity turn. But rockets with 4 fins always have little roll coupling - so much easier to control.  I'm sure it's not just the CoM/ CoL positions. And it's not using TS.

Edited January 15, 2021 by Krazy1

[Krazy1]

On topic - with KSP 1.11 and TS 2.4.4.4, I have a big rover with four 240% TR-2L wheels.  It's awesome but it's drifting on the ground. When I load it on the launch pad and apply the brakes, the front wheels slowly turn backwards and the rear wheels turn forwards. It drifts toward the center of the runway and falls off the launch pad after a couple minutes. I saw you did some testing with Recall -Driftless and didn't recommend using it with 1.11. Is it worth trying for this?

[Lisias]

5 hours ago, Krazy1 said:

Sorry for getting off topic but did that ship pictured roll massively after the last screenshot? I always wondered why my boosters with 3 fins have a terrible yaw-roll  coupling. Most are almost impossible to do a good gravity turn. But rockets with 4 fins always have little roll coupling - so much easier to control.  I'm sure it's not just the CoM/ CoL positions. And it's not using TS.

Kinda of.

That thing behave relatively well while flying, but it was somewhat over reacting on rolling - I usually need to trim down the Authority Limit of the control surfaces at flight to cope with the flight regime at the moment.

What I think it's happening is that with radial symmetry, the code that control the control surfaces is not doing a good job on distributing the forces equally on every control surface. This is happening on odd and even number of control surfaces, but on even numbers, there's a immediate counterpart to keep things... hum... more controllable.

By some reason, the code that works fine with an even number of control surfaces is not doing a good job ob odd ones - one of the control surfaces ends up "overloaded", carrying on almost all the work - and this exacerbate a lot the authority of that control surface.

 

4 hours ago, Krazy1 said:

On topic - with KSP 1.11 and TS 2.4.4.4, I have a big rover with four 240% TR-2L wheels.  It's awesome but it's drifting on the ground. When I load it on the launch pad and apply the brakes, the front wheels slowly turn backwards and the rear wheels turn forwards. It drifts toward the center of the runway and falls off the launch pad after a couple minutes. I saw you did some testing with Recall -Driftless and didn't recommend using it with 1.11. Is it worth trying for this?

I did some tests on a light craft using the TR-2L at 240%, and it didn't drifted. However, when using time acceleration the damn thing started to jump around like a frog on a hot plate.

So I remembered when I shrunk OPT and ended up with the craft doing similar things - what I solved by turning off the Spring/Dump:Auto thingy. And this solved the problem for me.

I'm guessing that this could help you too.

I'm wondering I need to find a way to interfere with the wheels PIDs while scaling. Adjusting a PID is essentially black magic, and these numbers are highly tied to a specific situation over some assumptions. By scaling the wheels up or down, I'm guessing we break these assumptions.

[ElonsMusk]

1 hour ago, Lisias said:

.. By scaling the wheels up or down, I'm guessing we break these assumptions..

I was under the impression when you scaled wheels you only affected the collider size and not the mechanics of the wheel. I guess it's less simple than that lol.

[Lisias]

1 minute ago, ElonsMusk said:

I was under the impression when you scaled wheels you only affected the collider size and not the mechanics of the wheel. I guess it's less simple than that lol.

In the dark ages of 2.4.3.x  , yes.

But that was less than optimal - smaller wheels got incredibly strong by their size, and bigger wheels terribly weak and fragile. Scaling wheels now has a functional purpose, not only cosmetic anymore - and without nasty collateral effects!

Spoiler

 

However, there're still some work to do.

 

 

[ElonsMusk]

That is so good to know. I can make some good changes to some crafts, now. God bless the mod teams.

This has got me thinking, does % scale directly correspond to part performance? For example does a 200% engine put out 200% thrust? Or is it more complicated? I see you were testing different scale RTGs.. I've always assumed this but clearly my assumptions go out of date.

Edited January 16, 2021 by ElonsMusk
no need to double post

[AccidentalDisassembly]

23 minutes ago, ElonsMusk said:

That is so good to know. I can make some good changes to some crafts, now. God bless the mod teams.

This has got me thinking, does % scale directly correspond to part performance? For example does a 200% engine put out 200% thrust? Or is it more complicated? I see you were testing different scale RTGs.. I've always assumed this but clearly my assumptions go out of date.

If I remember correctly (you can look it up in the TS configs somewhere), 2x engine dimensions = roughly 4x the thrust but 8x the weight (thrust as a function of nozzle surface area, weight as a function of volume). However, those scaling factors might have changed since the last time I looked...

[Lisias]

18 minutes ago, ElonsMusk said:

That is so good to know. I can make some good changes to some crafts, now. God bless the mod teams.

God bless the Users - without them, developers would not have reasons to be blessed!

 

19 minutes ago, ElonsMusk said:

This has got me thinking, does % scale directly correspond to part performance? For example does a 200% engine put out 200% thrust? Or is it more complicated? I see you were testing different scale RTGs.. I've always assumed this but clearly my assumptions go out of date.

It's more complicated.

There's not a hardcoded rule for scaling things, each part can have it's own scaling receipt - but virtually all of them are classified into "categories", and the receipts are cooked for each category.

For example, the weight of most parts are scaled cubicly, but engines and crewed parts are scaled by 2.5 (yeah, fractions!) - it was realised that this scaling is kinda more related to real life.

Engines's thrust are usually scaled by 2.5 too (bigger engines has bigger moving parts, and this taxes the net result), but SRBs are scaled cubicly!!! So, SCALE THAT Clydesdale, BABY!!!

Cheers!

4 minutes ago, AccidentalDisassembly said:

If I remember correctly (you can look it up in the TS configs somewhere), 2x engine dimensions = roughly 4x the thrust but 8x the weight (thrust as a function of nozzle surface area, weight as a function of volume). However, those scaling factors might have changed since the last time I looked...

Near enough for most applications!

[JadeOfMaar]

Hey @Lisias it's about time I ask you this little question. Have you confirmed support for engines, converters and RCS with B9 switching on their inputs? Sometime this year, I'm going to really need it if it isn't there already.

[Lisias]

19 hours ago, JadeOfMaar said:

Hey @Lisias it's about time I ask you this little question. Have you confirmed support for engines, converters and RCS with B9 switching on their inputs? Sometime this year, I'm going to really need it if it isn't there already.

As long no one shoves more that one fuel switch on the same part, B9PWS is fully supported as long as I know - I have no reports of problems, at least, and my sporadic tests didn't raised any problems:

If you are unsure, build a mockup of what you are planning to do and then check if anything goes wrong - be advised that everything non-stock (or DLCs) is being gradually deprecated on TweakScale "core", with fresh support being implemented on the TweakScale Companion Program.

-- POST EDIT -- 

Talked too soon. B9PS per appears to do not be a problem, but some parts using it are triggering some NRE on TweakScale.

I will not list the problematic parts because this may be realted to some new features on KSP 1.11 that are in need to be initialised, but obviously old parts cannot initialise what they don't know that exists and KSP itself appears to fail to proper initialise some things (see KSP Recall 0.0.6.0 beta for info).

In time, this finding can be related to this problem reported early.

Edited January 17, 2021 by Lisias
Post edit

[Krazy1]

On 1/15/2021 at 6:27 AM, Lisias said:

I did some tests on a light craft using the TR-2L at 240%, and it didn't drifted. However, when using time acceleration the damn thing started to jump around like a frog on a hot plate.

Well, I tried different spring/ damper values but it didn't have a large effect. I left the springs at 1.0 and damper at 1.4 for less bouncing while driving. Higher mass to wheel size ratio is worse. The dynamics of the wheels seems good though - good job man.

The drift solution I found was Kerbalish. I used 4 hydraulic cylinders to lift the whole rover up so the wheels are off the ground.  For whatever reason, it doesn't drift when it's up  on the "stilts". It adds a little mass but I like it. I have drills on it, so it's like a real life mobile drill rig. 

 

[Snips]

hi guys

first of all many thanks @Lisias and other modders for your effort modding this game. KSP wouldn't be KSP without guys like you. So after updated KSP to version 1.11 there was this incompatibility warning regarding tweakscale and I updated it to version 2.4.4.4 after it was available in CKAN. But since then, I can't add some parts in the craft-editor to a new or existing craft. For example, I can attatch engines like "Skipper" or "Vector", but not the stock parts "Mammoth" or "BACC Thumper Solid Fuel Booster" or modding parts like the "VW-200 VASIMR".  The complete editor (VAB) stops working and I have to load a saved craft to be able to exit VAB.

If I revert to a 2.4.3.X version of tweakscale in CKAN I can use all parts but get this warning message that all craft files may be corrupted.

Here's the Player.log: https://workupload.com/file/MsJ9zmecgP4

I know there are much modds in my current game, but maybe someone have a idea.

Thanks in advance,
Snips

[Lisias]

8 hours ago, Krazy1 said:

The drift solution I found was Kerbalish. I used 4 hydraulic cylinders to lift the whole rover up so the wheels are off the ground.  For whatever reason, it doesn't drift when it's up  on the "stilts". It adds a little mass but I like it. I have drills on it, so it's like a real life mobile drill rig. 

Humm... You should not be drifting on KSP 1.11, they implemented that "anchoring" stunt exactly to prevent that.

I tried KSP Recall on KSP 1.11, but it apparently didn't made (good) differences on me - but it screwed up the "anchoring" when the craft is not visible by camera, and so I decided to withdraw Driftless from 1.11 .  I wonder if it would not make a difference here, since even the anchoring is failing on your wheels.

What is the weight of your craft? I'm trying to reproduce the problem here, but no dice .

[edit: I reproduced the problem on a 120ton rover using 240% scaled up wheels. I will give KSP Recall a try on it.]

 

3 hours ago, Snips said:

hi guys

first of all many thanks @Lisias and other modders for your effort modding this game. KSP wouldn't be KSP without guys like you. So after updated KSP to version 1.11 there was this incompatibility warning regarding tweakscale and I updated it to version 2.4.4.4 after it was available in CKAN. But since then, I can't add some parts in the craft-editor to a new or existing craft. For example, I can attatch engines like "Skipper" or "Vector", but not the stock parts "Mammoth" or "BACC Thumper Solid Fuel Booster" or modding parts like the "VW-200 VASIMR".  The complete editor (VAB) stops working and I have to load a saved craft to be able to exit VAB.

Thanks!

What you are describing happens when an exception is thrown when KSP runs the code that "attaches" a part into the vessel. Of course, this doesn't happens on a "vanilla" instalment, otherwise I would not had released the thing, what implies there's something on your rig causing it.

Since 2.4.3 works, I'm guessing it's something on the Variant support. And the parts being affected supports this thesis.

I'm investigating it.

 

3 hours ago, Snips said:

If I revert to a 2.4.3.X version of tweakscale in CKAN I can use all parts but get this warning message that all craft files may be corrupted.

At the time the latest 2.4.3.x release was issued, it was not known if KSP 1.11 would change something that could render TweakScale playing havoc on the crafts, as it did on KSP 1.9.

The bad side of TweakScale misbehaving is that things that were scaled before are bluntly descaled - or, worse, badly scaled with some non visible problems being applied to the craft - and then you save it, launch it and just then you realise the part's resources were not scaled at all. The same also happens on every living craft on the savegame you load, so this is the reason I used that scaring message on TweakScale: when things go bad, boy, they really go down through the tubes.

Nowadays it's known that KSP 1.11 didn't changed anything on TweajScale, so you can ignore the message for now.

 

-- -- -- POST EDIT -- -- --

DUDE, your player log is scattered with Exceptions. Really, there are about 3016 of them. 2727 are NullReferenceExceptions.

TweakScale is not the only victim of the problem, it's the only one suffering visible effects. It's borking while creating the internal structures needed to scale things - what implies that such data is unavailable by some reason. At the point in which TweakScale is borking, the problem is on the prefab - something on the prefab is corrupted, and TweakScale trusts that prefact is upright.

It worths to mention that KSP itself is borking due the problem:

liquidEngineMainsail.v2 added to ship - part count: 10

(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

NullReferenceException: Object reference not set to an instance of an object
  at PartModule.get_HasAdjusters () [0x00006] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
  at PartModule.Save (ConfigNode node) [0x0005c] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
  at ShipConstruct.SaveShip () [0x00949] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
  at ShipConstruction.CreateBackup (ShipConstruct ship) [0x00000] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
  at EditorLogic.SetBackup () [0x0012a] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
  at EditorLogic.<SetupFSM>b__190_29 () [0x000f2] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
  at KerbalFSM.RunEvent (KFSMEvent evt) [0x0007b] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
  at KerbalFSM.updateFSM (KFSMUpdateMode mode) [0x00080] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
  at KerbalFSM.UpdateFSM () [0x00057] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
  at EditorLogic.Update () [0x00022] in <f8bc9e2b903e48a5b248ab0083c07c62>:0
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

So, in essence, your savegames may be being silently corruped as you play, because things are borking while being saved (to a craftfile, to a savegame, you name it), and Kraken knowns what is not being saved that it should.

Without the full KSP.log I cannot further help - the KSP.log has a lot of information that is not logged on the Player.log. My best guess is a borked PartModule being shoved on some parts, as the Mainsail, and the KSP.log will tell me who is patching it, so I can try to pinpoint a suspect.

In a way or another, I would rollback to KSP 1.10.1 on your place. Whatever is borking on KSP 1.11, is borking on the worst place possible!

Edited January 17, 2021 by Lisias
POST EDIT

[FreeThinker]

@Lisias I noticed that tweakscaleconfig for ModuleCargoPart en ModuleInventoryPart partmodules  is missing in Tweakscale currently, will you add it?

Edited January 17, 2021 by FreeThinker

[Lisias]

24 minutes ago, FreeThinker said:

@Lisias I noticed that tweakscaleconfig for ModuleCargoPart en ModuleInventoryPart partmodules  is missing in Tweakscale currently, will you add it?

Yes. Work in Progress at this time. There are 2 new modules and 24 new parts I need to map and support, but since KSP 1.11 release date I only had time to work on it this weekend!

  Version   |   ReleaseDt    |  ∑Modules  | ∑AllParts  | ∑AllDeprecated |  ∑Stock  |  ∑MH   | ∑Serenity  
------------+----------------+------------+------------+----------------+----------+--------+------------
        0.22|   2013-10-16   |          31|         156|               0|       156|       0|           0
      0.23.0|   2013-12-17   |          36|         157|               0|       157|       0|           0
      0.23.5|   2014-04-01   |          37|         157|               0|       157|       0|           0
      0.24.0|   2014-07-17   |          38|         158|               0|       158|       0|           0
      0.24.1|   2014-07-24   |          38|         158|               0|       158|       0|           0
      0.24.2|   2014-07-25   |          38|         158|               0|       158|       0|           0
        0.25|   2014-10-07   |          38|         153|               0|       153|       0|           0
        0.90|   2014-12-15   |          41|         168|               0|       168|       0|           0
       1.0.0|   2015-04-27   |          69|         245|               1|       245|       0|           0
       1.0.1|   2015-05-01   |          69|         246|               1|       246|       0|           0
       1.0.2|   2015-05-01   |          69|         246|               1|       246|       0|           0
       1.0.3|   2015-06-22   |          71|         250|               1|       250|       0|           0
       1.0.4|   2015-06-23   |          71|         250|               1|       250|       0|           0
       1.0.5|   2015-11-09   |          74|         263|               1|       263|       0|           0
       1.1.0|   2016-04-18   |          80|         267|               0|       267|       0|           0
       1.1.1|   2016-04-29   |          80|         267|               0|       267|       0|           0
       1.1.2|   2016-04-30   |          80|         267|               0|       267|       0|           0
       1.1.3|   2016-06-21   |          80|         267|               0|       267|       0|           0
       1.2.0|   2016-10-11   |          89|         275|               0|       275|       0|           0
       1.2.1|   2016-11-01   |          89|         275|               0|       275|       0|           0
       1.2.2|   2016-12-06   |          89|         275|               0|       275|       0|           0
       1.3.0|   2017-05-25   |          90|         276|               0|       276|       0|           0
       1.3.1|   2017-10-05   |          90|         276|               0|       276|       0|           0
       1.4.0|   2018-03-06   |          92|         279|              12|       279|       0|           0
       1.4.1|   2018-03-13   |          94|         340|              12|       279|      61|           0
       1.4.2|   2018-03-28   |          94|         340|              12|       279|      61|           0
       1.4.3|   2018-04-27   |          94|         340|              12|       279|      61|           0
       1.4.4|   2018-06-21   |          94|         340|              12|       279|      61|           0
       1.4.5|   2018-06-26   |          94|         340|              12|       279|      61|           0
       1.5.0|   2018-10-15   |          94|         340|              19|       279|      61|           0
       1.5.1|   2018-10-17   |          94|         340|              19|       279|      61|           0
       1.6.0|   2018-12-19   |          94|         340|              27|       279|      61|           0
       1.6.1|   2019-01-09   |          94|         340|              27|       279|      61|           0
       1.7.0|   2019-04-10   |          95|         342|              19|       280|      62|           0
       1.7.1|   2019-04-30   |         106|         371|              19|       280|      62|          29
       1.7.2|   2019-06-12   |         106|         371|              19|       280|      62|          29
       1.7.3|   2019-07-11   |         107|         388|              19|       280|      62|          46
       1.8.0|   2019-10-16   |         108|         398|              20|       283|      64|          51
       1.8.1|   2019-10-29   |         108|         398|              20|       283|      64|          51
       1.9.0|   2020-02-12   |         109|         399|              22|       284|      64|          51
       1.9.1|   2020-02-27   |         109|         399|              22|       284|      64|          51
      1.10.0|   2020-07-01   |         117|         409|              22|       292|      66|          51
      1.10.1|   2020-07-28   |         117|         409|              22|       292|      66|          51
      1.11.0|   2020-12-17   |         119|         423|              24|       308|      66|          49

On a side note, or I have a bug on my "database builder", or Serenity lose 2 parts on KSP 1.11.....

 

10 hours ago, Krazy1 said:

The drift solution I found was Kerbalish. I used 4 hydraulic cylinders to lift the whole rover up so the wheels are off the ground.  For whatever reason, it doesn't drift when it's up  on the "stilts". It adds a little mass but I like it. I have drills on it, so it's like a real life mobile drill rig. 

About this drifting, I found that turning off the Spring/Damper Auto eliminated the drift on KSP 1.11 and KSP-Recall (instrumented to shove Driftless on KSP 1.11). I let the computer running with the craft sitting on the runway with brakes applied for 1:30 hours, and the craft didn't drifted a single degree. I'm repeating the test without KSP Recall to see what I get, but in a way or another, I found the root cause of your problem.

A new module for KSP Recall will be created to handle the wheels. I just need to know if Driftless helped on the issue, or it's just placebo on it.

[FreeThinker]

@Lisias What would happen if a tweakscale exponent is defined multiple times, will they overrule eachother? cause exceptions? hangs?

what happend if you tweakscale a integer field , will it round to a integer?

 

Edited January 17, 2021 by FreeThinker

[Lisias]

2 hours ago, FreeThinker said:

@Lisias What would happen if a tweakscale exponent is defined multiple times, will they overrule eachother? cause exceptions? hangs?

The last one on the GameDatabase will prevail. The ScaleExponents are stored on a dict, so any duplicate will overwrite the previous one.

You raised a very good question - such a stunt can potentially ruin the savegame - next release of TweakScale will have a Sanity Check for it!

 

2 hours ago, FreeThinker said:

what happend if you tweakscale a integer field , will it round to a integer?

The code uses introspection to check the type of the atribute being scaled, and apply the correct operation. floats are operanted with float operators, etc. It's not different from using a variable, standard C# coercion applies.

 

14 hours ago, Krazy1 said:

The drift solution I found was Kerbalish. I used 4 hydraulic cylinders to lift the whole rover up so the wheels are off the ground.  For whatever reason, it doesn't drift when it's up  on the "stilts". It adds a little mass but I like it. I have drills on it, so it's like a real life mobile drill rig. 

Still about this behaviour, follow some findings on KSP 1.11:

1) Light crafts with scale up wheels drifts a lot, unless you deactivate the Spring/Damper Auto setting.

2) Somewhat heavier crafts with scaled up wheels don't drift too much, if at all.

3) Really heavy crafts with scaled up wheels drifts heavily no matter the Spring/Damper settings.

4) Using Drifitless from KSP Recall solves the drifting in all cases, as long the Spring/Damper is deactivated. With the Spring/Damper Auto activate, there's a very tiny [the drift is proportional to the weight and/or part count!] drift even with Driftless installed. Your mileage should vary, as I'm convinced that this is related to how much the physics engine taxes the CPU - my heavier designs were yellowing the M.E.T. display all the time, so perhaps the problem could not be exactly weight, but part count.

Really heavy rovers are blowing up on launch, unless you activate the No Crash Damage cheat. Yep, you read it right, the problem is not the joints, the problem is that KSP is "crashing" the heavy crafts on the runway at launch. You can deactivate the cheat after launch, the cheat is only needed on launch.

Spawning the crafts with Vessel Mover also works, what hints me that this is not a physics engine problem, but again something not being initialised soon enough while launching crafts (the same problem with some older parts, burning up instantly - the reason for the ChillingOut module from KSP Recall 0.0.6.0 Beta).

 

Edited January 17, 2021 by Lisias
Hit "Save" too soon!