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

[praise the suuun]

*edit* found the issue. all the mods are fine together with there own modulemnager.dll's except "deadly reentry. thats the one thats messing up my stock parts

[ialdabaoth]

*edit* found the issue. all the mods are fine together with there own modulemnager.dll's except "deadly reentry. thats the one thats messing up my stock parts

"with their own modulemanager.dll's"? You should never, EVER, have more than one copy of modulemanager.dll in your entire /GameData folder tree. EVER.

[praise the suuun]

but theyre written specifically for one mod and then coded to minimize clashes, deadly reentry just wasnt coded well enough.

[King Jareth]

ialdabaoth wrote modulemanager.dll other mods use the file he made.

If he says you should only have one copy of the file I think you should listen.

[ialdabaoth]

but theyre written specifically for one mod and then coded to minimize clashes, deadly reentry just wasnt coded well enough.

Afraid not. They're all written to be used by any number of mods. When modulemanager.dll is re-written to minimize clashes, it's re-written to minimize clashes with EVERYTHING. It's designed to be a SINGLE plugin, which any number of other mods can rely on. Having multiple copies of ANY plugin DLL will cause problems, because the same code will get executed multiple times.

modulemanager.dll goes in your /GameData root. If there's already a modulemanager.dll in your /GameData root, figure out which one is newer and keep that one.

[XeroXion]

but theyre written specifically for one mod and then coded to minimize clashes, deadly reentry just wasnt coded well enough.

The only thing to do with ModuleManager that is written specifically for each mod is the *.cfg file that stores their part modifications. As others have stated, you should only have ONE ModuleManager.dll, because everybody gets theirs from ialdabaoth here.

[Oinker]

I don't want to modify individual parts for each mod, but all parts where module = CommandPod in order to add mechjeb2 to them all. Additionally, I want to add remotetech to any part when module = CommandPod and CrewCapacity = 0. Can this be done? If not, would you add this functionality to the dll?

in the meantime, I have this: MechJeb and RemoteTech for All

Adds MechJeb2 to all command modules and probes. Adds RemoteTech remote control to all probes. Works for the stock parts and all the major addons.

Edited July 12, 2013 by Oinker

[praise the suuun]

so what do i do when mods come packed with it and place their own one?

[Frederf]

"with their own modulemanager.dll's"? You should never, EVER, have more than one copy of modulemanager.dll in your entire /GameData folder tree. EVER.

Except practically all MM-enabled mods include a copy of the dll with their mod.

[Oinker]

Except practically all MM-enabled mods include a copy of the dll with their mod.

Kindly ask the author to remove ModuleManager.dll from his mod and point to this forum (page 1) for the download. Ask that he change the documentation to copy the ModuleManager.dll to the {KSP}/GameData folder.

[ialdabaoth]

Also, ideally each mod maker should have their zipfile contain a /GameData directory, with modulemanager.dll directly in the /GameData directory, and everything else in their own sub-directory. (DeadlyReentry and ModularFuelSystem do this correctly, for example; both being my mods)

[Oinker]

Also, ideally each mod maker should have their zipfile contain a /GameData directory, with modulemanager.dll directly in the /GameData directory, and everything else in their own sub-directory. (DeadlyReentry and ModularFuelSystem do this correctly, for example; both being my mods)

It's your baby, but the reason I don't include ModuleManager.dll with my mod is so they come here to get the latest version. That way you don't end up with somebody overwriting the new with the old.

[praise the suuun]

Also, ideally each mod maker should have their zipfile contain a /GameData directory, with modulemanager.dll directly in the /GameData directory, and everything else in their own sub-directory. (DeadlyReentry and ModularFuelSystem do this correctly, for example; both being my mods)

So if i want to have more than one MM using mod, how do i have each of theyre own copies all directly in gamedata? wont they overwrite each other and the last to be added is the only mod with specific code in place?

[King Jareth]

Modulemanager.dll is not mod specific, the .cfg files are.

[m4ti140]

I ran into a strange issue. Although I made sure that I have only one ModuleManager.dll in the entire KSP folder (not only GameData), it applies all changes twice. When I look into info in VAB or right click part, all functions coming from modules injected with Module Manager appear twice, thus I suspect the part.cfg gets loaded with two identical MODULE sections. I checked and I haven't inserted lines manualy before. I have no idea what's going on. It kinda breaks remote tech bc it doubles energy drain.

Also, when testing this out I ran into an issue with DR. I know this is wrong thread but since you'll be reading this anyway, ialdabaoth, here we go: When ever I try inserting multiple parts with heatshield using symetry, at the very moment when it gets snaped to node I hear terrible noise, like if both reentry noise and g-force stretching was played at once, at max volume.

