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

[a__gun]

One of the fundamental conventions of programming isIndeedToWriteEverythingWithoutWhitespaces

[velusip]

Here's a little helper script that lists all parts which a module manager config does not account for:

#!/usr/bin/awk -f

# List parts which lack a ModuleManager @PART definition.

# Usage:  mmcfg <part path> <config path>
#   Parts directory
#   ModuleManager config file
#   e.g. $ ./mmcfg /pathto/KSP_linux/GameData/Squad/Parts /pathto/myMM.cfg

BEGIN {  
    # parts -- recursively find leaf nodes in Parts directory | prune 'sounds' directory
    get_parts = "find " ARGV[1] " -type d -links 2 | sed -e 's|/sounds||' -e 's|.*/||'"
    while((get_parts | getline line) > 0)
        stock_parts[line] = 0
    close(get_parts)

    # module manager cfg -- grep for @PART definitions | drop syntax around part name
    get_mmcfg_parts = "grep '@PART' " ARGV[2] " | sed -e 's/.*\\[//' -e 's/\\]//'"
    while((get_mmcfg_parts | getline line) > 0 )
        mmcfg_parts[line] = 0
    close(get_mmcfg_parts)
}

END {
    # print parts not in module manager config
    for(part in stock_parts)
        if((part in mmcfg_parts) == 0)
            print part
}

Note: I don't think this will work as-is in OSX due to the way the directory leafs are represented.

Edited October 28, 2013 by velusip
fixed close code

[ialdabaoth]

The complex part : I spoke with a few other modders and they had concerns about MM. One of this concern is that having MM always installed in the base dir makes it easy for one mod to overwrite it with an old version. And if mods install it in their folder you get multiple instance of it running, each of them applying all the available patch and making a mess of thing. They had some ideas to avoid this and I implemented them. It makes the upgrade a bit more complex and you'll have to read a bit. I hope I can make it clear enough.

So here are the other changes :

- MM will not work if installed at the root of the GameData folder

- you can have multiple MM installed in various subdirectory of GameData

- each instance of MM only process patch file in the subdirectory where its installed

Protip: This is a TERRIBLE idea.

- MM will display a warning if there are old ( before 1.4 ) version installed anywhere in gamedata

THIS is a good idea.

There should only be ONE copy of ModuleManager running. EVER. It needs to handle everything from /GameData on down. Putting ModuleManager.dll itself in /GameData is a good reminder of this.

Suggestion: Have ModuleManager print "ModuleManager version 1.5 initialized" before all the parsing, and 'ModuleManager version 1.5 finished" after all the parsing. (Obviously, increment version per update). If a user has a problem with a mod, that mod author can demand that the user tell them which version of ModuleManager they're running before they provide any support.

That's as far as you can take it, really.

[Kaa253]

@velusip. Shebang awk etc, grep, etc. Marvellous solution. Thanks for the tip / lesson.

[sarbian]

@ialdabaoth I do understand why you think it is a terrible idea. But having all the dll in 1 place is bad for user who don't really understand what they do when they unzip a mod and who't check files dates. It's easy for "power" user like us, but all players are not careful as we are.

The only hard part is the transition.

I have a newer version (1.4.1) that change things a little :

- anything between square brackets can use a wildcard search : @PART[*]:HAS[@RESOURCE[*]] // search all PART that have any ressource

