[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.7.6 - 2024-0322

[viperwolf]

Is there a way I can make the robotic parts smaller. They are way to big, to build a small rover with, but maybe this would invite the Kraken to dinner.

[OnlyLightMatters]

6 hours ago, viperwolf said:

Is there a way I can make the robotic parts smaller. They are way to big, to build a small rover with, but maybe this would invite the Kraken to dinner.

Have you tried the All Tweak addon provided with @VoidCosmos and @Lisias ? Be careful, it configures a general scaling rule for all parts.

@PART[*]:HAS[!MODULE[TweakScale]]:FINAL
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = stack
    }
}

I don't know whether this kind of definition is still appropriate regarding TS 2.4.4.5 or not, you should test that on a separate installation.
 

[Lisias]

7 hours ago, viperwolf said:

Is there a way I can make the robotic parts smaller. They are way to big, to build a small rover with, but maybe this would invite the Kraken to dinner.

Proper support is eternal work in progress. Ideally it should be simple, merely a new ScaleExponent and some patches on the parts.

However....Cheese Happens. Sometimes, something inside KSP just refuses to collaborate or, worst, decide it's a good time to troll us.

Right now I'm fighting to identify the reason by some imported crafts from 1.10 just ICA on my face on launch (ICA = Instantaneous Craft Annihilation) : https://github.com/net-lisias-ksp/TweakScale/issues/162

Robotics parts are proven to be tricky to deal with, and my experience from the Infernal Robotics taught me that there're numerous opportunities to summon the Krakens when scaling such things due the somewhat more complex physics involved - you overscale or underscale something, and the Rage of the Krakens are summoned on you.

On a side note, the Serenity's robotics are still more complex than Infernal Robotics - as these things also have dampeners to care about!

 

23 minutes ago, OnlyLightMatters said:

I don't know whether this kind of definition is still appropriate regarding TS 2.4.4.5 or not, you should test that on a separate installation.

TS 2.4.4.x are somewhat more relisent to changes than 2.4.3 and older, because I resurrected the code that migrates scalings. If you have a part on your craft that was defined to have a defaultScale of 1.25, but later it was revised to 2.5 (a very common mistake), now TweakScale detects and rework the scaling to fix the craft.

However, it only works fine when the scaleType is Stack. If the new definitions change the scaleType to free, the migration code will probably fail, and so you will probably have problems when updating Add'Ons that provides new TweakScale patches.

Once you install All Tweak, you need to be extra careful when updating and installing add'ons with new or revised patches for TweakScale.

In time, since TweakScale does not have ScaleExponents for Serenity, the scaling will be cosmetic only: smaller or bigger, the robotics parts will behave exactly as the unescaled one: smaller robotics will be absurdly strong, and bigger robotics will be unexpectedly weak.
 

[Lisias]

METAR

I finally nailed he problem plaguing me and described on the last METAR.

I ruled out TweakScale as a source or even a trigger for this problem. TweakScale is merely a facilitator (or enabler?) for this problem, it happens that TweakScale just made the problem easier to be triggered.

What happens is that, under certain conditions, we cannot have a pretty heavy part (as a scaled up LargeTank full of ore) into a octoStrut, put some wheels on the strut (or in the adjascent one) and then have a SEQ9 and a Service Bay between the heaviest part (usuallly the LargeTank) and the root part of the craft!

I managed to reproduce the problem only when the Mk1 Inline Cockpit or the Mk1 Crew Cabin are the root part, but I failed to detect the reason - probably it just happened that any part would trigger the problem and I didn't tested enough.

I detected situations where rerooting the craft into the noseCone solved the situation, but in some other it did not. In all situations, rerooting the craft to the heaviest part solved the situation.

So my verdict is that there's something borking up the code that finds the heaviest part starting from the root part - if there's some specific parts between them (and the heaviest part is really heavy, something only easily obtainable using TweakScale...), and you have Wheels on a pretty sweet (or bitter?) spot (apparently another octoStrut), we have ICA (Instantaneous Craft Annihilation).

The whole story is on the https://github.com/net-lisias-ksp/TweakScale/issues/162 with the most interesting entries on the bottom of the page (the first ones are my failed attempts to zero in the problem).

In a nutshell, the following crafts are OK on my tests:

Spoiler

But these ones blow up on launch:

Spoiler

And the only difference between them are the order in which they were built!!! The very same end result can blow up on ICA or just works depending on the order you place the parts on it. 

There are also some other unexplainable explosions happening that may be related to this problem!

Now... HOW IN HELL I report this stunt on the KSP bug track??? o.O

Edited February 4, 2021 by Lisias
moar pics!

[kcs123]

15 minutes ago, Lisias said:

Now... HOW IN HELL I report this stunt on the KSP bug track??? o.O

Just put link on this forum post on bugtracker . Seriosly, I doubt that any of active squad crew would go trough this issue in such deep detail.

[AccidentalDisassembly]

New error to report, unfortunately - I don't know how to describe it (offset/placement issue), but I can describe how to reproduce it reliably. This is on a SLIGHTLY modded install with things like EEX, ClickThroughBlocker, etc. (utilities or enabler mods).

1. Place pod and central tank in VAB as if building a rocket.
2. Place decoupler in radial symmetry (part doesn't matter, just has to be insymmetry), then place another part (tank) on to the decoupler.
3. Scale up the tank that was just placed on to the decoupler (but leave the decoupler alone).
4. Now pick up *the decoupler* and re-place it in symmetry on the central core of the rocket (when it's picked up, it will pick up the scaled tank with it). Important to pick up the decoupler, not the tank that got scaled.
5. When placed, the tank generated by symmetry (on top of the decoupler generated by symmetry) will be offset outward from its decoupler.
6. If you pick up and re-place *the scaled tanks*, they will be repositioned correctly (as a workaround).

[Lisias]

1 hour ago, AccidentalDisassembly said:

New error to report, unfortunately - I don't know how to describe it (offset/placement issue), but I can describe how to reproduce it reliably. This is on a SLIGHTLY modded install with things like EEX, ClickThroughBlocker, etc. (utilities or enabler mods).

1. Place pod and central tank in VAB as if building a rocket.
2. Place decoupler in radial symmetry (part doesn't matter, just has to be insymmetry), then place another part (tank) on to the decoupler.
3. Scale up the tank that was just placed on to the decoupler (but leave the decoupler alone).
4. Now pick up *the decoupler* and re-place it in symmetry on the central core of the rocket (when it's picked up, it will pick up the scaled tank with it). Important to pick up the decoupler, not the tank that got scaled.
5. When placed, the tank generated by symmetry (on top of the decoupler generated by symmetry) will be offset outward from its decoupler.
6. If you pick up and re-place *the scaled tanks*, they will be repositioned correctly (as a workaround).

Nice one.

Technically, it may not be a bug  , it's a technical debit already described on the KNOWN ISSUES (the variant stunt). If you use a part without variants (as the MK1 Liquid Fuel Fuselage), things works fine.

But it appears to be a new symptom for the technical debit, it was my understanding that only parts with variants that changes attachment points would suffer from misbehaviours (as this specific code is not implemented yet), and I reproduced this problem using a FL-T400 that IIRC doesn't changes attachment points on changing variants - so I will not rule out a bug yet.

But I will need some time to tackle this down, I have a considerable back log both on TweakScale as on my day job...  and you have a work around for it.

I will advise as soon as I manage to steal find time to check this.
 

-- -- -- POST EDIT -- -- -- 

On Mirror Symmetry, the misbehaviour does not happen!! NOW I'm worried - if the damned thing was misbehaving the same both on Mirror and Radial, things would be way easier to understand and fix...

Edited February 3, 2021 by Lisias
tyops, as usulla....

[AccidentalDisassembly]

2 hours ago, Lisias said:

Nice one.

Technically, it may not be a bug  , it's a technical debit already described on the KNOWN ISSUES (the variant stunt). If you use a part without variants (as the MK1 Liquid Fuel Fuselage), things works fine.

But it appears to be a new symptom for the technical debit, it was my understanding that only parts with variants that changes attachment points would suffer from misbehaviours (as this specific code is not implemented yet), and I reproduced this problem using a FL-T400 that IIRC doesn't changes attachment points on changing variants - so I will not rule out a bug yet.

But I will need some time to tackle this down, I have a considerable back log both on TweakScale as on my day job...  and you have a work around for it.

I will advise as soon as I manage to steal find time to check this.
 

-- -- -- POST EDIT -- -- -- 

On Mirror Symmetry, the misbehaviour does not happen!! NOW I'm worried - if the damned thing was misbehaving the same both on Mirror and Radial, things would be way easier to understand and fix...

Sounds good! Workaround is fully functional so far as I can tell, so it's not a huge deal in any case! Thanks for the time you put into this.

[Krazy1]

16 hours ago, Lisias said:

Now... HOW IN HELL I report this stunt on the KSP bug track??? o.O

I guess I started your headaches with my big rover wheel issues. Well, sorry. I am having a lot of fun with it on the Mun though.  Thanks

16 hours ago, Lisias said:

And the only difference between them are the order in which they were built!!! The very same end result can blow up on ICA or just works depending on the order you place the parts on it. 

When I was doing the circumnavigation endurance challenge, someone was trying to help me and he built basically the same plane and it flew a little faster with less fuel burn. I always suspected that the build sequence or the root part was changing the drag model. So hard to prove that though. 

[Lisias]

11 hours ago, Krazy1 said:

I guess I started your headaches with my big rover wheel issues. Well, sorry. I am having a lot of fun with it on the Mun though.  Thanks

I was trying to build a Ore Train. Essentially 5 of that 4 wheeled car chained using Serenity Hinges - I need to play with these things a bit in order to understand how to scale them, but then I realised that I can't launch the monster due this bug.

Using Vessel Mover to launch it kinda solved the problem, but then I realised that I cannot switch vessels when the monster was on the runway otherwise they would ICA the same.

And since the problem kinda happened too with unscaled wheels too, these issues are unrelated - or perhaps not, but if they are related, "my" stunt suggests that the problem is on the KSP engine in both cases.

(Boy, I would hate to be a test pilot on these things - poor Jebediah!)

 

11 hours ago, Krazy1 said:

When I was doing the circumnavigation endurance challenge, someone was trying to help me and he built basically the same plane and it flew a little faster with less fuel burn. I always suspected that the build sequence or the root part was changing the drag model. So hard to prove that though. 

Well, now you have evidence to support your hypothesis.

Depending on how you build the craft, the weight is being miscalculated somehow (I think it's going to infinity, due the way Vessel Mover is behaving at spawning that monster). It's absolutely logical that drag et all can also be failing on the same problem.

I'm guessing that this could be related to using a octoStrut or even the strutCube? This last one has no physics relevance, I was told...

Edited February 4, 2021 by Lisias
Tipos! Surprised? =P

[Cochise]

Idk how to delete a comment what

Edited February 6, 2021 by Cochise

[Lisias]

On 2/3/2021 at 3:01 PM, AccidentalDisassembly said:

New error to report, unfortunately - I don't know how to describe it (offset/placement issue), but I can describe how to reproduce it reliably. This is on a SLIGHTLY modded install with things like EEX, ClickThroughBlocker, etc. (utilities or enabler mods).

I'm happy and somewhat embarrassed to tell you that the problem (apparently) was... humm.. overcomed [fixed].

It ended up that it was, indeed, a bug that I unadrevtidly introduced  while trying to tackle down a problem on Chain Scaling - I tried to fix it on the symptom, instead on going straight into the root cause as I misdiagnosed the source of the problem.

Well, I removed the "fix", and fixed the description of the issue what was handling it: https://github.com/net-lisias-ksp/TweakScale/issues/131

The Chain Scaling is now (yet more) broken on symmetries (apparently only on mirror!),  but the thing was not working properly anyway - so the after math is positive.

On the bright side, I also diagnosed the problem with the chain scaling (it is ignoring the symmetry of the parts, and so some parts were being handled more than once - one by the code, the additional ones by the KSP gut's echoing the changes over my changes). I will try to fix this too before a new release, but if I fail, at least your issue will be fixed on the next release tomorrow night.

-- -- POST EDIT -- -- 

humm... I may have found something else that can negatively influence my proposed scheduling... 

-- -- POST POST EDIT -- -- 

There was a bug hidden inside the bug!
https://github.com/net-lisias-ksp/TweakScale/issues/163

It's fixed. It will be published on the next release.

Edited February 7, 2021 by Lisias
oh, well... Kerbal proposes, Kraken disposes...

[AccidentalDisassembly]

11 hours ago, Lisias said:

I'm happy and somewhat embarrassed to tell you that the problem (apparently) was... humm.. overcomed [fixed].

It ended up that it was, indeed, a bug that I unadrevtidly introduced  while trying to tackle down a problem on Chain Scaling - I tried to fix it on the symptom, instead on going straight into the root cause as I misdiagnosed the source of the problem.

Well, I removed the "fix", and fixed the description of the issue what was handling it: https://github.com/net-lisias-ksp/TweakScale/issues/131

The Chain Scaling is now (yet more) broken on symmetries (apparently only on mirror!),  but the thing was not working properly anyway - so the after math is positive.

On the bright side, I also diagnosed the problem with the chain scaling (it is ignoring the symmetry of the parts, and so some parts were being handled more than once - one by the code, the additional ones by the KSP gut's echoing the changes over my changes). I will try to fix this too before a new release, but if I fail, at least your issue will be fixed on the next release tomorrow night.

-- -- POST EDIT -- -- 

humm... I may have found something else that can negatively influence my proposed scheduling... 

-- -- POST POST EDIT -- -- 

There was a bug hidden inside the bug!
https://github.com/net-lisias-ksp/TweakScale/issues/163

It's fixed. It will be published on the next release.

Hooray! I think. That's great news and also not great news (because, well... who wants to find problems?), but still definitely great news.

[Qyst]

So I'm having this problem but I don't know if it's a bug or I'm doing something wrong. It's affecting both Tweakscale and KSP Recall in exactly the same way:

I tried installing from CKAN and installing manually the latest releases of each mod from their Github, on fresh installs of the game, with the same results. If my eyes don't deceive me, it would seem the "should be installed" and "currently installed" locations are the same.

In-game Tweakscale seems to work just fine if I just hit Cancel (no idea how I would test KSP Recall) but the error messages are, let's say, ominous, so I thought I'd ask.

Game Ver.: 1.11.1.3066 64-bit from GOG

OS: Manjaro Linux 20.2.1

Mod Vers.: Module Manager 4.1.4.0, KSP Recall 0.0.5.0, TweakScale 2.4.4.5

Log file: https://www.dropbox.com/s/gg801ho7n23iqv3/BugReport-TweakScale-2-4-4-5-KSPRecall-0-0-5-0-Player.log?dl=0

As a side effect, both mods erroring together creates "You cannot show two modal windows at once" spam in the log file.

[TheKurgan]

@Lisias
I am using a few old mods from Spanner, Large boat parts, and such... they have a few "Fatal" errors but I have had no issues with them when I am playing that particular install.
The one issue I have, is the fact that I forget sometimes if I need to click "Ok" or "Cancel" to carry on with the game loading, and in my haste, I have often I clicked the wrong one and it closed my game on me that took 10 min to load.
Yes yes I know, it states in the warning which is which   but after you have read the warning a few times, it becomes TLDR.
A small request, could you please change it from "Ok" and "Cancel" to something like "Continue" and "STOP" ?

 

[Lisias]

11 hours ago, TheKurgan said:

@Lisias
I am using a few old mods from Spanner, Large boat parts, and such... they have a few "Fatal" errors but I have had no issues with them when I am playing that particular install.
The one issue I have, is the fact that I forget sometimes if I need to click "Ok" or "Cancel" to carry on with the game loading, and in my haste, I have often I clicked the wrong one and it closed my game on me that took 10 min to load.

 

Try installing this one : https://github.com/net-lisias-ksp/TweakScaleCompanion_SMCE . It adds up to date TweakScale support to Large Part Boats, and more are to come (now that I know people is still using it).

 

11 hours ago, TheKurgan said:

Yes yes I know, it states in the warning which is which   but after you have read the warning a few times, it becomes TLDR.
A small request, could you please change it from "Ok" and "Cancel" to something like "Continue" and "STOP" ?

Well, you state yourself the need to the current buttons: people just instinctively clicks on "OK", instead of coming here complaining.

But by you coming here complaining,  I could do something to fix the issue - see the link above.

Most old patches will stop to work somewhere in the next releases, and this is a fact - as I fix and improve things on TweakScale, some things that used to work will not work anymore because I'm getting rid of the kludges made in the past to cope with odd situations from third-parties. Now these odd situations are tackled down case by case on the Companions - but failing to install the Companions will render your savegames inconsistent.

There's no easy way out of the mess. I make your life easier the wrong way, I risk ruining your savegames - and once people's savegames are ruined, they will blame TweakScale (as it was done in the past) and not themselves by doing the wrong thing. And this will affect the add'on's reputation (as it did in the past).

I can offer you the same I did for @Cochise - I customised, non supported, completely "rogue" compiling of TweakScale without any the messages on screen you don't like, but you will be at your own as no support will be offered by this custom version.

 

11 hours ago, Qyst said:

So I'm having this problem but I don't know if it's a bug or I'm doing something wrong. It's affecting both Tweakscale and KSP Recall in exactly the same way:

Yikes.... Libraries are fantastic tools to save efforts by sharing code - until something goes wrong and all the tools break at once.

 

11 hours ago, Qyst said:

I tried installing from CKAN and installing manually the latest releases of each mod from their Github, on fresh installs of the game, with the same results. If my eyes don't deceive me, it would seem the "should be installed" and "currently installed" locations are the same.

Yep, but the strings themselves differ. The "not on" directory is missing a trailing Path.DirectorySeparatorChar.

This should not be happening anymore, I already had preemptively tackled this down some time ago. Obviously, I missed something. I'm working on it.

The need for this stunt is because, nowadays, when KSP finds another copy of a DLL, it shunts it to the first one it loads - but links it as it were the newest one. So you can have a older DLL code being running while the runtime reports being the newest one (this had bitten Module Manager's SAS beautifully by the way). Now, with TweakScale changing release by release, risking an older Scale.dll somewhere else on the system is just unacceptable - trying to diagnose problems with the runtime lying to you is plain suicide.

 

11 hours ago, Qyst said:

In-game Tweakscale seems to work just fine if I just hit Cancel (no idea how I would test KSP Recall) but the error messages are, let's say, ominous, so I thought I'd ask.

Definitively, you should had asked. Thank you for the report, and apologies by the mistake  (it's a bug - I reopened the issue where this should had been fixed in the past: https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/6 ).

If more than one TweakScale is found on the system, you should not keep running the game or you risk absolutely unpredictable consequences (going from nothing bad to completely ruining every savegame you open right on the spot).

Of course, it's not this case - the code that checks it is borking on you - I just need to know where and why. 

 

11 hours ago, Qyst said:

As a side effect, both mods erroring together creates "You cannot show two modal windows at once" spam in the log file.

Yep, known issue. Not sure when I will tackled this down, however - the criticality of this one is very low. Once the first modal shows, ideally the user should abort everything and get here burning my years  ears, and the KSP.log will have the needed information from the failed modal windows anyway.

 

Well, I'm working on it. I also need to understand why this happened on Manjaro but not on MacOS and Gentoo (where this was already tested), as everybody runs the very same code by the way.

Can you follow up on the https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/6 issue? I will need some more info about your rig... [Dont bother, I found where I forgot to add some things...]

Edited February 8, 2021 by Lisias
"Don't bother"

[viperwolf]

 I tried to search for this no luck, but probably my wording I never get right. Im not sure if this a TS thing or what.  All the wheels I put on rovers are making it slide across the terrain. They are uncontrollable, and cannot figure out how to fix it.  IS this a known issue?

Mods are

Tweakscale

Restock only

Rocket Sound Enhancement

[Lisias]

5 minutes ago, viperwolf said:

 I tried to search for this no luck, but probably my wording I never get right. Im not sure if this a TS thing or what.  All the wheels I put on rovers are making it slide across the terrain. They are uncontrollable, and cannot figure out how to fix it.  IS this a known issue?

Mods are

Tweakscale

Restock only

Rocket Sound Enhancement

In which KSP version? The sliding happens when the vessel is parked or when it's running?

If you are on [1.8.0 <= KSP <= 1.10.1] and the sliding happens with parked crafts (it affects Kerbals too) , then install the latest KSP Recall. It's a bug on KSP itself, and Recall kinda work around the problem.

(I suggest waiting a few hours, I'm finishing an update with an important fix on a library it uses)

Otherwise, please publish your craft file so I can give it a look - it's easier to look for problems with a concrete example on hands!

[viperwolf]

Just now, Lisias said:

In which KSP version? The sliding happens when the vessel is parked or when it's running?

If you are on [1.8.0 <= KSP <= 1.10.1] and the sliding happens with parked crafts (it affects Kerbals too) , then install the latest KSP Recall. It's a bug on KSP itself, and Recall kinda work around the problem.

(I suggest waiting a few hours, I'm finishing an update with an important fix on a library it uses)

Otherwise, please publish your craft file so I can give it a look - it's easier to look for problems with a concrete example on hands!

As soon as I launch it starts sliding. Just using a basic rover module and wheels it will do it though.

Im running latest KSP with the latest CKAN of tweakscale.   Ill load the craft file, I just have to search how.

 

 

 

 

[Lisias]

5 minutes ago, viperwolf said:

As soon as I launch it starts sliding. Just using a basic rover module and wheels it will do it though.

Im running latest KSP with the latest CKAN of tweakscale.   Ill load the craft file, I just have to search how.

So KSP Recall will not help.

Zip the thing and post it here https://github.com/net-lisias-ksp/TweakScale/issues/92 with a link to your post. I will check it.

(I'm firing up my 1.11.1 test bed anyway, let's see what I get)

[viperwolf]

5 minutes ago, Lisias said:

So KSP Recall will not help.

Zip the thing and post it here https://github.com/net-lisias-ksp/TweakScale/issues/92 with a link to your post. I will check it.

(I'm firing up my 1.11.1 test bed anyway, let's see what I get)

Ok Thank You, I have to find another zip format bc it wont accept winrar I guess. So ill just wait until after the update, no use wasting your time.

[Lisias]

39 minutes ago, viperwolf said:

Ok Thank You, I have to find another zip format bc it wont accept winrar I guess. So ill just wait until after the update, no use wasting your time.

Well... Anyway, I already had fired the thing.  I loaded the Sample Craft called Bug-E Buggy and made some tests:

Scaling things down too much will mess up the wheels coliders, but the thing didn't wandered away on launch.

(I removed some non-scalable parts from the vessel).

So I scaled up the thing (and had to add some auto-struts to it).

And no drifting.

On a side note, this last test hinted me there're something wrong on the scaling the colliders - so this test was not useless. Thanks!

In a way or another, this is something on your installment. Mine works fine - I really need a concrete example from you so I can keep digging on the matter.

[viperwolf]

5 minutes ago, Lisias said:

Well... Anyway, I already had fired the thing.  I loaded the Sample Craft called Bug-E Buggy and made some tests:

Scaling things down too much will mess up the wheels coliders, but the thing didn't wandered away on launch.

(I removed some non-scalable parts from the vessel).

So I scaled up the thing (and had to add some auto-struts to it).

And no drifting.

On a side note, this last test hinted me there're something wrong on the scaling the colliders - so this test was not useless. Thanks!

In a way or another, this is something on your installment. Mine works fine - I really need a concrete example from you so I can keep digging on the matter.

The wheels I use are scaled down a bit, so that may be it. Ill get a short video and the file for you soon. Ill also test out regular size and things like that before hand. Thank you for your time and where is your donate page?

[viperwolf]

18 hours ago, Lisias said:

Well... Anyway, I already had fired the thing.  I loaded the Sample Craft called Bug-E Buggy and made some tests:

Scaling things down too much will mess up the wheels coliders, but the thing didn't wandered away on launch.

(I removed some non-scalable parts from the vessel).

So I scaled up the thing (and had to add some auto-struts to it).

And no drifting.

On a side note, this last test hinted me there're something wrong on the scaling the colliders - so this test was not useless. Thanks!

In a way or another, this is something on your installment. Mine works fine - I really need a concrete example from you so I can keep digging on the matter.

No use for me to post or bother you anymore. You er already working on the issue. It indeed only happens when I downscale the wheels.  Normal size they work fine. Thank You as always.

 

Side Note: Where do I donate to you?

[Qyst]

On 2/8/2021 at 12:38 AM, Lisias said:

[Dont bother, I found where I forgot to add some things...]

Glad to hear you managed to fix it and it's good to know it's safe to use. Thanks for your hard work on this really useful mod!