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

[Axelord FTW]

Well, KSP seemed fine but I'll do a Win10-DISM pass, then SFC.

[Lisias]

6 hours ago, Axelord FTW said:

Well, KSP seemed fine but I'll do a Win10-DISM pass, then SFC.

What doesn't means that everything else will be fine.

This kernel32.dll stunt is plaguing Windows users for years, as it appears.

Intel, Unreal Engine, VS Code users… You name  it.

[Axelord FTW]

Might be so, but everything work fine now at the very least.

[Lisias]

ANNOUNCE

Release 2.4.6.4 is available for downloading, with the following changes:

• Turns off by default (and makes hard to activate) the StealthSave due a (another) bug related to the Upgrade Pipeline.
• Reverts the KSPe.Light.TweakScale to the previous release due a excrementsstorm apparently related to borked Kernel32.dll on some systems

See OP for the links.

Notes

This is one of the bitter releases I ever made. The UpgradePipeline has bitten me in the SAS again, reopening old wounds.

One of the worst and most problematic problems I had on TweakScale in the past (and that was the trigger for a lot of nasty problems, as "scaling" parts to 0 mass) was exactly this Kraken damned feature, as it was injecting back into parts prefab information overwriting the current info on the section of the part being loaded. So, a perfectly sane craft (or savegame) became mangled (or corrupted, depending of the severity of the mess on the prefab) on load if an update on your rig renders problematic.

This thingy also prevented TweakScale from migrating scalings when the default scale for a part changed on the prefab, as the UpgradePipeline was acting before TweakScale could try to fix it and so, the old values needed to recalculate the new scalings were lost. So the need to be incredibly picky to the point of risking being obnoxious to avoid anything even slightly weird on the patching.

This crap took me more than a year to be tackled down, what happened on Issue #137 and was published on Release 2.4.4.0.

[addendum]

Besides being incredibly mad by this problem, originally I liked the feature after I learnt how to live with it -  it intended to allow us to update KSP and Add'Ons to newer bug free releases, what would be an improvement over the past M.O. where you was locked down on a set of versions (including KSP) for the duration of the savegame.

So, besides the immense trouble the UpgradePipeline gave me in the past, I had welcomed it once I understood what it was doing and why. In the end, I concluded it had worth the pain.

One of the reasons I'm incredibly mad with the stunt now is, PRECISELY, I'm being happy with it until recently - as it would theoretically open some pretty nice possibilities not only to updating broken things without breaking more things, but also on Module management as I was trying to do with the StealthSave.

Had I never seen any value on it, I would be way less angry now.

[/addendum]

And now, due a combination of yet another bug on the thingy and a old bad design decision that weren't correctly reworked, the StealthSave feature for TweakScale is from now on deactivated - with the express recommendation to be not activated unless you really want to push your luck on the matter, what apparently I did with success the whole year as the problem I will describe now never hit me in the whole time I was using it.

And this is the problem: some PartModules are installed more then once on the Part, being the ModuleEngineFX one of them: when you have multimode engines (as a turbofan with afterburner), each engine mode has its own ModuleEngineFX, and another module called MultiModeEngine manages the situation.

However, this creates a problem: how to univocally identify a PartModule on this mess? How about an UUID for each module? Or perhaps adding a hash to the name, like is done with the parts inside a craft? Nah, let's use the index of the damned Module on the array in memory and call it a day, what could possibly go wrong, right?

Well, by using the index of the PartModule, what happens is that YOU CAN'T UPDATE ANYTHING ON THE PREFAB without risking screwing up the savegames. You add an add'on, you remove an add'on, you UPDATE an existing add'on with something new, you even update KSP itself, and you may change the index of some PartModule and so, you are prone to the problem described on the Issue #215 . 

Essentially, updating things is playing Russian Roulette with your savegames. Simple like that.

It's not possible to overstate my displeasing (Forum Rules forbids me to express myself correctly) about this situation - not because I'm deactivating a nice-to-have but definitively non-essential feature, but because this means that for the last 2 3.5 years, since KSP 1.4.0, every single one of us shouldn't had update anything once a savegame is initiated. The whole UpgradePipeline stunt is near useless, what also means that all my work related to it was wasted.

Not being bitter enough, some pretty old stupidity from Windows is still alive and kicking nowadays. For some reasons I'm still working on, some Windows rigs are missing a system file called Kernel32.dll. There's no other option but to fix the system using DISM (after trying a stunt or another in the hope of avoiding it). Full information here.

