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

[Lisias]

3 hours ago, Black034 said:

I meant the Tantares_Tweakscale cgf in the Patches folder, I'm not really sure what to do with it honestly :c 

How I missed that add-on? Great one! And exactly what I was needing.

Well, in theory, should be simple: Download the 2.4.0.4 PreRelease on the first post of this thread, download Tantares.zip and TantaresLV.zip, unzip them on the GameData from your KSP, and that's it.

The Tantares_TweakScale.cfg is "run" automatically, and patches some parts from Tantares to suppor TweakScale. The parts that the current config patches are the ones between "@PART[" and "]".

You can create more patches by copying this file into somewhere else (do not edit the original, not only you loose your "warranty", but you will also loose your changes on updates), and changing the names for the ones you want to add support. Delete everything you do not edit (to avoid double patching), and see what happens.

About the Tantares_TweakScale.cfg, I found no obvious problems except that I didn't found some parts on the Tantares zip file. Perhaps name changes? If yes, we need to update it.

I checked, and only a few parts are, indeed, patched. The L-K15 Luna Lander Can works fine - besides not increasing the crew capacity.

I also found this that can be of use:

https://github.com/julienrosa/TantaresRebalanceOverhaul

Edited October 26, 2018 by Lisias
more info, and some bad grammars

[TranceaddicT]

On 10/25/2018 at 8:17 AM, Lisias said:

As an addendum, sooner than later you get parts so heavy that you must start mangling with AutoStruts. And even Kerbal-Joint-Reinforcement too.

Just for the lulz, I once made a contraption so heavy that I had to use AutoStruts, then I had to add Struts, and I had to make sure that I AutoStrutted the Struts.

Brings new meaning to 'strut your stuff'. (You may need to make an UrbanDictionary entry about it. )

22 hours ago, AccidentalDisassembly said:

Just a thought for a future update - one nice thing to do in TweakScale would be to replace very patch that creates AND assigns variables like this:

{
type = stack
}

...with the %type = stack create-or-replace thingy in ModuleManager.

The reason for this is simply to prevent scaling from not working in the even that other people (like me) have custom patches that accidentally assign a "type" or whatever BEFORE TweakScale does. Then, when TweakScale patches, it creates a second type rather than changing the existing one. Alternatively, maybe have it so that TweakScale just picks one of the assigned "types" and doesn't break when someone goofs on the patches... dunno.

Probably a fairly quick change with Notepad++ ... maybe.

Or you could use :AFTER[TweakScale] so it gets applied ... wait for it ... after TweakScale.

You could even use :FINAL so the patch gets applied during ModuleManagers ... wait for it ... FINAL pass.

[Black034]

Very informative, I'll get cracking then

Thanks!

Edited October 27, 2018 by sumghai
Removed empty quote

[pellinor]

2 hours ago, TranceaddicT said:

Or you could use :AFTER[TweakScale] so it gets applied ... wait for it ... after TweakScale.

Yes this will work. Just as :BEFORE[TweakScale] works because the patches that come with TweakScale take effect at an earlier time. So things are not as trivial as they seem. Actually I like the idea of preferring "%type=..." just because it leads to more robust behavior.

[Lisias]

ANNOUNCE

Pre Release 2.4.0.6 available for testing, see OP for links.

The NREs appears to be fixed. TweakScale is proved to work fine under the following environments:

• KSP 1.4.3 (with and without Making History) with TweakScale 2.4.0.5, B9* and Impossible Innovations
• KSP 1.4.5 (with and without Making History) with TweakScale 2.4.0.5, B9* and Impossible Innovations
• KSP 1.5.1 (with and without Making History) with TweakScale 2.4.0.5, B9* and Impossible Innovations

KSP 1.5.1 is now officially supported - or, at least, didn't capsized on me yet.  

TweakScale is good to go gold. If everything works fine to the end of the day, Tomorrow morning we will have a Proper Release for TweakScale!  

Known Issues:

• An Unholy Interaction between add-ons is currently responsible for B9PartsSwitch borking on TweakScale.
  • This is not on B9's shoulders, everything is working fine on a reduced add-on installment.
  • This is not on TweakScale shoulders neither. 
• Another Unholy Interaction between add-ons (perhaps the same one?) is causing some NREs on TweakScale at initialization on the parts used for Kerbal EVA.
  • This is not on TweakScale shoulders. Everything works fine on a reduced add-on installment.
  • This doesn't cause any collateral effect, so I decided to keep things this way
    • with luck, someone else can help on pinpointing the cause.]

