[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season

[Starwaster]

I have gotten a message for mod manager I have never seen it says one of my patch cfgs is hidden? any idea what that means?

Ignore it. It just means that a config patch has dependencies that are unmet. Namely a mod that it is for isnt present.

New question, is there a way to supersede a ":FINAL" modifier from another MM config? I've tried using ":FINAL" as well as ":AFTER[X]" in mine, but neither seem to work to override another mod's ":FINAL".

Final is literally the final pass. The only way to override it is a :FINAL in a file that occurs alphabetically after that mod.

Mods shouldn't even use final anymore any way but I guess we'll be doing it still for awhile.

Edited June 25, 2014 by Starwaster

[SpacedInvader]

Ignore it. It just means that a config patch has dependencies that are unmet. Namely a mod that it is for isnt present.

Final is literally the final pass. The only way to override it is a :FINAL in a file that occurs alphabetically after that mod.

Mods shouldn't even use final anymore any way but I guess we'll be doing it still for awhile.

Ok, so if I want my config to supersede everything else (this is my personal tweaks package) I should name the mod folder something like zMyTweaks? Or is it the config file name that matters?

[BudgetHedgehog]

Ok, so if I want my config to supersede everything else (this is my personal tweaks package) I should name the mod folder something like zMyTweaks? Or is it the config file name that matters?

:Final will be fine. I can't remember off by heart, but looking at the output_log will tell you in what order those :Final patches are applied. If alphabetically, then naming your patch 'zblah.cfg' would be the thing to do. If there's no apparent order, then you can name it whatever - it'll still get applied.

I can't remember off the top of my head how MM orders the :Final patches though, so it's best to look first.

[SpacedInvader]

:Final will be fine. I can't remember off by heart, but looking at the output_log will tell you in what order those :Final patches are applied. If alphabetically, then naming your patch 'zblah.cfg' would be the thing to do. If there's no apparent order, then you can name it whatever - it'll still get applied.

I can't remember off the top of my head how MM orders the :Final patches though, so it's best to look first.

The issue is that there is another MM config that is using :FINAL for a lot of parts. I want to make sure my :FINAL is applied after that :FINAL.

[BudgetHedgehog]

The issue is that there is another MM config that is using :FINAL for a lot of parts. I want to make sure my :FINAL is applied after that :FINAL.

Like I literally just said, it's the FINAL pass - I'm not sure if it's ordered or anything but I think, in essence, it's run after all :FOR, :NEEDS and :BEFORE patches are run. This means that all :Final passes are done after those and the ordering of those configs shouldn't matter.

If it's vitally important that your :Final is run after someone elses :Final, why not edit their cfg to say :BEFORE[MyMod] or yours to say :AFTER[TheirMod]?

[Starwaster]

Ok, so if I want my config to supersede everything else (this is my personal tweaks package) I should name the mod folder something like zMyTweaks? Or is it the config file name that matters?

That's a good question.... I think the file name.... but I can't say that the folder structure isn't factored in too. You could always make a couple of sample files that modify some made up for this exercise config node. Then check in the log file which one got applied first/last.

[Starwaster]

Like I literally just said, it's the FINAL pass - I'm not sure if it's ordered or anything but I think, in essence, it's run after all :FOR, :NEEDS and :BEFORE patches are run. This means that all :Final passes are done after those and the ordering of those configs shouldn't matter.

If it's vitally important that your :Final is run after someone elses :Final, why not edit their cfg to say :BEFORE[MyMod] or yours to say :AFTER[TheirMod]?

Forgive the double post, but YES. Unequivocably YES, if you have two patches both using :FINAL and both affecting the same node then ordering is very much an issue.

Edit: And overwriting their actual files leaves them in a state that is not undone when a player deletes the mod that did the overwriting.

Bad move.

[BudgetHedgehog]

You could always make a couple of sample files that modify some made up for this exercise config node. Then check in the log file which one got applied first/last.

I can't remember off by heart, but looking at the output_log will tell you in what order those :Final patches are applied. If alphabetically, then naming your patch 'zblah.cfg' would be the thing to do. If there's no apparent order, then you can name it whatever - it'll still get applied.

I can't remember off the top of my head how MM orders the :Final patches though, so it's best to look first.

Sometimes, I feel like I don't exist.

[Starwaster]

Sometimes, I feel like I don't exist.

Race conditions affect rapid fire forum posting.

Sad but true.

[SpacedInvader]

Like I literally just said, it's the FINAL pass - I'm not sure if it's ordered or anything but I think, in essence, it's run after all :FOR, :NEEDS and :BEFORE patches are run. This means that all :Final passes are done after those and the ordering of those configs shouldn't matter.

If it's vitally important that your :Final is run after someone elses :Final, why not edit their cfg to say :BEFORE[MyMod] or yours to say :AFTER[TheirMod]?

That's a good question.... I think the file name.... but I can't say that the folder structure isn't factored in too. You could always make a couple of sample files that modify some made up for this exercise config node. Then check in the log file which one got applied first/last.

Forgive the double post, but YES. Unequivocably YES, if you have two patches both using :FINAL and both affecting the same node then ordering is very much an issue.

Edit: And overwriting their actual files leaves them in a state that is not undone when a player deletes the mod that did the overwriting.

Bad move.

Well, some testing has resulted the following information: Filename has zero effect, as does folder structure within a mod. The only way to affect the order of :FINAL is to make sure the mod folder is alphabetically after the other mod folder you're worried about.

Also, for the record I'm pretty sure :FINAL will not be going away any time soon because we will always need a modifier that will ensure the application of a mod no matter what other mods affect the node in question. That being said, hopefully people will stop using it so much.

Edited June 25, 2014 by SpacedInvader

[BudgetHedgehog]

And overwriting their actual files leaves them in a state that is not undone when a player deletes the mod that did the overwriting.

I believe that bug has been fixed. But still, just put OPs cfgs in a folder called 'zblah' and make them say :BEFORE[zblah]. If they delete the mod it modifes, delete that cfg too. Not terribly difficult.

Also, no hard feelings, man

[TaranisElsu]

Is there a way to edit another mod's settings config file through a MM config? I'm currently working on a TACLS MM config that will give it units that make sense, but part of the requirement to make it work is that the consumption and production rates for it's units will also have to be edited. I am planning on offering the config for public use, so that means I've either got to find a way to change those settings through the MM config or deliver the MM config with a set of instructions on what values to set where. Any help would be appreciated.

Thanks.

You don't want to and should not edit another mod's files, even if you could.

You can edit its config nodes which is what MM is for in the first place. You would likely want to use the AFTER or FINAL directives to ensure that your changes happen last. AFTER assumes the other mod is making use of MM 2.1.5 ordering

I don't mean I want to actually edit the files, but rather configure them after the fact through module manager, basically creating a temporary configuration through the MM config while leaving the mod's actual files untouched.

I have my own TACLS MM config file that uses realistic masses and volumes, but still keeps the amounts in "days of resources per kerbal". It might be a good starting point for you if you're going for a units-in-mass or units-in-volume approach.

TACLS keeps its settings in PluginData, which is not visible to GameDatabase. So no.

Shipping with instructions it will be then. Thanks for the info.

There is potential for bad things to happen if you change my mod's (TACLS's) settings through a MM config file, and those changes would be written out the next time it saves so it would not leave the "actual files untouched."