So, until I cook a way to detect this problem and avoid letting the blame fall on TweakScale, I'm rollbacking the KSPe.Light.TweakScale for the previous version - that also has the need for Kernel32.dll on Windows, but since it handles less borderline situations, the incidence of the problem is near nill . Of course this will cause some borderline situations on Windows to pass through, triggering false alarms on some users. But I have to be pragmatic on this, I do not work for Microsoft after all: I'm choosing the less traumatic path on the short run, as I have RL™ duties to carry on at the same time.  

— — — — —

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.

The reasoning is to gradually distribute a potentially Support Fest release in a way that would me allow to provide proper support if anything else goes wrong.

 

 

Edited November 27, 2021 by Lisias
addendum - and boy, I'm still really mad. All Distribution Channels are up to date.

[darthgently]

I'm about to give up on TweakScale, which is pretty much giving up on KSP as I can't imagine having much enjoyment dealing with the clunky part size options.  Clean 1.12.2 install with the latest TS and stock parts and I'm having severe issues in the editor.  It seems that the attachment nodes don't always scale with the parts, especially when <modkey>-copying a part or assembly.  For multi-part assemblies with TS'd parts, if one <modkey>-clicks the assembly to copy it, more often than not all the attachment nodes revert to their pre-scaled geometry making a complete mess of of the assembly.  I've had similar things happen in flight, but much more rarely.  There are corner cases that the code is missing apparently.  Important corner cases.  No errors show in the log when performing these operations at the time of the operation.  Sorry to be whinging but obviously this isn't the only issue when dealing with KSP.  Add all those issues together and I spend more time dealing with these kinsds issues than learning more about orbital mechanics.  If it weren't for kOS and my self-educational goals I'd have been long gone awhile ago.  But to be quite frank, TS and many other mods need to a full regression test and a bug fix *only* release in my opinion.  I'm really ust trying to be helpful here.  When new functionality is mixed in with fixes it always seems to cascade into more chaos.

Looking more at it, the attachment nodes aren't reverting to the pre-scaled points.  It is more like the scaling is being applied twice, or incorrectly.  See image at link.  Let me know if link doesn't work

https://imgur.com/a/UAD1jnW

Edited November 25, 2021 by darthgently

[USAA]

I've got my game saying there's some issues with my mods. What do I do?

 

(It involves TweakScale)

[Lisias]

20 hours ago, USAA said:

I've got my game saying there's some issues with my mods. What do I do?

Publish your KSP.log on dropbox or something, and I will inspect it to see what's happening.

 

20 hours ago, darthgently said:

I'm about to give up on TweakScale, which is pretty much giving up on KSP as I can't imagine having much enjoyment dealing with the clunky part size options.  Clean 1.12.2 install with the latest TS and stock parts and I'm having severe issues in the editor.  It seems that the attachment nodes don't always scale with the parts, especially when <modkey>-copying a part or assembly.  For multi-part assemblies with TS'd parts, if one <modkey>-clicks the assembly to copy it, more often than not all the attachment nodes revert to their pre-scaled geometry making a complete mess of of the assembly.  

Acknowledged. But I will need some crafts with the problems described. Preliminary tests suggests the nodes are being scaled correctly.

Also, please note that the nodes visual cues has only 3 sizes, and any value between two of these sizes sizes are "snapped" to the nearest existent size. It's a game engine limitation, nothing I can do about - at least, under Forum rules. But the BreakingForce and the BreakingTorque are being scaled, and these are the values used by the physics engine.

On the example below, the central tank is on default scale. The second to to the left was scaled to 1.875 and the next to the left was scaled to 2.5. Note that only the 2.5 one had the attachment note visual cue scaled, because there's no intermediary value available between 1.875 and 2.5. The same for the 5M scale, aggravated by the fact that there's not a fourth size - so once the attachment node reaches size 3, everything bigger will have this size and that's it.

The right tanks were created by ALT_Click the left ones (i.e., using the OnCopy method).

I could not reproduce your issue with the OnCopy handler (the Alt+Click thingy). It's always working for me. Craft file and SFS on this post on Issue track.

Additionally, please remember that Stock KSP has bugs that hinders TweakScale and a lot of add'ons more. You need to have KSP-Recall installed, or some features (from TweakScale and also some other add'ons) will not work as expected - alternativelly, you can install a new alternative available on GitHub that appears to make things in a more straightforward (and clean) way, but since apparently Forum Rules doesn't allows add'ons with some of the techniques used, I prefer to do not mention it here - but once you use it and find something that may be related to a KSP bug, you will need to ask that Add'On maintainer for guidelines, as I can only give support for KSP-Recall.

Additionally, until recently the node size limitation used to be tackled down by Kerbal Joint Reinforcement. It's my opinion that you are complaining about a KSP issue on the wrong Thread.

 