NOTE:

To the ones still willing to live dangerously and are taking their chances with the Experimental release, please update to the latest PreRelease of KSPe. And backup your savegames!  

Edited October 27, 2018 by Lisias
Uh… Forgot something on the 2.4.0.5… =/

[Lisias]

Anyone here is using TweakableEverything? I would be very grateful if one could help me testing this before going gold!

[Lisias]

#sigh I forgot to merge a code on the 2.4.0.5.

The current new PreRelease is the 2.4.0.6, and the previous one silently ceased to exist.  

[Lisias]

TweakScale 2.4.0.6 gone Gold.

Available on CurseForge, GitHub and SpaceDock.

CKAN is Work in Progress. [It's done already.]

Edited October 28, 2018 by Lisias
new info. Craft Manager has no role in this play.

[TranceaddicT]

12 hours ago, Lisias said:

Anyone here is using TweakableEverything? I would be very grateful if one could help me testing this before going gold!

I'll be back home late tomorrow.  I can set up a test install to assist. What is your base modded install for testing purposes?  

[Lisias]

4 hours ago, TranceaddicT said:

What is your base modded install for testing purposes?  

Everything and the kitchen's sink.   A copy of your running KSP installment would be perfect, as it would be a mirror of the "production line". It's what I do after the SmokeTests (controlled, minimalistic setups).

This also make easier to spot subtle errors, as you know how your setup behave, and will note fast if something "became weird".

My current concerning is what I call "Unholy nInteractions between add-ons".   

[Lisias]

Now that we have a good dozen hours of release, about 1500 downloads and the skies didn't fall (yet) on my head  , I think we can go back to the ideas for future development.

On 10/17/2018 at 12:11 PM, FreeThinker said:

A: One thing that always annoyed in Tweakscale me is the tech unlocking. You can unlock a specific tweakscale size only by a single tech. Instead, I propose it will also be the combination of the part unlocking tech and the specific size unlocking. That way I can unlock fuel tank with a fuel tech but only allow a bigger tweakscale sizes after unlocking colossalRocketry.

On 10/17/2018 at 6:45 PM, pellinor said:

Now I understand. So if no scale is allowed the current behavior is probably to allow the defaultScale. This looks like a workaround because once the partModule comes to life it is too late to hide the part. Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful.

I find this idea a really good one. In my first career savegame, I borked beautifully due abusing TweakScale. I progressed too fast - I probably should had tried an unmodded game first, but I was hungry for using some of that magnificent mods I was using on sandbox for months (using blimps on career is something that I really recommend!).

Such implementation would allow green players (as I was) to use TweakScale on their game without unattended cheating.  

However… TweakScale would have to proactively handle the Tech Tree itself, as "boolean operations" on Tech Tree requirements are not (to my best acknowledge) implemented on KSP. Since all the metadata would be on the GameDatabase, I don't see difficulties on implementing the code, but I see a lot of friendly fire happening with fellow modders that also handle the TechTree. HideEmptyTechTreeNodes is one those feet would be probably stomped by me.

Should TweakScale act before or after HETT? Should I handle both situations, as I don't have control on the order the plugins are executed on Space Center Scene? How about some mods "hijacking" the TechTree unconditionally, forcing the others add-ons to "hijack" it back? How I would insert myself, deterministically, in such chain of "hijecks" in order to prevent a huge Kraken's Poo Storm?  

Edited October 29, 2018 by Lisias
typing late of night, misplaced some words. fixing.

[Tyko]

23 hours ago, Lisias said:

Now that we have a good dozen hours of release, about 1500 downloads and the skies didn't (yet) fall on my head  , I think we can go back to the ideas for future development.

Thanks! Are you still considering adding 1.875 and some other interstitial sizes (.3125, .9375, 1.875, 3.125)? I've written and tested all the code already. Obviously you'd want to do more testing, but I've at least gotten you part way.

[Lisias]

4 hours ago, Tyko said:

Thanks! Are you still considering adding 1.875 and some other interstitial sizes (.3125, .9375, 1.875, 3.125)? I've written and tested all the code already. Obviously you'd want to do more testing, but I've at least gotten you part way.

I plan to support Stock on the main download. Too much options are not necessarily a good option to the end user, most people usually resent too many options.

On the other hand, some people do like "MOAR OPTIONS", and I agree with you that I should think on something.

Disclaimer: pure brainstorming on the Spoiler below. Nothing will be changed on the Orthodox branch and, so, nothing will be change on the Mainstream Releases.

Spoiler

I am considering to "split up" the current TweakScale in sub-packages, where the most trickery add-ons to be supported would have a dedicated, complementary package to be downloaded.

Let's suppose that something on "Impossible Innovations" would need a change on TweakScale that could impact a very widely used "Mod X" by some hypothetical reason. Well, this guy would download 'TweakScae-X.Y.Z.z.zip" and "TweakScale-ImpossibleInnovations-X.Y.Z.z.zip" - so if something goes wrong (and something always can go wrong when enough mods are installed on your KSP), at least such mishap would affect only the guys that use "TweakScale-ImpossibleInnovations", and not the whole userbase - this would let me diagnose the problem way faster too.

This is something way ahead on the time yet, and, obviously, will be tested first on the Heterodox branch first. NO WAY this will implemented on Orthodox without a good set of trials on Heterodox first, so please, rest assured that nothing will  change on the short run.

Assuming this will work fine on Heterodox and this "sub-packs" idea sticks, an additional pack of settings for "Advanced Users" can have your patches added. And then, we could keep both sides of the equation satisfied.

Sounds viable to you?

 

[AccidentalDisassembly]

4 hours ago, Lisias said:

I plan to support Stock on the main download. Too much options are not necessarily a good option to the end user, most people usually resent too many options.

On the other hand, some people do like "MOAR OPTIONS", and I agree with you that I should think on something.

Disclaimer: pure brainstorming on the Spoiler below. Nothing will be changed on the Orthodox branch and, so, nothing will be change on the Mainstream Releases.

  Hide contents

I am considering to "split up" the current TweakScale in sub-packages, where the most trickery add-ons to be supported would have a dedicated, complementary package to be downloaded.

Let's suppose that something on "Impossible Innovations" would need a change on TweakScale that could impact a very widely used "Mod X" by some hypothetical reason. Well, this guy would download 'TweakScae-X.Y.Z.z.zip" and "TweakScale-ImpossibleInnovations-X.Y.Z.z.zip" - so if something goes wrong (and something always can go wrong when enough mods are installed on your KSP), at least such mishap would affect only the guys that use "TweakScale-ImpossibleInnovations", and not the whole userbase - this would let me diagnose the problem way faster too.

This is something way ahead on the time yet, and, obviously, will be tested first on the Heterodox branch first. NO WAY this will implemented on Orthodox without a good set of trials on Heterodox first, so please, rest assured that nothing will  change on the short run.

Assuming this will work fine on Heterodox and this "sub-packs" idea sticks, an additional pack of settings for "Advanced Users" can have your patches added. And then, we could keep both sides of the equation satisfied.

Sounds viable to you?

 

With respect to one aspect of your proposal in specific: it would be both easy and handy to simply create an "Extras" folder that would always be present inside the main TweakScale package, and in that folder include either:

A) individual config files that add specific sizes to scaletypes, e.g. a Size3.125.cfg that adds that specific size, and additional configs for additional sizes, so people can pick and choose, OR