The file in question, LifeSupport.cfg, has some user preferences* saved with the consumption rates but I would not worry about those. Just ship your mod with a drop in settings file. And include instructions to overwrite the existing file when installing your mod, and delete your file (leaving no file) when uninstalling your mod to return to default values.

Please post any responses in my thread so that I am sure to see them.

P.S. * I am going to separate those user preferences into another file to keep them away from consumption rates, since they change under different circumstances. And, I am moving to "1 unit = 1 liter" in the next release. See my math: https://docs.google.com/spreadsheet/ccc?key=0Aioc9ek3XAvwdGNsRlh3OVhlbTFBR3M4RW0zLUNTRFE&usp=sharing

[Starwaster]

Well, some testing has resulted the following information: Filename has zero effect, as does folder structure within a mod. The only way to affect the order of :FINAL is to make sure the mod folder is alphabetically after the other mod folder you're worried about.

Also, for the record I'm pretty sure :FINAL will not be going away any time soon because we will always need a modifier that will ensure the application of a mod no matter what other mods affect the node in question. That being said, hopefully people will stop using it so much.

It's not a question of whether people should use it, it's a question of whether modders should use it. Originally it was intended for players to affect their installed mods without overwriting their mod files. But it was also the only way for a modder to ensure that a vitally required patch executed after another specific patch. But now we also have :FIRST, :BEFORE, :FOR and :AFTER. Though, their use depends to an extent on everyone using them. I forget what pass a patch is applied in if no pass is specified.

