Jump to content

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


ialdabaoth

Recommended Posts

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 by loppnessmonsta
Link to comment
Share on other sites

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 by ialdabaoth
Link to comment
Share on other sites

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 by Fel
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by Fel
Link to comment
Share on other sites

"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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :D

Link to comment
Share on other sites

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

Edited by khyron42
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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. :(

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Mulbin
Link to comment
Share on other sites

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 by toril
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...