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

[FreeThinker]

42 minutes ago, Lisias said:

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!

 

could I use any MM check to only apply define a ScaleExponents  exponent if it isn't defined yet?

[Krazy1]

45 minutes ago, Lisias said:

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.

Where is the "dev worship" emoji? I'll give you 5 stars at least 

I was testing at 80t before (simulating ~200t on Duna) and you found 120t was drifting. I've also been experimenting and I have a very good (bad) example to share that has large and very fast oscillations of the wheels what make them look blurry. I think is the same problem I saw before but much more extreme.

big rover with vibrating wheels

It doesn't always vibrate immediately at spawn - drive a little and it should start. I guess the game engine (integrator) is unstable and it's cycling between 2 states. The wheel autostruts may be involved. I so wish the game devs wouldn't have bandaged wheel strength problems with autostruts. Yes - the "auto" setting for the spring/ damper often oscillates with big craft. I usually override it and set damper value >= spring. With this example file I turned auto off and left it default 1.0 for both. 

[Lisias]

49 minutes ago, FreeThinker said:

could I use any MM check to only apply define a ScaleExponents  exponent if it isn't defined yet?

Can't really tell. I had had problems in the past on editing root nodes using MM, and didn't found a way to workaround it and what you asks implies on creating a new root node. I didn't managed to do it (what's different of not being possible however).

It's the reason I gave up and just allowed some ScaleExponents on TweakScale Companion for Firespitter to duplicate the deprecating ones on TweakScale "core" for while - I'm going to get rid of anything non stock/DLC on the main TweakScale, and replacing them with optional Companions - what will prevent a lot of problems TweakScale had in the past to happen again.

IMHO, if you have some disagreement about how TweakScale scale things, the best line of action is to create a new ScaleExponent for you and then apply them on the parts you want it (after removing any previous TweakScale patches on that part).

I remember you asking in the past about the Converters, for example. I could not fulfil your request because that would break some assumptions that every TweakScale user have about the Converters, breaking savegames. But this doesn't means you had a bad idea, au contraire - I just could not fulfil it on the Stock TweakScale without an extended behaviour, otherwise every station already made will unexpectedly run out or resources.

And so on.

That can create some situations nearly impossible to detect without a lot of hard digging (and  lot of wasted time). But if you create your own customised Exponents and apply them using your patches, this will keep things easy to track on the MM log.

 

41 minutes ago, Krazy1 said:

Where is the "dev worship" emoji? I'll give you 5 stars at least 

 

41 minutes ago, Krazy1 said:

I was testing at 80t before (simulating ~200t on Duna) and you found 120t was drifting. I've also been experimenting and I have a very good (bad) example to share that has large and very fast oscillations of the wheels what make them look blurry. I think is the same problem I saw before but much more extreme.

big rover with vibrating wheels

I got good results with 120tons, a hacked Driftless and Wheels without auto dampers. Less than 40 to 50 tons worked well without Driftless. So what we need is somehting that would turn off the Spring/Damper Auto on rest, and restore them when moving. That made the trick for me, at least.

500 tons, however... I made a Ore Train using Serenity hinges as connectors. Even driftless didn't helped on it.  I'm trying that Ore Train on KSP 1.10.1, and is just became a fur-ball after less than an hour.

So I'm not really sure if Driftless is really helping at all on KSP 1.11 - it surely didn't helped on 1.10.1.

On the other hand, that monster didn't exploded on launch on KSP 1.10.1, so we definitively have a new misbehaviour on KSP 1.11.0 . Squad forgot some initialisation procedure for sure, probably the same procedure those absense is exploding some old parts due pornographic amounts of heat (the thing ChillingOut from Recall 0.0.6 is trying to overcome) coming from nowhere at launch.

Interesting enough, my laggy rig can be useful sometimes - I noticed that by one or two frames the craft was below the runway before exploding - I think KSP is spawning the craft on the ground level, instead of spawning it over the runway and due the extreme weight of the craft, whatever is pushing up the craft is not being able to do so fast enough....

47 minutes ago, Krazy1 said:

It doesn't always vibrate immediately at spawn - drive a little and it should start. I guess the game engine (integrator) is unstable and it's cycling between 2 states. The wheel autostruts may be involved. I so wish the game devs wouldn't have bandaged wheel strength problems with autostruts. Yes - the "auto" setting for the spring/ damper often oscillates with big craft. I usually override it and set damper value >= spring. With this example file I turned auto off and left it default 1.0 for both. 

