[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.6 - 2024-0921

[ColdJ]

2 hours ago, Lisias said:

It only throws the exception when the current crew size is bigger than the prefab

Could you expand this explanation please. I am uncertain by what you mean by prefab?

 

[Lisias]

2 hours ago, ColdJ said:

Could you expand this explanation please. I am uncertain by what you mean by prefab?

This is going to be somewhat dense and technical, so I suggest to anyone reading this to grab some popcorns.

That's the history: OOP may be messy sometimes, but it's still to this moment one of the best approaches for controlling complexity - and a Game Engine is anything but simple. But OOP has a drawback (there's no free lunch, the complexity always "leaks" to somewhere else), OOP makes the initialisation and the deinitialisation way too CPU intensive. Objects has a thing called Constructor, and the runtime call this Constructor every time you say "new" to a class. And once the system became more complex, you have Objects inside Objects inside Objects in many, many levels - and each one of them needs to have the Constructor called when the Top Cat, I mean, the Top Object is instantiated (the technical term for what happens when you do a "new" to a class).

Once an object dies, the runtime does the same, but calling the Destructors this time. And again we have lots and lots of CPU time being used on cascading calls. On C# things are yet a bit more messy because you don't "kill" objects, you abandon them until the Garbage Collector realises there's an abandoned object lingering around and goes for it to free the memory.

Unity choose a different approach for this problem: realising that most objects are initialised to a same state (i.e., have the same initial values once instantiated), they choose to "run the Constructors" on building time only once (instead of every time the Object is created) and save the state on a blob, that so would be injected inside a "fast track constructed" object. A memcpy is way faster than a lot of calls doing settings and gettings scattered on the heap.

Obviously, this also has a cost: these Fast Track objects can only have a "default constructor" (i.e., the Constructor must not have any parameters), as a Constructor with parameters will create at runtime a State that it's impossible to precompile at building time (you would need a blob for every possible values - or combinations of values - of the parameters of the Constructor!).

The collection of every premade blob for every Game Object is called the prefabs - pre-fabricated objects. And this makes loading and initialising things a lot faster (as long you obey by the rules).

And this is where things get interesting on KSP - Since the very first release, KSP was fiercely intended to be modded. And Fiercely is the keywork here - every single measure or idea that could improve moddability was tested and some were implemented. One thing that makes harder to mod a game is… the prefab!! How to safely mod a part, if their data is carved on stone on the prefab? And how to mod a modded part without screwing up everything? Just imagine two guys trying to change a part at runtime at the same time, one undoing what the other did...

Yep. Terribly messy.

And so the KSP's creator decided to wave a bit the speed of the prefabs (remember, there's no free lunch - and you can't have the cake and eat it too!) by waving building the prefab at the game's building time, to create the prefabs on loading time! Every time you boot up KSP, instead of reading a giant blob full of prefabs, KSP loads its essential bundles (with some prefabs already premade) and then go hunt for Config Files on the file system. These config files are then "compiled" and used to create the prefab of the parts of the game.

Once the game is loaded, Game Objects are "cloned" (as instantiate is not the correct term anymore) using these prefabs built at load time. And this is the reason KSP is so moddable - you don't need to decompile the prefab of a part, change the values you want, recompile and then replace somehow the original blob with yours (and then hope for nobody else trying to do the same on the same part). You just change a Config file, or write a new one, and voila!! A changed or new prefab without the need to recompile the whole shebang! #HURRAY!! 

Spoiler

So, ok, now you know what's a prefab, and now you know that all that patches made by TweakScale to be run by Module Manager are essentially instructions to built a customised prafab. And now you know why Module Manager is so important - because it is the arbitrator that allows hundreds of mods to co-live together.

So, and going direct to the matter now, when you take a Cockpit from the Part's Pallet and attach it to another part, KSP does that process I described above: it clone the part, inject on it a copy of its prefab (to fast initialise everything), and then attach the part to that another, and now you have a new living part to use.

My kludge with the Crew is exactly that: if I write a patch to shove 100 Kerbals on a MK1 cockpit, KSP will happily allow me to shove 100 Kerbals on the MK1 Cockpit, completely disregarding the number of seats of the IVA. But if TweakScale tries to do the same, KSP will reject it.

But, hey, you don't need to trust me on this, you can verify yourself! Shove this patch somewhere in your GameData (I suggest __LOCAL, so you can localise it easily and remove the stunt later):

@PART[*]:HAS[!MODULE[KerbalEVA],!MODULE[ModuleAsteroid],!MODULE[ModuleComet]]:FINAL
{
        @CrewCapacity *= 100
}

And see what you can do now:

12 Kerbals (still have 88 slots available) on a MK1 cockpit - and the thing has only one seat.

Github issue: https://github.com/net-lisias-ksp/TweakScale/issues/44

Last time I bored to try the stunt here.

[ColdJ]

@Lisias Thank you for the explanation. I understand the concept now. Personally, even if you made the capsule the size of the VAB I would leave the capacity of crew alone. It makes sense on fuel tanks to increase the internal volume when you increase the size of the tank but I think that the number of available seats should determine how many crew, otherwise it is Robert A Heinlein's "The Number of the Beast" novel, where when their ship visits a magical, fictional universe, they have the the rear of the cockpit magically expanded to have rooms and a fully functional bathroom, without changing the external ship dimensions, much like the T.A.R.D.I.S. Yes I realise that in this case you 'are' increasing the external dimensions, but you understand the magical reference.

[Lisias]

7 hours ago, ColdJ said:

@Lisias Thank you for the explanation. I understand the concept now. Personally, even if you made the capsule the size of the VAB I would leave the capacity of crew alone. It makes sense on fuel tanks to increase the internal volume when you increase the size of the tank but I think that the number of available seats should determine how many crew, 

You perhaps, but not other people. Forcing your way of playing into people is not the best way to make friends.

I would understand such limitation on Editor, because Editor needs to know how many Kerbals the part support to draw the slots - by Editor could take this value from the part instead of the prefab, but whatever.

But there's no such limit on flying time.

And, again, if the problem would be the number of available seats, the criteria should be applied on the prefab itself too. Anyone can shove 100 Kerbals on a MK1 Cockpit using a patch, but TweakScale can't shove 3 by scaling the cockpit up.

Again, sounds arbitrary and unneeded.

Edited October 8, 2021 by Lisias
tyop! Surprised?

[ColdJ]

4 hours ago, Lisias said:

Again, sounds arbitrary and unneeded.

That is what I was saying. I wasn't suggesting coming up with a way to add seats, I was suggesting not trying to get tweakscale to adjust crew size. Which would save you a lot of headache. I certainly wouldn't want to force players into a limited way of playing. Not adding a feature in the first place is not doing that. Tweakscale allows you to build a massive range of craft in a realistic way, whether it be humungous rockets or finely detailed jets. There is a plethora of mods that add crew capacity in a realistic way, so thought it would mean less stress for you.

But hey, it is all good. I am just a rubber ducky.

 

[Lisias]

2 hours ago, ColdJ said:

There is a plethora of mods that add crew capacity in a realistic way, so thought it would mean less stress for you.

That's the problem! If TweakScale can't, so they can't neither - because they would use the very same mechanism and, so, they would be blocked the same - unless they use some internal KSP feature I'm not aware, and so I want to be aware of that! 

On the bottom line, it's not up to the game engine to impose limits to the content creators - others than the ones needed to keep the engine healthy. Limiting the size of the crew on editing time to save the Editor from coping with this I consider undesired (because reading the crew size from the living part instead of the prefab is incredibly easy), but understandable (they would not want to add a test for this use case on the Quality Assurance).

Limiting the size of the crew while launching the craft doesn't protects the Editor from any problems, and prevent the content creators from doing something that I already had proved the game engine can cope without problems.

 

2 hours ago, ColdJ said:

But hey, it is all good. I am just a rubber ducky.

It's a harsh work, but someone has to do it!!!  

Spoiler

 

Edited October 8, 2021 by Lisias
Tyops. Who would guess it? :D

[Lisias]

ANNOUNCE

Release 2.4.6.0 2.4.6.1  is available for downloading, with the following changes:

• Breaks the 1.4.4 barrier! Now TweakScale supports from KSP 1.3.0 to the latest! #HURRAY!!
• Resurrects the AutoScale feature. Use CTRL-L to activate/deactivate
  • A HotKey collision with a 3rd-party add'on is a Known Issue. This will be tackled down on Issue #202.
• Updates KSPe.Light.TweakScale to 2.4.0.4
  • ATTENTION!! : Users of the following TweakScale Companions must update them immediatelly, as this release breaks binary compatibility (i.e. they will not load!!):
    • TSCo_FS
    • TSCo_KIS
    • TSCo_PKMC
    • TSCo_Visuals

And yes, this is working!!!

See OP for the links.

Highlights

Full support from KSP 1.3.0 to the latest

You install the package, something doesn't works, I will fix it! No questions asked! -- other than "what gone wrong?"

This is the pinnacle of 2 years of heavy and intensive planning - that was completely useless, because I didn't managed to follow a single line of the planning!! (damn, what a mess was this development, wasn't KSP-Recall??).

However, I won't use this on KSP 1.3.x on ongoing savegames, just in case. I don't have savegames from the 1.3.x era, so I can't thoroughly test the new patches on a living (backup'ed!) savegame to double check my synthetic tests on KSP 1.3.1 .

