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

[Lisias]

On 7/20/2020 at 1:03 AM, LittleBitMore said:

I noticed a few stock non-DLC parts, specifically some antennas and dishes, do not function with Tweakscale and have not ever functioned with it.

Antennas and dishes? They are supported (or should be). This is the link for the lines where the support is applied on TweakScale 2.4.3.19.

The following Antennas and dishes are supported:

• SurfAntenna, Communotron 16-S
• longAntenna, Communotron 16
• mediumDishAntenna, Communotron DTS-M1
• commDish, Communotron 88-88
• HighGainAntenna, Communotron HG-55

However, you are right about 5 others:

• HighGainAntenna5, HG-5 High Gain Antenna
• RelayAntenna5, RA-2 Relay Antenna
• RelayAntenna50, RA-15 Relay Antenna
• RelayAntenna100, RA-100 Relay Antenna

These last 5 are deactivated, as you can see on the link above. The reason given for their deactivation is that their functionalities does not scales with the size, rendering the scaling useless. However, it's 4 years since the deactivation, lots of things had changed on KSP and there's a good chance I can manage to make them work now.

There're some more parts that are deactivated on the patches right now, as Wheels, Fairings and Decouplers.

All of these (but the fairings) will be worked out on the 2.4.4.x series, and what can be scaled will be - Wheels are already scalable on the TS 2.5 Beta, but it didn't gone to Mainstream yet because their buoyancy is ridiculous and I don't know what else is being scaled this way.

 

One very important thing to remember is that scaling can be problematic if not done correctly, as the following video demonstrates:

Spoiler

 

And that's the reason it sometimes takes a long time to get done.

Edited July 21, 2020 by Lisias
moar pics!

[LittleBitMore]

I see. Good luck with all of this, it sounds very difficult.

[Krazy1]

17 hours ago, Lisias said:

Wheels are already scalable on the TS 2.5 Beta, but it didn't gone to Mainstream yet because their buoyancy is ridiculous and I don't know what else is being scaled this way.

Didn't expect that video ending! It's unfortunate your game runs so slow... like 1/4 real time? You are patient. I get the yellow clock a lot too but not that slow unless there's 800 parts. 

Big wheels would be nice. I tried so hard to make a giant VTOL rover. But the wheels kept breaking. When I used many wheels, on uneven ground, it concentrates all the force on a few wheels and they break. The XL3 wheels just wouldn't turn it either.

[Lisias]

9 hours ago, Krazy1 said:

Didn't expect that video ending! It's unfortunate your game runs so slow... like 1/4 real time? You are patient. 

It does not - most of the time. That machine was a MacMini i5, and the video was made after the Apple's patch that crippled the CPU to cope with the Intel bug of MeltDown and Spectre. And it was running also the QuickTime, recording the gaming.

The machine was just overloaded.

The funny thing is that now I'm on a MacMini running on a i7, and guess what... The game runs better, but QuickTime borks on recording videos - sigh. I'm buying an external recorder as soon as my wallet agrees with it.

Edited July 21, 2020 by Lisias
I need more coffee.

[Vanamonde]

Some comments have been removed. You are free to disagree with each other, but you are not free to derail threads with personal arguments. Please keep the tone polite. 

[JcoolTheShipbuilder]

hmmm... how do i edit the config to allow bigger parts? like... a 50m part would be cool, but i somehow managed to do it one time, but then i cant do it anymore...

[Lisias]

16 hours ago, JcoolTheShipbuilder said:

hmmm... how do i edit the config to allow bigger parts? like... a 50m part would be cool, but i somehow managed to do it one time, but then i cant do it anymore...

Not that hard, but a bit cumbersome for doing it right. As always, wet your feet cautiously, as too much big parts can lead to some physics attributes bigger than the physics engine can handle - if you have an incredibly big mass dividing something small (lift, by example), you can get a value too close to zero, and injecting this number on the physics engine can lead to some NaNs, and by then...

Spoiler

 

So I don't advise to blindly shove this stunt on everything, but only on the few selected parts you want to have that size (and, so, minimising your surface of exposition to the problem):

If the part uses a ScaleType called stack, use this:

@PART[my-big-fancy-part]:FINAL
{
        %MODULE[TweakScale]
        {
                //type = xxx - use this for stack and stack_square only!
                //defaultScale = xxx - Don't touch this thing!
                %scaleFactors   = 0.1,  0.3,   0.625, 1.25,  1.875, 2.5,  3.75, 5.0, 7.5, 10, 20, 50
                %incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2, 0.5
        }
}

If the part uses a ScaleType called free, use this one:

@PART[my-big-fancy-part]:FINAL
{
        %MODULE[TweakScale]
        {
                //type = xxx - use this for free and free_square only!
                //defaultScale = xxx - Don't touch this thing!
                %scaleFactors   = 10 , 50 , 100 ,  200 , 400, 5000
                %incrementSlide = 1 ,  1 ,   2 ,    5, 50
        }
}

If the part uses a ScaleType called surface (some oldies still use it, and I like it more than free):

@PART[my-big-fancy-part]:FINAL
{
        %MODULE[TweakScale]
        {
                //type = xxx - use this for surface only!
                //defaultScale = xxx - Don't touch this thing!
                %scaleFactors   = 0.1  , 0.5  , 1    , 2     , 4 , 50
                %incrementSlide = 0.01 , 0.01 , 0.02 , 0.05, 5
        }
}

 

Shove these stunts on a config.cfg file somewhere on your gamedata (I suggest GameData/__LOCAL/something for easy access and remembering) and you are set.

Edited July 24, 2020 by Lisias
Eternal typos of the Englishless Mind

[JcoolTheShipbuilder]

sooo... i have to do this with every part i want to do it to?

[Lisias]

3 hours ago, JcoolTheShipbuilder said:

sooo... i have to do this with every part i want to do it to?

Yep.

You can use wildcards and carefully crafted :HAS patches, but since I expect that some parts would fail before others, you will probably ending up fallbacking to single part patching anyway - it's possible that some parts can be scaled to 100 meters, while others would not reach 30 or 40 without blowing up something.

In a way or another, the joints will be easily overloaded - you will need KJR for sure sooner or later.

Check the hotfixes and workarounds on the Extras folder of the TweakScale distribution for examples of how to write your patches.

-- -- -- BRUTE FORCE POST MERGE -- -- -- 

On 7/19/2020 at 5:29 PM, Lisias said:

What I did wrong: see https://github.com/net-lisias-ksp/TweakScale/issues/125 , things will be explained there somewhere between tonight and tomorrow (I've got incredibly busy this whole week, today included).

I took way more time to fill you guys because I ended up discovering that, well, I didn't really borked on it and needed time to do a lot of testings in order to be really sure this time. Now I know that I could do better, but yet it would "fail" the same because the behaviour on KSP <= 1.7.3 is really different from the one on KSP >= 1.8.0 .  

Oh well... SNAFU. Life goes on.

Cheers!  

Edited July 24, 2020 by Lisias
brute force post merging.

[MKSheppard]

I was wondering if rocket engine plumes/effects/fx would be looked at at some point.

If you scale an engine; the plumes end up looking weird relative to the original scale.

[Lisias]

5 minutes ago, MKSheppard said:

I was wondering if rocket engine plumes/effects/fx would be looked at at some point.

If you scale an engine; the plumes end up looking weird relative to the original scale.

Eventually.

https://github.com/net-lisias-ksp/TweakScale/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.4.4.1

[etmoonshade]

1 minute ago, Lisias said:

The problem with that approach is that you need to remember things while updating - at least for me, not the best of ideas.

