[0.20] ModuleManager 1.3 - for all your stock-modding needs

[Camacha]

I have sort of the same question. How would I go about to get FAR, RemoteTech, Crew Support and Deadly Reentry working via the Mod Manager? Would that simply be throwing in the official versions of the mod, the Module Managed versions/configs and adding Deadly Reentry?

I am sort of confused by the seperate ModuleManager cfg's. Is any manual assembly required before going to the Mod Manager or can I just throw everything together and let the software work it out? I am absolutely loving not having to dig through configs and the copypasta that comes with that, but I am a bit unsure how to proceed now.

[Kethevin]

*whew* I wasn't sure if it was time to pound my head on the keyboard.

Thanks!

[ialdabaoth]

I have sort of the same question. How would I go about to get FAR, RemoteTech, Crew Support and Deadly Reentry working via the Mod Manager? Would that simply be throwing in the official versions of the mod, the Module Managed versions/configs and adding Deadly Reentry?

I am sort of confused by the seperate ModuleManager cfg's. Is any manual assembly required before going to the Mod Manager or can I just throw everything together and let the software work it out? I am absolutely loving not having to dig through configs and the copypasta that comes with that, but I am a bit unsure how to proceed now.

Yep! All you have to do is install the mods and make sure ModuleManager.dll is installed, it merges everything together itself.

Then if later you want to make a custom config, you could make for example GameData/Camancha/Camancha.cfg and type in part tweaks. MOST of the time you don't need to know the details; ModuleManager (as of 1.0) just finds all the .cfg files, figures out which ones are @patch configs, and applies them (applying all :Final configs after all non-final configs)

[loppnessmonsta]

I have sort of the same question. How would I go about to get FAR, RemoteTech, Crew Support and Deadly Reentry working via the Mod Manager? Would that simply be throwing in the official versions of the mod, the Module Managed versions/configs and adding Deadly Reentry?

I am sort of confused by the seperate ModuleManager cfg's. Is any manual assembly required before going to the Mod Manager or can I just throw everything together and let the software work it out? I am absolutely loving not having to dig through configs and the copypasta that comes with that, but I am a bit unsure how to proceed now.

Expanding on this, can this find strings/commands/whatever other than PART{}? So, for example, could I tell it to look for every instance of MODULE { Name = ModuleEngines } and, when it finds that, to add Throttlesteering to that part? It would need to be outside that particular string, but that would simplify things on the user end. That way it could look for all engines, give them throttlesteering. Look for all command pods, give them MechJeb, etc, with only one search command.

Edit: Actually, as I'm re-reading the instructions, it sounds like it can do this, using the @NODE commands. That's awesome. Now if only my KSP would load. Edit2: Oops, looks like KSP doesn't like blank cfg files.

Edited June 1, 2013 by loppnessmonsta

[ialdabaoth]

Expanding on this, can this find strings/commands/whatever other than PART{}? So, for example, could I tell it to look for every instance of MODULE { Name = ModuleEngines } and, when it finds that, to add Throttlesteering to that part? It would need to be outside that particular string, but that would simplify things on the user end. That way it could look for all engines, give them throttlesteering. Look for all command pods, give them MechJeb, etc, with only one search command.

Edit: Actually, as I'm re-reading the instructions, it sounds like it can do this, using the @NODE commands. That's awesome. Now if only my KSP would load. Edit2: Oops, looks like KSP doesn't like blank cfg files.

well, keep in mind that it only does search-and-replace within its current context.

So if you have a @PART[blah] { @MODULE[Foo] }, it will find MODULE Foo within part Blah. If you just did @MODULE[Foo] {}, it would look for all modules that aren't attached to parts - and of course not find any. If it DID find any, it would replace one of them (this doesn't do wildcard search-and-replace).

I'm a little leery of allowing people to do @PART[*] {} wildcarding; there's some weird-but-inevitable edge cases where the logic won't do what you expect, no matter how it's coded. I COULD solve this by adding a full regexp system and conditionals, but you'd have to pay me a salary to devote that much time and effort to this.

Edited June 1, 2013 by ialdabaoth

[Fel]

well, keep in mind that it only does search-and-replace within its current context.

So if you have a @PART[blah] { @MODULE[Foo] }, it will find MODULE Foo within part Blah. If you just did @MODULE[Foo] {}, it would look for all modules that aren't attached to parts - and of course not find any. If it DID find any, it would replace one of them (this doesn't do wildcard search-and-replace).