New savegames will end up being beneficed by the new patches as I revise and backport new versions of Add'Ons to KSP 1.3.0, but ongoing savegames gain too little to nothing on using TS 2.4.6.x - unless you are lazy as me and want one single package for everything!  

(not to mention using new features on previous KSP versions - you know, I still play 1.4.5 now and then...)

Selective persistence on saving craft files

From 2.4.5.4, a long time wished feature (the task was created on late 2019!!) is finally reaching the mainstream after being tested inhouse for half the year: TweakScale now omits its data on parts with default settings when saving craft files.

This new (and unexpected) feature is meant to declutter your craft files from unnecessary TweakScale sections, preventing your crafts from being flagged as using TweakScale when all your parts are plain vanilla sized!

This will save you from creating special KSP installments when participating of challenges where TweakScale is not allowed. Now you just can save the file normally and publish it without that pesky TweakScale config sections lingering on the file without doing anything useful.

This feature works on every KSP that have that Upgrade Pipeline thingy that will recreate the default TweakScale data from the prefab when it doesn't find it on loading. TweakScale does not activate this feature for KSP versions without this thingy for obvious reasons. Even users of older TweakScale versions will be able to load the craft files (the heavy lifting is done by the Pipeline) - so this feature is 100% retro-compatible.

There's a proof of concept on Kerbal-X where a craft with all parts unescaled (but the miniFulelage) is available for downloading. By inspecting the craft, you will see that only miniFuselage has a TweakScale section - but, yet, the craft will load fine on your KSP 1.12.2. There's another version made on KSP 1.4.5 that you can use to test the feature on previous KSP versions (make the Pipeline sweat!). Click on the "Version 1 of 2" thingy on the upper left part of the page.

