Config load order within single plugin

[Waifu Art Thou Romeo]

I can't be the first person with this problem, but I also can't figure out how to Google it to find an answer.

Is there a way to control (or at least know) what order config files will be loaded within a single plugin?

For example, I'm making some parts FAR-compatible, but I have another patch that does a rescale. Is there a way to ensure that the rescale happens first so that I can scale up the aerodynamic properties for FAR correctly (e.g. "MAC = 10 * rescaleFactor")? If the FAR config is loaded first, the scaling won't happen correctly.

I naively tried to append ":AFTER[my_far_config.cfg]" to the "PART" preprocessing function, but that doesn't seem to work

 

EDIT: Okay, so I think I get it now. The functionality I wanted was to have a name that I could reference for the load order. The way you do this is with the :FOR[arbitrary_name] command, which is used only once in a config file and specifies basically a timeslot in the load order.

Then, :AFTER[same_arbitrary_name] refers to the timeslot immediately after that one, which is why you can't have multiple BEFOREs and AFTERs in the same step.

Is this right?

Edited May 28, 2021 by Waifu Art Thou Romeo
Maybe found the answer?

[Beetlecat]

On 5/28/2021 at 12:26 PM, Waifu Art Thou Romeo said:

I can't be the first person with this problem, but I also can't figure out how to Google it to find an answer.

Is there a way to control (or at least know) what order config files will be loaded within a single plugin?

For example, I'm making some parts FAR-compatible, but I have another patch that does a rescale. Is there a way to ensure that the rescale happens first so that I can scale up the aerodynamic properties for FAR correctly (e.g. "MAC = 10 * rescaleFactor")? If the FAR config is loaded first, the scaling won't happen correctly.

I naively tried to append ":AFTER[my_far_config.cfg]" to the "PART" preprocessing function, but that doesn't seem to work

 

EDIT: Okay, so I think I get it now. The functionality I wanted was to have a name that I could reference for the load order. The way you do this is with the :FOR[arbitrary_name] command, which is used only once in a config file and specifies basically a timeslot in the load order.

Then, :AFTER[same_arbitrary_name] refers to the timeslot immediately after that one, which is why you can't have multiple BEFOREs and AFTERs in the same step.

Is this right?

 

a further way to get nuance and load order could be to utilize the file order? MM will process files in alphanumeric order--that's why you'll see mods with 000 to start their folder names (or zzz). Could this help as well?

[Stone Blue]

On 5/28/2021 at 3:26 PM, Waifu Art Thou Romeo said:

IDIT: Okay, so I think I get it now. The functionality I wanted was to have a name that I could reference for the load order. The way you do this is with the :FOR[arbitrary_name] command, which is used only once in a config file and specifies basically a timeslot in the load order.

Then, :AFTER[same_arbitrary_name] refers to the timeslot immediately after that one, which is why you can't have multiple BEFOREs and AFTERs in the same step.

Is this right?

I could be wrong, but I dont think you need both a FOR & AFTER, in the ame patch, targeting the same mod. I think AFTER implies FOR?

Have you tried adding a BEFORE <FAR>, in the rescale patch, and an AFTER <rescale mod>, in your FAR patch?

Also, these might help, if yo havent seen them yet..?? vOv
https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax

https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook

Edited June 1, 2021 by Stone Blue

[Waifu Art Thou Romeo]

23 hours ago, Beetlecat said:

a further way to get nuance and load order could be to utilize the file order? MM will process files in alphanumeric order--that's why you'll see mods with 000 to start their folder names (or zzz). Could this help as well?

I *had* seen that and wondered what it was about. Thank you for explaining.

22 hours ago, Stone Blue said:

I could be wrong, but I dont think you need both a FOR & AFTER, in the ame patch, targeting the same mod. I think AFTER implies FOR?

Have you tried adding a BEFORE <FAR>, in the rescale patch, and an AFTER <rescale mod>, in your FAR patch?

Also, these might help, if yo havent seen them yet..?? vOv
https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax

https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook

Does "patch" mean the whole file or the individual code blocks?  And how do you mean "AFTER implies FOR"? You have to declare a name with :FOR in order to reference that name somewhere else with :BEFORE or :AFTER

What I ended up doing was a :FOR in my non-rescale files, and then an :AFTER in each code block of my rescale file to address how rescaling interacts with each mod. That was the most object-oriented way I could think to do it.

e.g.

Spoiler

// From FAR.cfg
@PART[KipEngSkylonStabiliser]:NEEDS[FerramAerospaceResearch|NEAR]:FOR[KipardSkylon_FAR] {
    %MODULE[FARControllableSurface] 
	{
        
        %b_2 = 3.80
        %MAC = 3.73
        %TaperRatio = 0.21
        %MidChordSweep = 50.69 // degrees
        %rootMidChordOffsetFromOrig = 2.187, 0.480, 0
        %maxdeflect = 20
        %ctrlSurfFrac = 1
        %nonSideAttach = 0
    }
}

// From RSS.cfg
@PART[KipEngSkylonWing*|KipEngSkylonCanard*|KipEngSkylonStabiliser]:NEEDS[RealSolarSystem&FerramAerospaceResearch]:AFTER[KipardSkylon_FAR]
{
    @MODULE[FARControllableSurface],* 
	{  
        @b_2 *= 1.35
        @MAC *= 1.35
        @rootMidChordOffsetFromOrig[*] *= 1.35
    }
}

 

Also thank you for the resources. That handbook is a lifesaver

Edited June 2, 2021 by Waifu Art Thou Romeo
typo

[Stone Blue]

23 hours ago, Waifu Art Thou Romeo said:

Does "patch" mean the whole file or the individual code blocks?  And how do you mean "AFTER implies FOR"? You have to declare a name with :FOR in order to reference that name somewhere else with :BEFORE or :AFTER

What I ended up doing was a :FOR in my non-rescale files, and then an :AFTER in each code block of my rescale file to address how rescaling interacts with each mod. That was the most object-oriented way I could think to do it.

technically, a "patch" is the individual "blocs".. but can also be used to refer to all blocks in a seperate "patch file", or "patch" for short

Ahh.. I see... Technically, you may not need the :FOR as you have it, *if* the part(s) you are targeting *are in that folder*. Since then, obviously the folder would have to exist if the target is in that folder. But I'm not sure if thats what you have, or if thats the case.

Also, I was thinking your NEEDS & AFTER, *were for the same mod* you were declaring the FOR, for... thats where the "implies" comes in.. but I may be wrong on that if *only* the AFTER was used... It looks like I may have mispoken, and only NEEDS implies FOR... (with a NEEDS, youre targeting a specific folder, so to satisfy that, the folder would HAVE to exist, to apply... hence no need to use a FOR *and* a NEEDS.)

But what you have there should work