I usually recommend a patch to disable the parts using a patch placed on a easily remembered place (i like GameData/__LOCAL/ for that - but anything goes as long you remember where the patch are and don't remove it by accident).

It's something like this:

@PART[part1,part2,part3<etc>]:FINAL
{
	-MODULE[TweakScale],* { }
}

If you know for sure that every part with a module should not be scalable, as KRnD, try this:

@PART[*]:HAS[@MODULE[KRnDModule]]:FINAL
{
	-MODULE[TweakScale],* { }
}

Of course, it works for any module (engine, lift, etc) - just replace the KRnDModule for ModuleEnginesFX (if you don't want scalable engines) or something else. In time, that :FINAL thingy is important, I should had put it on my previous examples!

It's safer this way because if you update something and forget you had removed the patches from that thing, on the next boot the patches will be applied (of course) and then be shoved on your crafts and savegames on load (I think I understand why, but need more time to be sure), and this will play havoc on the savegame as an empty, unusable section will be shoved on that parts and TweakScale will detect it and complain about.

Cheers!

Let's see if quoting from another thread breaks anything...

(this feels like it should be moved over here, since it really has nothing to do with the mod thread we were on anymore )

It looks like KRnD applies to everything, and I'm fairly certain it decides internally that if TweakScale is present (or B9PartSwitch, or IFS, or...) it's not going to do anything with it. Probably a smarter way of doing things really, since so many people seem to use ":FINAL" and I have no idea how it prioritizes multiple patches with that in it.

I like the general concept though, and it's certainly more maintainable than my way - I can probably figure out a way to tweak it so it drops TweakScale from the stuff I don't want to have it.

 

[TranceaddicT]

8 minutes ago, etmoonshade said:

 

Let's see if quoting from another thread breaks anything...

(this feels like it should be moved over here, since it really has nothing to do with the mod thread we were on anymore )

It looks like KRnD applies to everything, and I'm fairly certain it decides internally that if TweakScale is present (or B9PartSwitch, or IFS, or...) it's not going to do anything with it. Probably a smarter way of doing things really, since so many people seem to use ":FINAL" and I have no idea how it prioritizes multiple patches with that in it.

I like the general concept though, and it's certainly more maintainable than my way - I can probably figure out a way to tweak it so it drops TweakScale from the stuff I don't want to have it.

 

 

Patching commits in this order:

:FIRST

:Remove unmet NEEDS, :BEFORE, :AFTER, :LAST

LEGACY (no ordering) patching

:BEFORE

:FOR

:AFTER

:LAST

:FINAL (This SHOULD NOT be used by mod makers and is intended for the end-user/player.)

[Lisias]

11 minutes ago, etmoonshade said:

Let's see if quoting from another thread breaks anything...

Apparently not!

 

11 minutes ago, etmoonshade said:

(this feels like it should be moved over here, since it really has nothing to do with the mod thread we were on anymore )

My bad, I totally missed we were on someone's thread.. I'm jumping between many tasks today, and this plays havoc on noticing details... 

 

14 minutes ago, etmoonshade said:

It looks like KRnD applies to everything, and I'm fairly certain it decides internally that if TweakScale is present (or B9PartSwitch, or IFS, or...) it's not going to do anything with it. Probably a smarter way of doing things really, since so many people seem to use ":FINAL" and I have no idea how it prioritizes multiple patches with that in it.

Try this so:

@PART[part1,part2,<etc>]:BEFORE[KRnD]
{
	-MODULE[TweakScale],* { }
}

(Assuming the MM tag for KRnD is KRnD). This will ensure TweakScale is removed before KNrD tries to patch it.

 

17 minutes ago, etmoonshade said:

I like the general concept though, and it's certainly more maintainable than my way - I can probably figure out a way to tweak it so it drops TweakScale from the stuff I don't want to have it.

:BEFORE, :AFTER:, :LAST and :FINAL are pretty useful (and underestimated) tools!

[etmoonshade]

15 minutes ago, TranceaddicT said:

Patching commits in this order:

:FIRST

:Remove unmet NEEDS, :BEFORE, :AFTER, :LAST

LEGACY (no ordering) patching

:BEFORE

:FOR

:AFTER

:LAST

:FINAL (This SHOULD NOT be used by mod makers and is intended for the end-user/player.)

lol no

I mean, I totally agree, but I can't find a single instance of ":LAST" in GameData, and I see 6 mods that are using ":FINAL"

Do I name and shame? :V

 

10 minutes ago, Lisias said:

Apparently not!

 

My bad, I totally missed we were on someone's thread.. I'm jumping between many tasks today, and this plays havoc on noticing details... 

 

Try this so:

@PART[part1,part2,<etc>]:BEFORE[KRnD]
{
	-MODULE[TweakScale],* { }
}

(Assuming the MM tag for KRnD is KRnD). This will ensure TweakScale is removed before KNrD tries to patch it.

 

:BEFORE, :AFTER:, :LAST and :FINAL are pretty useful (and underestimated) tools!

Sorry, I probably wasn't clear - KRnD just doesn't do anything if it finds TweakScale applied to a part. TweakScale works fine, KRnD just says "pick another part to upgrade." I'm actually not sure how it'll react to a part that doesn't have the module on it, now that I think of it...

 

Side question, since people appear to be paying attention:

Isn't there a way to do math/conditionals in Tweakscale? I'd swear I saw it somewhere, but I can NOT find it in any documentation anywhere. And my Google-Fu seems to be failing me today.

Edit: Specific use case is that I want to modify the minAltitude on SCANSat parts down to 5km, but I don't want to modify anything that's got a minimum that's below that (i.e. BTDT scanner at 0km)

Edit: gdi ignore me I've been looking for tweakscale math when I need MM math no wonder I couldn't find it

Edited July 27, 2020 by etmoonshade

[TranceaddicT]

30 minutes ago, etmoonshade said:

lol no

I mean, I totally agree, but I can't find a single instance of ":LAST" in GameData, and I see 6 mods that are using ":FINAL"

 

TbF, ":LAST" is a new passSpecifier. It was introduced in Jan 2020, so ...

[Lisias]

1 hour ago, etmoonshade said:

I mean, I totally agree, but I can't find a single instance of ":LAST" in GameData, and I see 6 mods that are using ":FINAL"

shhh... don't snitch me!!!  

 

30 minutes ago, TranceaddicT said:

TbF, ":LAST" is a new passSpecifier. It was introduced in Jan 2020, so ...

And there's one more possible reason, this one affecting TweakScale.

On the beginning of time, there was only the LEGACY. The patches were applied in the order they were found, and they were found alfabetically -- essentially, a find . -name "*.cfg" | sort with the difference the filenames are URL escaped (due Unity's architectural decisions).

It as a mess, but since TweakScale is ordered near the end of the patching list, every single add'on those name comes before T is patched first, and TweakScale so ends up patching later, overwriting any eventual patching. A lot of tricks were applied to overrule TweakScale due this.

Then the pass specifiers came, people started to use it and then everything changed - now TweakScale patches first, and everybody else started to overrule TweakScale by default, without efforts. And after some toe stomping fests we reached another fragile equilibrium for some time.

On this previous status quo, trying to use :FOR on TweakScale would have caused a huge breakage on the patching because this would withdraw TweakScale from the LEGACY, breaking the expected chain of patching on add'ons that wants to overrule TweakScale. So some of my patches ended up in need to use :FINAL, because I could not use :AFTER[TweakScale], because TweakScale could not use :FOR at that time.

My pesky insistence on telling people to do not use % when they are the owner of the patch not only prevented double patching on TweakScale, it ended up with patches being written without relying on TweakScale being on the LEGACY - the easy (and suicidal) way out of shoving % on everything and hope for the best didn't worked anymore.

And so, now, TweakScale is migrating the patches to correctly cope with the new status quo. The 2.4.4.x series will be the last minor version with TweakScale on the LEGACY phase. The TweakScale 2.5 Beta is using :FOR for ages now, and nowadays people using it on the field are not getting any of the problems I got when I first tried using :FOR on my test beds so it's certain the 2.4.5.x (assuming I don't came to terms on going straight to 2.5 at once) will have :FOR on the patches.

Spoiler

The hardest part of this stunt was my mom complaining on burnt ears..  

 

[TranceaddicT]

4 minutes ago, Lisias said:

And so, now, TweakScale is migrating the patches to correctly cope with the new status quo. The 2.4.4.x series will be the last minor version with TweakScale on the LEGACY phase. The TweakScale 2.5 Beta is using :FOR for ages now, and nowadays people using it on the field are not getting any of the problems I got when I first tried using :FOR on my test beds so it's certain the 2.4.5.x (assuming I don't came to terms on going straight to 2.5 at once) will have :FOR on the patches.

Yeah, about that :FOR milestone.  I think you should probably be going for :NEEDS.

The strange thing about the :BEFORE > :FOR > :AFTER sequence ... only :FOR will cause a non-installed mod to be recognized as if it IS installed.

So this is a bad arrangement: authorModB will not create a new part because of authorModA's :FOR[FooBar].

authorModA has a MMConfig: @PART[authorModA]:FOR[FooBar] {}

authorModB has a MMConfig: +PART[authorModB]:NEEDS[!FooBar] {}

This is a good arrangement: authorModB will create a new part because of authorModA's :FOR[FooBar].

authorModA has a MMConfig: @PART[authorModA]:NEEDS[FooBar] {}

authorModB has a MMConfig: +PART[authorModB]:NEEDS[!FooBar] {}

 

[Lisias]

8 hours ago, TranceaddicT said:

Yeah, about that :FOR milestone.  I think you should probably be going for :NEEDS.

The strange thing about the :BEFORE > :FOR > :AFTER sequence ... only :FOR will cause a non-installed mod to be recognized as if it IS installed.

Yep. It's subtle, you need to pay attention to see the damage this can cause. At first glance on my mobile I didn't got it, I had to come back to my computer and see it on the big screen to have something snapping on my head.

I can think on a one or two use cases where someone would want to use :FOR[TweakScale]:NEEDS[TweakScale] on their patches -- in a nutshell he wants to be sure that his TweakScale support for his parts should be available to everybody at the same time TweakScale does his owns, so people using :AFTER[TweakScale] and :BEFORE[TweakScale] would not have their toes stomped by him.

Consider the following scenario: some people strongly disagrees with the free scaling on stock parts (i.e., the hability to allow scaling the thing between two hard scales - discrete scaling). So this guy write this:

@PART[*]:AFTER[TweakScale]
{
	@MODULE[TweakScale]
	{
		%freeScale = false
	}
}

But that other other guy had named his Add'On as TyBarneyBlobs . So, alphabetically, it's executed after TweakScale. He uses :AFTER[TweakScale] as a good citizen of Kerbin nevertheless. But then, that guy that prefer discrete scaling also used :AFTER[TweakScale] and ended up being patched first - and the after math is that some parts will be discrete scaled, and a few others don't.

Okey, this will be solved by :LAST[TweakScale]. Until someone else uses it too, and now we have a new race condition for the :LAST position.

This can be prevented if people that wants his own parts with TweakScale support but don't need to be patched on any special order could also use :FOR[TweakScale] . So their patches would be applied at the same time TweakScale's ones, and anyone wanting to second guess TweakScale scaling decisions would not have any problems on using :AFTER[TweakScale] or :LAST[TweakScale]. This is a legit use of the :FOR[TweakScale] by third-parties writing their own patches.

For some time, I considered doing it on the TweakScale Companions - but then I thought that it would make it harder for people to detect the Companion itself, and concluded that I would be regressing to some of the problems I had before deprecating anything but Stock+DLCs on TweakScale itself.

In a way or another I agree that everybody (but TweakScale) need to use :NEEDS[TweakScale] on his patches, only TweakScale stock own patches should use :FOR[TweakScale] alone - and this includes the Companions, as they should be handled as third-party from TS point of view.

Spoiler

Sometimes, I think that perhaps it should exist a :THIS[addon] , and then :FOR would be used by the fewer add'ons on the situation I depicted above, and would have the semantics of the current :FOR[xxx]:NEEDS[xxx] .

The :THIS would be the only operator that would create the tag on MM, not :FOR.

This is just a thought that I have now and then. I don't think there's something inherently wrong with the current :FOR - as long people remember to use also the :NEEDS.

But I would like to use something like this on the Companions: :THIS[TweakScaleCompanion_Foobar]:FOR[TweakScale]

 

Edited July 28, 2020 by Lisias
Tyops!

[TranceaddicT]

14 hours ago, Lisias said:

I can think on a one or two use cases where someone would want to use :FOR[TweakScale]:NEEDS[TweakScale] on their patches

 

 

 

 

 

 

 

 

 

:FOR[TweakScale]:NEEDS[TweakScale] will never happen. The 1st thing module manager does is initial load every patch that is in GameData. The 2nd thing it does is discard every patch which has a :NEEDS conditional that is not met. Only then does it begin applying patches.

Another trick module manager does is it considers a directory folder to be a mod. So, the folder GameData/TweakScaleCompanion is considered mod by module manager. This is the reason a personal mod folder (for me, zzzzzAS_KSPMods) got processed.

Being an end-user, dude with :FOR[TweakScale]:NEEDS[TweakScale] should be using :NEEDS[TweakScale]:FINAL to ensure his is the last patch ever.

I think the use case you presented is better suited to mods with companion-style directory hierarchies, like TweakScale. Because TweakScale has complementary configuration patches which exist SEPARATE from the core module itself, you're use case is better applied :FOR[TweakScaleCompanion/ABC]:NEEDS[TweakScale] (yeah, it can parse subdirectories.)  That also solves your :THIS situation.

Edited July 28, 2020 by TranceaddicT

[Lisias]

33 minutes ago, TranceaddicT said:

:FOR[TweakScale]:NEEDS[TweakScale] will never happen. The 1st thing module manager does is initial load every patch that is in GameData. The 2nd thing it does is discard every patch which has a :NEEDS conditional that is not met. Only then does it begin applying patches.

I think we are not on the same page anymore, we lost the thread of the discussion somehow. I just tested :FOR[TweakScale]:NEEDS[TweakScale] and it worked (and, yeah, I used the Official MM on this test):

[LOG 10:00:55.709] :BEFORE[TWEAKSCALE] pass
[LOG 10:00:55.709] :FOR[TWEAKSCALE] pass
[LOG 10:00:55.749] Applying update TyBarneyBlobs/Stunt/@PART[mk1-3pod]:FOR[TweakScale]:NEEDS[TweakScale] to Squad/Parts/Command/Mk1-3Pod/mk1-3.cfg/PART[mk1-3pod]
[LOG 10:00:55.750] :AFTER[TWEAKSCALE] pass
[LOG 10:00:55.750] :BEFORE[TYBARNEYBLOBS] pass
[LOG 10:00:55.750] :FOR[TYBARNEYBLOBS] pass
[LOG 10:00:55.750] :AFTER[TYBARNEYBLOBS] pass
[LOG 10:00:55.752] :FINAL pass

And the patch I used to test this is:

@PART[mk1-3pod]:FOR[TweakScale]:NEEDS[TweakScale]
{
	%title = This is impossible. Or not?
}

And, of course, the MM cache for the mk1-3pod has:

UrlConfig
{
	parentUrl = Squad/Parts/Command/Mk1-3Pod/mk1-3.cfg
	PART
	{
		name = mk1-3pod
		module = Part
		author = RoverDude
		scale = 1

		<cut!!!>

		bulkheadProfiles = size2, size1
		tags = capsule cmg control ?eva fly gyro ?iva moment pilot react rocket space stab steer torque
		title = This is impossible. Or not?

What happened is exactly what you described, MM scanned for every patch, created the tags, get rid of the unsatisfied :NEEDS and applied the patches. The only thing that happened differently is that since TweakScale was tagged, the TyBarneyBlobs "add'on" had the patch applied together the ones from TweakScale - exactly as I talked about on my last post.

 

1 hour ago, TranceaddicT said:

Another trick module manager does is it considers a directory folder to be a mod. So, the folder GameData/TweakScaleCompanion is considered mod by module manager. This is the reason a personal mod folder (for me, zzzzzAS_KSPMods) got processed.

What I think is not exactly ideal. IMHO Add'On tags should be directory agnostic - or, at least, should exist a way to overrule this (like that :THIS of mine).

 

1 hour ago, TranceaddicT said:

Being an end-user, dude with :FOR[TweakScale]:NEEDS[TweakScale] should be using :NEEDS[TweakScale]:FINAL to ensure his is the last patch ever.

However, I'm not talking about end-users. I was talking about proper managed Add'Ons, as the TweakScale Companions!

I think we are not on the same page anymore?

 

1 hour ago, TranceaddicT said:

I think the use case you presented is better suited to mods with companion-style directory hierarchies, like TweakScale. Because TweakScale has complementary configuration patches which exist SEPARATE from the core module itself, you're use case is better applied :FOR[TweakScaleCompanion_ABC]:NEEDS[TweakScale]. It also solves your :THIS situation.

But at the same time prevents me to use :FOR when I need something happening :AFTER or :BEFORE something else.

:BEFORE, :FOR, :AFTER et all are mutually exclusive. I can't use :FOR[TweakScaleCompanion_ABC]:AFTER[ABC].

What can be easily verified with the following stunt:

@PART[mk1-3pod]:FOR[ArbitrarilyDefinedTag]:NEEDS[TweakScale]:AFTER[Squad]
{
	%title = This is impossible. Or not?
}

That renders the following on MM's log:

[WRN 10:25:58.535] more than one pass specifier detected, ignoring all but the first: TyBarneyBlobs/Stunt/@PART[mk1-3pod]:FOR[ArbitrarilyDefinedTag]:NEEDS[TweakScale]:AFTER[Squad]

<CUT>

[LOG 10:26:00.123] :BEFORE[ARBITRARILYDEFINEDTAG] pass
[LOG 10:26:00.123] :FOR[ARBITRARILYDEFINEDTAG] pass
[LOG 10:26:00.123] Applying update TyBarneyBlobs/Stunt/@PART[mk1-3pod]:FOR[ArbitrarilyDefinedTag]:NEEDS[TweakScale]:AFTER[Squad] to Squad/Parts/Command/Mk1-3Pod/mk1-3.cfg/PART[mk1-3pod]
[LOG 10:26:00.124] :AFTER[ARBITRARILYDEFINEDTAG] pass
[LOG 10:26:00.124] :BEFORE[ASSEMBLY-CSHARP] pass
[LOG 10:26:00.124] :FOR[ASSEMBLY-CSHARP] pass
[LOG 10:26:00.124] :AFTER[ASSEMBLY-CSHARP] pass
<CUT>
[LOG 10:26:00.124] :BEFORE[TWEAKSCALE] pass
[LOG 10:26:00.124] :FOR[TWEAKSCALE] pass
[LOG 10:26:00.162] :AFTER[TWEAKSCALE] pass
[LOG 10:26:00.162] :BEFORE[TYBARNEYBLOBS] pass
[LOG 10:26:00.162] :FOR[TYBARNEYBLOBS] pass
[LOG 10:26:00.162] :AFTER[TYBARNEYBLOBS] pass
[LOG 10:26:00.163] :FINAL pass

:FOR really shouldn't be the tag used to create MM tags, I think.

[TranceaddicT]

44 minutes ago, Lisias said:

 

2 hours ago, TranceaddicT said:

Another trick module manager does is it considers a directory folder to be a mod. So, the folder GameData/TweakScaleCompanion is considered mod by module manager. This is the reason a personal mod folder (for me, zzzzzAS_KSPMods) got processed.

What I think is not exactly ideal. IMHO Add'On tags should be directory agnostic - or, at least, should exist a way to overrule this (like that :THIS of mine).

Yeah, this is legacy behaviour from when MM was first conceived. Then:FOR guy added and then things got complicated. There are still patches out there with no conditionals and they get processed before anything else.

 

41 minutes ago, Lisias said:

What happened is exactly what you described, MM scanned for every patch, created the tags, get rid of the unsatisfied :NEEDS and applied the patches. The only thing that happened differently is that since TweakScale was tagged, the TyBarneyBlobs "add'on" had the patch applied together the ones from TweakScale - exactly as I talked about on my last post

So, no TS installed?

If that is the case, that's an unintended consequence. My understanding is if there's declared mod.dll or no folder, then the :NEEDS condition hasn't been met and the patch should be discarded. What you described, means the :BEFORE,:FOR and :AFTER conditionals are being evaluated as they're being loaded and module manager is making the declaration for them.

51 minutes ago, Lisias said:

However, I'm not talking about end-users. I was talking about proper managed Add'Ons, as the TweakScale Companions!

Ah, okay, now what you said makes more sense. This is where we diverged.

55 minutes ago, Lisias said:

:BEFORE, :FOR, :AFTER et all are mutually exclusive. I can't use :FOR[TweakScaleCompanion_ABC]:AFTER[ABC].

It may be time to review the legacy behavior. MM had been around long enough that :FOR can be reimplemented to act as it intuitively should - a positional pointer between :BEFORE & :AFTER. And, as a result, could make way for introducing a :THIS conditional. 

[Lisias]

5 hours ago, TranceaddicT said:

So, no TS installed?

Ah!  Now I understood where the lines got crossed!

You were talking about NOT having TweakScale installed, I was talking about "co-patching" when TweakScale IS installed!

Edited July 28, 2020 by Lisias
Jesus Christ... My grammars surprises even to me sometimes... =P

[Foefue]

Do I still need ksp recall installed for 1.10.1 now or do i just get rid of it?

[TranceaddicT]

2 hours ago, Foefue said:

Do I still need ksp recall installed for 1.10.1 now or do i just get rid of it?

Your should remove it.  If you get any warnings or complaints about Module[Resourceful], they can be safely disregarded.