- You can check for missing properties (by Starwaster) : @PART[*]:HAS[#module[Part],~breakingTorque[]] // search for all PART with module=part but no breakingTorque defined

- And the big change that I hope will make most of you agree with me :

I still use this 3 concept :

- MM will not work if installed at the root of the GameData folder

- you can have multiple MM installed in various subdirectory of GameData

- MM only process patch file in the subdirectory where its installed ( each of those patch can edit anything )

BUT when all the instance of MM starts they look at each other and 1 will be chosen to process all MM patch file (the one with the highest version) while the other will stop themselves. (it works even with X copy of the same version).

This instance will then process patch files in all the subdirectory of all the MM instances.

Exemple :

\GameData
	\ModA		
		ModuleManager.dll   ( Version 1.4.2 )
		ModA.cfg  (name not important)
	\ModB
		ModuleManager.dll   ( Version 1.4.1 )
		ModB.cfg
	\ModC
		ModuleManager.dll   ( Version 1.4.2 )
		ModC.cfg

The ModuleManager.dll in ModB and ModC won't do anything (older version, and copy of the newest version). The ModuleManager.dll in ModA will process ModA.cfg + ModB.cfg + ModC.cfg.

It helps with multiple version since as soon as you update 1 mod you get the newer ModuleManager for all others. You only have 1 version running. And :Final works as usual since all cfg are processed by 1 instance.

I'll add a few more popup/log to explain user that they need to remove MMSarbianExt.dll, and useful help for the transition. But nothing else should change.

[NathanKell]

sarbian, I still think MM ever not processing CFGs is a terrible idea. If you already are version checking, that's cool, but it's really bad if there's ever a situation that a MM-compliant CFG, no matter where it's placed, will ever not be processed.

Why not do your version checking and only run MM once, but still process all confignodes? It just seems such a needless restriction.

The bloody _point_ of MM is that it processes CFGs anywhere.

[Gaius]

sarbian, I still think MM ever not processing CFGs is a terrible idea. If you already are version checking, that's cool, but it's really bad if there's ever a situation that a MM-compliant CFG, no matter where it's placed, will ever not be processed.

Why not do your version checking and only run MM once, but still process all confignodes? It just seems such a needless restriction.

The bloody _point_ of MM is that it processes CFGs anywhere.

It has never processed configs "no matter where it's placed" or "anywhere", and that would be an extraordinarily bad idea. I regularly move old configs to an archive directory, along with mods I'm currently not using but might want to reinstall later. I've always relied on the fact that ModuleManager does not and never has processed config files "no matter where [they're] placed". It would be really bad if there were ever a situation where it did try to process files outside its scope.

What the new version does is provide for multiple scopes, managed by different mods using potentially different versions of this plugin. It loses precisely zero capabilities, and gains a lot in terms of easy of use and flexibility and eliminates many possible kinds of conflicts and compatibility issues. As someone who maintains my own mod, I'm glad to know that any time I drop a new version of MM in my mod's plugins folder, I know it won't have any effect at all on other mods that might also be using this plugin, rather than potentially breaking them if the new version I use for my mod has compatibility issues with older versions.

Edited November 3, 2013 by Gaius

[NathanKell]

I did not feel I needed to say "anywhere that KSP loads data"--that seemed rather obvious. And yes, it does process a CFG wherever it's placed in that scope, because it doesn't process files. That's the point. It processes confignodes. KSP processes files, and MM cfgs are read just like any other CFG by KSP.

It loses a quite chief capability: processing all MM-valid confignodes.

[sarbian]

I'd rather have the people who asked me for this to comment on their use case.

But I don't really understand why you are so afraid MM can miss cfg. If your mod needs MM then just add the dll inside you mod directory, then you are sure It will process the file you need to.

The only case that should require hand works is :

- custom cfg by user. Easy solved, they just need to move it to a dir

- old mods : They require some manual copy of the file, which I agree could be annoying

But if I release a version that works just like the old one then you'll have this case : user overwrite the mod with an old 1.3. Most of the patch works, but those that use the new functions don't (* and the like). Your mod is half working and it will be even harder to diag than no patch applied at all.

[NathanKell]

1. They need to move it to a dir _with another copy of MM_, unless I'm misreading you.

And you have that 1.3 problem in either case, because if a user installs an old mod with MM 1.3, then it's going to process confignodes, and so is your version, so you're still stuck. What you're proposing doesn't actually fix the old-MM problem. It just adds complexity.

Because if I go and add MM inside my mod directory, and someone still has 1.3 in the root (the problem you're so worried about)...having another DLL in my mod directory will mean those nodes get processed _twice_. Which if they're adding rather than splicing is _real bad news_.

I think your adding version checking, and making sure only 1 MM patchrun is run, is a great change. But I don't think you need to also decide to not process some confignodes. I think the best policy is to keep that, and process all confignodes, and make sure that the new MM still sits in root GameData, overwriting old copies. And then, obviously, all mods using MM need to update, but I don't offhand recall any that bundle it whose authors have totally disappeared.

[sarbian]

For the 1.3 problem I solved it simply : if 1.3 is present then the new version display a popup explaining that 1.3 is obsolete, telling the user to delete the dll (with full path displayed) and stop itself.

The user custom cfg is a fringe case. The users who can write a MM patch file are quite computer literate and won't have trouble moving 2 files.

[scottholio]

If you named each version of module manager to include the version number e.g. ModuleManager_141.dll and kept it in the GameData folder, then the dll would never be overwritten by an older version. Then just run a check when it is run, and delete older versions if the dll.

In any case, I really enjoy the work you have done and are doing on this. So thanks.

[NathanKell]

Then why also decide to leave some cfg patches unexecuted? That's what I'm still not understanding.

[MedievalNerd]

Was managing MM version that hard for people?

Why not simply have the .dll name include the version.

IE:

ModuleManagerV13.dll

And if someone gets confused at that point well there is a bigger problem to begin with.

I just find having all these multiple ModuleManager files everywhere will just lead to more problems. IE, people over look one of their MM files that wasn't updated or something.

I just find that making a clear distinction of what version if being used can make it easy to the user to check. OK, the mod i'm downloading has 1.2 version, so i'll keep the .13 version I have.

Cheers,

EDIT: I see that my amazing suggestion was already cited. Oh well! Great minds think alike.

Edited November 4, 2013 by MedievalNerd

[Starwaster]

I'd rather have the people who asked me for this to comment on their use case.

Only the people who asked for these changes get to provide input? This affects all of us. You're cutting out the rest of the community who then basically get this rammed down their throats. Just because a few people aked for this doesn't mean it has to be done. The changes under debate address a non-issue. One DLL, one location. If there's a choice required to overwrite or not then, look at the dates.

and honestly there are not (by now) so many versions floating around that we have a version issue to begin with. MM works and aside from updates to address future KSP updates breaking MM. It does one thing and should do it well.

The only other addition I can see being ok are your wildcard extensions. But aside from that, it's not like it has to have tons and tons of features. It's ok if ModuleManager never ever again gets another update!!! Just so long as it continues to do what it currently does with future versions of KSP.

But I don't really understand why you are so afraid MM can miss cfg. If your mod needs MM then just add the dll inside you mod directory, then you are sure It will process the file you need to.

The only case that should require hand works is :

ModuleManager should mirror the way that KSP itself functions with regards to a ConfigNode. KSP loads them and processes them no matter where in Gamedata they are. ModuleManager should do the same. It shouldn't matter where in in the Gamefolder they are any more than any other cfg file. They're already there when ModuleManager loads. So execute them.

But if I release a version that works just like the old one then you'll have this case : user overwrite the mod with an old 1.3. Most of the patch works, but those that use the new functions don't (* and the like). Your mod is half working and it will be even harder to diag than no patch applied at all.

See above. If you're already envisioning adding so many features that something can break then you're falling victim to classic feature bloat already. That's not a good sign.

Was managing MM version that hard for people?.

Nope.

Edited November 4, 2013 by Starwaster

[sarbian]

@Starwaster chill out. I did not mean they are the only one I'll listen too.

I did not release a version and said "this is the one". I am here explainning my choice and listenning to those who reply. As I said I don't understand why you find my option that bad since it simplify mod deployment, but I listen.

@MedievalNerd I have to disagree here. Mod management is not easy for all user.

Edited November 4, 2013 by sarbian

[mwlue]

errrr sorry, what's new in 1.4.1 just curious as the OP didn't mention it.

[sarbian]

I need to update it. This post has the changes :

http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-1-4-1-Beta-release?p=751919&viewfull=1#post751919

[Starwaster]

@Starwaster chill out. I did not mean they are the only one I'll listen too.

I did not release a version and said "this is the one". I am here explainning my choice and listenning to those who reply. As I said I don't understand why you find my option that bad since it simplify mod deployment, but I listen.

@MedievalNerd I have to disagree here. Mod management is not easy for all user.

I'm finding the current implementation simple enough. Even testing your 1.4.x would require me to copy your dll to too many folders and then deciding where to move too many other config files from where they're currently at. Too much work to move from a system that just works.

Too much needless complication to solve a problem that's trivial at best. Non-existent at worst.

But the thing is, after all the objections raised, you still say you don't understand then where do we possibly go from here?

[sarbian]

Yes, I don't undertsand. My change would require mod dev to bundle a DLL in a different directory they actualy use. It's 1 change per mod and all the patch file just need to be in the same dir, or subdirectory of that same dir which shoud already be the case. I don't think it's a verry large change, but maybe it is for some mod and/or I may have missed something obvious.

But I want to release something that the mod dev use, so if most of you think I took a wrong decision I'll use a dll with a version number in the name in /gamedata.

[NathanKell]

sarbian, I apologize if I'm coming across as harsh. Not my intention.

Examples of why this is bad: I would have to just blindly copy your new DLL to every root folder in GameData, just to be sure that there are no stray CFGs. Second, I could no longer, when I'm helping someone on the forums, tell them to stick their changes in a cfg somewhere; I'd have to find out where they have a modulemanager dll and tell them to put the file there. Those or two examples off the top of my head; I can come up with more.

Further, we've all spent the last year or so telling everyone to use only 1 ModuleManager and keep it in root; we've almost won that battle of getting people to understand, and there are tons of posts to that effect. And now we'd have to tell everyone the opposite, and there will be two sets of instructions lying around on the forums.

With my mod dev hat on (all the mods I maintain do or will use ModuleManager) I much prefer the current system. In fact I've already had to say on a few posts "make sure you're using MM 1.3."

[skbernard]

So the wildcard thing would be awesome, but i just cant wrap my head around the need for breaking up multiple DLLs into various mod folders, then only processing CFGs under those folders...

so if i wanted to add science integration to some mods that dont have it right now, like Kethane or SumDum's Station things - in your system i would have to create a CFG under each other those folders with that folder's contained parts that i wanted to add to the tech tree?

That would get annoying as i'd then have to go into each mod's folder, edit that config for those parts, then go to the other folder and mod those parts, and do this for all my mod's parts that i'm adding tot he tree - it would even be more annoying if i could reference all other mod's parts from that one kethane folder or what not - i'd have to remember where i put the CFG with my science integration

right now i just have one file at GameData, called MM_scienceIntegration.cfg and dump all parts in there separated by nice commented out dividers, this seems a lot easier for me

[CAPFlyer]

Yes, I don't undertsand. My change would require mod dev to bundle a DLL in a different directory they actualy use. It's 1 change per mod and all the patch file just need to be in the same dir, or subdirectory of that same dir which shoud already be the case. I don't think it's a verry large change, but maybe it is for some mod and/or I may have missed something obvious.

But I want to release something that the mod dev use, so if most of you think I took a wrong decision I'll use a dll with a version number in the name in /gamedata.

If you don't understand, then your correct course of action would be to revert your change. Period. You have a way of thinking that almost every dev and user who's posted disagrees with. You've broken compatibility with *ALL* currently released mods that use ModuleManager without getting input first. As a guy who's been around a while, you know both are clear signals that you made an error. Just accept that the majority of the community who's posted here don't agree with your thinking and move on.

Yes, I understand your frustration over several different versions of MM out there with different changes made by developers to fit their addon and that some of them *DO* break compatibility with other mods that use custom ModuleManager instances, but the solution isn't to totally change how it's implemented. The solution is to change how the devs implement it and allow you to have the base MM dll in the root GameData folder and then if they want a custom implementation, they must create their own DLL branch with a different name.

[Guest]

I second the call for a central, single ModuleManager plugin rather than tons of different little ones, at the very least so that functionality of the :final directive is retained.

E: IIRC, this was a Majiir thing, right? I recall him bringing it up in #KSPmodders, what's his use case? It might be beneficial to have MM check for an MM instance within the mod directory, although that presents other challenges.

Edited November 4, 2013 by regex

[Starwaster]

Yes, I understand your frustration over several different versions of MM out there with different changes made by developers to fit their addon and that some of them *DO* break compatibility with other mods that use custom ModuleManager instances, but the solution isn't to totally change how it's implemented. The solution is to change how the devs implement it and allow you to have the base MM dll in the root GameData folder and then if they want a custom implementation, they must create their own DLL branch with a different name.

What mods are distributing actual modified ModuleManager.dll files?