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

Lisias · March 2, 2019

14 hours ago, DylanSemrau said:

Okay cool, thanks again! Hopefully one of your theories are correct and the issue can be resolved

Well… The power shortage was done before I waked up, or it will happens later, so I got some time to play with this.

I don't have good news, however.

Module Manager is doing its job properly. It is not the source of the misbehaviour.
TweakScale is not making any mistakes at startup while handling the Prefabs. Your parts already had lost (or never earned) TweakScale's module entry by the time TweakScale has the opportunity to do something on it.

It's not good news because if I had found any problem on the mentioned artifacts, it would be something I could fix for your. Chances are that it was already fixed by now.

The curious thing is that other module I have installed as a Ghinea Pig , PartInfo, was correctly loaded and it's working as expected. So whatever prevented TweakScale to work with your part, didn't did the same to PartInfo. What, again, turns the cannons towards TweakScale somehow.

— — — — — POST EDIT — — — — —

Dude… Since i had flopped on detecting the problem, and since things still pinpoint TweakScale as the source of the problem in a way or another, I restarted the whole process of researching from scratch. It was pretty obvious I missed something.

So.. YEAH. I had missed something.

This is an excerpt from a part with TweakScale working on the MM Cache

UrlConfig
{
	name = HeatShield1
	type = PART
	parentUrl = Squad/Parts/Aero/HeatShield/HeatShield1
	PART
	{
		name = HeatShield1
		module = Part
		author = RoverDude
		rescaleFactor = 1
               
	-- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT
	}
	MODULE
	{
		name = TweakScale
		type = stack_square
		defaultScale = 1.25
	}

And this is from a part of yours:

UrlConfig
{
	name = FirstStageEngineCluster
	type = PART
	parentUrl = Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster
	PART
	{
		name = FirstStageEngineCluster
		module = Part
		author = Dylan Semrau
		rescaleFactor = 1.0
        
	-- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT

	MODULE[TweakScale]
	{
		type = stack
		defaultScale = 3.75
	}

Yeah. You got it by now. It's a patch problem. It's a <insert your favorite non-forum-compliant-adjective here> typo or something on the patch.

As soon as I stop laughing, I will check the patch again.

— — — LAUGHING MY SAS OUT — — — —

Dude, here. This patch works as expected.


@PART[FirstStageFuelTank]:NEEDS[TweakScale]
{
	MODULE
	{
		name = TweakScale
		type = stack
		defaultScale = 3.75
	}
}
@PART[FirstStageEngineCluster]:NEEDS[TweakScale]
{
	MODULE
	{
		name = TweakScale
		type = stack
		defaultScale = 3.75
	}
}

There're some improvements opportunities for Module Manager here. I would enumerate them , but currently I'm busy trying to stop laughing before my son take the phone and call that Loony Bin near home (Yes, there's a Psychiatric Hospital near where I live! )

— — —

And, yeah. This problem was solved above, on this post. But since at that time it didn't worked due the "_" and " " problem, nobody paid attention. Including me.

I think this is a good time to pay my taxes, review my credit card bills, or anything like that to break my current mood. I'm still laughing on it.

Edited March 2, 2019 by Lisias
DAMN! :D

Osumunbro · March 3, 2019

HELP!!! im getting an error with tweakscale :( after i finish building, i launch, and after a couple seconds my game crashes. then i go back to load the craft and it said there is an unknown part module 'TweakScaleDisabled' how do i fix this????

Lisias · March 3, 2019

10 hours ago, Osumunbro said:

HELP!!! im getting an error with tweakscale after i finish building, i launch, and after a couple seconds my game crashes. then i go back to load the craft and it said there is an unknown part module 'TweakScaleDisabled' how do i fix this????

You have rogue patches on your installments (unfortunately, a few on them were on default patches on TweakScale).

You can safely ignore the "TweakScaleDisabled" nodes. It's TweakScale preventing you to suffer from rogue duplicates, the real ones are preserved. So, this is not an error. It's an error being fixed.

The crash, however, is something to be investigated. Please publish your KSP.log.

pellinor · March 3, 2019

On 3/2/2019 at 3:21 AM, DylanSemrau said:

By removing "_" and " " from the part name...

I faintly remember that KSP does some automatic conversion that has caused confusion in the past. It was something along the lines of converting every "_" to "." in part names. Might also be config strings in general.

Osumunbro · March 4, 2019

8 hours ago, Lisias said:

You have rogue patches on your installments (unfortunately, a few on them were on default patches on TweakScale).

You can safely ignore the "TweakScaleDisabled" nodes. It's TweakScale preventing you to suffer from rogue duplicates, the real ones are preserved. So, this is not an error. It's an error being fixed.

The crash, however, is something to be investigated. Please publish your KSP.log.

I cant figure out how to add attachments here so this is the link to where i uploaded it on google drive. Basically what happens if i dont crash, is i get sent up into space and the whole ship just vaporizes.

Lisias · March 4, 2019

32 minutes ago, Osumunbro said:

I cant figure out how to add attachments here so this is the link to where i uploaded it on google drive. Basically what happens if i dont crash, is i get sent up into space and the whole ship just vaporizes.

Ugh. There're an awful amount of Duplicated TweakScale on your KSP.log. BDArmory and SpaceY are the preferred victims, I think. I expect this to be fixed on the next minor release, currently being worked.

(yeah. The Refactoring will be delayed. Again)

However, you stopped the log while still in Editor, so whatever it happens on launch, I didn't get it. So I still blind on the issue.

On completely unrelated subject, I found some Exceptions that need your attention. On the spoiler below to prevent cluttering the topic with unrelated data.

Spoiler

Your KSP-AVC is old, or perhaps built for the wrong KSP version. This one appears to be compiled to work on KSP 1.3.1 , but you are using 1.6.1!


[LOG 19:24:15.197] KSP-AVC -> Assembly: Z:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\KSP-AVC\KSP-AVC.dll
[LOG 19:24:15.197] KSP-AVC -> Starter was created.
[LOG 19:24:15.197] KSP-AVC -> System.MissingMethodException: Method not found: 'UnityEngine.Texture2D.LoadImage'.
  at KSP_AVC.Toolbar.ToolbarWindow.InitialiseStyles () [0x00000] in <filename unknown>:0
  at KSP_AVC.Toolbar.ToolbarWindow.Start () [0x00000] in <filename unknown>:0
[LOG 19:24:15.197] KSP-AVC -> Checking Root: Z:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData
[LOG 19:24:15.197] KSP-AVC -> CheckerProgressGui was created.
[EXC 19:24:15.277] NullReferenceException: Object reference not set to an instance of an object
        UnityEngine.GUILayoutEntry.ApplyStyleSettings (UnityEngine.GUIStyle style)
        UnityEngine.GUILayoutGroup.ApplyStyleSettings (UnityEngine.GUIStyle style)
        UnityEngine.GUILayoutEntry.set_style (UnityEngine.GUIStyle value)
        UnityEngine.GUILayoutUtility.BeginWindow (Int32 windowID, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options)
        UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, Int32 instanceID, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single

This is flooding your KSP.log with exceptions, as something that is expected to be loaded wasn't, and the code that try to use it borks relentlessly. But I don't think this is related to the crashing - it will just make the thing work fine, and make my life easier as that huge amount of Exceptions will not be there anymore next time I analyse it.

Tonka Crash · March 4, 2019

@DylanSemrau You shouldn't have spaces in the names of your parts in their. cfg file. "name = First Stage Engine Cluster" is bad. It should be "name = FirstStageEngineCluster". or "name = First_Stage_Engine_Cluster" either of these would be fine. MM is parsing the spaces out as they are loaded, but its poor form to assume this will work. I didn't know it even did this I would have expected an error. As the last couple of pages demonstrate, this can lead to confusion since the part name in the file doesn't match what MM turns it into. It doesn't matter what the .cfg is named or the directory, but even for these it is normal for mod makers to avoid spaces.

Osumunbro · March 4, 2019

20 hours ago, Lisias said:
Ugh. There're an awful amount of Duplicated TweakScale on your KSP.log. BDArmory and SpaceY are the preferred victims, I think. I expect this to be fixed on the next minor release, currently being worked.

(yeah. The Refactoring will be delayed. Again)

However, you stopped the log while still in Editor, so whatever it happens on launch, I didn't get it. So I still blind on the issue.

On completely unrelated subject, I found some Exceptions that need your attention. On the spoiler below to prevent cluttering the topic with unrelated data.
Reveal hidden contents
Your KSP-AVC is old, or perhaps built for the wrong KSP version. This one appears to be compiled to work on KSP 1.3.1 , but you are using 1.6.1!
[LOG 19:24:15.197] KSP-AVC -> Assembly: Z:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\KSP-AVC\KSP-AVC.dll
[LOG 19:24:15.197] KSP-AVC -> Starter was created.
[LOG 19:24:15.197] KSP-AVC -> System.MissingMethodException: Method not found: 'UnityEngine.Texture2D.LoadImage'.
  at KSP_AVC.Toolbar.ToolbarWindow.InitialiseStyles () [0x00000] in <filename unknown>:0
  at KSP_AVC.Toolbar.ToolbarWindow.Start () [0x00000] in <filename unknown>:0
[LOG 19:24:15.197] KSP-AVC -> Checking Root: Z:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData
[LOG 19:24:15.197] KSP-AVC -> CheckerProgressGui was created.
[EXC 19:24:15.277] NullReferenceException: Object reference not set to an instance of an object
        UnityEngine.GUILayoutEntry.ApplyStyleSettings (UnityEngine.GUIStyle style)
        UnityEngine.GUILayoutGroup.ApplyStyleSettings (UnityEngine.GUIStyle style)
        UnityEngine.GUILayoutEntry.set_style (UnityEngine.GUIStyle value)
        UnityEngine.GUILayoutUtility.BeginWindow (Int32 windowID, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options)
        UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, Int32 instanceID, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single
This is flooding your KSP.log with exceptions, as something that is expected to be loaded wasn't, and the code that try to use it borks relentlessly. But I don't think this is related to the crashing - it will just make the thing work fine, and make my life easier as that huge amount of Exceptions will not be there anymore next time I analyse it.

So if i remove BDArmory will it stop me from crashing? and KSP-AVC is only updated to 1.3.1... i wasnt able to find any newer versions of it

Lisias · March 5, 2019

8 hours ago, Osumunbro said:

So if i remove BDArmory will it stop me from crashing? and KSP-AVC is only updated to 1.3.1... i wasnt able to find any newer versions of it

What will really solve the problem is better patches. BDarmory is not the problem, rogue patches are. I'm applying some fixes on the patches on TweakScale, I expect some improvements on the current status quo.

About KSP-AVC you will find a newer version (working on recent KSP) here. It's what I'm using.

About the crashes, I need a full log with them to be sure. Bugs are social beings, they like to gather togheter.

Edited March 5, 2019 by Lisias
Hit "Save" too soon.

Lisias · March 7, 2019

News from the Front. For who is not following what I'm doing ("todo mundo menos uns 3 ou 4 gatos pingados" ), I'm hunting down and closing issues about patches for the next minor release, what I wanted to put on the wild this week but...

~~This is the problem, and it's not a unexpected one.~~

After adding ":FOR" on every patch, things works fine as much as everybody uses :AFTER , :BEFORE or :NEEDS . This will work for new patches (or for KSP installments with only Stock parts and TweakScale).

~~But older patches, now, have precedence as legacy patches are applied first by Module Manager.. And then my patches bork due other Add'On "taking over" the parts:~~

[LOG 19:19:18.920] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale]
[LOG 19:19:18.921] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale]
[LOG 19:19:18.921] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale]
[LOG 19:19:18.921] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale]
[LOG 19:19:18.929] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale]
[LOG 19:19:18.929] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale]
[LOG 19:19:18.929] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale]
[LOG 19:19:18.929] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale]