TweakScaleExperimental support for parts and modules

From 2.4.5.2, TweakScale is starting to support, as possible, all KSP modules - and not only the most visible ones, as well parts.

In order to pursue that goal without risking your ongoing savegames (as changing Exponents will unbalance your designs, potentially ruining your crafts), some parts and modules scaling are only available on Experimental mode.

Such mode will patch almost all KSP parts and modules (but Serenity/Breaking Ground as this one will be tackled down later, see the backlog for more information), including some that I'm unsure should be scaled - not to mention Exponents that I'm pretty sure will need some rebalancing.

In order to toy with these parts and modules, you need to create a directory called TweakScaleExperimental in your GameData. The directory may be empty, it's enough to have it on GameData so Module Manager will register it, satisfying the :NEEDS that enable such patches and Exponents.

Please only enable these patches on disposable or non valuable KSP installments. These patches are going to change for sure in the near future, and these changes will be incompatible with savagames created with the previous set of Experimental patches.

Standard mechanism to control TweakScale availability

From 2.4.5.0 and up, it's possible to deactivate TweakScale on some (or even all) parts by patching or on the user interface without affecting living crafts on the savegame (or even already existent craft files).

A patching only feature can lock up TweakScale on the current state, making easier to create artefacts to automatically reconfigure a savegame for Challenges with specific rules. Again, without affecting existent crafts or savegames - once the craft is launched, it's not affected by these options.

See the Documentation for details.

Formal support for KSP from 1.3.0 to 1.12.2

From KSP 1.3.0 to KSP 1.12.2, every single version of KSP is formally supported. You find a bug, it will be fixed. Eventually.

TweakScale 2.5 aims to bring back support for KSP down to 1.2.2 (exactly how, is still work in progress, but it's feasible as being demonstrated by some Unofficial forks of mine).

Parts with Variants

Variants that change Cost and/or Mass are now fully supported, but TweakScale is struggling to support Parts with Variants that changes Attachment Nodes.

I had planned to withdraw TweakScale support from such parts as I did in the past, but then I realised that most Version 2 parts from already scalable parts (as Terrier...) would had TweakScale withdrawn, and this would render some crafts and savegames corrupted.

Since most of these parts didn't misbehave on a noticeable way, I decided to just let it go as is for while. Just a few stock parts are misbehaving into a noticeable way, and these parts are (until the moment):

• The Mastodon engine
• The Structural Tubes
  • T-12
  • T-18
  • T-25
  • T-37
  • T-50

And probably more, as Add'Ons starts to use such feature.

The only workaround at the moment is to descale these parts before applying the variant and then scaling them again. Alternatively, just detach and reattach the misbehaving parts.

A proper fix is Work in Progress, and is expected to be released. Soon™.

Deprecating Patches

Support for all non Squad parts are on a deprecating status and will be definitively removed on TweakScale 2.5. The TweakScale Companion Program will be the source for supporting third-parties add'ons.

It's advised to install the needed Companions as they reach Gold status.

Sanity Checks

Parts using Firespitter's FSbuoyancy needs the latest TweakScale Companion for Firespitter, as only the Companion has the specific code that knows how to handle it.

Embedded Firespitter Support is on Deprecating status anyway, so soon the TSCo-FS will be the only way to support Scaling on FireSpitter.

Overrules

A overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things "broken" in a deterministic way.

A complete essay can be found here.

Hot Fixes

A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don't break compatibility with sane installments, so you can start new savegames and share your crafts without worries.

A complete essay can be found here.

New Scaling Behaviour

A new TWEAKSCALEBEHAVIOUR, ModuleGeneratorExtended , is available for parts using ModuleGenerator that wants to scale the INPUT_RESOURCES too. This feature wasn't introduced directly into the ModuleGenerator's TWEAKSCALEEXPONENTS to prevent damage on Add'Ons (and savegames) that rely on the current behaviour (scaling only the output), as suddenly the resource consumption would increase on already stablished bases and crafts.

Just add the lines as the example below (the output resources scaling is still inherited from the default patch!).

@PART[my_resource_converter]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[ModuleGeneratorExtended]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = free
    }
}

WARNINGS

Keep an eye on the Known Issues file.

— — — — —

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), by Wedsday night (with luck)

The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps - and some issues on Day Job ended up leaking into this week that I was hoping to be an easy one...