20 hours ago, darthgently said:

There are corner cases that the code is missing apparently.  Important corner cases.  No errors show in the log when performing these operations at the time of the operation. 

This is perfectly possible. I need feed back in order to identify these borderline situations, because it's impossible to any author identity and correct every single one of them - at least, without breaking some Forum Rules.

 

20 hours ago, darthgently said:

Sorry to be whinging but obviously this isn't the only issue when dealing with KSP.  Add all those issues together and I spend more time dealing with these kinsds issues than learning more about orbital mechanics.  If it weren't for kOS and my self-educational goals I'd have been long gone awhile ago. 

Perfectly understandable. If you read my last post, you will find similar complains, wrote on a similar mood under a similar state of mind. And I'm the author of the damned thing.

 

20 hours ago, darthgently said:

But to be quite frank, TS and many other mods need to a full regression test and a bug fix *only* release in my opinion.  I'm really ust trying to be helpful here.  When new functionality is mixed in with fixes it always seems to cascade into more chaos.

And this is exactly what's happening, sir. At least on TweakScale.

Please read the CHANGE LOG and also, the ROAD MAP. And the milestones, you can influence the order I will tackle down these ones.

 

20 hours ago, darthgently said:

Looking more at it, the attachment nodes aren't reverting to the pre-scaled points.  It is more like the scaling is being applied twice, or incorrectly.  See image at link.  Let me know if link doesn't work

https://imgur.com/a/UAD1jnW

Looks like a known problem. I don't know if this is a new behaviour for this issue, or if it's a new problem at it own right - but when you "invert" the the part on a chain (i.e, you attach the bottom side of a part on the bottom side of the other), TweakScale misbehaves while calculating the part displacements.

It's this way since forever, but by some reason it passed unnoticed all these years. It was only recently that I became aware of this specific misbehaviour.

A easy way to reproduce it is to take a fuel tank (anyone), then take another one and attached it inverted (bottom to bottom), then attach a third one. Activate Chain Scale, and then scale up the root part. You will find a similar problem as depictured on your screenshot.

For now, the only workaround until I have time to dig into this one is to do not "invert" parts while stacking them up - at least, if you want to scale them. Sorry for that. [nope, the #208 is not back from the dead. It's something else.]

 

20 hours ago, darthgently said:

 I've had similar things happen in flight, but much more rarely. 

About *THIS*, I think it may be related to Issue #215 that I just closed for the latest Release (already available on GitHub, and finding its way into the other Distribution Channels). And it is, PRECISELY, the motivator for my bitter rant on the post I mentioned.

Edited November 26, 2021 by Lisias
Brute force post merge.

[Lisias]

10 hours ago, darthgently said:

Looking more at it, the attachment nodes aren't reverting to the pre-scaled points.  It is more like the scaling is being applied twice, or incorrectly.  See image at link.  Let me know if link doesn't work

https://imgur.com/a/UAD1jnW

About this one, I made further tests and I could not reproduce it neither. Initially I thought it could be the recently fixed #208 resurrected, but it's working fine from 1.3.0 to 1.12.2 (yep, I do such tests).

So, and assuming you are not using a old TweakScale version (it was fixed on 2.4.6.2), I will need your craft file and KSP.log in order to pursue this issue.

[Moshbot]

On 11/23/2021 at 5:40 PM, Lisias said:

@Moshbot, @Axelord FTW,   @KAO, you guys need to fix your Windows, I found instructions for how to fix your Windows from a trustable source here.

I've done all what I could in attempts to reinstall all possible problems. From reinstalling this Kernel dll and PowerShell repair, to reinstalling last few windows updates. PowerShell say "Everything working just fine. There is no errors. Darn it please stop reinstalling maniacally all what your eyes seeing!!"

So... now I've got only one thing to say - 

 

[Lisias]

4 minutes ago, Moshbot said:

I've done all what I could in attempts to reinstall all possible problems. From reinstalling this Kernel dll and PowerShell repair, to reinstalling last few windows updates. PowerShell say "Everything working just fine. There is no errors. Darn it please stop reinstalling maniacally all what your eyes seeing!!"

(sigh) So it must be something on the code itself.

I need to figure out exactly what changed on Windows, because this was working when I wrote it. It was tested on the field by people that were helping me with the matter at that time.

Since I didn't changed that code since them, it must be something on Windows that had changed.

 

2 minutes ago, Moshbot said:

So... now I've got only one thing to say - 

(sigh)

Are you using the most recent release, 2.4.6.4? I reverted the KSPe.Light to the previous version.

If even by reverting it, you are still getting this error, I will need to compile a special KSPe.Light for you in order to get it working, as it appears…

[Moshbot]

13 minutes ago, Lisias said:

Are you using the most recent release, 2.4.6.4? I reverted the KSPe.Light to the previous version.

If even by reverting it, you are still getting this error, I will need to compile a special KSPe.Light for you in order to get it working, as it appears…

Hm... Yes, I'm using this one. Also I'm using TweakableEverything and TweakScaleCompanion. Well, not such "using" as install them in hopes that they will fix this problem. But... you know the rest)