These are not parts from another Add'Ons. The parts borking are Stock ones. ~~There're random patches "taking over" the control of Stock parts, and this will break everybody once I publish this next Release that would be relying on default TweakScale behaviour.~~

~~There're no easy way out of this.~~

~~Well. Bug fixes are in hold while I enumerate the Add'On(s) that are doing this. Definitively, not fun.~~

— — — — POST EDIT — — — —

I was wrong! The problem is not with the :FOR thingy, it is with the parts themselves!! At this point, this can be even a bug on MM or in any other Add'On that mangles GameData as it appears - the problem is not deterministic anymore: the same installed Add'Ons are not causing the trouble anymore for 'reasons', and now I'm trying to make the problem happens again...

Oh, joy !

— — — — POST POST EDIT — — — —

This Kraken food freaking problem has vanished.

I, indeed, did updated some Add'Ons on the installment where that happens and had forgot about - just remembered now that I was updating some more and realized the timestamps of some directories. Duh.. Never mix fun and business, they say.

In a way or another, it was indeed a patch related problem and so, it will probably happen again. But at least, now I know in advance about the issue, so I will respond to it way faster in the future.

Edited March 20, 2019 by Lisias
tasting my own medicine :)

Lisias · March 8, 2019

I'm moving this here, as the subject is way offtopic on the original Thread, and besides not being exactly about TweakScale, it's what I had to cope on TweakScale, so it's kind of on-topic here.