Edited October 17, 2021 by Lisias
Distribution Channels are up to date.

[Lisias]

METAR

There's a new old Kraken Food pesking TweakScale these days - but, granted, it's exarcebated by a bug on TweakScale itself. 

That's the history: at least on a situation that appears to involve ReStock (but it's not ReStock fault! It's only the trigger), sometimes when loading craft files from another savegame some parts ends up with the Z coordinate inverted (i.e., the part with the bottom "down" on the source savegame ends up with the bottom "up"), and this is a situation badly handled by TweakScale:

On this sample craft, you will note that the fairing is Z axis inverted (node how the building goes downwards). The fuel tanks under it are also Z ais inverted, and it's the reason you see some texture fight where one tank attaches to the other (meaning that they were misplaced, and this is where TweakScale borks too). It's also the reason the Lander got pushed above the Monopropellant tank (that was also Z axis inverted, triggering the bug that pushed the Lander above it).

Making things yet more interesting, the tank's texture is on the right position. What's messed up are the attachment points - and I confirmed this by detaching the tanks and reattaching them upside down - a situation where "normal" tanks would  bork the scaling (due a bug on TS, just to make it clear), but on this craft it ended up working (due the swapped attachment points, apparently).

Once I invert the misplaced parts (or delete them and get new ones from the Palette), the problem vanish for good. It didn't came back once I saved the craft on a new file, even by removing and adding back ReStock on the installment. And this is the reason I'm sure ReStock is not the troublemaker, but was merely involved on the fürball.

Neither installments (mine and the source of the craft) had Harmony, by the way. So this is happening on a "vanilla" Stock binaries. I'm inclined to accuse the UpgradePipeline, as this one was known for screwing up the Z-Axis of Control Surfaces when KSP 1.8.x came to light - and since Control Surfaces are surface mounted parts, the attachment point bug of TweakScale doesn't kicks in, the only annoyance is having to invert the control of the part all the time once you launch it.

In a way or another, I'm reporting this so people are aware of the situation - even by fixing TweakScale, the attachment points will still be inverted and this may screw up others add'ons too. Additionally, this TS bug is present on every previous version of TweakScale (including the ones from the 1.3.x era), so there's no reason to postpone the SpaceDock update as I was doing while I was not sure about the real reason of this major group borkage. So I'm updating SpaceDock this night for the latest TweakScale.

As the result of this borkage, I'm rescheduling the RoadMap to tackled down this attachment related bugs for the next Release (to be issued Soon™) 

Cheers!

[viperwolf]

5 hours ago, Lisias said:

METAR

There's a new old Kraken Food pesking TweakScale these days - but, granted, it's exarcebated by a bug on TweakScale itself. 

That's the history: at least on a situation that appears to involve ReStock (but it's not ReStock fault! It's only the trigger), sometimes when loading craft files from another savegame some parts ends up with the Z coordinate inverted (i.e., the part with the bottom "down" on the source savegame ends up with the bottom "up"), and this is a situation badly handled by TweakScale:

On this sample craft, you will note that the fairing is Z axis inverted (node how the building goes downwards). The fuel tanks under it are also Z ais inverted, and it's the reason you see some texture fight where one tank attaches to the other (meaning that they were misplaced, and this is where TweakScale borks too). It's also the reason the Lander got pushed above the Monopropellant tank (that was also Z axis inverted, triggering the bug that pushed the Lander above it).

Making things yet more interesting, the tank's texture is on the right position. What's messed up are the attachment points - and I confirmed this by detaching the tanks and reattaching them upside down - a situation where "normal" tanks would  bork the scaling (due a bug on TS, just to make it clear), but on this craft it ended up working (due the swapped attachment points, apparently).

Once I invert the misplaced parts (or delete them and get new ones from the Palette), the problem vanish for good. It didn't came back once I saved the craft on a new file, even by removing and adding back ReStock on the installment. And this is the reason I'm sure ReStock is not the troublemaker, but was merely involved on the fürball.

Neither installments (mine and the source of the craft) had Harmony, by the way. So this is happening on a "vanilla" Stock binaries. I'm inclined to accuse the UpgradePipeline, as this one was known for screwing up the Z-Axis of Control Surfaces when KSP 1.8.x came to light - and since Control Surfaces are surface mounted parts, the attachment point bug of TweakScale doesn't kicks in, the only annoyance is having to invert the control of the part all the time once you launch it.

In a way or another, I'm reporting this so people are aware of the situation - even by fixing TweakScale, the attachment points will still be inverted and this may screw up others add'ons too. Additionally, this TS bug is present on every previous version of TweakScale (including the ones from the 1.3.x era), so there's no reason to postpone the SpaceDock update as I was doing while I was not sure about the real reason of this major group borkage. So I'm updating SpaceDock this night for the latest TweakScale.

As the result of this borkage, I'm rescheduling the RoadMap to tackled down this attachment related bugs for the next Release (to be issued Soon™) 

Cheers!

This is the exact issue I ran into after the update, thanks for catching it. You Rock!!!!

[darthgently]

@Lisias,  quick FYI, I upgraded TweakScale to the latest and nearly all my craft in my game are getting an error that the craft are missing part KIS.Container1.  I downgrade tweakscale and game loads fine.
 