B) A "TweakScaleExtended.cfg" in the extras folder which includes many additional size increments at the same time.

That way, people looking for additional scales don't have to go very far. Seems like a good solution for the additional scale increments (which, I agree, should not be included by default).

Then, with respect to splitting other functions out... dunno about that one, sorry!

[Lisias]

9 hours ago, AccidentalDisassembly said:

With respect to one aspect of your proposal in specific: it would be both easy and handy to simply create an "Extras" folder that would always be present inside the main TweakScale package, and in that folder include either:

That was my initial thought. But once some specific per-mod code is unavoidable, where some mods support would be mutually exclusive (i.e., if you install TweakScale_ModX… you should not install TwekScale_ModY…), perhaps could be a good idea to expand the concept to optional sizes.

Usually, users don't want to cope with files, they want to check up what they want on a user interface, click "Do it" and forget about.

The current package would be a meta-package, with dependencies that would build the current status-quo (or near it, as I think that some mutually exclusive support are already there, being that the reason for some glitches on my KSP installment). So, minimal fuss with legacy.

[TranceaddicT]

On 10/28/2018 at 4:58 AM, Lisias said:

Everything and the kitchen's sink.   A copy of your running KSP installment would be perfect, as it would be a mirror of the "production line". It's what I do after the SmokeTests (controlled, minimalistic setups).

This also make easier to spot subtle errors, as you know how your setup behave, and will note fast if something "became weird".