— — — — — -

On 3/8/2019 at 1:04 AM, Cheif Operations Director said:

On 3/7/2019 at 10:54 PM, Lisias said:

It's not so simple "downthere" on the CPU. This subject is way off topic, so ping me here if you are interested.

Reveal hidden contents

But in a nutshell, when you try to mangle some key data from KSP kernels, you risk crashing it due mishaps - not only from you, but from anyone that tries to use the same data without being aware of each other. Two Add'Ons trying to change the mass at the same time (yeah, it happened) risk one of them getting a part with zero mass. And zero mass parts sooner or later sparks a Division by Zero exception inside the physics engine guts.

This is not exclusive for mass and TweakScale. It only happens that TweakScale is somewhat popular, so things usually blew under my bonnet.

Interesting, Maby a way to override the pervious mass? I don't know I don't code just an idea.

It's not what happens (overriding the mass), but how.

The mass must be overwritten, that's simple. But where is the mass of that part? On a data structure. Now let's suppose we have TWO different codes, running in TWO different threads willing to overwrite the same mass, or one of them willing to overwrite another datum on the same data structure. What will happens?

Nobody knows. We have a problem here called "race condition" - the result will depend of which code reaches there first, and by the nature of multi-threading and multi-processing, this is non-deterministic.

On the parts borking on TweakScale, what was happening is that on the prefab working phase (when TweakScale oversees every part instrumented by MM to guarantee the dry-mass is correctly calculated), some other Add'Ons were also mangling that data structures too (the GameData). These Add'Ons were reading the Node, creating another one with custom data, and putting it back.

Since this was happening at the same time TweakScale was doing its business, it was usual that other Add'Ons were destroying the TweakScale data after the correction (as their Node were replacing the one TweakScale fixed), and by the nature of the ConfigNode's API, absent data can be defaulted to zero.This explains why some parts had negative mass: a Zero_Mass minus Dry_Mass == -Dry_Mass.

Things get really hairy when by similar reasons we end up with Zero Mass and Zero Dry_Mass. The resulting mass is now Zero. And since in Physics a lot of formulae uses Mass on multiplies that are later used as divisor, we end up with Division by Zero exceptions everywhere on the physics and 3D engine. When such exceptions are not handled (i.e., empty try-catch, unfortunately a common practice on Add'On authoring in KSP), the data is stored as "NaN" (Not A Number), a special flag used by the math routines to flag when things goes through the tubes on the calculations, or "Inf" (Infinity), a special flag to allow some calculations to go on.

From that point on, every calculation with some variable with that flags ends themselves resulting in "Inf" or "NaN" or even another Zero, propagating the mishap to the whole memory structures. If you know anything about Bresenham or Gourad, you will start to foresee where things will end even by not understanding orbital mechanics - sooner or later, something will blow up into the Infinity (hehehe)

And it did a lot.

Edited March 20, 2019 by Lisias
tasting my own medicine :)