[Lisias]

8 hours ago, viperwolf said:

This is the exact issue I ran into after the update, thanks for catching it. You Rock!!!!

From all the possible problems TS 2.4.6.0 would cause, this is the most unexpected one.

The difference from TS 2.4.6.0 from the previous are only are essentially the DLL loading mechanisms, and these ones are being tested for the best part of this year.

What you are getting now should be happening on TS 2.4.5.x… KSP, sometimes, surprises me in the most obscure ways… 

 

6 hours ago, darthgently said:

@Lisias,  quick FYI, I upgraded TweakScale to the latest and nearly all my craft in my game are getting an error that the craft are missing part KIS.Container1.  I downgrade tweakscale and game loads fine.

Did you installed/updated the TweakScale Companion for KIS? The KSP.log would help me to diagnose the problem - I had not problems like this one while testing the latest release of TSCo-KIS and the TS 2.4.6.0 (when in RC), but something always can pass through...

[Endergaming2546]

Not sure if I am in the right place but when I installed TweakScale from CKAN I messed up with the directory and copy/pasted all my mods to the correct one. I booted up KSP, then the Houston we have a problem window showed up. I pressed okay and loaded it up, and it was there again. Did it 3 times and then tried CKAN. Nothing worked. Afaik I have no incompatible mods. Also it stops loading around Sqaud/Parts (I think)/MassiveSRB(I think), which could be tweakscale,but I doubt it

 

[Lisias]

4 hours ago, Endergaming2546 said:

Not sure if I am in the right place but when I installed TweakScale from CKAN I messed up with the directory and copy/pasted all my mods to the correct one. 

Ugh… I did a major bork once by uploading the wrong zip file on Spacedock what could explain your problem - but I just checked the file on SpaceDock and it's the correct one. However… The netkan guy's changes on the netkan file exactly due that screw up of mine may be the answer for your problem, if by some reason the netkan client failed to checkout the updated file - what's a bit odd, since the borkage happened last June 27 - many weeks ago.

You will need to reach the CKAN guys to sort this out for sure, however.

 

4 hours ago, Endergaming2546 said:

I booted up KSP, then the Houston we have a problem window showed up. I pressed okay and loaded it up, and it was there again. Did it 3 times and then tried CKAN. Nothing worked. Afaik I have no incompatible mods. Also it stops loading around Sqaud/Parts (I think)/MassiveSRB(I think), which could be tweakscale,but I doubt it

Send me your KSP.log (and since things just freezes on you, the Player.log will also help). The instructions about how to get these ones are on the OP, under a  Spoiler on the final.

There're many reasons for TweakScale shoving a Houston on our noses, I need these files to checkout what one bite you.

Cheers!

[Endergaming2546]

2 hours ago, Lisias said:

Send me your KSP.log (and since things just freezes on you, the Player.log will also help). The instructions about how to get these ones are on the OP, under a  Spoiler on the final.

I figured that part out and was able to load, but TweakScale's localization was weird. Thats the only problem I have found though

[Lisias]

1 hour ago, Endergaming2546 said:

I figured that part out and was able to load, but TweakScale's localization was weird. Thats the only problem I have found though

UGH!!! That passed trough!! I'm so used to run TweakScale beta that I just filter out the problem from my sigh!!

Fixing this right now.

— — — 

Annouce

TweakScale 2.4.6.1 in on the wild, with the fix for the bork mentioned above.

All Distribution Channels were updated at once.

Cheers!

Edited October 17, 2021 by Lisias
Announce

[viperwolf]

This is such an important mod IMO. I really hope KSP 2 comes stock with this, but we will see. You have been patient and rock solid sense you took this over.

[darthgently]

14 hours ago, Lisias said:

From all the possible problems TS 2.4.6.0 would cause, this is the most unexpected one.

The difference from TS 2.4.6.0 from the previous are only are essentially the DLL loading mechanisms, and these ones are being tested for the best part of this year.

What you are getting now should be happening on TS 2.4.5.x… KSP, sometimes, surprises me in the most obscure ways… 

 

Did you installed/updated the TweakScale Companion for KIS? The KSP.log would help me to diagnose the problem - I had not problems like this one while testing the latest release of TSCo-KIS and the TS 2.4.6.0 (when in RC), but something always can pass through...

I have not installed the companion for KIS.  When will all the companions be on CKAN?  The stragglers bite me every time

[Lisias]

4 hours ago, darthgently said:

I have not installed the companion for KIS.  When will all the companions be on CKAN?  The stragglers bite me every time

The main and most important reason for the recent update to the 2.4.6.x series is the KSPe.Light thingy. This guy has core services that will allow me to install Companions safely without the dependencies installed - a situation that if unhandled will end up with KSP not loading correctly due a bug on the stock AssemblyLoader. How it does it's subject for another (huge) post.  

(TweakScale being able to run from KSP 1.3.0 to 1.12.2 is a beneficial side effect of that core services - since they are there, I just used them on TS too!)

