Starwaster Posted June 24, 2014 Share Posted June 24, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
SpacedInvader Posted June 25, 2014 Share Posted June 25, 2014 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? Quote Link to comment Share on other sites More sharing options...
BudgetHedgehog Posted June 25, 2014 Share Posted June 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
SpacedInvader Posted June 25, 2014 Share Posted June 25, 2014 :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. Quote Link to comment Share on other sites More sharing options...
BudgetHedgehog Posted June 25, 2014 Share Posted June 25, 2014 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]? Quote Link to comment Share on other sites More sharing options...
Starwaster Posted June 25, 2014 Share Posted June 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
Starwaster Posted June 25, 2014 Share Posted June 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
BudgetHedgehog Posted June 25, 2014 Share Posted June 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
Starwaster Posted June 25, 2014 Share Posted June 25, 2014 Sometimes, I feel like I don't exist.Race conditions affect rapid fire forum posting.Sad but true. Quote Link to comment Share on other sites More sharing options...
SpacedInvader Posted June 25, 2014 Share Posted June 25, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
BudgetHedgehog Posted June 25, 2014 Share Posted June 25, 2014 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 Quote Link to comment Share on other sites More sharing options...
TaranisElsu Posted June 25, 2014 Share Posted June 25, 2014 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 orderingI 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 Quote Link to comment Share on other sites More sharing options...
Starwaster Posted June 25, 2014 Share Posted June 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
BudgetHedgehog Posted June 25, 2014 Share Posted June 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
NathanKell Posted June 25, 2014 Share Posted June 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
BudgetHedgehog Posted June 25, 2014 Share Posted June 25, 2014 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 Quote Link to comment Share on other sites More sharing options...
Starwaster Posted June 25, 2014 Share Posted June 25, 2014 , save the craft. Then switch the module order. BOOM! Settings lost in both modules on reload of craft..Or worse... Quote Link to comment Share on other sites More sharing options...
JackGruff Posted July 2, 2014 Share Posted July 2, 2014 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? Quote Link to comment Share on other sites More sharing options...
Pondafarr Posted July 2, 2014 Share Posted July 2, 2014 My load list has 770....takes a looong time to load Quote Link to comment Share on other sites More sharing options...
Gaalidas Posted July 2, 2014 Share Posted July 2, 2014 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. Quote Link to comment Share on other sites More sharing options...
BigD145 Posted July 2, 2014 Share Posted July 2, 2014 My load list has 770....takes a looong time to load Sooooo 5 years to load? 5 seconds? "Long" is completely arbitrary. Quote Link to comment Share on other sites More sharing options...
Eleven Posted July 2, 2014 Share Posted July 2, 2014 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. Quote Link to comment Share on other sites More sharing options...
NathanKell Posted July 2, 2014 Share Posted July 2, 2014 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. Quote Link to comment Share on other sites More sharing options...
Eleven Posted July 2, 2014 Share Posted July 2, 2014 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 Quote Link to comment Share on other sites More sharing options...
Mecripp Posted July 2, 2014 Share Posted July 2, 2014 Your adding something to parts like MODULE or changing them not textures. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.