My current concerning is what I call "Unholy nInteractions between add-ons".   

Wait, you want a copy of my install???  All (currently) 3.2GB?  I can do that, or do you want the .ckan file, here.?

As for the newest release ...

I not gotten deep into a game yet so the only error I have currently encountered is associated with part setup for AirplanePlus/Parts/Structure and Fuel/size2parts/size2tank.cfg

181030T104651.972 [ERROR] [TweakScale.PrefabDryCostWriter+<WriteDryCost>d__4.MoveNext] TweakScale::PrefabDryCostWriter: negative dryCost: part=size2Fuselage, DryCost=-3.814697E-05

I'm still nailing down some trouble with SettingsMaster, but I think I"ve got it narrowed sufficiently for LinuxGuruGamer to work with; so you're next in line.  (Get ready.)

It's your turn monkey. 
 

Edited October 30, 2018 by TranceaddicT

[TranceaddicT]

5 hours ago, Lisias said:

That was my initial thought. But once some specific per-mod code is unavoidable, where some mods support would be mutually exclusive (i.e., if you install TweakScale_ModX… you should not install TwekScale_ModY…), perhaps could be a good idea to expand the concept to optional sizes.

Usually, users don't want to cope with files, they want to check up what they want on a user interface, click "Do it" and forget about.

The current package would be a meta-package, with dependencies that would build the current status-quo (or near it, as I think that some mutually exclusive support are already there, being that the reason for some glitches on my KSP installment). So, minimal fuss with legacy.

With your initial (hidden) idea, you are creating Rabbithole Field; something you don't want to go down.

Might I suggest taking a look at the extensibility function of  ContractConfigurator.  This might be a better option for you by giving the mod author the tools to extend TweakScale in a way that is elegant but does not add burden to maintaining TweakScale.

[Tyko]

What about using PatchManager from @linuxgurugamer ? It gives an in-game interface which allows players to choose amongst optional patches.

 

[Lisias]

3 hours ago, TranceaddicT said:

Wait, you want a copy of my install???  All (currently) 3.2GB?  I can do that, or do you want the .ckan file, here.?

 

No, no! I want you to run it on a copy if your KSP install!!! 

3 hours ago, TranceaddicT said:

I not gotten deep into a game yet so the only error I have currently encountered is associated with part setup for AirplanePlus/Parts/Structure and Fuel/size2parts/size2tank.cfg

181030T104651.972 [ERROR] [TweakScale.PrefabDryCostWriter+<WriteDryCost>d__4.MoveNext] TweakScale::PrefabDryCostWriter: negative dryCost: part=size2Fuselage, DryCost=-3.814697E-05

Humm… Now I'm worried (anyone remember Alfred E. Neuman?). I have AirplanePlus on the very same installment I found this DryCost thing, but only (some) B9 parts got this error.

Could you, please, send me your KSP.log? All the info I will need (as mods installed) is there.

post-edit: the .ckan file was helpful, thanks! But the KSP.log will be yet more helpful!

Edited October 30, 2018 by Lisias
moar info

[Lisias]

57 minutes ago, TranceaddicT said:

Might I suggest taking a look at the extensibility function of  ContractConfigurator.  This might be a better option for you by giving the mod author the tools to extend TweakScale in a way that is elegant but does not add burden to maintaining TweakScale.

 

Just now, Tyko said:

What about using PatchManager from @linuxgurugamer ? It gives an in-game interface which allows players to choose amongst optional patches.

The problem appears not to be on the patches, but on the code itself.

There're a combination of mods that, when installed together with TweakScale, plays havoc somewhere on KSP.

One mod that was being "victim" of this combination was B9. In testbeds with TweakScale and B9 only, everything works fine. But on my installment with about 140 mods installed, something makes B9 go crazy, that so makes TweakScale goes crazy (or vice versa), and then some parts became anchored in the tridimensional world - and things explode by stress when you hit the gas pedal.

Now I have notice that one mod that I have installed on the same installment and until the moment had no entry on the log, now is being "listed" on TranceaddicT's KSP.

So things appears to be not deterministic - the "taint" appears to choose another mod in circumstances that happens on his KSP.

So, ContractConfigurator and PatchManager cannot help me on this. At least, not yet.

[Tyko]

4 minutes ago, Lisias said:

 

The problem appears not to be on the patches, but on the code itself.

There're a combination of mods that, when installed together with TweakScale, plays havoc somewhere on KSP.