The Companions, due its nature, have a problem called Triangular Dependencies (a "plague" that happens too on MM Patches, but MM doesn't crashes the game because of that!).

Let's take , for example, the TSCo-KIS you just installed: it :NEEDS  both Scale and KIS Assemblies to be installed, otherwise its loading will raise a Reflection Exception like this one:

[LOG 00:58:11.276] PartLoader: Compiling Part 'B9_Aerospace/Parts/Body_Mk2_Cockpit/body_mk2_cockpit_a/B9_Body_Mk2_Cockpit'
[ERR 00:58:11.294] MechJeb caught exception in core OnLoad: System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
  at KSP.IO.File.Exists[T] (System.String filename, Vessel flight) [0x00053] in <9d71e4043e394d78a6cf9193ad011698>:0
  at MuMech.MechJebCore.OnLoad (ConfigNode sfsNode) [0x00097] in <2e230d4e49354a07858a9faa52799159>:0

When this happens, something inside KSP gets broken and lots of things start to fail without reason. On the KSP.log I took this example, the following borkage was the consequence :

[EXC 01:00:19.076] ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
        System.Reflection.Assembly.GetTypes () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0)
        AssemblyLoader.GetTypesOfClassesImplementingInterface[T] () (at <9d71e4043e394d78a6cf9193ad011698>:0)
        Expansions.Missions.MissionsUtils.InitialiseAdjusterTypes () (at <9d71e4043e394d78a6cf9193ad011698>:0)
        Expansions.ExpansionsLoader+<LoadExpansions>d__21.MoveNext () (at <9d71e4043e394d78a6cf9193ad011698>:0)
        UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <5aeafee3fea24f37abd1315553f2cfa6>:0)

CKAN doesn't understand Triangular Dependencies neither - I can't say to CKAN "If TweakScale is installed and KIS is installed too, you need to install TSCo-KIS" . All I can do is to suggest and/or recommend all the Companions on the TweakScale netkan file, what will probably prompt the user to install them anyway - and if by bad luck the user installs the TSCo-FS one by mistake, we will have a crashed KSP on the next boot because the TSCo-FS will fail to be loaded because Firespitter is not installed - and then that nasty bug on the stock KSP AssemblyLoader will screw up the internal game state, and lots of things will not work correctly after the borkage. The example above is just one of the possible consequences, I have tons of these issues on my database.

So, in order to overcome this royal borkage from KSP since 1.8.0, I needed to reenginer the Companions to do selective DLL loading: the DLLs that are loaded by KSP are "safe", without hard dependencies. They then check if the needed Assemblies are loaded by KSP, and only then they load the DLLs with hard dependencies - avoiding the whole mess.

If any of the dependencies are not met, the plugin just shuts itself down. Not even the patches are applied, as the tag needed on their :NEEDS are generated by that very same code that only does it after checking the dependencies.

So, now and just now, it's safe to start to distribute the Companions using Curseforge and CKAN.

The final step for a complete solution is a WatchDog for the Companions that will monitor the add'ons installed and then prompt the user to install the respective Companion if needed.

It's not as nice as being able to tell CKAN to do it automatically, but at least it's better than what happened to you now!

Cheers!

Edited October 17, 2021 by Lisias
Better phrasing

[viperwolf]

If Im only running KAS and not KIS do I need a companion?

[Lisias]

16 hours ago, viperwolf said:

If Im only running KAS and not KIS do I need a companion?

Not yet.

Eventually I will deprecate for good the old patches on TS distribution,  but this will not happen until I tackle down this dependency problem. 

As far as I know, the current patches for KAS are still acceptable, so is unlikely that I will rework them in the short run.

But you can aways check the TweakScale Companion thread for news. 

Cheers!

Edited October 18, 2021 by Lisias
yeah, tyops. But you alreday knew it. :)

[Darknote]

So I got this annoying bug where I upscale some parts from ReStock+ and save the craft. Do some stuff, come back to load it and it appears like so in the VAB
Modlist:
 

Spoiler