[Lisias]

2 hours ago, Moshbot said:

Hm... Yes, I'm using this one. Also I'm using TweakableEverything and TweakScaleCompanion. Well, not such "using" as install them in hopes that they will fix this problem. But... you know the rest)

TweakableEverything is completely unrelated to the current TweakScale (apparently they were tied in the past, but that was before my tenure).

About the Companions, some of them have a hard dependency on the very same KSPe.Light. So they will bork the same - I don't play Microsoft on my "products", I don't promote DLL Hell by spreading duplicated dependencies everywhere.

Having a dependency borking on you is extremely annoying, as you are seeing. On the bright side, once I detect the problem and fix it, EVERTYTHING ELSE gets fixed at the same time - and this is the reason we do DLLs.

May I ask your assistance? I will need to run some small programs on your rig in order to detect what's going on. Once I build them (the source will be available on github), could you - please - download them, run them and send me the results? 

I hope I will have something by tomorrow night (I would like today by night, but I will probably not be able).

Edited November 25, 2021 by Lisias
relevant link

[Lisias]

On 11/25/2021 at 1:52 AM, darthgently said:

Looking more at it, the attachment nodes aren't reverting to the pre-scaled points.  It is more like the scaling is being applied twice, or incorrectly.  See image at link.  Let me know if link doesn't work

https://imgur.com/a/UAD1jnW