I believe that bug has been fixed. But still, just put OPs cfgs in a folder called 'zblah' and make them say :BEFORE[zblah]. If they delete the mod it modifes, delete that cfg too. Not terribly difficult.

Also, no hard feelings, man

Overwriting a file isn't a bug... and there's no fixing it other than reinstallation. Unless you meant something else when you mentioned 'editing their cfg' but I'm not sure what would do that..... other than overwriting the file.

[BudgetHedgehog]

Overwriting a file isn't a bug... and there's no fixing it other than reinstallation. Unless you meant something else when you mentioned 'editing their cfg' but I'm not sure what would do that..... other than overwriting the file.

My mistake, I must;ve misunderstood - there was some serious bugginess around 2.1.0-3 or something that meant that loading crafts with modules out of order thanks to MM would break things spectacularly - I thought this what you were referring to.

[NathanKell]

No, the issue was that loading crafts with modules out of order due to whatever would break due to SQUAD loader bugs. For example, try, without using MM, creating a part with two modules. Make a craft, save the craft. Then switch the module order. BOOM! Settings lost in both modules on reload of craft.

MM fixed the SQUAD bugs in the loader, by dint of dynamically reordering all .craft / .sfs MODULEs to match the PartModule order in the prefab part.

[BudgetHedgehog]

No, the issue was that loading crafts with modules out of order due to whatever would break due to SQUAD loader bugs. For example, try, without using MM, creating a part with two modules. Make a craft, save the craft. Then switch the module order. BOOM! Settings lost in both modules on reload of craft.

MM fixed the SQUAD bugs in the loader, by dint of dynamically reordering all .craft / .sfs MODULEs to match the PartModule order in the prefab part.

Ohhhhhhhh! I see now... thanks. That makes sense. Thank you

[Starwaster]

, save the craft. Then switch the module order. BOOM! Settings lost in both modules on reload of craft.

.

Or worse...

[JackGruff]

First, ialdabaoth and sarbian, thank you so much for this.

Second, is it normal for MM to pause loading for ~1 minute for ~70 patches?

[Pondafarr]

My load list has 770....takes a looong time to load

[Gaalidas]

that's nothing, I have over 2300 of them, and it takes about... hmm... I never actually timed it but it doesn't take all that long really.

[BigD145]

My load list has 770....takes a looong time to load

Sooooo 5 years to load? 5 seconds? "Long" is completely arbitrary.

[Eleven]

My load list has 770....takes a looong time to load

830 files loaded here. 2 minutes dead on from double click to start-up screen. I have a Lenovo G580 laptop with 8 gigs of ram, running Linux Mint 14 and the 64bit Linux Client.

[NathanKell]

The number of MM files/patches will have almost 0 influence on your load time. What *actually* takes time is (a) reading textures from disk and ( compressing them.

[Eleven]

The number of MM files/patches will have almost 0 influence on your load time. What *actually* takes time is (a) reading textures from disk and ( compressing them.

But doesn't the number of files MM looks at reflect the number of textures loaded? Seems to be related to the number of parts in my Mods...if I add a Mod, the MM file number goes up, and if I delete parts then the MM file number goes down

[Mecripp]

Your adding something to parts like MODULE or changing them not textures.