What hints me that perhaps the problem is the CPU load. The PIDs that controls the Wheel's dampers and springs may be skipping some frames due CPU overload, and then they start to overshoot themselves.

That would explain why Driftless didn't helped at all on KSP 1.10.1, but apparently did some good on KSP 1.11 - on 1.11, Squad implemented something called "Anchoring", and Driftless may be doing some weight lifting on the problem, making things easier to that Anchoring.

[FreeThinker]

@Lisias  I guess in that case I simple make a custom class that inheit from the stock class an write a tweakscale component for custom class that, that way it should always work in my mod

[Lisias]

4 minutes ago, FreeThinker said:

@Lisias  I guess in that case I simple make a custom class that inheit from the stock class an write a tweakscale component for custom class that, that way it should always work in my mod

Now you lose me, I think I  need further information about what you need to do - otherwise I may be only making things worse...

About extending stock classes, I tried it some time ago and got some unwanted misbehaviours... Once you extend a stock Module, every single instance of the original module will be replaced by yours instead - no matter what you call it.

I was trying to extent the ModuleControlSurface (to tell you the true, I was trying to tinker with Atmospheric Autopilot that does that), don't remember the details, but let's call this new class ModuleControlSurfaceHacked.

Well, every single part on the game ended up instantiating the ModuleControlSufaceHacked, and not only the parts I created using explicitly this Module. Worst, on saving the craft (and the savegame), every part is serialized using the ModuleControlSurfaceHacked. And so you can't export crafts or remove the add'on without needing to manually edit every single craft and savegame to rename ModuleControlSurfaceHacled back to ModuleControlSurface.

I found, some time ago, a post on this forum explaining something that leaded me to conclude that in some previous KSP version (older than 1.4 for sure), you could do this stunt because KSP would load the Module by the name you used on the ConfigNode, and not by the topmost extending class. On that times, what you want to do would be safe, but nowadays, I think you are going to have more problems than the one you want so solve worths.

What I would do instead is creating a "Helper" Module that would monitor your Module of Interest and then call TweakScale to do what you need when something happens - it's essentially how I implemented support for FSBuoyance for Firespitter, and also how I implemented that fancy scaling on KIS (you can scale the number of slots, or you can scale the size of each slot).

I think this way is safer nowadays.

[Krazy1]

35 minutes ago, Lisias said:

whatever is pushing up the craft is not being able to do so fast enough....

Do you have "ease in gravity" setting on? I do. It drops the craft when it spawns. So it doesn't spawn underground but it's a shock to the craft. Like you said, I've seen  (1.9 or 1.10?) where it falls under ground when it touches down and there's a log entry that says it pushed it back up.

44 minutes ago, Lisias said:

What hints me that perhaps the problem is the CPU load.

Well the rover I just made has 14 parts and I just upgraded my PC. Green clock for sure. 

[Lisias]

20 minutes ago, Krazy1 said:

Do you have "ease in gravity" setting on? I do. It drops the craft when it spawns. So it doesn't spawn underground but it's a shock to the craft. Like you said, I've seen  (1.9 or 1.10?) where it falls under ground when it touches down and there's a log entry that says it pushed it back up.

Yes. It doesn't helps on KSP 1.11 . The craft already spawns under the runway.

Interestingly, I spawned that 500 tons rover using Vessel Mover and let it place it gently into the ground.. .Dude, that thing moved up the rover to 300 meters, and started to down it to the ground at less than 0.5M per second! It took minutes to lay the craft on the ground!

This hints me that the weight is the key. I think that something on spawning the craft is placing the rover on the PQS ground level, instead of firing a ray from the skies into the ground to find the runway collider. Then, before the physics kicks in, something else finds the nearest collider and moves the craft there - but the routine used, by some reason, uses the weight of the craft to decide the speed the thing will move into the proper place (as it happened with Vessel Mover!), and with very heavy crafts, things ends up too slow and the physics kicks before the craft is on the right place...

In time, I just checked. It's not on spawning the craft, it's on unpacking the craft! I just tricked KSP into spawning the 500tons rover (using the cheat), then I unchecked the cheat, then I moved to the Space Center. Then I moved back to the craft, and it exploded too.

Then I respawned the rover using the cheat (again), drove it to the grass (on the PQS ground level), unchecked the cheat (again) and moved to the Space Centre. Now, by going back to the rover, it didn't exploded!