I'm a little leery of allowing people to do @PART[*] {} wildcarding; there's some weird-but-inevitable edge cases where the logic won't do what you expect, no matter how it's coded. I COULD solve this by adding a full regexp system and conditionals, but you'd have to pay me a salary to devote that much time and effort to this.

Why are you over-complicating what is fairly simple? DOS has been wild-carding for ages, only "problems" would be "user error" (i.e. del /s /q c:\* <--- AND NO ONE TRY THAT!!!)

(And even then, C# has native RegEx support, so your parser would just turn any thing in the PART[] into a "new regex(string)")

In fact, that is an insanely lazy way to do it (effective though) which means the only thing you'd have to do is walk the node rather than using the GetNode / GetValue interface.

Edited June 1, 2013 by Fel

[TriggerAu]

How about an alternative to wildcarding. What if you made it so it could target based on other attributes. eg. @Part[VesselType=Probe] - then for example your remotetech cfg file could be much more compact. Would also help for say adding Flight Engineer to all commandpods, or other things like that. Just a suggestion/idea.

BTW. This is a great mod and it has made installing things for me much easier.

Thanks

[Fel]

How about an alternative to wildcarding. What if you made it so it could target based on other attributes. eg. @Part[VesselType=Probe] - then for example your remotetech cfg file could be much more compact. Would also help for say adding Flight Engineer to all commandpods, or other things like that. Just a suggestion/idea.

BTW. This is a great mod and it has made installing things for me much easier.

Thanks

Selectors are actually a bit more work than wildcards (A RegEx can replace "String.Compare", but Selectors require entirely different code). The reason why isn't because it is "hard," but for some reason ialdabaoth doesn't want to do any expansion on the project. I SUSPECT he wants to act as an intermediary between "SQUAD Code" and "ModuleManager" such that when squad fixes their code he can abandon the project.

Although he did do a lot of brute-force advertisement; but perhaps he just wanted people to switch over to the format rather than persist in their old ways.

*In short, I notice there are a number of people who agree with my initial assessment... ialdabaoth understands what would need to be done... but keeps giving dissatisfying responses as to why it will not be done.

Edited June 1, 2013 by Fel

[loppnessmonsta]

"im not getting paid enough for that" seems like a perfectly valid response to me. unfortunately, that kinds limits the usefulness of this from the user end. if i need to list each part i want to change, i'm not saving much, if any, time/effort over just going to each part and doing the change myself. Still incredibly useful from the modder end, though.

[yongedevil]

ModuleManager is awesome. Thank you ialdabaoth.

I have a question though about trying to modify parts that aren't installed. I'm considering doing this to add support for other mods into my own. Are there any downsides to this that I should be aware of?

[ialdabaoth]

Why are you over-complicating what is fairly simple? DOS has been wild-carding for ages, only "problems" would be "user error" (i.e. del /s /q c:\* <--- AND NO ONE TRY THAT!!!)

(And even then, C# has native RegEx support, so your parser would just turn any thing in the PART[] into a "new regex(string)")

In fact, that is an insanely lazy way to do it (effective though) which means the only thing you'd have to do is walk the node rather than using the GetNode / GetValue interface.

Be my guest. ModuleManager has an open API; you can add it to your References and call ModifyNode() and ModifyPart() to your heart's content. All the nodes are in GameDatabase.GetConfigNodes(string type), where in this case type is exact (for example, "@PART[*]" would be one type, where @PART[a*]" would be another type, and @PART[a*]:Final" would be a third type).

I had less than this to go on when I started, and had a working version within four hours. Let's see how you do.

[ialdabaoth]

ModuleManager is awesome. Thank you ialdabaoth.

I have a question though about trying to modify parts that aren't installed. I'm considering doing this to add support for other mods into my own. Are there any downsides to this that I should be aware of?

None whatsoever; it starts with the PART {name=part} node, searches for all @PART[part] nodes and applies them, then searches for all @PART[part]:Final nodes and applies them. If there's no PART {name=part}, then it never even starts the process so your @PART[part] node just gets ignored by the system.

[Zakarik]

Hi,

I found a bug when I used B9 Aerospace and ModuleManager. The bug is with ExsurgentEngineering.dll and ModuleManager.dll plugin.

After some research, it is with "primaryEngine", which is used in Engine_Sabre_M and Engine_Sabre_S in B9.

When ModuleManager found "primaryEngine" it does not load any more .cfg and sent an error in DebugMode.

Sorry for my bad English.

[Scotius]

I have the same problem. Looks like i will ave to delay playing with SABREs, because MM is too essential for flights i already have all over the system. Stack of cookies for anyone who can find a workaround to this snag

[Mihara]

Ah, so that's why all my part patches stopped working.

[khyron42]

Sorry, edited to remove my complaint, which should go to the people redistributing this dll without good installation instructions.

Edited June 2, 2013 by khyron42

[Scotius]

It's an issue with ExsurgentEngineering. dll. Deleting this file only partially restores useability of MM. For example: on some ships i can detach and attach small parts using 'grab' command from KAS. On other i can only detach them, but there is no option to attach parts again - they are stuck to my Kerbal.

[yongedevil]

I'm having trouble applying changes to a part because it has a space in the name. I'm using the following syntax.

@PART[Part Name]
{
	...
}

If I remove the space in the part.cfg and in the modulemanger.cfg it works so I know it's the space character that causing trouble. Does anyone know how to go about specifying a part that has a space in the name?

[ialdabaoth]

I'm having trouble applying changes to a part because it has a space in the name. I'm using the following syntax.

@PART[Part Name]
{
	...
}

If I remove the space in the part.cfg and in the modulemanger.cfg it works so I know it's the space character that causing trouble. Does anyone know how to go about specifying a part that has a space in the name?

Spaces in names are bad.

[Mihara]

Spaces in names are bad.

That goes without saying, but what do we do with them?

[ialdabaoth]

That goes without saying, but what do we do with them?

Edit the part.cfg to not have a space in it, and post in the original mod author's thread that they need to re-release without spaces.

I know that the point of ModuleManager is to be able to make changes to parts without editing their config files, but that's precipitated on the idea that those config files don't have errors in them. If a cfg file isn't built correctly, go ahead and edit it to be right, and then apply ModuleManager to make further changes.

[Mulbin]

Ok I have a weird problem with mod compatibility...

I use Ioncross and Remotetech, both of which use module manager. Copying the ioncross modulemanager file over the remotetech works fine... both mods work fine.

Here is the problem - For me there is far too much O2 in the pods in Ioncross (weeks of O2 in fact) which makes the mod pointless for Mun missions... which I mostly play. So I generally alter the amounts of O2 for each pod in ModuleManager_Squad.cfg

However if I make even the tiniest change to ModuleManager_Squad.cfg, it kills part of the remotetech mod - the part that adds remotetech capability to stock probes and antenna.

Any Idea why this happens? Is there a work around?

Basically it seems if you alter a single number in ModuleManager_Squad.cfg, module manager can no longer see remotetech.cfg Which is in a completely different folder.... for different parts... for a different mod...

Is it not possible to edit cfg files on mods that use modulemanager?

Edited June 3, 2013 by Mulbin

[toril]

Ok I have a weird problem with mod compatibility...

I use Ioncross and Remotetech, both of which use module manager. Copying the ioncross modulemanager file over the remotetech works fine... both mods work fine.

Here is the problem - For me there is far too much O2 in the pods in Ioncross (weeks of O2 in fact) which makes the mod pointless for Mun missions... which I mostly play. So I generally alter the amounts of O2 for each pod in ModuleManager_Squad.cfg

However if I make even the tiniest change to ModuleManager_Squad.cfg, it kills part of the remotetech mod - the part that adds remotetech capability to stock probes and antenna.

Any Idea why this happens? Is there a work around?

Basically it seems if you alter a single number in ModuleManager_Squad.cfg, module manager can no longer see remotetech.cfg Which is in a completely different folder.... for different parts... for a different mod...

Is it not possible to edit cfg files on mods that use modulemanager?

don't know if this will help, but i had a simular problem and it turned out o be the chatterer cfg file for mm that was messing up the stock eantennas for me. they replace the animation with the chatterer module instead of just adding the chatterer module to the end. I assume that mm works on a first come first served method and when i changed a file it processed the rbr file first and made it impossable for the rtech file to work

Edited June 3, 2013 by toril

[zgrillo2004]

I dont understand how this work. am I suppose to modify something in order to make the probe parts to Remote-tech?

[lyndonguitar]

Hi,

I found a bug when I used B9 Aerospace and ModuleManager. The bug is with ExsurgentEngineering.dll and ModuleManager.dll plugin.

After some research, it is with "primaryEngine", which is used in Engine_Sabre_M and Engine_Sabre_S in B9.

When ModuleManager found "primaryEngine" it does not load any more .cfg and sent an error in DebugMode.

Sorry for my bad English.

Any fix yet?