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

[Arrowmaster]

@PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand]]:Final
{
	@category = Control
}

Should be what you want.

[BudgetHedgehog]

Lurvly, I'll give that a shot when I'm home, thanks!

[Senshi]

Would it be possible to allow calculations using ModuleManager with reasonable effort?

This would allow to apply "flat" scalings very easily, such as:

@PART[*]:HAS[@MODULE[ModuleCommand]]
	@MODULE[ModuleReactionWheel]
	{
		@PitchTorque = @value * 0.1
		@YawTorque = @value * 0.1
		@RollTorque = @value * 0.1
	}
}

To achieve the same right now, you need to access every single part, calculate the new value yourself and add it as a new definition. And whenever some part mod gets added/updated, you have to revisit it...

[ialdabaoth]

Would it be possible to allow calculations using ModuleManager with reasonable effort?

This would allow to apply "flat" scalings very easily, such as:

@PART[*]:HAS[@MODULE[ModuleCommand]]
	@MODULE[ModuleReactionWheel]
	{
		@PitchTorque = @value * 0.1
		@YawTorque = @value * 0.1
		@RollTorque = @value * 0.1
	}
}

To achieve the same right now, you need to access every single part, calculate the new value yourself and add it as a new definition. And whenever some part mod gets added/updated, you have to revisit it...

I think so, yes! However, I think it would be better like this:

@PART[*]:HAS[@MODULE[ModuleCommand]]
	@MODULE[ModuleReactionWheel]
	{
		@PitchTorque *= 0.1
		@YawTorque *= 0.1
		@RollTorque *= 0.1
	}
}

Full-on math might be a little much, but at the very least I can do +=, -=, and *=

[Gaius]

Some way to reference the existing value would be nice, though. Particularly with the description. I've wanted in the past to embed the old description in a new one, e.g. something like.

@description = Some new intro text. @description Some new postscript.

Or even better:

@description = Awesome part, but mind the @mass ton weight...

[Superfluous J]

Some way to reference the existing value would be nice, though. Particularly with the description. I've wanted in the past to embed the old description in a new one, e.g. something like.

@description = Some new intro text. @description Some new postscript.

Or even better:

@description = Awesome part, but mind the @mass ton weight...

Let me tack on my want to this (pseudocode, I don't care how per-se):

@description = $mid(@descripiton, 0, 56) thing to say in the middle $mid(@description, 57, 0)

[GavinZac]

I think so, yes! However, I think it would be better like this:

@PART[*]:HAS[@MODULE[ModuleCommand]]
	@MODULE[ModuleReactionWheel]
	{
		@PitchTorque *= 0.1
		@YawTorque *= 0.1
		@RollTorque *= 0.1
	}
}

Full-on math might be a little much, but at the very least I can do +=, -=, and *=

Well, that would be cool, but the ideal usecase for that is making a "little and large" version of parts. Unfortunately we still won't be able to define a new part, right?

[Senshi]

Would be great if it makes it in, iald .

No need for a full-on math library. And += is certainly cleaner, good idea.

My "typical usercase" would be just what I wrote in pseudocode: Numbing down all those ridiculously overpowered reaction wheels across the board . as I still have the full selection/filter range available this way, I can still make sure that e.g. mod parts with reasonable reaction wheels can be exempted. It'd be perfect to have conditional comparator selections:

"if PitchTorque * mass > 1 then @PitchTorque = PitchTorque / (PitchTorque * mass)

But that would be a whole lot more work again . Hm, maybe I really should just fork this and try myself at stuff like this. No harm in pull requests, I guess. Sadly I'm a Java guy and not that firm with C#...Maybe I can use the next batch of free time to finally tackle it.

[ialdabaoth]

Some way to reference the existing value would be nice, though. Particularly with the description. I've wanted in the past to embed the old description in a new one, e.g. something like.

@description = Some new intro text. @description Some new postscript.

Or even better:

@description = Awesome part, but mind the @mass ton weight...

*twitch*

So you want a full programming language.