EDIT: The first one got solved automagically ??? If the problem comes back I'll inform you.

Edited July 12, 2013 by m4ti140

[praise the suuun]

Modulemanager.dll is not mod specific, the .cfg files are.

this is helpful. but I have another question. I've been cleaning out all but one modulemanager.dll for gamedata, but my issue (values of stock air breathers frzon at non stock values) still persists. will a clean install of all modulemanager using mods reset this problem?

[Cilph]

Feature request: Ability to globally change all instances of a partmodule.

eg:

@MODULE[ModuleCommand]
{
    @name = ModuleSomethingElse
}

not

@PART[SomePart]
{
    @MODULE[ModuleCommand]
    {
        @name = ModuleSomethingElse
    }
}

Regex or wildcards maybe?

Edited July 13, 2013 by Cilph

[Kaleb]

As a software developer myself, I totally understand ialdabaoth's reluctance to add complexity via wildcard/regex support. But I wonder whether an alternative compromise solution might be acceptable: what if the square brackets after PART could list multiple parts? Maybe comma-separated (or whatever delimiter works)? It would just be a shorthand for typing the same block of text multiple times, but would (hopefully) avoid the potential for unforeseen consequences that a regex might introduce. So it might look something like this:

@PART[SomePart, SomeOtherPart, YetAnotherPart, JebediahsPieceOfJunk, MyUberModdedCheatPart]
{
    @MODULE[ModuleCommand]
    {
        @name = ModuleSomethingElse
    }
}

Granted, you still have to manually update the part list when another part comes along, but at least its all in one place.

[asmi]

Looks like the mod doesn't work with parts that have space in it's name. I've tried this:

@PART[Mir Core Module]

{

MODULE

{

name = MechJebCore

}

}

and this:

@PART["Mir Core Module"]

{

MODULE

{

name = MechJebCore

}

}

Neither works.

[AlmightyR]

Is it possible to change the torque-curve keys in the following syntax?

MODULE
    {
    	name = TracksMain
    	developmentMode = false
    	identity = Controller1
    	customStatusLine = Track Links:
    	customStatusLineMin = 15
    	customStatusLineMax = 19
    	brakingTorque = 10
	rollingResistance = 0.5
    	TorqueCurve
    	{
    		key = -20 0
    		key = -10 0.5
    		key = 0 15
    		key = 10 0.5
    		key = 40 0
    	}
    	INPUT_RESOURCE
    	{
    		name = ElectricCharge
    		torqueLinkedRate = 0.01
    		rpmLinkedRate = 0.0001
    	}
    }

How? Just make a "@TorqueCurve" reference and give new values? I'm not sure how to do this.

[AlmightyR]

As a software developer myself, I totally understand ialdabaoth's reluctance to add complexity via wildcard/regex support. But I wonder whether an alternative compromise solution might be acceptable: what if the square brackets after PART could list multiple parts? Maybe comma-separated (or whatever delimiter works)? It would just be a shorthand for typing the same block of text multiple times, but would (hopefully) avoid the potential for unforeseen consequences that a regex might introduce. So it might look something like this:

@PART[SomePart, SomeOtherPart, YetAnotherPart, JebediahsPieceOfJunk, MyUberModdedCheatPart]
{
    @MODULE[ModuleCommand]
    {
        @name = ModuleSomethingElse
    }
}

Granted, you still have to manually update the part list when another part comes along, but at least its all in one place.

I like the idea...Bloody painful (and extremely ugly-looking) to, for example, add mechjeb to all command modules installed (vanilla + mods) by hand.

Which this, rather than repeating the @MODULE code infinitillion times, only one, plus the list of parts up top, would be required.

[sarbian]

I have a version with wildcard pattern (* ?) and test for things like module = CommandPod.

The code is not too ugly. But I won't post if without ialdabaoth consent.

[Oinker]

I have a version with wildcard pattern (* ?) and test for things like module = CommandPod.

The code is not too ugly. But I won't post if without ialdabaoth consent.

That's what I'm talkin' about! Maybe put the code online on Google Docs or Office Online so you can work on it together or mark it up. Can we also check for multiple conditions with IF: AND, OR, >, <, =, not = :THEN set condition

[sarbian]

I'll wait for a word from ialdabaoth. More complex test will make the code ugly fast, and there is limtation with how KSP parse cfg files ( can't use = )

[Captain Man]

Is there a way to comment out lines in the .cfg?