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

[Majiir]

Ialdabaoth, could you post license terms for creating and distributing derivative works? Your license currently only addresses distribution of the compiled assembly.

Cheers,

Majiir

[somnambulist]

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

Two forward slashes at the start of a line. // comment

[ialdabaoth]

Ialdabaoth, could you post license terms for creating and distributing derivative works? Your license currently only addresses distribution of the compiled assembly.

Cheers,

Majiir

Hrm. I had honestly never considered derivative works. I'll need to think about it; I've always been a fan of complete open-source CC style licenses, but I'm afraid of too many incompatible ModuleManager derivatives cluttering things up and leaving me a debugging nightmare.

HOWEVER, since ModuleManager seems to be highly stable at this point, I don't see much reason not to release it into the wild and see what kind of mutant offspring it produces.

From this point forward, I'm releasing ModuleManager's source under a CC share-alike license. Anyone is free to do anything they like with ModuleManager's source, with two caveats:

1. You credit me as the original creator that your code is based on

2. You make it ABSOLUTELY CLEAR that your code is not the original ModuleManager, and that any problems that people have with your fork should be taken up with YOU, not me.

Beyond those caveats, knock yourselves out, but in the interest of politeness and code extensibility, it would be nice if people who are writing wildcard systems could make them interface with and extend the ModuleManager.dll assembly, rather than overwriting it. I.e.: ModuleManager.dll should give you all the tools necessary to do ConfigNode merging and exact-match ConfigNode referencing, so please make a module that *interfaces* with ModuleManager.dll rather than making your own DLL that *replaces* ModuleManager.dll, or we'll BOTH have a nightmare horde of angry and confusing users who don't know who to yell at when things break.

And since the wildcard genie is out of the bottle and I'm not responsible for granting its wishes, I'll go ahead and muse how I think wildcarding SHOULD work. I think your ideal syntax looks something like this:

@PART[*]:HAS(@MODULE[ModuleEngines]:HAS(PROPELLANT[Oxidizer]), @MODULE[ModuleAlternator], !MODULE[ModuleGimbal])
{
}

That would apply itself to any PART that contains both a ModuleAlternator and a ModuleEngines MODULE and DOESN'T contain a ModuleGimbal, but only if the ModuleEngines contains an Oxidizer PROPELLANT.

I think the IF/AND/OR stuff sounds like a good idea at first, but you'll inevitably wind up over-engineering it. Really you just need AND and NOT; OR can be handled by making multiple cases.

Edited July 20, 2013 by ialdabaoth

[ialdabaoth]

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.

You can absolutely do this, but you have to replace all the values instead of adding new ones. You'd do the following:

@MODULE[TracksMain]
    {
    	@TorqueCurve
    	{
    		@key,0 = -15 -1 // changed from -20 0
    		@key,1 = -12 -0.5 // changed from -10 0.5
    		@key,2 = 10 0 // changed from 0 15
    		@key,3 = 15 0.5 // changed from 10 0.5
    		@key,4 = 30 1 // changed from 40 0
    	}
    }

[xZise]

Hi is it already possible to add the same modules to multiple parts like:

@PART[foo]
@PART[bar]
{
    MODULE
    {
        name=snafu
    }
}

Oh and I got another question: Are foo/bar the part's name or the part's directory name?

Fabian

Edited July 21, 2013 by xZise

[ialdabaoth]

Hi is it already possible to add the same modules to multiple parts like:

@PART[foo]
@PART[bar]
{
    MODULE
    {
        name=snafu
    }
}

Oh and I got another question: Are foo/bar the part's name or the part's directory name?

Fabian

1. No, that doesn't work that way (or at least, I'd be VERY surprised if it did).

2. The part's name.

[Oinker]

@PART[cupola]
@PART[landerCabinSmall]
@PART[Mark1Cockpit]
@PART[Mark2Cockpit]
@PART[mark3Cockpit]
@PART[Mark1-2Pod]
@PART[mk1pod]
@PART[mk2LanderCabin]
@PART[probeCoreCube]
@PART[probeCoreOcto]
@PART[probeCoreOcto2]
@PART[probeCoreSphere]
@PART[probeStackLarge]
@PART[probeStackSmall]
@PART[seatExternalCmd]
{
	MODULE
	{
	name = MechJebCore
	}
}

I tested this and it does not work. Too bad though. It's a hell of a lot easier to read and update.

[xZise]

When I get the source correctly, you parse the file by the game, so there is no way to add this in without implementing an own parser?

Fabian

[sarbian]

[...]From this point forward, I'm releasing ModuleManager's source under a CC share-alike license. [...]

Thanks

Beyond those caveats, knock yourselves out, but in the interest of politeness and code extensibility, it would be nice if people who are writing wildcard systems could make them interface with and extend the ModuleManager.dll assembly, rather than overwriting it. I.e.: ModuleManager.dll should give you all the tools necessary to do ConfigNode merging and exact-match ConfigNode referencing, so please make a module that *interfaces* with ModuleManager.dll rather than making your own DLL that *replaces* ModuleManager.dll, or we'll BOTH have a nightmare horde of angry and confusing users who don't know who to yell at when things break.

And since the wildcard genie is out of the bottle and I'm not responsible for granting its wishes, I'll go ahead and muse how I think wildcarding SHOULD work. I think your ideal syntax looks something like this:

@PART[*]:HAS(@MODULE[ModuleEngines]:HAS(PROPELLANT[Oxidizer]), @MODULE[ModuleAlternator], !MODULE[ModuleGimbal])
{
}

That would apply itself to any PART that contains both a ModuleAlternator and a ModuleEngines MODULE and DOESN'T contain a ModuleGimbal, but only if the ModuleEngines contains an Oxidizer PROPELLANT.

I'll see how I can do that. A DLL that would only process node that the default modulemanager dont process, and call modulemanager function do do the editing. Your syntax look nice, I'll check how it's parsed by KSP.

I think the IF/AND/OR stuff sounds like a good idea at first, but you'll inevitably wind up over-engineering it. Really you just need AND and NOT; OR can be handled by making multiple cases.

Won't do it in mine. You are right, it's over-engineering

[Cloudancer]

And since the wildcard genie is out of the bottle and I'm not responsible for granting its wishes, I'll go ahead and muse how I think wildcarding SHOULD work. I think your ideal syntax looks something like this:

@PART[*]:HAS(@MODULE[ModuleEngines]:HAS(PROPELLANT[Oxidizer]), @MODULE[ModuleAlternator], !MODULE[ModuleGimbal])
{
}

That would apply itself to any PART that contains both a ModuleAlternator and a ModuleEngines MODULE and DOESN'T contain a ModuleGimbal, but only if the ModuleEngines contains an Oxidizer PROPELLANT.

I think the IF/AND/OR stuff sounds like a good idea at first, but you'll inevitably wind up over-engineering it. Really you just need AND and NOT; OR can be handled by making multiple cases.

Sounds a lot like SQL logic:cool:.

Sarbin, if you stick to SQL rules it's likely to be pretty robust. Not saying you should do all of SQL (that's way overkill), but modeling your logic so it has the same general syntax should avoid problems later from design choices now. Do you have a link to your code in Github or somewhere you wouldn't mind sharing? I'd love to see what you have so far.

-Cloudancer

[Benie]

Could I get the script to make MechJeb be enabled of all pods/capsules? I know it's lurking around here.

Edited July 23, 2013 by Benie

[Oinker]

Another thing, could I get the script to make MechJeb be enabled of all pods/capsules? I know it's lurking around here.

Click here: MechJeb on all stock capsules and all major add-ons (selectable for add-ons).

[Benie]

Nevermind. I found a way. Thanks.

Edited July 23, 2013 by Benie

[sarbian]

Do you have a link to your code in Github or somewhere you wouldn't mind sharing? I'd love to see what you have so far.

As ialdabaoth said IF/OR are overkill. And would remind me to much of a CS test 15 years ago

I did not have much time to work on it but here is what I have : https://github.com/sarbian/MMSarbianExt/ ( I'll change the name later )

Wildcard search works. I need to implement the condition search.

I found out that the parenthesis are not parsed by KSP, so I had to change them for brackets : @PART[*]:Has[@MODULE[ModuleEngines]:HAS[PROPELLANT[Oxidizer]]

It's less friendly to read ...

[ialdabaoth]

As ialdabaoth said IF/OR are overkill. And would remind me to much of a CS test 15 years ago

I did not have much time to work on it but here is what I have : https://github.com/sarbian/MMSarbianExt/ ( I'll change the name later )

Wildcard search works. I need to implement the condition search.

I found out that the parenthesis are not parsed by KSP, so I had to change them for brackets : @PART[*]:Has[@MODULE[ModuleEngines]:HAS[PROPELLANT[Oxidizer]]

It's less friendly to read ...

Actually, I mistyped in my original example; this should probably be

@PART[*]:HAS[@MODULE[ModuleEngines]:HAS[@PROPELLANT[Oxidizer]]

That way you can just recurse on down as far as you need to go.

[xZise]

Isn't there one ] missing?

Fabian

[sarbian]

Yes there is.

Ok, finished the condition check.

New thread to keep this one clear

http://forum.kerbalspaceprogram.com/showthread.php/41616-Extension-for-ModuleManager-with-wildcard-and-conditional-v0-1-23-july-2013

[BioSehnsucht]

Does this still work in 0.21? Is it needed? (Since in theory, wasn't what MM does originally supposed to be stock, but has been bugged the whole time?)

[Gaius]

Does this still work in 0.21? Is it needed? (Since in theory, wasn't what MM does originally supposed to be stock, but has been bugged the whole time?)

Yup, it still works. I assume it's still needed... if there's now a stock way to do this, I'd love to know the details.

[BioSehnsucht]

Yup, it still works. I assume it's still needed... if there's now a stock way to do this, I'd love to know the details.

Well, way back on the first page ... this is why I was asking if it was still necessary I guess "If it ain't broke because the community fixed it, we have higher priority bugs / features"

Wait, I thought this was a core feature that was currently broken. Huh?

It is. I fixed it.

Also: updated the .zip to include a config file that applies ModularFuelTanks data to KSPX parts.

[Benie]

Ok. I read somewhere that someone managed to hack a Hooligan Labs Airship to go higher. I'm having trouble trying to do so with ModuleManager.

Basically, I set the 'Una' Airship to have 50.2 volume, and only that. But when I do a test (Core + Una Airship), one thing is the GUI doesn't show up. The next, when the physics kick in, it goes skyward on its own. It literally launches by itself, like a rocket. It climbed to an altitude of 247km out of Kerbin, at a surface speed of over 1200m/s.

Not sure if it's even caused by this thing, but.. this is what I currently have in my little "script";

@PART[HL_AirshipEnvelope_Una] {
	MODULE {
		name = HLEnvelopePartModule

		envelopeVolume = 50.2
	}
}

Any help would be lovely. I'm using the 0.20 version of the Airship mod.

I also have another question. When making these custom scripts, do they have to be in the same folder as what you're editing, or can I put it in /GameData/MMScripts/ and still have them load?

Edited July 27, 2013 by Benie

[sarbian]

Your code add a new module to the part, and you want to edit the one already here.

You need to do this :

@PART[HL_AirshipEnvelope_Una] {
	@MODULE[HLEnvelopePartModule] {
		@envelopeVolume = 50.2
	}
}

[Benie]

Ok, cool. I will try this and see if it works.

[Benie]

I hope you can help me with another problem. I tried to add the 0.21 IVA of the hitchhiker module into 0.20. It works if I put it directly into a modded version of that module, but I can't do it through MM.

This is my script. I tried to make it similar to the way you helped me before;

@PART[crewCabin] {
	@INTERNAL[crewCabinInternals]
	}
}

It won't give me the IVA of the Stock hitchhiker module, but as I said, it will of my modded version. The modded version is just shrinking it down so it'll fit on standard-sized rockets.

[sarbian]

This time the Internal is not already here, so you need to remove the @ to add it. But i don't know if this internal will work with 0.20

@PART[crewCabin] {
	INTERNAL[crewCabinInternals]
	}
}