albany_ · March 15, 2019

Hey @Lisias -- sorry if I missed this somewhere, there's been a lot of posts with stuff I haven't fully followed -- but the mod patch issue you mentioned above, was that resolved? I'm still running into it with some of Ven's Stock Revamp parts and was hoping to find some direction on how to resolve it on my end.

To be clear, the issue I'm referring to is configs that add TweakScale modules to Squad parts that are modified/hijacked by other mods aren't working correctly in-game and reporting a null reference error.

Thanks! :)

Lisias · March 15, 2019

On 3/14/2019 at 9:46 PM, albany_ said:

Hey @Lisias -- sorry if I missed this somewhere, there's been a lot of posts with stuff I haven't fully followed -- but the mod patch issue you mentioned above, was that resolved? I'm still running into it with some of Ven's Stock Revamp parts and was hoping to find some direction on how to resolve it on my end.

To be clear, the issue I'm referring to is configs that add TweakScale modules to Squad parts that are modified/hijacked by other mods aren't working correctly in-game and reporting a null reference error.

Thanks!

Ugh. Appears to be something new. The latest TweakScale gets rid of the duplicates, so at least in theory, you are facing something new.

The newest commits (se the orthodox branch) are patches only. You can fetch them and test them on your installment and check what happens.

That weird problem I described by last just vanished. The glitch happened on my playing installment, and the dud SAS here forgot it next day and updated some Add'Ons, and now I can't reproduce it anymore.

At least this hints that by updating to the newest versions of the Add'Ons the problem goes away. but i'm unrest about it, I want to know what happened.

I would like to see your KSP.Log to compare with mine. This can help us to narrow down the glitch's source!

— — — — —

Guys, I found some Kraken Food between TweakScale and Kerbal Animation Suite.

https://github.com/net-lisias-ksp/TweakScale/issues/29

At the moment, there's no other workaround but to do not install both Add'Ons at the same time.

It's not clear if it's a TweakScale issue, KerbalAnimationSuite one, or if there's something else inducing the borking by side effect. More news on it ASAP.

Edited March 20, 2019 by Lisias
tasting my own medicine :)

albany_ · March 16, 2019

On 3/14/2019 at 8:01 PM, Lisias said:

Ugh. Appears to be something new. The latest TweakScale gets rid of the duplicates, so at least in theory, you are facing something new.

The newest commits (se the orthodox branch) are patches only. You can fetch them and test them on your installment and check what happens.

That weird problem I described by last just vanished. The glitch happened on my playing installment, and the dud SAS here forgot it next day and updated some mods, and now I can't reproduce it anymore.

At least this hints that by updating to the newest versions of the mods the problem goes away. but i'm unrest about it, I want to know what happened.

I would like to see your KSP.Log to compare with mine. This can help us to narrow down the glitch's source!

— — — — —

Guys, I found some Kraken Food between TweakScale and Kerbal Animation Suite.

https://github.com/net-lisias-ksp/TweakScale/issues/29

At the moment, there's no other workaround but to do not install both mods at the same time.

It's not clear if it's a TweakScale issue, KerbalAnimationSuite one, or if there's something else inducing the borking by side effect. More news on it ASAP.

Thanks for pointing me towards the orthodox branch. I dropped in the GameData folder from that branch and I'm still seeing this issue:

Worth noting that the "Scale - Default" option can't be changed and the Scale doesn't match stack defaults, nor does it increase TWR, mass, or cost. Full KSP.log here -- woulda used pastebin, but it was too long.

I should say, try not to take too much stock into what I described the problem's source as initially -- I don't know if that's actually the problem here, it's just what I thought was the problem based on reading posts in this thread from the last month or so.

Entirely new parts don't appear to have this problem. It doesn't seem like parts that aren't set to stack scale have this issue either, but I haven't looked closely enough to say for certain.

Let me know if there's anything else I can provide.

Edited March 16, 2019 by albany_

Lisias · March 16, 2019

13 hours ago, albany_ said:

Worth noting that the "Scale - Default" option can't be changed and the Scale doesn't match stack defaults, nor does it increase TWR, mass, or cost. Full KSP.log here -- woulda used pastebin, but it was too long.

I should say, try not to take too much stock into what I described the problem's source as initially -- I don't know if that's actually the problem here, it's just what I thought was the problem based on reading posts in this thread from the last month or so.

Let me know if there's anything else I can provide.

Your assessment of the situation was accurate. Something is, indeed, duplicating (or deleting!!!) the TweakScale node on the Spark engine.

There's something weird happening here. The internal name of the engine you used (Spark) is liquidEngineMini.v2. In my test bed, this part is working perfectly fine (ie, I can scale and use it without any new issues besides the already known ones - the plumes not scaling).

This reflects on my KSP.log (I tested it twice, with and without Making History just to be sure)

[LOG 01:08:59.178] ******* Log Initiated for Kerbal Space Program - 1.6.1.2401 (OSXPlayer) en-us *******
Kerbal Space Program - 1.6.1.2401 (OSXPlayer) en-us