So I have confirmation for my thesis - the craft is being spawned on the PQS ground level, and heavy crafts are failing to be placed over the neared collider on unpacking.

 

30 minutes ago, Krazy1 said:

Well the rover I just made has 14 parts and I just upgraded my PC. Green clock for sure. 

Well, another confirmation for the craft's weight thesis. :)

[FreeThinker]

8 hours ago, Lisias said:

Now you lose me, I think I  need further information about what you need to do - otherwise I may be only making things worse...

About extending stock classes, I tried it some time ago and got some unwanted misbehaviours... Once you extend a stock Module, every single instance of the original module will be replaced by yours instead - no matter what you call it.

I want to do this on a part that isn't introduced yet, specifical a radial inventory container and wanted to add Tweakscale so you can make it bigger or smaller when needed

Edited January 18, 2021 by FreeThinker

[Lisias]

14 hours ago, FreeThinker said:

I want to do this on a part that isn't introduced yet, specifical a radial inventory container and wanted to add Tweakscale so you can make it bigger or smaller when needed

This explains your interest on support for ModuleCargoPart and ModuleInventoryPart.

What I plan to do is to support these things the same way I did on KIS: allowing the user to choose to scale the quantity of slots, or the size of each slot (those quantity remains the same). It's essentially what I'm working on now, and I expect a new TS release (or, at least, a new 2.5 Beta with it) in a couple weeks.

But since this is not necessarily what you may want to do with your part, and since TweakScale will provide Exponents aiming to support the stunt I mentioned in the previous paragraph, there's a chance you would prefer something else.

I think that, so, the solution for you is the SCALEBEHAVIOR. Behaviours are a way to override the Exponents when needed. For example. there's a Behaviour for Engines because their weight scale at 2.5, and not 3 as (almost) all the other parts.

And since TweakScale nowadays just don't touch anything non Stock or DLC, you can rest assured that TweakScale will never touch any of your parts, so anything you do will be preserved now and in the future. Third parties, however, may be a problem on it.

In a way or another, your SCALEBEHAVIOR should be something like this:

TWEAKSCALEBEHAVIOR
{
	name = KSPIE-ModuleInventoryPart
	MODULE
	{
		name = TweakScale
		TWEAKSCALEEXPONENTS
		{
			name = ModuleInventoryPart
			InventorySlots = 3             # Use this one
			//packedVolumeLimit = 3        # OR this one. NOT BOTH!
		}
	}
}

and then

@PART[KSPIE-RadialCargoContainer]:AFTER[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[KSPIE-ModuleInventoryPart]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = free 	# for radial parts, usually free is the choice
    }
}

I agree this is a bit convoluted, but I could not think on anything so better than could worth changing years of already made patches, so...