That's what C# is for. I am so, so, SO not reproducing some kind of LUA script for cfg files.

[sarbian]

But that would be a whole lot more work again . Hm, maybe I really should just fork this and try myself at stuff like this. No harm in pull requests, I guess. Sadly I'm a Java guy and not that firm with C#...Maybe I can use the next batch of free time to finally tackle it.

Doing what you ask for is not doable with the current code base. MM rely on the KSP parser to read and transform the .cfg into object, and this parser has a lot of restriction on format and parsed characters. If you want to do "some kind of LUA script for cfg files" (ialdabaoth comparison is perfect here) you would go faster with writing a brand new plugin.

And C# and Java are not that different. I'm a java guy too and the real challenge is the KSP API.

Edited March 24, 2014 by sarbian

[ialdabaoth]

To anyone who wants to be on the bleeding edge, here is the download link for ModuleManager.2.0.0.dll from my gitHub.

This should be considered "alpha", aka "try at your own risk". Delete ModuleManager_1_5_6.dll or ModuleManager_1_5_7.dll before installing, obviously.

A few changes:

You do NOT need a MOD {} confignode. In fact, I haven't implemented them yet.

If it detects a loaded DLL, it assumes it's a mod and creates a :BEFORE, :FOR and :AFTER pass for it.

If you use underscores to specify your mod's version in the filename, ModuleManager will regrettably think that these are part of the filename, because I can't tell the difference between "MyMod_1_3_6" and "Mod_1337s_Cool_Stuff", and I do not want to try to. On the other hand, if you use periods to specify your mod's version, then "MyMod.1.3.6" will correctly be identified as "MyMod".

This means that there will always be the following passes:

:FIRST

:BEFORE[Assembly-CSharp]

:FOR[Assembly-CSharp]

:AFTER[Assembly-CSharp]

:BEFORE[ModuleManager]

:FOR[ModuleManager]

:AFTER[ModuleManager]

:FINAL

Specifying ':FIRST' is optional; I just named the 'main' pass so that the log file is clearer.

If your mod includes a DLL, please PLEASE PLEASE put all your MM patch nodes in the :FOR[yourMod] pass.

If your mod does not include a DLL, then pick a name for your mod THAT DOES NOT CONFLICT WITH ANY OTHER MOD'S DLL, and then put all your MM patch nodes in the :FOR[yourMod] pass.

If you do this, other mods can use :BEFORE[yourMod] and :AFTER[yourMod] to politely modify things further at the correct sequence.

The following parameters are currently implemented:

:BEFORE[ModName] - execute this patch BEFORE ModName executes its patches.

:FOR[ModName] - I am ModName, and these are my patches.

:AFTER[ModName] - execute this patch AFTER ModName executes its patches.

:NEEDS[ModName1] - execute this patch only if ModName1 is installed.

:NEEDS[!ModName2] - do not execute this patch if ModName2 is installed.

You can combine NEEDS nodes like this:

:NEEDS[ModName1, !ModName2]

I am loading version info for each mod, but I am not yet using it for anything.

value scaling (@key *= mult and @key += add) are not yet implemented.

Any questions?

Edited March 25, 2014 by ialdabaoth

[K3-Chris]

Is it possible to check for installed mods? Specifically RPM, I have an IVA I want both RPM and non-RPM versions of, or is it alright for the internal.cfg to include props that doesn't exist?

[camlost]

Does node[name,index] work now? If it does, which version of MM ?

[ialdabaoth]

Yes! So does wildcard matching in subnodes, and :HAS[] criteria in subnodes. At least, in 2.0.0 it does, if you are brave enough soul to download it.

You can match subnodes in one of seven ways:

@NODE[name] // will wildcard match name (so you can do ModuleEnginesFX or ModuleEngines*), and apply itself to the first NODE it finds.

@NODE[name],index // will wildcard match name, and apply itself to the indexth NODE it finds.

@NODE[name],* // will wildcard match name, and apply itself to ALL matching NODEs.

@NODE[name]:HAS[criteria] // will wildcard match name and apply itself to all matching NODEs which also meet the :HAS criteria