Found the problem. The attachment nodes are being reset when you apply a Variant after scaling the part! [Nope! The attachments nodes are fine, it's the part that was being reset to the wrong place! See the METAR below!]

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

I will try to have this fixed for the WeekEnd, but I can't make any promises on it - it's more likely I will be able to work on it on the WeekEnd, and so the fix will be published by Sunday night or something.

Edited November 26, 2021 by Lisias
Nope!

[PlateGlassArmour]

7 hours ago, Lisias said:

I will try to have this fixed for the WeekEnd, but I can't make any promises on it

Was just coming here to help diagnose the "modkey copy reverting to previous geometry" issue, only to see that you're already on top of it.

In the goal of completeness, I'll document my observations just in case they help with the issue: Placing a part and then scaling it is fine. Placing a "new" copy of a scaled part is usually fine (i.e. subassembly.) Copying a part that has already been scaled uses the default geometry of the part for attachment. See pic.

Region A is the parts at the original scale. Region B parts were copied with the modkey-copy function, then scaled. Region C was scaled, then copied with the modkey-copy function and ran into clipping issues as though they were the original size when attaching.

Thanks for your work.

Edited November 26, 2021 by PlateGlassArmour

[Moshbot]

19 hours ago, Lisias said:

May I ask your assistance?

Of course, I will be happy to help!
Will wait the link then.
It will be some kind of ingame error detector? Or it searching in system itself? 

[Lisias]

13 hours ago, PlateGlassArmour said:

Was just coming here to help diagnose the "modkey copy reverting to previous geometry" issue, only to see that you're already on top of it.

In the goal of completeness, I'll document my observations just in case they help with the issue: Placing a part and then scaling it is fine. Placing a "new" copy of a scaled part is usually fine (i.e. subassembly.) Copying a part that has already been scaled uses the default geometry of the part for attachment. See pic.

Region A is the parts at the original scale. Region B parts were copied with the modkey-copy function, then scaled. Region C was scaled, then copied with the modkey-copy function and ran into clipping issues as though they were the original size when attaching.

For the sake of completude and transparency, last night I detected we have two problems stacked up!  

One it's this one you described. By some reason I still trying to figure out, when OnCopying a part (the code that handles the Alt+Click thingy), the part itself is correctly duplicated, but the parts attached to it is "reset" to the original place of its attachment node.

"Great, let's reapply the code that scaled the attachment nodes and we are done!", right? Well, nope  . If you detached the wrongly placed part, you will find that all attachment nodes are on the right place. And if you reattach the part, it will be placed correctly. This means that the attachment points are fine (otherwise the part would attach wrongly again).

This one is the one that it's bitting my SAS on this moment.

The other stacked problem is some stupidity I did when merging branches - a single line of code was removed that was restoring the scalings when you apply the subassembly in mirror mode - the original subassembly works, the copies didn't. This line was placed back, on the weekend I will release the fix.

In time, all these problems only affect parts with Variants, so this is the Variant code on KSP overruling TweakScale on some borderline situations. It's not exactly a bug on TweakScale, but a change on the running environment. But still…

 

10 hours ago, Moshbot said:

Of course, I will be happy to help!
Will wait the link then.
It will be some kind of ingame error detector? Or it searching in system itself? 

Thanks! It will be a small program to be run on the system itself, without KSP on the circuit.

In time, do you know if your NTFS filesystem has the case sensitivity activated?

Edited November 26, 2021 by Lisias
tyop! Surprised?

[Moshbot]

2 hours ago, Lisias said:

In time, do you know if your NTFS filesystem has the case sensitivity activated?

Don't know at all

[Lisias]

METAR

18 hours ago, Lisias said:

Found the problem. The attachment nodes are being reset when you apply a Variant after scaling the part!

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

Further testing suggests that the OnCopy code is behaving as expected.

What's happening is that, apparently, something is resetting the attached part's position using the prefab's value after calling OnCopy (damnit!!), undoing part of the job OnCopy did.

My current RiP (Research In Progress) is to determine if my thesis is right, and how to redo again the job after that Kraken damned code undid what OnCopy did.

Edited November 26, 2021 by Lisias
tyops. as usulla.

[ototcon]

Hey, I got a pop-up when I got to the main menu that sent me here. Something about some of my craft having fatal errors that are going to obliterate my saves.

Help?

I can send you my log file if you want it.

Edited November 27, 2021 by ototcon

[Lisias]

4 minutes ago, ototcon said:

Hey, I got a pop-up when I got to the main menu that sent me here. Something about some of my craft having fatal errors that are going to obliterate my saves.

Help?

Publish your KSP.log on dropbox or something and I will inspect it for the problem!

(wow… 4 minutes of SLA… a record!)

[Lisias]

METAR

The problem described below was solved.

Right now I'm playing a bit with KSP to see if I find something, or if something else had a regression due the stunt (hopefully not, as the latests refactoring allows me to keep support for different KSPs sandboxed, preventing exactly that a fix on one would bork the others).

Then I will attend some Real Life™ demands and, a bit later, I will try to fix some known issue more to stuff up the next Release that I will publish today night (or tomorrow early morning) on GitHub for the early adopters.

On 11/26/2021 at 3:17 PM, Lisias said:

METAR

Further testing suggests that the OnCopy code is behaving as expected.

What's happening is that, apparently, something is resetting the attached part's position using the prefab's value after calling OnCopy (damnit!!), undoing part of the job OnCopy did.

My current RiP (Research In Progress) is to determine if my thesis is right, and how to redo again the job after that Kraken damned code undid what OnCopy did.

— — — POST EDIT — — — 

Sometimes, you just can't win. I'm going back to bed, I will sleep the rest of the day. 

(had I not taking some medicine due the teeth, I would be getting wasted right now - Geez, what a week!)

 

 

Edited November 27, 2021 by Lisias
post edit. damn.

[Dioso]

tweakscale not working when i just got the recent update it isnt working when i try to scale it up the numbers change but it didnt scaled up

i am so annoyed that it cant work bruh.

https://imgur.com/a/wfLudJs

*giant log file snipped*

Edited November 28, 2021 by Gargamel
Log Snipped

[Lisias]

9 hours ago, Dioso said:

tweakscale not working when i just got the recent update it isnt working when i try to scale it up the numbers change but it didnt scaled up

I need the full KSP.log, please publish it on dropbox or something and then send me the link.

Additionally, do not publish long dumps of a log on Forum. It overloads pages, making things bad for everybody. Publish it on dropbox or something, quoting only small pieces of it if you think you found something interesting - I always need the full thingy anyway, and Forum can't cope with long and boring walls of text!

Cheers, and waiting for you log!

Edited November 28, 2021 by Lisias
Grumpyness factor detected and corrected. :)

[Moshbot]

On 11/25/2021 at 8:35 PM, Lisias said:

I will need to run some small programs on your rig in order to detect what's going on. Once I build them (the source will be available on github), could you - please - download them, run them and send me the results? 

Could you please mention me in comment, when it will be ready to download?

[Lisias]

1 hour ago, Moshbot said:

Could you please mention me in comment, when it will be ready to download?

I will! Things took a bit longer than I would like today, so this specific test ended up delayed.

Thanks!