OS: Mac OS X 10.12.6
CPU: Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz (4)
RAM: 16384
GPU: Intel HD Graphics 3000 OpenGL Engine (579MB)
SM: 40 (OpenGL 3.3 INTEL-10.2.37)
RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, RGB111110Float, RG32, RGBAUShort, RG16

<....>

[LOG 01:09:58.071] DragCubeSystem: Creating drag cubes for part 'liquidEngineMini.v2'
<....>
[LOG 01:10:34.416] Part found: liquidEngineMini.v2
[LOG 01:10:34.416]        Part liquidEngineMini.v2 has Module ModuleEnginesFX
[LOG 01:10:34.417]        Part liquidEngineMini.v2 has Module ModuleJettison
[LOG 01:10:34.417]        Part liquidEngineMini.v2 has Module ModuleGimbal
[LOG 01:10:34.417]        Part liquidEngineMini.v2 has Module ModuleTestSubject
[LOG 01:10:34.417]        Part liquidEngineMini.v2 has Module ModulePartVariants
[LOG 01:10:34.417]        Part liquidEngineMini.v2 has Module FXModuleAnimateThrottle
[LOG 01:10:34.417]        Part liquidEngineMini.v2 has Module TweakScale
[LOG 01:10:34.417]        Part liquidEngineMini.v2 has Module ModulePartInfo
[LOG 01:10:34.417] Part liquidEngineMini.v2 has drycost 240 with ignoreResourcesForCost False
<....>
[LOG 01:12:07.053] liquidEngineMini.v2 added to ship - part count: 3

(my DLL is the debug version, a relentless log spammer! )

But this is what I got from yours:

[LOG 21:40:06.797] DragCubeSystem: Creating drag cubes for part 'liquidEngineMini.v2'
<.....>
[WRN 21:40:23.438] [TweakScale] Removing [LOG 21:39:27.132] ******* Log Initiated for Kerbal Space Program - 1.6.1.2401 (WindowsPlayer x64) en-us *******
Kerbal Space Program - 1.6.1.2401 (WindowsPlayer x64) en-us