6 Seat Mk3 Cockpit (SixSeatMk3cockpit 1.2)
B9 Part Switch (B9PartSwitch v2.18.0)
ballisticfox's neutral tufx profile (BallisticFoxsNeutralTUFXProfile V1.3)
ballisticfox's vintage TUFX profile (BallisticFoxsVintageTUFXProfile V1.0)
BetterTimeWarpContinued (BetterTimeWarpCont 2.3.12.9)
Breaking Ground (BreakingGround-DLC 1.7.1)
Chatterer (Chatterer 0.9.99)
Chatterer Extended (ChattererExtended 0.6.2)
ClickThrough Blocker (ClickThroughBlocker 1:0.1.10.17)
Community Category Kit (CommunityCategoryKit v5.2.0.0)
Community Resource Pack (CommunityResourcePack 1.4.2)
Contract Configurator (ContractConfigurator 1.30.5)
Contract Pack: Bases and Stations Reborn (ContractConfigurator-KerbinSpaceStation 2:3.7.2.5)
Contract Pack: Exploration Plus (ContractConfigurator-ExplorationPlus 2.0.1)
Contract Pack: Field Research (ContractConfigurator-FieldResearch 1.2.2)
Contract Pack: Kerbal Academy (ContractConfigurator-KerbalAcademy 1.1.10)
Contract Pack: Tourism Plus (ContractConfigurator-Tourism 1.5.2)
Crowd Sourced Science (CrowdSourcedScience v6.0)
Cryo Tanks (CryoTanks 1.6.2)
Cryo Tanks Core (CryoTanks-Core 1.6.2)
Cryogenic Engines (CryoEngines 1:2.0.3)
Custom Pre Launch Checks (CustomPreLaunchChecks 1.8.1.1)
Deployable Engines Plugin (DeployableEngines 1.3.1)
Distant Object Enhancement /L (DistantObject v2.1.1.5)
Distant Object Enhancement /L default config (DistantObject-default v2.1.1.5)
Dynamic Battery Storage (DynamicBatteryStorage 2:2.2.5.0)
Easy Vessel Switch (EVS) (EasyVesselSwitch 2.3)
Environmental Visual Enhancements Redux (EnvironmentalVisualEnhancements 3:1.11.3.1)
Far Future Technologies (FarFutureTechnologies 1.2.0)
Ferram Aerospace Research Continued (FerramAerospaceResearchContinued 3:0.16.0.4)
Harmony 2 (Harmony2 2.0.4.0)
Heat Control (HeatControl 0.6.1)
JNSQ (JNSQ 0.10.0)
JNSQ Real Date (JNSQ-RealDate 1.2)
JX2Antenna (JX2Antenna 2.0.5)
Kerbal Actuators (KerbalActuators v1.8.4)
Kerbal Atomics (KerbalAtomics 1:1.3.2)
Kerbal Attachment System (KAS 1.9)
Kerbal Engineer Redux (KerbalEngineerRedux 1.1.9.0)
Kerbal Inventory for All (KerbalInventoryForAll 1:1.2.2)
Kerbal Inventory System (KIS 1.28)
Kerbal Konstructs (KerbalKonstructs v1.8.3.0)
Kerbal Renamer (KerbalRenamer v1.5.0)
Kerbalism (Kerbalism 3.14)
Kopernicus Planetary System Modifier (Kopernicus 2:release-1.12.1-59)
kOS: Scriptable Autopilot System (kOS 1:1.3.2.0)
Kronometer (Kronometer v1.12.0.1)
Making History (MakingHistory-DLC 1.12.1)
MechJeb 2 (MechJeb2 2.12.3.0)
Midweeks lesser red Tufx config (MidweeksLesserRedTUFXConfig 1.0)
Midweeks tufx config (MidweeksTUFXConfig 1.0)
Midweeks_Green (MidweeksGreenTUFXConfig 1.1)
Mk3 Stockalike Expansion (Mk3Expansion 1.6.1.3)
ModularFlightIntegrator (ModularFlightIntegrator 1.2.10.0)
Module Manager (ModuleManager 4.2.1)
Near Future Aeronautics (NearFutureAeronautics 2.1.1)
Near Future Construction (NearFutureConstruction 1.3.1)
Near Future Electrical (NearFutureElectrical 1.2.3)
Near Future Electrical - Decaying RTGs (NearFutureElectrical-DecayingRTGs 1.2.3)
Near Future Electrical Core (NearFutureElectrical-Core 1.2.3)
Near Future Exploration (NearFutureExploration 1.1.2)
Near Future IVA Props (NearFutureProps 1:0.7.1)
Near Future Launch Vehicles (NearFutureLaunchVehicles 2.2.0)
Near Future Propulsion (NearFuturePropulsion 1.3.5)
Near Future Propulsion - Xenon Hall Effect Thrusters (NearFuturePropulsion-XenonHETs 1.3.5)
Near Future Solar (NearFutureSolar 1.3.2)
Near Future Solar Core (NearFutureSolar-Core 1.3.2)
Near Future Spacecraft (NearFutureSpacecraft 1.4.3)
Near Future Spacecraft - LFO Engines (NearFutureSpacecraft-OrbitalLFOEngines 1.4.3)
QuazSpace TUFX Config (QuazSpaceTUFXConfig 1.1)
Rational Resources (RationalResources 1.20.2)
Rational Resources Companion (RationalResourcesCompanion 1.20.2)
Rational Resources Kerbalism (RationalResourcesKerbalism 1.20.2)
RealChute Parachute Systems (RealChute v1.4.8.3)
RecoveryController (RecoveryController 0.0.4.1)
ReStock (ReStock 1.4.2)
ReStock+ (ReStockPlus 1.4.2)
scatterer (Scatterer 3:v0.0772)
Scatterer Default Config (Scatterer-config 3:v0.0772)
Scatterer Sunflare (Scatterer-sunflare 3:v0.0772)
ScienceAlert ReAlerted (ScienceAlert 1.9.9.3)
SIMPLEX Kerbalism (SIMPLEXKerbalism 2:3.4)
SIMPLEX TechTree (SimplexTechTree 3:1.25)
Space Dust (SpaceDust 0.4.3)
SpaceTux Library (SpaceTuxLibrary 0.0.8.2)
StageRecovery (StageRecovery 1.9.5.4)
Stockalike Station Parts Expansion Redux (StationPartsExpansionRedux 2.0.5)
System Heat (SystemHeat 0.5.6)
TextureReplacer (TextureReplacer v4.5.2)
Toolbar Controller (ToolbarController 1:0.1.9.6)
TUFX (TUFX 1.0.2.3)
VesselMover Continued (VesselMoverContinued v1.12.0)
Waterfall Core (Waterfall 0.6.7)
Waypoint Manager (WaypointManager 2.8.3.1)
Zero MiniAVC (ZeroMiniAVC 1:1.1.1.1)