Of course, you may want to customise the numbers above. Perhaps you would like 2.95 as the InventorySlots exponent (for any reason you could think of, as the need to cope with the extra mass needed by the extra slot's walls), or perhaps 3.1 on the packedVolumeLimit (idem). You can tinker with the mass exponent too, crewed parts on TweakScale patches has a mass exponent of 2.5.

Toy with the numbers if you are in the mood, sometimes we get results more related to real life (as someone did in the past by using 2.5 with the engines) playing "what if". (boy, I miss the times in which I could tinker with the parts by mangling the craft files, now I need to restart KSP...)

 

Edited January 19, 2021 by Lisias
DAMN, I'M AN IDIOT! I ERR ON MY OWN PATCH!! :(

[FreeThinker]

20 minutes ago, Lisias said:

TWEAKSCALEBEHAVIOR
{
	name = KSPIE-ModuleInventoryPart
	MODULE
	{
		name = TweakScale
		TWEAKSCALEEXPONENTS
		{
			name = ModuleInventoryPart
			InventorySlots = 3             # Use this one
			//packedVolumeLimit = 3        # OR this one. NOT BOTH!
		}
	}
}

 

 

Volume is obviously more important than inventoryslots, But why not Both?

Edited January 18, 2021 by FreeThinker

[FreeThinker]

Unfortunatly it doesn't seem to work

I guess I need to write a custom partmodule that implements ITweakscale

Edited January 18, 2021 by FreeThinker

[Snips]

On 1/17/2021 at 4:21 PM, Lisias said:

-- -- -- 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!

Hi

Thanks for your time investigating my problem. As you suggested, I returned to a fresh KSP 1.10.1 installation and now the "problem parts" can correctly be attatched in the editor.

Nevertheless, I get a error: fatal at startup for 60 parts, all like:

ERROR: **FATAL** Part Decoupler.1p5 (Entkoppler TD-18) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

If you have some time, here is the KSP.log:https://workupload.com/file/2ghnEapYzRq

 

Thanks a lot,
Snips

[Lisias]

1 hour ago, FreeThinker said:

Volume is obviously more important than inventoryslots, But why not Both?

Because you would ended up with 9 times more storage than the original part, not 3!

Suppose you have a container 3 meters by 3 meters, with slots with 1m³ each. So you have 9 slots, and the container has 9 m³.

By scaling the container to  twice the size, you till have a container with 6 meters by 6 meters, or 36m³. BUT, by scaling the slot's size and the quantity of slots on the container, you will end with 36 slots with 3m³ each = 108m³ - the numbers don't fit.

(unless you are a fan of Doctor Who, of course!  )

 

1 hour ago, FreeThinker said:

Unfortunatly it doesn't seem to work

I guess I need to write a custom partmodule that implements ITweakscale

Damn. Or I did something wrong on the patch, or I will have to follow suit with you and brute force my way into the problem.

I will give it a shot by the night, stay tuned!

[FreeThinker]

6 minutes ago, Lisias said:

Damn. Or I did something wrong on the patch, or I will have to follow suit with you and brute force my way into the problem.

I will give it a shot by the night, stay tuned!

Don't bother, I will custom update this. Good point about the rows of 3 rule. I will take it into account, with someyhing like

InventorySlots = System.Math.Max(3,  3 * (int)Math.Round(extInventorySlots / 3)) ;

 

[FreeThinker]

Alright, I managed to make it work

with this code:

using System;
using TweakScale;

namespace InterstellarFuelSwitch
{
    class ModuleInventoryPartController: PartModule, IRescalable<InterstellarFuelSwitch>
    {
        [KSPField] public double extInventorySlots = 9;
        [KSPField] public double extPackedVolumeLimit = 0;

        private StartState _state;

        private ModuleInventoryPart _moduleInventoryPart;

        private ModuleInventoryPart ModuleInventoryPart
        {
            get
            {
                if (_moduleInventoryPart != null)
                    return _moduleInventoryPart;

                _moduleInventoryPart = part.FindModuleImplementing<ModuleInventoryPart>();

                return _moduleInventoryPart;
            }
        }

        public override void OnStart(StartState state)
        {
            _state = state;
            base.OnStart(state);
        }

        public void OnRescale(ScalingFactor factor)
        {
            if (ModuleInventoryPart == null)
                return;

            _moduleInventoryPart.InventorySlots = Math.Max(1, 3 * (int)(extInventorySlots * factor.absolute.linear / 3));
            _moduleInventoryPart.packedVolumeLimit = (float)(extPackedVolumeLimit * factor.absolute.cubic);

            _moduleInventoryPart.OnStart(HighLogic.LoadedSceneIsEditor ? StartState.Editor : _state);
        }
    }
}

 

Edited January 18, 2021 by FreeThinker

[Lisias]

48 minutes ago, FreeThinker said:

Alright, I managed to make it work

Excellent! But so I don't understand why the patch above failed, because TS does kinda the same, but using introspection... Anyway, by night I will check this - I must had done something stupid on that patch... 

 

 

1 hour ago, Snips said:

Thanks for your time investigating my problem. As you suggested, I returned to a fresh KSP 1.10.1 installation and now the "problem parts" can correctly be attatched in the editor.

Welcome. I understand this solution is less than desirable, but there're so much time available to check and pursue every new change (and bug introduced) on each new KSP version, so Authors need some time to understand what's happening to cope with - for example, I managed to understand why some old parts are blowing up due heat on launch, but now I realised that heavy crafts are blowing up too!! (and heavy crafts are one of the reaons people use TweakScale...). All of this can easily overwhelm our free time - yet more to who works on this time of the year, as me...

I'm pretty sure these parts are suffering something near the heat problem I think I solved on KSP Recall 0.0.6 (beta!!!), so there's a good chance I can manage to cook a workaround (if someone else don't do it first!). But for now.... 

 

1 hour ago, Snips said:

Nevertheless, I get a error: fatal at startup for 60 parts, all like:

ERROR: **FATAL** Part Decoupler.1p5 (Entkoppler TD-18) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

 

Humm... When you rolled back, you did the installing one by one, or just moved the GameData's folder contents (except Squad and SquadExpansion, of course) to the 1.10.1  one? These errors should had happened on 1.11 too.

In a way or another, I found the problem - such a amount of FATALities are usually related to installing something twice on the system. Essentially what's happened on you rig:

[LOG 18:05:46.140] Config(@PART[Tube1p5]) TweakscaleMakingHistoryConfigs/Structural/@PART[Tube1p5]

TweakScaleMakingHistoryConfig was an old add'on that was retired (and I think incorporated into TweakScale - that was before my time here), and since now TweakScale is the canon patches for Making History, there's no need for this add'on anymore.

Frankly, I can tell you you don't want it, because TweakScale's patches were revamped and some little details fixed.

Remove TweakScaleMakingHistoryConfig from your GameData and everything will be fine.

In time, can you check the licensing terms of the TweakScaleMakingHistoryConfig and, if the license allows it, can you pack it and send me a copy? I can't find a pristine copy of it anywhere in the Web (it was distributed once on SpaceDock, but as I said, it was withdrawn...)

I need to check if TweakScale original MH parches came from it and, if yes, I need to proper acknowledge it - current patches are a complete rework from scratch, but until 2.4.3, that patches were the canon and I think that guy deserve the credit for the work.

Edited January 18, 2021 by Lisias
Brute force post merging

[FreeThinker]

1 hour ago, Lisias said:

Excellent! But so I don't understand why the patch above failed, because TS does kinda the same, but using introspection... Anyway, by night I will check this - I must had done something stupid on that patch... 

Instead of inheritening from ModuleInventorPart , which gave weird  GUI issues, I converted it into a controller. This will allow it to function with any ModuleInventorPart  when added to the part, which is pretty neat.

Edited January 18, 2021 by FreeThinker

[Snips]

3 hours ago, Lisias said:

Remove TweakScaleMakingHistoryConfig from your GameData and everything will be fine.

Dude, you're awsome. I removed TweakScaleMakingHistroyConfig and the error messages are gone.

3 hours ago, Lisias said:

Humm... When you rolled back, you did the installing one by one, or just moved the GameData's folder contents (except Squad and SquadExpansion, of course) to the 1.10.1  one? These errors should had happened on 1.11 too.

I completely deinstalled KSP from steam, deleted all related folders and did a fresh 1.10.1 installation. Afterwards I installed my mods via CKAN out of my local cache.

3 hours ago, Lisias said:

In time, can you check the licensing terms of the TweakScaleMakingHistoryConfig and, if the license allows it, can you pack it and send me a copy? I can't find a pristine copy of it anywhere in the Web (it was distributed once on SpaceDock, but as I said, it was withdrawn...)

The mod is unter WTFPL, so I think there is no big deal in sharing this mod: https://workupload.com/archive/96FXKhp4

Thanks a lot again,
Snips

[AccidentalDisassembly]

Threw a couple easy-to-fix issues up on the github in case you don't receive notifications for it! Some quick fixes with brackets and two duplicate patches that can be removed from squad patches (Control.cfg).

[Cochise]

I say all of this politely; writing it on here takes it out of tone: I am sorry to go against any rules or norms on here but I must say, again, how much I disagree with your choice to make the "Ok" button on "Houston we have a problem" windows automatically exit the program. It makes no sense, and a modded install takes a long time to load. It's incredibly frustrating if I, god forbid, hit the wrong button... and that button doesn't say "Exit" or "Quit" (!!!) and my game quits after all of that loading. So now I have to wait another 10 mins or whatever ridiculous amount of time it is. It's totally cool if you want to have a quit button, but at least make it acknowledge the fact that it's going to quit the program. I'm not reading that whole long thing you wrote on the pop up message window or whatever it's called.

 

And for the record.... whatever is triggering the message to begin with is not a "SHOW STOPPER PROBLEM". I've been playing with it for like a year now across multiple game versions/mod versions... so maybe take a look at that, idk, probably also my fault... but worth investigating. 

[Lisias]

4 hours ago, Cochise said:

I say all of this politely; writing it on here takes it out of tone: I am sorry to go against any rules or norms on here but I must say, again, how much I disagree with your choice to make the "Ok" button on "Houston we have a problem" windows automatically exit the program. It makes no sense, and a modded install takes a long time to load. It's incredibly frustrating if I, god forbid, hit the wrong button... and that button doesn't say "Exit" or "Quit" (!!!) and my game quits after all of that loading. So now I have to wait another 10 mins or whatever ridiculous amount of time it is. It's totally cool if you want to have a quit button, but at least make it acknowledge the fact that it's going to quit the program. I'm not reading that whole long thing you wrote on the pop up message window or whatever it's called.

I understand your objections, but this solution aims to prevent unattended people of running the game on a probable inconsistent and dangerous state.

Most people just click on the "OK" button without caring, and your description of your objections just comproves the thesis!

Yes, I want people to pesky me here in order to get rid of that FATALities, and if they choose no to do so, I need to be absolutely sure it's a conscious choice, and not some automatic reflex on clicking on "OK".

I do not want, never more, under no circumstances, to have again users here complaining because "TweakScale ruined his 3 years old savegame".

If this is so much a problem for you, I can compile for you a version without any warnings - but, by then, I will not provide support neither accept responsibilities (i.e., no bug reports) on what can happen on your rig. You will be on your own.

 

4 hours ago, Cochise said:

And for the record.... whatever is triggering the message to begin with is not a "SHOW STOPPER PROBLEM". I've been playing with it for like a year now across multiple game versions/mod versions... so maybe take a look at that, idk, probably also my fault... but worth investigating. 

Good for you, you survived the Russian Roulette. But not because the problem was imaginary, but because I (and/or Squad) cooked a lot more safeties on TweakScale (and/or KSP) that apparently is working most of the time. At least for while - anything changes, even a new mishap of mine, and weird things that was working by plain luck start to bite your SAS.

A Russian Roulette with a 100 bullets capacity on the cylinder and only one bullet on it it's still a Russian Roulette.

The name for what you want me to do is Normalization of Deviance. Sorry, I will not do it.

Again, I can compile a specialised version of TweakScale for you, without any of the peskiness you don't like as long you agree that I will not provide any kind of support for you.

Edited January 20, 2021 by Lisias
better phrasing

[Lisias]

ANNOUNCE

Release 2.4.4.5 is available for downloading, with a last minute fix.

This build fixes some embarrassing borks on the default patching. Special thanks to @AccidentalDisassemblyfor detecting them!

(this time I reacted fast!  )

See OP for download links.

This Release will be published using the following Schedule:

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

Being another important bug fix, and being it the only change from the last version, I shoved the release everywhere at once.

Edited January 20, 2021 by Lisias
Tyops

[Cochise]

16 hours ago, Lisias said:

I understand your objections, but this solution aims to prevent unattended people of running the game on a probable inconsistent and dangerous state.

Most people just click on the "OK" button without caring, and your description of your objections just comproves the thesis!

Yes, I want people to pesky me here in order to get rid of that FATALities, and if they choose no to do so, I need to be absolutely sure it's a conscious choice, and not some automatic reflex on clicking on "OK".

I do not want, never more, under no circumstances, to have again users here complaining because "TweakScale ruined his 3 years old savegame".

If this is so much a problem for you, I can compile for you a version without any warnings - but, by then, I will not provide support neither accept responsibilities (i.e., no bug reports) on what can happen on your rig. You will be on your own.

 

Good for you, you survived the Russian Roulette. But not because the problem was imaginary, but because I (and/or Squad) cooked a lot more safeties on TweakScale (and/or KSP) that apparently is working most of the time. At least for while - anything changes, even a new mishap of mine, and weird things that was working by plain luck start to bite your SAS.

A Russian Roulette with a 100 bullets capacity on the cylinder and only one bullet on it it's still a Russian Roulette.

The name for what you want me to do is Normalization of Deviance. Sorry, I will not do it.

Again, I can compile a specialised version of TweakScale for you, without any of the peskiness you don't like as long you agree that I will not provide any kind of support for you.

Thank you for offering to do that, I appreciate it, but it's not necessary. While I do still disagree with the wording on the buttons themselves, I hear your reasoning and I get it. I'll be quiet. Thanks for maintaining the mod for us. 

[viperwolf]

Thank You so much for your work Lisias!!!!!!!!

 

Can anyone tell how to add the Domelight MK1 and Spotlight mk1 to tweakscale.

Edited January 21, 2021 by viperwolf

[Lisias]

6 hours ago, viperwolf said:

Thank You so much for your work Lisias!!!!!!!!

Can anyone tell how to add the Domelight MK1 and Spotlight mk1 to tweakscale.

Welcome!

I'm working on supporting the new 1.11 parts right now, I think I will have them implemented on the weekend.

Adding support for the parts is not a big deal, but adding support for the new cargo and inventory modules is going to give me some trouble...