@NODE:HAS[criteria] // will apply itself to all matching NODEs which also meet the :HAS criteria

@NODE,index // will apply itself to the indexth NODE it finds

@NODE,* // will apply itself to ALL NODEs

These apply to @, ! and % nodes. $ nodes are necessarily single-application, and thus will always apply to the first node they find.

[PolecatEZ]

Ok, I'm now beating my head on the wall after reading through all 49 pages of this. I'm basically working on a retexturing mod for Squad and FS to have B9 colors, and also getting B9 to be less wonky.

Part of the anti-wonky mm .cfg package is to make thinner wings, on par with stock and FS wings. The problem is that the lift no longer is applied in the actual game once I patch the MODEL on the wings.

Here's a sample of my initial code:

@PART[B9_Aero_Wing_SH_A65_2m]
{ 
@module = Part
!mesh = DELETE
MODEL
{  
model = B9_Aerospace/Parts/Aero_Wing_SH_A65_2m/model
scale = 1, 1, .35
} 
}

Works beautifully to reshape the wings...except that the lift values get eaten...like, no longer there in the game. It still shows in debug that they're alive and well, they just don't show in the catalog, and the wings have no actual function while flying.

So I tried to delete out the values and reset them, like in this example:

@PART[B9_Aero_Wing_SH_A35_4m]
{ @module = Part
!mesh = DELETE
MODEL
{  
model = B9_Aerospace/Parts/Aero_Wing_SH_A35_4m/model
scale = 1, 1, .35
} 
!dragCoeff = DELETE
!deflectionLiftCoeff = DELETE

dragCoeff = 0.83
deflectionLiftCoeff = 2.69

}

No luck. If I just manually add the MODEL bit to the actual config file, everything functions in the game just fine. It also works just fine when I amend a .cfg that already has a MODEL node. However, if I add it via mm, I can't make the LiftCoeff function at all.

What am I missing or is this some limitation to MM that I hit?

Edited March 27, 2014 by PolecatEZ

[sarbian]

I don't have KSP here to check the cfgs but if you convert a wing into a "Part" you'll need to add the proper module (forgot wich one) that adds the lift

[PolecatEZ]

"@module = Part" just became "@module = Winglet" and everything works perfectly now. Nice

[mostlydave]

I'm trying to add modules to 10 parts to make them Kerbal Attachment System compatible. I've created a file for each one in the root of my ksp gamedata folder with the .cfg extension and the following code:

@PART [lightlongkso]

{

MODULE

{

name = KASModuleGrab

evaPartPos = (0.0, 0.0, -0.15)

evaPartDir = (0,0,-1)

storable = true

storedSize = 6

attachOnPart = True

attachOnEva = False

attachOnStatic = False

}

}

It worked, but it seems to have add kas to all parts and I can't figure out why, anybody see what I'm doing wrong here? I used another file to add mechjeb to all command pods and that worked beautifully. I'm not sure whats going on here.

[sarbian]

@PART [lightlongkso] <= remove the space

@PART[lightlongkso]

[mostlydave]

Thanks! I would never have caught that.

[MrWizerd]

Anyone know if module manager is working with the new update that released today, April first?

[BudgetHedgehog]

I believe it is, yes. I have the MM config to ad KER to all command modules and it happened, so I'm assuming it works fine.

[Starwaster]

Yes. It does work.

[MrWizerd]

Odd, I wrote a cfg file for mechjeb and protractor, and it didn't work, then I also noticed that the additional antennae from remote tech 2 was also not installed although all the independent modules are working. The info is not showing up in the information, nor working... maybe something else is wacky... I will do more investigating.

[Gaius]

Odd, I wrote a cfg file for mechjeb and protractor, and it didn't work, then I also noticed that the additional antennae from remote tech 2 was also not installed although all the independent modules are working. The info is not showing up in the information, nor working... maybe something else is wacky... I will do more investigating.

ModuleManager is working fine. MechJeb and Remote Tech 2 are broken (although sarbain posted a fixed MJ DLL in the thread).