And if I do an instant Save/Load Function of a Craft, it shows the Tweaked parts glitching into each other

 

Player log: https://1drv.ms/u/s!AucfyQV7bniVgYgeNAdYSH4ZNuzhow?e=o94N72

 

Any help is appreciated!!

Edited October 17, 2021 by Darknote

[Lisias]

2 hours ago, Darknote said:

So I got this annoying bug where I upscale some parts from ReStock+ and save the craft. Do some stuff, come back to load it and it appears like so in the VAB
Any help is appreciated!!

Yeah, unfortunately it's a known issue.  

It's two bugs bitting you in a row: the first (and most serious, as it affects everybody) is from KSP, that now and then screw up something on the UpgradePipeline (probably) and invert the Z Axis of the part (or at least, from the attach nodes). Sometimes the fairings get inverted, and you can't build the fairing towards the right end of the rocket due this. This I can't help, it's a long standing KSP problem that started to happen on 1.8.0 (I first noticed it on the control surfaces).

The second bug is on TweakScale. In all these years since the first version, no one (including me) thought that someone would want to invert the part before scaling, and so the code was made assuming the part is always pointing towards the root. This is scheduled to be fixed for the next release, in which I (hope) to start to work on the middle on this next week.

Until there, the only workaround is to detach the affect parts, invert it, and reattach them. This solves the problem for good on this craft - or at least, I still didn't got a report of the thing happening again on the same craft on the same savegame - the KSP bug triggers when loading crafts from another savegame I think (but I'm not 100% sure).

Until this moment only ReStock parts are being reported - but I really doubt this is a ReStock problem. Once you fix the craft and save it, you can remove and reinstall ReStock that the bug doesn't triggers anymore.

A more thoughtful discussion can be found on this post:

 

[Darknote]

Well darn! I can't wait for that new version then because I tried downgrading to  2.4.5.0 and Tweakscale doesn't get activated

[Pehvbot]

On 10/8/2021 at 11:52 AM, Lisias said:

That's the problem! If TweakScale can't, so they can't neither - because they would use the very same mechanism and, so, they would be blocked the same - unless they use some internal KSP feature I'm not aware, and so I want to be aware of that! 

Apparently you can remove seats instead.  In theory that means patching in a bunch of seats when the game loads then dynamically removing  seats that don't fit.  I haven't tried this myself and don't even recommend it it, but if true it should at least be possible to 'add' seats (i.e. remove fewer of them) and apply an appropriate IVA dynamically.   It's something I briefly thought about, but fortunately I came to my senses.

Edited October 17, 2021 by Pehvbot

[Lisias]

1 hour ago, Darknote said:

Well darn! I can't wait for that new version then because I tried downgrading to  2.4.5.0 and Tweakscale doesn't get activated

You should had forgot to completely remove the TweakScale folder. I downgrade things here now and then just to see what happens, and no problems were detected - as long you completely get rid of all binaries before "downgrading" to the previous release.

Keep in mind that 2.4.6.x is a deal breaker to some Companions (it's the reason I had to update some of them). In order to use TweakScale 2.4.5.0, you will need to downgrade also the Companions mentioned on the github's Release page.

Breaking binary compatibility sucks, I know, but I had drawn myself to a corner with some APIs and had to do it sooner or later, and took the opportunity to do it now since some new APIs would need the Companions to be rewritten anyway, so we would endure two pains by the price of one.

 

1 hour ago, Pehvbot said:

Apparently you can remove seats instead.  In theory that means patching in a bunch of seats when the game loads then dynamically removing  seats that don't fit.  I haven't tried this myself and don't even recommend it it, but if true it should at least be possible to 'add' seats (i.e. remove fewer of them) and apply an appropriate IVA dynamically.   It's something I briefly thought about, but fortunately I came to my senses.

Exactly. Scaling Crew down works - since nobody is launching exceptions when this happens. Observe that the U,I. adapts itself normally with you scale down a 3 crewed part to 2 and then 1 crew. I fail to understand why this would be a problem for scaling up.

The excuse of "people would find weird the IVA not following the new crew size" - as people would not be using borrowed IVAs from other parts and shoving more (or less) kerbals on it that the available seats. As I said, you can MM your way on it and KSP doesn't complains about the part having more crew on the prefab than IVA seats.

Mangling the IVA seats was something that I had though, but since KSP resets everything to the prefab on launch, TweakScale needs to reapply the scaling on the first frames of life of the Craft - and by then, KSP already had thrown that Exception on me.

The Solution for this would be writing a new PartModule with a new Crew support to avoid the KSP's ban (like KIS does with cargo). From there, I could do anything I want (including generating IVAs at runtime - a somewhat daunting endeavour  ). But then we have R.L. kicking my balls and forcing me to compromise - there're more pressing things in need to be done ASAP (as you can see above).