One mod that was being "victim" of this combination was B9. In testbeds with TweakScale and B9 only, everything works fine. But on my installment with about 140 mods installed, something makes B9 go crazy, that so makes TweakScale goes crazy (or vice versa), and then some parts became anchored in the tridimensional world - and things explode by stress when you hit the gas pedal.

Now I have notice that one mod that I have installed on the same installment and until the moment had no entry on the log, now is being "listed" on TranceaddicT's KSP.

So things appears to be not deterministic - the "taint" appears to choose another mod in circumstances that happens on his KSP.

So, ContractConfigurator and PatchManager cannot help me on this. At least, not yet.

Ouch, those issues are a pain to track down. Do you need to go through the mods you're using one at a time and look for which ones include TS patches? TS itself seems pretty benign in that it applies scaling to discrete parts. I know there are "tweakscale everything" patches out there, but don't know of any mods that have a global patch like that.

[TranceaddicT]

5 minutes ago, Tyko said:

Ouch, those issues are a pain to track down. Do you need to go through the mods you're using one at a time and look for which ones include TS patches? TS itself seems pretty benign in that it applies scaling to discrete parts. I know there are "tweakscale everything" patches out there, but don't know of any mods that have a global patch like that.

Yeah, this is a matter of 'finding the silent voice in the screaming mob.'

[Lisias]

Just now, Tyko said:

Ouch, those issues are a pain to track down. Do you need to go through the mods you're using one at a time and look for which ones include TS patches? TS itself seems pretty benign in that it applies scaling to discrete parts. I know there are "tweakscale everything" patches out there, but don't know of any mods that have a global patch like that.

I already did it. The mods, alone, works fine. It's a combination of mods the trigger for the Kraken poo storm.

Edited October 30, 2018 by Lisias
typo

[TranceaddicT]

MWAHA-MWAHA-MWAHAHAHAHAHA

 

I've located the kerbalEVA culprit ... HullcamVDS; specifically, FirstPersonEVA.cs.

 

//Add EVA camera to all Kerbals on EVA
[KSPAddon(KSPAddon.Startup.MainMenu, true)]
public class initKerbalEVA : UnityEngine.MonoBehaviour {
    public void Awake() {
           
        ConfigNode EVA = new ConfigNode("MODULE");
        EVA.AddValue("name", "EVACamera");
        EVA.AddValue("cameraName", "EVACam");

        try {
                        
            PartLoader.getPartInfoByName("kerbalEVA").partPrefab.AddModule(EVA);
        }
        catch{}
        try { PartLoader.getPartInfoByName("kerbalEVAfemale").partPrefab.AddModule(EVA); 
        }
        catch {}
    }
}

 

[Lisias]

On 10/31/2018 at 2:49 AM, TranceaddicT said:

I've located the kerbalEVA culprit ... HullcamVDS; specifically, FirstPersonEVA.cs.
 

Makes sense! I have it too on my Installment!

Tonight I'll fire up a testbed with minimum mods to reproduce the problem!

— POST—EDIT — 

False alarm, or perhas this is not the only trigger. I made a copy of my installment where this problem happens determiniscally, deleted HullCameraVDS and fire it up (after deleting Module Manager cache) and the exception are still there.

[FALSE FALSE ALARM!  IT WAS EXACTLY THIS CODE! SEE MORE AHEAD!]

Spoiler

[EXC 13:38:30.812] NullReferenceException: Object reference not set to an instance of an object
        IRSequencer_v3.Gui.UIAssetsLoader.LoadBundleAssets ()
        IRSequencer_v3.Gui.UIAssetsLoader+<LoadBundle>d__0.MoveNext ()
        UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)
[ERR 13:38:30.935] [TweakScale] ERROR: [TweakScale] Exception on kerbalEVA.prefab.Modules.Contains: System.NullReferenceException: Object reference no
t set to an instance of an object
  at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0
  at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0
  at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__4.MoveNext () [0x00000] in <filename unknown>:0

[ERR 13:38:30.936] [TweakScale] ERROR: [TweakScale] Exception on kerbalEVAfemale.prefab.Modules.Contains: System.NullReferenceException: Object refere
nce not set to an instance of an object
  at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0
  at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0
  at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__4.MoveNext () [0x00000] in <filename unknown>:0

 

Next step is to build a clean KSP installment with a minimum set of mods *and* HullCameraVDS in order to have (or not) a counter-evidence. But this. just by night for sure.  

Edited November 2, 2018 by Lisias
NEW INFORMATION