OS: Windows 10  (10.0.0) 64bit
CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12)
RAM: 32708
GPU: NVIDIA GeForce GTX 1080 Ti (11127MB)
SM: 30 (Direct3D 9.0c [nvldumdx.dll 25.21.14.1935])
RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, RG32
<.....>
TweakScale support for liquidEngineMini.v2.
[ERR 21:40:23.438] [TweakScale] Part liquidEngineMini.v2 didn't passed the sanity check due having a ModulePartVariants with Mass - see issue #13 https://github.com/net-lisias-ksp/TweakScale/issues/13.
<.....>
[LOG 21:40:48.730] liquidEngineMini.v2 added to ship - part count: 2
[WRN 21:40:50.841] Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TSGenericUpdater.OnRescale (ScalingFactor factor) [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.CallUpdaters () [0x00000] in <filename unknown>:0 
[WRN 21:41:36.487] Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TSGenericUpdater.OnRescale (ScalingFactor factor) [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.CallUpdaters () [0x00000] in <filename unknown>:0 
[WRN 21:41:45.804] Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TSGenericUpdater.OnRescale (ScalingFactor factor) [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.CallUpdaters () [0x00000] in <filename unknown>:0 
[LOG 21:43:03.880] deleting part liquidEngineMini.v2
[ERR 21:43:07.222] Cannot find module 'TweakScale' (-699235618)
<....>

We have the exact same KSP version, the very same TweakScale version (mine is just compiled in debug mode), and you tried the new patches on the github (that I'm using too), and yet, two completely different results.

So, or MacOS has something hidden that automatically fix things that bork on Windows :sticktongue: ,, or we have something mangling/hijacking/trolling TweakScale patches.

A quick search on your KSP reveals the there're more people besides me using the ":FOR" clausule, what's plain wrong. And since they are sorted alphabetically before TweakScale, they got applied first, rendering my patches ineffective or duplicated in second place. That can be a good explanation by the same part passing the Sanity Checks on my installment, but being refused on yours - and since the duplicates detector honors the first occurrence, deactivating the remaining ones, it ends up deactivating my patches. leading to:

The second slider doesn't works - as expected, as the duplicate detector got rid of the Module instance that would answer to it
The first sliders borking on NREs, as they are tied to the first occurrence of the TweakScale module that was not injected by my patches.

~~Again, your assessment of the situation was accurate - these parts were hijacked by rogue patches.~~ [I got the behaviour right, but pinpoint the wrong doer. This is happening at runtime!]

By morning I will generate a report from your log with all the offending patches, so we can fix your copies in situ and, if things became right, start to firing up Issues to the maintainers.

In time, "[x] Science!" is borking relentlessly on your KSP. I suggest you update it to a 1.6 compatible release, or plain delete it if such version doesn't exists. This is hurting your KSP, as it's happening on a event handler that can be aborting a chain of events:

[ERR 21:40:23.296] Exception handling event onNewGameLevelLoadRequestWasSanctionedAndActioned in class ScienceChecklistAddon:System.MissingMethodException: Method not found: 'MusicLogic.SetVolume'.
  at ScienceChecklist.ScienceChecklistAddon.onLevelWasLoaded (GameScenes action) [0x00000] in <filename unknown>:0 
  at EventData`1[GameScenes].Fire (GameScenes data) [0x00000] in <filename unknown>:0

EVE Manager is also borking, but I don't think this is anything but a annoyance by now:

[LOG 21:47:47.635] EVEManager: Issue loading ShadowManager! Error:
System.NullReferenceException: Object reference not set to an instance of an object
  at Utils.MaterialPQS.RemoveFromPQSCities () [0x00000] in <filename unknown>:0 
  at Utils.MaterialPQS.Remove () [0x00000] in <filename unknown>:0 
  at CelestialShadows.ShadowObject.Remove () [0x00000] in <filename unknown>:0 
  at EVEManager.GenericEVEManager`1[T].Clean () [0x00000] in <filename unknown>:0 
  at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 
  at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 
  at EVEManager.GenericEVEManager`1[T].Setup () [0x00000] in <filename unknown>:0 
  at CelestialShadows.ShadowManager.Setup () [0x00000] in <filename unknown>:0 
  at EVEManager.GlobalEVEManager.Setup (Boolean late) [0x00000] in <filename unknown>:0 
[LOG 21:47:47.635] [Scatterer] Celestial Body: Kerbin (CelestialBody)

Edited March 16, 2019 by Lisias

albany_ · March 16, 2019

7 minutes ago, Lisias said:

A quick search on your KSP reveals the there're more people besides me using the ":FOR" clausule, what's plain wrong. And since they are sorted alphabetically before TweakScale, they got applied first, rendering my patches ineffective or duplicated in second place. That can be a good explanation by the same part passing the Sanity Checks on my installment, but being refused on yours - and since the duplicates detector honors the first occurrence, deactivating the remaining ones, it ends up deactivating my patches. leading to:

The second slider doesn't works - as expected, as the duplicate detector got rid of the Module instance that would answer to it

The first sliders borking on NREs, as they are tied to the first occurrence of the TweakScale module that was not injected by my patches.

Again, your assessment of the situation was accurate - these parts were hijacked by rogue patches.

By morning I will generate a report from your log with all the offending patches, so we can fix your copies in situ and, if things became right, start to firing up Issues to the maintainers.

Incredible response. I'm impressed you were able to deduce so much from just a log, though I suppose that's the objective of logging.

A quick scan through my installed mods doesn't throw up any immediate red flags for conflicts -- most of them are visual/aesthetic. The outliers that could maybe be mucking things up... maybe SCANsat? I don't know, I worry more that this is a problem particular to my setup, given that a) the mods I use aren't particularly obscure or large in scale and b) I couldn't find many people posting with a similar problem. The other weird thing is that I've played KSP off and on for ages and have included pretty much the same mods every time I update and start messing around again and this is the first time I've run into any problems with TweakScale. But hey, what do I know?

I really appreciate your willingness to help me sort out this issue -- I know it's partly because there could be a bug somewhere, but still.

Quote

In time, "[x] Science!" is borking relentlessly on your KSP. I suggest you update it to a 1.6 compatible release, or plain delete it if such version doesn't exists. This is hurting your KSP, as it's happening on a event handler that can be aborting a chain of events.

Thanks for the heads up -- looks like it's being maintained again. Took a shot at seeing if it suddenly fixed the issue -- no luck, but that's probably expected.

Lisias · March 16, 2019

On 3/16/2019 at 2:07 AM, albany_ said:

Incredible response. I'm impressed you were able to deduce so much from just a log, though I suppose that's the objective of logging.

Partially due the log, partially due I'm the one that wrote some of the code - so by the log, I know what code did what. That, and some burnt skin due another problems that lead me to hunting bugs high and low, and knowing them by first name.

On 3/16/2019 at 2:07 AM, albany_ said:

I worry more that this is a problem particular to my setup, given that a) the mods I use aren't particularly obscure or large in scale and b) I couldn't find many people posting with a similar problem.

It's not a problem particular to your setup. It's a problem particular to some few Add'Ons having problem in coping with themselves. Your setup just happened to have one of the possible combinations that leads to the problem (see the chain of events below).

People were posting about worse problems (like this one - this happened to me in last October, by the way - so when this guy opened this issue, it was already fixed), that I managed to turn into less critical ones. It's better to cope with some guys complaining about missing support for some parts, then to really angry guys complaining about KSP crashes and savegames corrupted.

In time, that NREs of yours were probably saving you from a crash (the first link from the bunch above). I will end up applying yet another stunt on TweakScale2 due this.

On 3/16/2019 at 2:07 AM, albany_ said:

The other weird thing is that I've played KSP off and on for ages and have included pretty much the same mods every time I update and start messing around again and this is the first time I've run into any problems with TweakScale. But hey, what do I know?

Some glitches just became a problem recently due some internal changes on KSP and some now common practices on the Add'Ons authoring scene. It's rarely a single cause, but a chain of events that lead to such problems.

Some (and just some!) of these events are KSP changing internally - sometimes these changes break the chain (so a problem just "vanishes"), and sometimes they reinstate that chain later (so the problem "resurrects"). Some problems are only really nasty when they happens at the same time with another ones (that have their own chain of events, a few of them in common).

Reading historical commits from the Add'Ons I mangle is incredibly useful and informative on this aspect, as they give me information that explain what happens on the ones I really maintain, helping me to identify that very few links common to many chains - and by breaking that links, a lot of problems cease to be a problem and come back to be just glitches - I can fix TweakScale only, all the rest I can only workaround - so turning problems into glitches was my focus on the recent months.

Edited March 20, 2019 by Lisias
tasting my own medicine :)

pellinor · March 16, 2019

6 hours ago, Lisias said:

The second slider doesn't works - as expected, as the duplicate detector got rid of the Module instance that would answer to it

The first sliders borking on NREs, as they are tied to the first occurrence of the TweakScale module that was not injected by my patches.

Just in case you haven't ruled that out already: the two sliders can also come from the same module. Both members "tweakScale" and "tweakName" have a tweakable, and a correctly initialized TweakScale module is supposed to use one of them and hide the other.

Lisias · March 16, 2019

1 hour ago, pellinor said:

Just in case you haven't ruled that out already: the two sliders can also come from the same module. Both members "tweakScale" and "tweakName" have a tweakable, and a correctly initialized TweakScale module is supposed to use one of them and hide the other.

Thanks for the advice. This explains better what's happening now.

And gave me an idea on that new stunt of mine!

Lisias · March 16, 2019

10 hours ago, albany_ said:

I really appreciate your willingness to help me sort out this issue -- I know it's partly because there could be a bug somewhere, but still.

One little detail about community driven development: we are prone to community driven borks. And by nature of TweakScale (it mangles with everything!), it have a huge area of exposition for bugs and mishaps. It's part of the job, as it appears.

In time. Do you have Python installed? My machine is way smaller than yours, it doesn't withhold your environment, so I guess I need to try a hot patch on your machine before giving this issue as solved. Of course, use it on a copy of your installment, please. [Never mind! This specific issue is on the KSP.log of another fellow Kerbonaut, and I mistake it with yours - "working" late night is rarely the best of ideas!!]

— — — — — — —

On a side note: after reviewing the last night's job (and realizing I did part of the job on the wrong KSP.log - geriatrics, anyone?), I think that we have the prefab problem resurrected. Frankly, I was very afraid of this and I think I was in denial yesterday night, and my analysis on the wrong KSP.log was an attempt of my subconsciousness to try to avoid the subject.

There're a lot of people (including Making History) using the Main Menu as a event starter for a lot of initializations, and some of them are also mangling the GameDatabase, leading to that Race Condition thingy I mentioned above (KSP is a multithreaded game now). The non-deterministic nature of the multithreading makes this very hard to univocally detect and essentially impossible to debug, and it's way dependent of the machine's performance and load.

In a nutshell - it can borks on your machine and works fine (by plain luck) on mine. Essentially, it's a Russian Roulette.

I would be crying on my bed now if Pellinor didn't advised above - thanks (again!) dude!

My next steps is to clone and eye ball all the source code of the add'ons you use that i didn't did that yet. see which of them are mangling the GameDatabase at the same time I'm doing and try to figure out a new stunt to get out of the mess. To anyone that was around last time this happened, no, I can't do it on the Space Center Scene. The prefab data must be checked and fixed before loading a savegame, or the crafts data on your game can be corrupted (as the module data on your crafts would mismatch the prefab ones, and now KSP honor's prefab even on live crafts - my old stunts on handcrafting parts on living crafts are working different nowadays).

At the same time, I need to enhance the Sanity Checks to include the behaviours you are describing, this thing is corrupting your savagames and craft files.

Edited March 16, 2019 by Lisias
never mind. =P

albany_ · March 16, 2019

4 hours ago, Lisias said:

My next steps is to clone and eye ball all the source code of the add'ons you use that i didn't did that yet. see which of them are mangling the GameDatabase at the same time I'm doing and try to figure out a new stunt to get out of the mess.

If it would be helpful, I can make a list of the addons I'm using, or send you links to where I pulled them from, or even just zip up the whole folder (minus Squad) and shoot it your way. Just let me know.

Lisias · March 16, 2019

On 3/16/2019 at 4:36 PM, albany_ said:

If it would be helpful, I can make a list of the addons I'm using, or send you links to where I pulled them from, or even just zip up the whole folder (minus Squad) and shoot it your way. Just let me know.

Yes, please. I can gather the data from the logs, but having them already gathered with links would be a somewhat welcomed time saver.

Zipping the whole shebang would be even more helpful, but we have currently a License Hell around here, and some licenses don't allow derivatives (and your ZIP would be one). So by exchange it publicly here would be both a potential license infringement but also a Forum Policy infringement - and I prefer not to push on such things around here, we already had enough drama on the subject.

Right now, I'm playing safe and I'm implementing Yet Another Stunt on TwekScale (tm) to prevent cases like yours to go unnoticed. The sad side effect of it will be that TweakScale will be withdrawn from these parts. with the very potential breakage I had in the recent past. But since your crafts and savegames would be silently corrupted by not doing that, as now prefab also shapes the parts being loaded from living crafts, it's again a choice about loosing the battle with the lesser prejudice possible.

If I [don't] manage to cook something to cope with the (current) troublemaker, at least I will have code to detect when the next one arises. If not, what I'm doing now will be another workaround for the mean time.

Edited March 18, 2019 by Lisias
tyops as usulla… and entertaining grammars! :D

albany_ · March 16, 2019

3 minutes ago, Lisias said:

Yes, please. I can gather the data from the logs, but having them already gathered with links would be a somewhat welcomed time saver.

Sure thing!

Astronomer's Visual Pack | Latest, installed via GitHub instructions

MechJeb2 (v2.8.3) | download

MechJeb For All (v???) | download (just a config file, I can't find where I originally downloaded it from)

SCANsat (v18.10) | download

Ven's Stock Revamp (latest 1.6 branch) | download

TweakScale (latest orthodox branch) | download

AutomatedScienceSampler (v1.3.5) | download*

[x] Science Continued (v5.20) | download

*Add-on was not explicitly compiled for/released as compatible with 1.6.1, but community reports have suggested compatibility.

---

Also, here's a filelist with paths of everything in my KSP GameData folder, in case that might come in handy.

Red Stapler · March 18, 2019

I just wanted to come in here and shout out a huge thank you to Lisias for all your work, attention to detail and entertaining grammar. :cool: This thread is like reading a technical novella...rewarding and entertaining!!

Also a big thank you to the army of testers helping identify issues and keep TS as 'fresh' as possible...some of the recent gremlins you guys are dealing with are very convoluted to say the least. If I run across anything 'newish' I'll report back

I just read thru the last 10 or so pages as I'm gonna update TS tonight and hope it plays well with my plethora (said in 'The Three Amigos' movie way) of mods. Also gonna create a config for Nertea's NF Aeronautics as I didn't see those engines in the current configs included.

Anyhow, no new bugs or complaints, just a pile of thank yous!

Ok, back to the VAB with me....

Cheers!

Edited March 18, 2019 by Red Stapler

Red Stapler · March 20, 2019

Updated TS last night and all good (so far)!

Also @Lisias, I created a config for Near Future Aeronautics last night (latest v1.04), here it is in case you want to add in future like you did for Stock Alike Station Parts...

Spoiler

//Near Future Aeronautics

//ENGINES

@PART[nfa-atomic-jet-25-1] // J-N160 'Fireflash' atomic engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-atomic-multimode-25-1] // J-N500 'Project Eeloo' atomic engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-turbofan-25-1] // J-90 'Dudley' jet engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-turbofan-25-2] // J-593 'Arcadia' jet engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-turbojet-25-1] // JE-X4 'Valkyrie' jet engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-liftfan-10-1] // HVR-ONE Ultra-Heavy liftfan engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 5.0
}
}
@PART[nfa-liftfan-25-1] // HVR-THREE liftfan
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-liftfan-375-1] // HVR-TWO Heavy liftfan
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 3.75
}
}
@PART[nfa-multimodal-25-1] // AE-1 B.R.O.A.D.S.W.O.R.D. multimode engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-multimodal-25-2] // AE-2 C.U.T.L.A.S.S. multimode engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-multimodal-125-1] // AE-2B S.C.I.M.I.T.A.R. multimode engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 1.25
}
}
@PART[nfa-propfan-125-1] // AP27 'Corkscrew' prop engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 1.25
}
}
@PART[nfa-turboprop-125-1] // AP4000 "Buzzsaw" prop engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 1.25
}
}
@PART[nfa-vtol-125-1] // JL-40 'Hornet' vtol engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 1.25
}
}
@PART[nfa-vtol-0625-1] // JL-16 'Yellowjacket' vtol engine
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = stack
defaultScale = 0.625
}
}

// NACELLES

@PART[nfa-enginecooler-25-1] // Heavy Engine precooler
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-enginenacelle-25-1] // Heavy Extended Engine nacelle
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-enginenacelle-25-2] // Heavy Engine nacelle
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-enginepod-1] // Two-slot engine pod
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 1.25
}
}
@PART[nfa-enginepod-2] // Three slot engine pod
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 1.25
}
}
@PART[nfa-enginepod-large-1] // AVX-20 Heavy Engine pod
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-fueltank-25-1] // Mk2A 800X Aviation Fuel tank
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-fueltank-25-2] // Mk2A 400X Aviation Fuel tank
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-fueltank-25-3] // Mk2A 200X Aviation Fuel tank
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-fueltank-25-4] // Mk2A 100X Aviation Fuel tank
{
%MODULE[TweakScale]
{
type = stack
defaultScale = 2.5
}
}
@PART[nfa-intake-largecircular] // High-Bypass Fan intake
{
%MODULE[TweakScale]
{
type = stack_square
defaultScale = 2.5
}
}
@PART[nfa-intake-largeramp] // Advanced Ram intake
{
%MODULE[TweakScale]
{
type = stack_square
defaultScale = 2.5
}
}
@PART[nfa-intake-largeshock] // Advanced Shock intake
{
%MODULE[TweakScale]
{
type = stack_square
defaultScale = 2.5
}
}
@PART[nfa-intake-radial-1] // Heavy Ram intake
{
%MODULE[TweakScale]
{
type = stack_square
defaultScale = 2.5
}
}
@PART[nfa-intake-radial-2] // Heavy Ram intake mount
{
%MODULE[TweakScale]
{
type = stack_square
defaultScale = 1.25
}
}

// RCS

@PART[nfa-rcsblister-1] // ARV-100-8 Heavy RCS Blister
{
#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
%MODULE[TweakScale]
{
type = free
}
}

I compared vs several of the other configs in TS patches so hopefully the code is correct for engines, nacelles/intakes and RSC parts.

If any issues, let me know so I can correct and learn. I'll be testing it further tonight as well.

Thanks,

RS

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation