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

[Speadge]

hi,

so you accidently call Testflightcore in Scale.cs without checking if it is installed?

[Lisias]

On 11/3/2018 at 6:10 PM, linuxgurugamer said:

change the code, so that instead of running at the main menu, run at the space center screen.  That will hopefully avoid any other race conditions

I had cooked not only one, but TWO possible solutions. But I'll need some time to implement and test them before a proposal.

Until there, I will jump suit with you and move the thing to the Space Center. Currently, only TechTree and Physics mods are using SpaceCenter as a starting point to instrument KSP internals, so I (probably) be fine doing that.

Dude… This is going to be "interesting".  

19 hours ago, Le-chimiste said:

Hi, i am new here.

In the past we can tweak all the core parts and now only some of them, why ?

Interesting, I didn't had this problem on my games (or didn't noticed…). I'll give a look on a clean install, but I will probably need your KSP.log in order to check this. See this article for how to publish it (use github's gist or pastebin,   posting LOGs on Forum is discouraged by the Moderators - it overloads the system).

NOPS. The behaviour on my test installment is consistent.

Spoiler

For KSP 1.5.1 + MH


For KSP 1.4.5 +MH

It's an issue specific to KSP 1.5.1 and TweakScale must be updated to cope with that.

I created an issue on github, if you want to track it.

Edited November 11, 2018 by Lisias
moar info on the issue.

[Lisias]

On 11/10/2018 at 10:41 PM, Speadge said:

hi,

so you accidently call Testflightcore in Scale.cs without checking if it is installed?

Nope. The interface for the Testflightcore is loaded into a atribute called tfInterface, and before trying using it, the method aborts if the atribute is null. See lines 135 and 477 from the source.

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

— POST — EDIT — 

On the line 163, "CallUpdaters" is inside a TryCatch that logs an Exception on exceptions. CallUdaters calls updateTestFlight , the one what could be doing such a mess. So, if this code were being triggering an exception, we would had a log on it.

CallUpdaters is also called from OnTweakScaleChanged, that it's called on lines 343 and 732. No TryCatch on these calls, so a Stack Dump would happen for sure on your kSP log.

The absence of such entries on my log suggests that's TweakScale is not directly involved on the mess.

Edited February 16, 2019 by Lisias
MOAR INFO. and a delightful typo. =P

[Speadge]

4 hours ago, Lisias said:

Nope. The interface for the Testflightcore is loaded into a atribute called tfInterface, and before trying using it, the method aborts if the atribute is null. See lines 135 and 477 from the source.

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

 

leads anyway to an error in KSP log:

[ERR 01:32:32.344] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[ERR 01:32:32.353] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

 

not essential - but its an error cause it cant be loaded :-/
Do you think there might be a clean way to program around it / catch this error since it is expected?

Edited November 11, 2018 by Speadge

[Lisias]

On 11/11/2018 at 6:07 AM, Speadge said:

leads anyway to an error in KSP log:

[ERR 01:32:32.344] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[ERR 01:32:32.353] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

not essential - but its an error cause it cant be loaded :-/
Do you think there might be a clean way to program around it / catch this error since it is expected?

There're no errors about unsatisfied DLL dependencies on my TestBeds using the latest TweakScale. I would hadn't reproduced the problem from our colleague Le-chimiste if it had.

I need your KSP.log and output.txt . This is not TweakScale. Such an obvious error would be caught by my test beds, as I used an internal version of some mods that blows up everything if the DLLs are not correctly loaded making such mishap impossible to pass unnoticed.

What lead you to think it could be TweakScale? There're some stackdump mentioning it?

— POST—EDIT — 

A bit of technical background:

The log messages that start with "ADDON BINDER" happens on the early stages of KSP loading, while it loads the DLLs it found on GameData. On this stage, not a single AddOn had been instantiated yet. So, not a chance that a code would provoke it.

Later, you will find logs messages like "[AddonLoader]: Instantiating addon" . This is the phase in which some code is executed (the "Awake" method), and, so, it's where something could go wrong like this.

It's the difference between Hard Dependencies and Soft Dependencies: Hard Dependencies break on the binding phase ("ADDON BINDER"), while Soft Dependencies happens on runtime, way after the binding.

But nothing of this is related to TweakScale (this time at least!  ) because the code you pinpointed is on the "OnLoad" method of a PartModule. This is executed while loading parts - way after the "[AddonLoader]" stuff, that happens after the "ADDON BINDER" stuff.

So… You have a hard dependency problem. You (or something) installed a DLL hard bound to the TestFlightCore assembly, and there're no assembly on your GameData providing such assembly.

If you are on MacOS or Linux, you can get a listing of every DLL on your GameData using this command sequence:

cd $KSP_ROOT # $KSP_ROOT is where you installed your KSP
cd GameData
find . -name "*.dll"

This will pinpoint an eventual loose DLL forgotten somewhere on your GameData (a mistake I did once - took me some hours to diagnose).

Forget all what  I said, I managed to reproduce the problem!!!

 

Edited November 13, 2018 by Lisias
problem reproduced

[Lisias]

I managed to reproduce the problem. It's happening WAY after the loading phase. Something very different from what I used to see is happening. @Speadge, I would had detected this sooner with your KSP.og, please provide one in the next occurrence.

[LOG 00:43:35.732] PartLoader: Compiling Part 'AviationLights/Parts/lights/lightstrobe_white/lightstrobe_white'
[LOG 00:43:35.812] PartLoader: Part 'AviationLights/Parts/lights/lightstrobe_white/lightstrobe_white' has no database record. Creating.
[LOG 00:43:35.821] DragCubeSystem: Creating drag cubes for part 'lightstrobe.white'
[LOG 00:43:35.881] PartLoader: Compiling Part 'B9_Aerospace/Parts/Adapter_C125/Adapter_C125/B9_Adapter_C125'
[ERR 00:43:36.013] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[ERR 00:43:36.013] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[LOG 00:43:36.065] PartLoader: Part 'B9_Aerospace/Parts/Adapter_C125/Adapter_C125/B9_Adapter_C125' has no database record. Creating.
[LOG 00:43:36.073] DragCubeSystem: Creating drag cubes for part 'B9.Adapter.C125'
[LOG 00:43:36.136] PartLoader: Compiling Part 'B9_Aerospace/Parts/Adapter_M1/Adapter_SM1/B9_Adapter_SM1'

I don't have the slightest idea about what is happening here! Apparently B9_Adapter_C125 was instrumented by someone to have a MODULE entry with direct or indirect hard dependency to TestFlightCore. This part has no MODULE on the config file, so it's something being done by someone else.

And this appears to be happening on PartLoading, so, yeah, it's plausible that TweakScale would being fooled into believing that TestFlightCore is installed - but I think that TweakScale is trying to use someone else that have this hard dependency. TweakScale only tries to use TestFlightCore if it find that Interface on the system.

Problem is… I don't remember when and what I updated my "production" (heavily modded) KSP on the last days, so I don't have a starting point to start the investigation. This is going to took some time.

And again, I don't see how one of these two statements:

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

bool valueAdded = (bool)tfInterface.InvokeMember("AddInteropValue", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static, null, null, new System.Object[] { part, name, value, owner });

would trigger a "[ADDON BINDER]" error event (unless this is not an error, but a warning misnamed). TweakScale is dealing with Reflection, would this code being run, the message would be about "method not found", 'invalid call" or something like this.

And here, the Microsoft API Documentation where one can check what I'm saying:

https://docs.microsoft.com/en-us/dotnet/api/system.type.gettype?view=netframework-3.5#System_Type_GetType_System_String_System_Boolean_

https://docs.microsoft.com/en-us/dotnet/api/system.type.invokemember?view=netframework-3.5

Edited November 13, 2018 by Lisias
updated URLs for 3.5 version

[Speadge]

2 hours ago, Lisias said:

I managed to reproduce the problem. It's happening WAY after the loading phase. Something very different from what I used to see is happening. @Speadge, I would had detected this sooner with your KSP.og, please provide one in the next occurrence.

Sorry, didnt plan to file a bug-report. Just wanted to ask if this is intentional / could be avoided.

Actually the error happens for me while loadingphase.
I had set up a debug-install for finding the cause of stuttering in my addon-heavy game.

So i started with tweakscale - and already had this issue, which cause me asking you about it.
I thought there might be a way to check for testflight before referencing it...

 

KSP.log

https://pastebin.com/SxUdF49Q

edit: my assumption was, that it is cause by this section in the code:

Line 126:

Spoiler

protected virtual void SetupPrefab()

{

ConfigNode PartNode = GameDatabase.Instance.GetConfigs("PART").FirstOrDefault(c => c.name.Replace('_', '.') == part.name).config;

ConfigNode ModuleNode = PartNode.GetNodes("MODULE").FirstOrDefault(n => n.GetValue("name") == moduleName);

ScaleType = new ScaleType(ModuleNode);

SetupFromConfig(ScaleType);

tweakScale = currentScale = defaultScale;

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

} 

or

Line 475:

Spoiler

private void updateTestFlight()

{

if (null == tfInterface) return;

BindingFlags tBindingFlags = BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static;

string name = "scale";

string value = ScalingFactor.absolute.linear.ToString();

string owner = "TweakScale";

bool valueAdded = (bool)tfInterface.InvokeMember("AddInteropValue", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static, null, null, new System.Object[] { part, name, value, owner });

Debug.Log("[TweakScale] TF: valueAdded=" + valueAdded + ", value=" + value.ToString());

}

i didnt dug into this to get behind the code - so i might be totally wrong here
but since you are not using "testflightcore" somewhere else and referencing to a class here, not just a method....

Edited November 13, 2018 by Speadge

[Lisias]

On 11/13/2018 at 2:09 PM, Speadge said:

Sorry, didnt plan to file a bug-report. Just wanted to ask if this is intentional / could be avoided.

Too late!  

It's a bug. I don't know where, but it's a bug. And I have a policy of ZERO unknown bugs on my project. I can withhold known bugs - sometimes, it's cheaper (or even the only option) to learn how to live with a bug - but we need to known the Kraken damned bug!  

On 11/13/2018 at 2:09 PM, Speadge said:

 

i didnt dug into this to get behind the code - so i might be totally wrong here
but since you are not using "testflightcore" somewhere else and referencing to a class here, not just a method....

I asked because in the (very likely event) the problem is not fixable by TweakScale, whatever I do will probably break again in the future, and knowing what leaded you to TweakScale will allow me to document the problem there, so the next fellow will diagnose the problem sooner. Perhaps TweakScale is not part of the problem, but it costs very little to be part of the solution (once I find one).  

In time, you did OK.

I'm a professional developer, I do this for living and have some background experience in big corporations. Sometimes, I forget I'm not working on a corporation anymore, and switch to "corporate mode" without being aware: one can think I'm annoyed or grumpy about the issue, but it's just how we "talk" on corporates: the minimum necessary, with objective questions and short answers - the less you talk, the less you have to explain later if something goes not exactly as it should.  

Your report is welcome. It's a bug, and it should be handled.   

Edited February 16, 2019 by Lisias
tyops as usulla...

[Lisias]

in time, please leave de log only for some days - I will have time to investigate this in two or three days.

[Speadge]

2 minutes ago, Lisias said:

in time, please leave de log only for some days - I will have time to investigate this in two or three days.

cant you reproduce it with a clean install? (+tweakscale)

Edited November 13, 2018 by Speadge

[Lisias]

1 minute ago, Speadge said:

cant you reproduce it with a clean install?

I will check tonight. I hope I don't, or I will have to cook up some new tools to help me on the smoke-tests I do once a build it done.

Currently, I "grep" for "[TwekScale]" looking for anomalies and/or idiosyncrasies and play a bit with some crafts designed specifically to test some internals. I never considered a [ADDON BINDER] error could happen later, after the game boots - it is (or was) my understanding that KSP scans and loads all add-on's DLL it finds on GameData on launch, and your report implies I was wrong on it.

[Lisias]

I killed some job time (don't tell my boss!) and… YES. This happens on a nearly clean GameData on KSP 1.4.5 + MH. Other versions at time allows.

Spoiler

************************************************************************

Environment Info
Unix 7FFFFFFFFFFFFFFF  Args: KSP

Mod DLLs found:
Stock assembly: Assembly-CSharp v0.0.0.0
KSPe v2.1.0.0
ModuleManager v3.1.1.1
ClickThroughBlocker v0.1.6.7 / v1.0.0.0
KSPAPIExtensions v2.1.0.0
Toolbar v1.7.17.12
ToolbarControl v0.1.6.16
Stock assembly: KSPSteamCtrlr v0.0.1.35
Scale v2.4.0.4
Scale_Redist v1.0.0.0 / v2.4.0.4

Folders and files in GameData:
000_ClickThroughBlocker
000_KSPAPIExtensions
000_Toolbar
001_ToolbarControl
Stock folder: Squad

Stock folder: SquadExpansion

TweakScale
Stock file: .DS_Store

000_KSPe.dll
ModuleManager.CHANGE_LOG.md
ModuleManager.LICENSE
ModuleManager.README.md
ModuleManager.dll
ModuleManager.version

************************************************************************

[A REALLY BIG CUT]

[LOG 19:23:46.671] Resource Ore added to database
[LOG 19:23:46.671] Resource Ablator added to database
[LOG 19:23:46.671] [ModuleManager] INFO: Reloading Trait configs
[LOG 19:23:46.672] [ModuleManager] INFO: Reloading Part Upgrades
[LOG 19:23:46.770] [ModuleManager] INFO: Ran in 13.774s
[LOG 19:23:46.968] PartLoader: Creating part database
[LOG 19:23:46.971] PartLoader: Compiling Part 'Squad/Parts/Aero/HeatShield/HeatShield0/HeatShield0'
[LOG 19:23:46.996] EffectList: Created 14 effect types
[ERR 19:23:47.085] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[ERR 19:23:47.085] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[LOG 19:23:47.115] PartLoader: Part 'Squad/Parts/Aero/HeatShield/HeatShield0/HeatShield0' has no database record. Creating.
[LOG 19:23:47.157] DragCubeSystem: Creating drag cubes for part 'HeatShield0'
[LOG 19:23:47.298] PartLoader: Compiling Part 'Squad/Parts/Aero/HeatShield/HeatShield1/HeatShield1'
[LOG 19:23:47.333] PartLoader: Part 'Squad/Parts/Aero/HeatShield/HeatShield1/HeatShield1' has no database record. Creating.

Some other mods mentioned on the log to help me contextualize the problem.

So, yeah. I need new custom toys on my toolchain. TweakScale is the only one mentioning TestFlightCore right now, and the phase of the KSP bootup in which this happens is compatible with the code in which TweakScale probes TestFlightCore  - on loading parts (note the parts database on the log!).

So, yeah. You are right. Not knowing how (allegedly) KSP works internally didn't prevented you from looking on the right place, as it happened to me. Thanks.

At the moment I don't think I can do anything about. Theoretically, TweakScale is doing everything by the book - it is asking to the runtime "Hey, did you have an Assembly around called "TestFlightCore"? If yes, give me a pointer to that "TestFlightCore.TestFlightInterface" thingy, please". The absence of a Warning and/or stackdumps from TweakScale indicates that the updateTestFlight method isn't, indeed, running so no harm is being done.

I think that the "error" itself is an error. It should be a Warning. Im also puzzled by the reason it's happening twice.   

[Speadge]

2 hours ago, Lisias said:

I killed some job time (don't tell my boss!) [...]

have to set priorities in live

 

actually, in my log was a significant time gap between the two errors:

[ERR 17:06:44.878] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

 

[ERR 17:06:44.887] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

might indicate its kinda loop or sth processed here,  not JUST this code processed once that generates two errors!?

 

---
Edit:

since we are already talking - is it a good timing to suggest some default TS patches for "StockalikeStationParts"?

Spoiler

SCALETYPE
{
    name = SSPXR_stack25
    freeScale = true
    defaultScale = 1.25
    suffix = m
    scaleFactors   = 0.625,     1.25,     1.875,  2.5,      3.75,     5.0, 7.5, 10
    incrementSlide = 0.0625,     0.0625, 0.025,     0.125,     0.125,     0.1, 0.25
    TWEAKSCALEEXPONENTS { mass = 2.5 }
}
SCALETYPE
{
    name = SSPXR_stack
    freeScale = true
    defaultScale = 1.25
    suffix = m
    scaleFactors   = 0.625,     1.25,     1.875,  2.5,      3.75,     5.0, 7.5, 10
    incrementSlide = 0.0625,     0.0625, 0.025,     0.125,     0.125,     0.1, 0.25
}
SCALETYPE
{
    name = SSPXR_surface
    freeScale = true
    defaultScale = 1.0
    scaleFactors   = 0.5,    0.75,    1.0,    1.25,    1.5
    incrementSlide = 0.05,    0.05,    0.05,    0.05
    suffix = x
}
@PART[sspx-adjusting-base-25-1,sspx-adjusting-base-cradle-25-1]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = SSPXR_stack25
        %defaultScale = 2.5
    }
}
@PART[sspx-adjusting-base-375-1,sspx-adjusting-base-cradle-375-1]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = SSPXR_stack25
        %defaultScale = 3.75
    }
}
@PART[sspx-adjusting-base-125-1,sspx-adjusting-base-cradle-125-1]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = SSPXR_stack25
        %defaultScale = 1.25
    }
}
@PART[sspx-cargo-container-25*]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = SSPXR_stack
        %defaultScale = 2.5
    }
}
@PART[sspx-cargo-container-375*]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = SSPXR_stack
        %defaultScale = 3.75
    }
}
@PART[sspx-cargo-container-radial*]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = SSPXR_surface
    }
}
@PART[sspx-adapter-125-25*|sspx-cargo-25*|sspx-attach-25*|sspx-hub-25*|sspx-tube-25*]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = SSPXR_stack25
        %defaultScale = 2.5
    }
}
@PART[sspx-adapter-0625-125*|sspx-attach-125*|sspx-cargo-125*|sspx-hub-125*|sspx-tube-125*]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = SSPXR_stack25
        %defaultScale = 1.25
    }
}
@PART[sspx-adapter-25-375*|sspx-attach-375*|sspx-tube-375*]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = SSPXR_stack25
        %defaultScale = 3.75
    }
}

 

Edited November 13, 2018 by Speadge

[AccidentalDisassembly]

Quick question about Firespitter's buoyancy feature: I can't seem to make it function properly. With default install of TweakScale, plus SXT (which contains parts that use FSBuoyancy, like the airplane floats or the crash pad bag things), scaling parts with FSBuoyancy up and down creates weird numbers. Example:

This is the part unmodified (defaultScale was set to 1.25 because of an error in the TS patch in SXT, but shouldn't matter) - the max floatBuoyancy is 50:

This is the part scaled up to 2.0x - note the mysterious new value for floatBuoyancy, which does not persist when launching the craft. Upon launching, right clicking on the part reveals floatBuoyancy maxed out at 102.4 or so, but adjusting floatBuoyancy changes the range back to 0-50.

Then, this is the part scaled back down to 1.0x - the floatBuoyancy is now more than it was at 1.25x, for some reason:

Finally, here is the part scaled BACK up to 2.0 after the previous step where I scaled it down to 1.0 - new value for floatBuoyancy again:

 

The module looks like this in part files (well, similar anyhoo):

MODULE
    {
        name = FSbuoyancy
        waterImpactTolerance = 250 // 50
        dragInWater = 2
        buoyancyForce = 10.0
        splashFXEnabled = False // added
    }

I tried to fix this issue by doing the following, but it did not work:

TWEAKSCALEEXPONENTS
{
    name = FSbuoyancy
    buoyancyForce = 3
}

 

Any idea what's going on here?

Edited November 16, 2018 by AccidentalDisassembly

[Lisias]

On 11/13/2018 at 8:01 PM, Speadge said:

actually, in my log was a significant time gap between the two errors:

[ERR 17:06:44.878] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[ERR 17:06:44.887] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

might indicate its kinda loop or sth processed here,  not JUST this code processed once that generates two errors!?

10 milliseconds is barely the minimum time the Thread.sleep can delay a thread on Windows, AFAIK.

On a C++ it's a huge time lapse. On CSharp, not that much.

Since this code is run on the "OnLoad" event of a Part, and since This happens by merely installing TweakScale on a plain vanilla installment, that would imply that KSP load Parts in more than one thread - so we would have concurrency. The variable that controls the presence of that interface is a static one - so the value is the same for every Part that instantiates this code - so, se second part would trigger the same code before the first part had time to reach that code. By the time the third (concurrent or not) part loading reaches this code, by some reason this would not happen anymore. 

But all the evidences I have says that parts are loaded sequentially in a single thread on KSP load time. More interestingly, on my machine both logs happens at the exact same time:

[ERR 18:53:24.524] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

[ERR 18:53:24.524] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

And there're a huge time between loading two parts on the same machine (on the same run I extracted the previous log):

[LOG 18:53:04.877] PartLoader: Compiling Part 'AirplanePlus/Parts/Aero/fixedwings/modelwarhawkfin/warhawkfin'
[LOG 18:53:04.906] PartLoader: Part 'AirplanePlus/Parts/Aero/fixedwings/modelwarhawkfin/warhawkfin' has no database record. Creating.
[LOG 18:53:04.912] DragCubeSystem: Creating drag cubes for part 'warhawkfin'
[LOG 18:53:05.090] PartLoader: Compiling Part 'AirplanePlus/Parts/Aero/flaps/doublefowlerflap/doublefowlerflap'

See that it takes at least 30 milliseconds between the "compiling part" and "no database record".

My guess is that this entry ("ADDON BINDER") is being issued two times on the same occurrence on the first run, and then being suppressed on the second and beyound. Your time can had happened by switching context between KSP and some other background process on your machine on a tight memory constrained box. But… This is a guess too.

On 11/13/2018 at 8:01 PM, Speadge said:

since we are already talking - is it a good timing to suggest some default TS patches for "StockalikeStationParts"?

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

 

[Lisias]

2 hours ago, AccidentalDisassembly said:

Quick question about Firespitter's buoyancy feature: I can't seem to make it function properly. [cut by Lisias]

Any idea what's going on here?

It works for me!!!

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

 

Edited November 17, 2018 by Lisias
moar pics!

[AccidentalDisassembly]

29 minutes ago, Lisias said:

It works for me!!!

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

 

But in the second picture, the zero setting on the floatBuoyancy of the left-hand part is 25.4016... Drag the slider up; what's the maximum? It looks like it's not working correctly, at least. Did you launch and see what happens there, too?

Edited November 17, 2018 by AccidentalDisassembly

[Lisias]

15 minutes ago, AccidentalDisassembly said:

But in the second picture, the zero setting on the floatBuoyancy of the left-hand part is 25.4016...

It's not zero. The current value is too small for the scale bar to render it as it has a "snap" value, and the computed value was below the first snap point....

Hummmm....

It deserves a second test run. I will do it in the morning.

NOW I understood what you mean.

Edited November 17, 2018 by Lisias

[Speadge]

12 hours ago, Lisias said:

My guess is that this entry ("ADDON BINDER") is being issued two times on the same occurrence on the first run, and then being suppressed on the second and beyound. Your time can had happened by switching context between KSP and some other background process on your machine on a tight memory constrained box. But… This is a guess too.

well, ksp uses > 20gb ram on my machine, but not at this time of the startup.
Context switching is not the cause - it happens on each boot.

the 10ms gap showed me, that it might NOT be happenig in one loop, but 2 independent one - but just a guess as well.
But if its only me experiencing this, dont bother about it! I thought i was just the only one the stumpled over it

[Lisias]

3 hours ago, Speadge said:

well, ksp uses > 20gb ram on my machine, but not at this time of the startup.
Context switching is not the cause - it happens on each boot.

It's a somewhat juicy machine this if yours!  (check it on the logs!)

 

3 hours ago, Speadge said:

the 10ms gap showed me, that it might NOT be happenig in one loop, but 2 independent one - but just a guess as well.
But if its only me experiencing this, dont bother about it! I thought i was just the only one the stumpled over it

It was what I was considering, until that log message with both in the very same millisecond. Not exactly due this being an "evidence" (it's not), but due the incredible amount of "luck" to such thing to happen on the environment I'm using it.

By the lessons learnt on recent (unhappy) events on my MacOS, I learnt that your time gap is, probably, due switching context or any other O.S. locking up due external causes. But… It's just another probability.  

I found this interesting, as if you are right (and you still might), that would imply on possible Race Conditions on loading time - with all that nasty known effects. But without more information, I tend to invest my time on the issues I already have under my nose (and they are smelly ones!!).

If you find something new on the issue, kick me here.

Edited November 17, 2018 by Lisias
ARRRGH!!! I'm twisting word!!! =P

[Lisias]

16 hours ago, AccidentalDisassembly said:

Any idea what's going on here?

Nope. But at least I could confirm the behaviour. Testing things late Friday is not a good idea.  

Something is messed up, indeed. I'll be working on it soon.

[Space Scumbag]

Just noticed your new thread. Good luck on your new work. This is one of my favoritve mods!

[AccidentalDisassembly]

On 11/17/2018 at 10:06 AM, Lisias said:

Nope. But at least I could confirm the behaviour. Testing things late Friday is not a good idea.  

Something is messed up, indeed. I'll be working on it soon.

I'm just happy to know I'm not a loony.

[Lisias]

On 11/19/2018 at 1:35 AM, AccidentalDisassembly said:

I'm just happy to know I'm not a loony.

Dude. You are chatting with a bunch of naked monkeys that enjoy wasting time watching green little men/gals being exploded on half baked rockets flying on a 1/10th scale simulated solar system using physics that are not like anything in real world.

This is a bin. We are the loonies on the bin.

[etmoonshade]

Random question:

How do I interpret how TweakScale scales things? I see "ScaleExponents.cfg," but I'm not sure what formula said exponents would go into.

In this specific case, I'm looking at reaction wheels. I see the following:

TWEAKSCALEEXPONENTS
{
    name = ModuleReactionWheel
    PitchTorque = 3
    YawTorque = 3
    RollTorque = 3
    inputResources
    {
        rate = 3
    }
}

Does this mean that for every doubling in size, it's multiplied by three? Or is it cubed? Or is it for some other step in size?