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

[ev0]

Looking at the code, it looks like | for OR is allowed in HAS blocks at the top level (i.e. @PART:HAS[]) but not in sub-nodes or variable lookups.

Yeah, nothing's working. From testing it looks like indexes don't work in variable lookups either. So if I assume that the top ANIMAL Dog will always have four legs, doing a search from the bottom up as @dislikes = #$/ANIMAL:HAS[#fourLegs[True]],-1(or-2)/id$ doesn't work either.

[sashan]

Hello guys.

I want to make a patch. Basically, take all the rocket engines that have less than 4 degrees of gimbal range, and triple their range. So far I've got this, but it affects orbital engines like Poodle and 909 as well, which is bad - they have enough range already. I need it for FAR - real rockets usually have around 10 degrees of gimbal range.

I'm using modulejettison as additional filter - all the required rocket engines have it.

Can anyone help me?

@PART[*]:HAS[@MODULE[ModuleGimbal]]:HAS[@MODULE[ModuleJettison]]

{

@MODULE[ModuleGimbal]

{

@gimbalRange *= 3

}

}

[Crzyrndm]

@PART
[*]:HAS[@MODULE[ModuleGimbal]:HAS[#gimbalRange[<4]],@MODULE[ModuleJettison]]
{
    @MODULE[ModuleGimbal]
    {
        @gimbalRange *= 3
    }
}

This should be fairly close

[sashan]

Thanks. Maybe now I would keep my rocket from flipping at maxQ.

[DBowman]

Hi, I'm wanting to have some global flags that I can use to drive inclusion of things in MM.cfg files. The end effect I want is that by replacing/tweaking one .cfg all the others should change their behaviour. For example in a .cfg:

...

MODULE:NEEDS[MY_TWEAK_A&!MY_TWEAK_B] { // module A version }

MODULE:NEEDS[!MY_TWEAK_A&MY_TWEAK_B] { // module B version }

...

and MY_TWEAK_A etc is 'set' in tweakit.cfg

I 'got the effect' by adding a file GameData/MY_TWEAK_A/Stub.cfg with - but that feels like a misuse of things, and I'd much rather keep the tweakit.cfg inside the directory of all my .cfgs

I saw some 'variable access' kind of stuff I've not come to grips with yet, it looks like the kind of thing I'm after but I don't know how to leverage that into a NEEDS style effect (nor how to actually use it yet...).

Can anyone suggest a neater way to get the effect I want?

[sarbian]

if you have a node with FOR you ll have the same effect as adding a dir :

MY_TWEAK:FOR[MY_TWEAK_A] { }

[DBowman]

thanks sarbian - ah a bogus node...

I just now tried that:

Patch.cfg with BOGUSNODE:FOR[PatchNode] {}

part.cfg with ...MODULE:NEEDS[PatchNode]{}...MODULE:NEEDS[!PatchNode]{}...

I tried with the Patch.cfg in MyMod directory and in the GameData directory - it always matched the NEEDS[!PatchNode] one.

the log says things like:

Config(BOGUSNODE:FOR[PatchNode]) MyMod/Patch/BOGUSNODE:FOR[PatchNode] - if I put Patch.cfg in GameData/MyMod

or

Config(BOGUSNODE:FOR[PatchNode]) /Patch/BOGUSNODE:FOR[PatchNode] - if I put Patch.cfg in GameData

and later

[ModelManager] Deleting node in file: MyMod/Part/part subnode: +PART [solarPanels2]/+PART[solarPanels2][]/MODULE:NEEDS [PatchNode] as it can't satisfy its NEEDS

I hope you can see something obvious I'm doing wrong. Maybe there is a well known example of where someone uses this technique? - I could pull down that mod and take a look.

[Snarfster]

I am trying to write a module manager patch so only IR parts have tweakscale enabled. I can't seem to get it right.

The following strips TweakScale from everything when I'd expect it'd look at the manufacturer tag.

// Module Manager Config to make only IR parts have TweakScale

@PART[*]:HAS[!manufacturer[Magic?Smoke?Industries]]:FINAL
{
	!MODULE[TweakScale] {} // Remove TweakScale from all non IR parts.
}

Anyone see the obvious error I must be making?

[sarbian]

@PART[*]:HAS[!#manufacturer[Magic?Smoke?Industries]]:FINAL

Edit : tired

[Snarfster]

Thanks so much... I was at a complete loss.

EDIT: I must be going nuts... That still strips the IR parts.

Edited June 3, 2015 by Snarfster

[BudgetHedgehog]

Why not just remove the TweakScale configs for everything but the IR parts?

[NAMROG]

Is there a reason why MM would be seriously lagging my game? I've noticed it's the one mod that's killing my frames.

I've only got Remote tech and FAR installed.

Edited June 4, 2015 by NAMROG

[Crzyrndm]

Most plausible reason is that a module manager patch is adding something with significant impact (of which FAR certainly could be doing) or something that is heavily spamming the log.

[NAMROG]

Curious. Any way to see that log?

Or I guess because I hate myself, would merging all files dependent on MM into one mod file bypass that?

[BudgetHedgehog]

Curious. Any way to see that log?

Or I guess because I hate myself, would merging all files dependent on MM into one mod file bypass that?

1, yes, it's a txt file (output_log.txt) in the KSP_Data folder.

2, no.

[futrtrubl]

Why not just remove the TweakScale configs for everything but the IR parts?

That's exactly what he is trying to do.

[BudgetHedgehog]

That's exactly what he is trying to do.

No, he is trying to remove the Tweakscale modules from all except IR parts. What I suggested was to not add the Tweakscale module in the first place.

Tweakscale ships with many config files to add Tweakscale modules to many parts, stock and modded, through the use of ModuleManager. Rather than keeping those configs and making another MM config to remove what they add, just remove those configs that add TS module to parts.

Edited June 4, 2015 by ObsessedWithKSP

[NAMROG]

Well I feel like an idiot, guys. I never unblocked Module Manager's file. :/

All systems go again. See you up there!

[Snarfster]

No, he is trying to remove the Tweakscale modules from all except IR parts. What I suggested was to not add the Tweakscale module in the first place.

Tweakscale ships with many config files to add Tweakscale modules to many parts, stock and modded, through the use of ModuleManager. Rather than keeping those configs and making another MM config to remove what they add, just remove those configs that add TS module to parts.

That would be my last resort. I would like to just have a mm.cfg in my GameData to set the mods up the way I prefer it, this so that when an update to those mods is published, I can just replace that mod's directory.

[bsooner77]

I'm trying to add 3 science experiments to all the command pods, it works in that it adds the experiments but the crew report experiment is not availible in the right click menu anymore...I'm using this

@PART

[*]:HAS[@MODULE[ModuleCommand],#vesselType[ship]]:Final

{

MODULE

{

name = ModuleScienceExperiment

experimentID = gravityScan

experimentActionName = Log Gravity Data

resetActionName = Delete Data

useStaging = False

useActionGroups = True

hideUIwhenUnavailable = False

xmitDataScalar = 0.4

dataIsCollectable = True

collectActionName = Take Data

interactionRange = 1.2

rerunnable = True

usageReqMaskInternal = 1

usageReqMaskExternal = 8

}

MODULE

{

name = ModuleScienceExperiment

experimentID = temperatureScan

experimentActionName = Log Temperature

resetActionName = Delete Data

useStaging = False

useActionGroups = True

hideUIwhenUnavailable = False

xmitDataScalar = 0.5

dataIsCollectable = True

collectActionName = Take Data

interactionRange = 1.2

rerunnable = True

usageReqMaskInternal = 1

usageReqMaskExternal = 8

}

MODULE

{

name = ModuleScienceExperiment

experimentID = GeigerCounter

experimentActionName = Activate Geiger Counter

resetActionName = Reset Geiger Counter

useStaging = False

useActionGroups = True

hideUIwhenUnavailable = True

resettable = True

resettableOnEVA = True

rerunnable = True

xmitDataScalar = 0.6

FxModules = 0

collectActionName = Take Data

dataIsCollectable = True

interactionRange = 2

}

}

EXPERIMENT_DEFINITION

{

id = gravityScan

title = Gravity Scan

baseValue = 20

scienceCap = 22

dataScale = 3

requireAtmosphere = False

situationMask = 51

biomeMask = 51

RESULTS

{

default = Recorded accurate measurements of gravitational forces in these conditions.

MohoInSpace = The sensor passes over the terrain of Moho surverying for variances in the gravitational field.

MohoSrfLanded = Landing here has provided a very accurate and stable measure of gravitational forces.

EveInSpace = The sensor records slight variances as in gravity as you pass over a massive crater site.

EveSrfLanded = The gravitational field is very strong here. The sensor records detailed data about the local field.

GillyInSpace = The sensor picks up the fluctuations in the gravity of this lumpy body.

GillySrfLanded = The team back at KSC will enjoy these detailed readings.

KerbinInSpace = The sensor finds subtle changes in the gravity field of Kerbin. The science team will want to see these readings!

KerbinSrfLanded = The sensor seems to think it's being calibrated.

KerbinSrfLanded = After reading the manual a few times, the command team is able to take an accurate reading of the local gravity.

KerbinInSpaceGrassLands = The instrument surveys the gravity over the grasslands. It appears the field is very stable here.

KerbinInSpaceHighlands = The instrument surveys the highlands of Kerbin. The rolling hills seem to affect local gravity slightly.

KerbinInSpaceMountains = The field appears to be strongest along these mountain ranges.

KerbinInSpaceDeserts = The dunes appear to have a very stable gravitation, though some spikes would indicate the underground terrain varies in composition.

KerbinInSpaceBadlands = The sensor reads the gravity over the badlands of Kerbin.

KerbinInSpaceIceCaps = The sensor detects variances under the surface of the ice. Is there a landmass under that ice?

KerbinInSpaceShores = The sensor passes over the shores of Kerbin. The readings appear to be nominal.

KerbinInSpaceWater = The sensor shows a surprising variance as it passes over the oceans. Hinting at the varied topology deep below the waters.

KerbinSrfSplashedWater = The sensor has detected changes in the local gravity that seem to be related to the passing of the Mun.

MunInSpace = The instrument surveys for changes in the field of the Mun. This data will help to accurately calculate the mass of the body.

MunSrfLanded = The sensor conducts a detailed survey of the local gravity.

MunSrfLanded = After calibration the sensor is able to detect the interplay of gravity between Kerbin and the Mun.

MinmusInSpace = Passing over the surface of Minmus the sensor sweeps across the gravitational field of Minmus.

MinmusSrfLanded = The sensor takes detailed readings of the local gravity on Minmus.

MinmusSrfLanded = The scan picks up the subtle changes in field caused by the orbit of the Mun. This data will provide valuable insight into the local planetary system.

DunaInSpace = The sensor passes over the mottled surface of Duna. Gravity appears lowest in the massive canyon that stretches across the surface.

DunaSrfLanded = The sensor performs a detailed and calibrated sweep of local gravity on Duna.

DunaSrfLanded = The sensor is able to record the affects of Ike as it orbits Duna.

DresInSpace = The sensor sweeps the surface and finds the average gravitational pull to be quite low for a planet.

DresSrfLanded = The sensor measures the local gravity in fine detail and records all variations.

JoolInSpace = The sensor calibrates to measure the massive gravitational forces of Jool.

JoolInSpace = The sensor picks up a wealth of information about the local planetary system.

JoolSrfLanded = The instrument has been crushed by the massive gravitational forces. Science!

LaytheInSpace = The sensor scans the gravity of Laythe. It helps hint at the diverse terrain under the water.

LaytheSrfLanded = The Sensor scans the local gravity of Laythe, recording the influence of Jool.

LaytheSrfSplashed = The sensor provides detailed gravity information in relation to the tides.

VallInSpace = Scanning from orbit provides a clearer picture of the internal makeup of Vall.

VallSrfLanded = Scanning on the surface details gravitational fluctuations in the shifting interior of the planet.

TyloInSpace = The planet has lower gravity then anticipated. This will give our scientists information about the interior makeup of Tylo.

TyloSrfLanded = Detailed scans have hinted to hollow spaces in the interior of the planet.

BopInSpace = Orbiting Bop allows for scans of the varied surface. Interesting stuff!

BopSrfLanded = The sensor is giving odd readings here...

PolInSpace = The sensor picks up multiple layers under the surface of the planet.

PolSrfLanded = Landing on the planet has allowed for highly detailed scans of the interior gravity on Pol.

EelooInSpace = Though the surface appears to be smooth, there are fluctuations under the surface of the planet.

EelooSrfLanded = Gravity scans are very clear here. There appears to be little influence from other bodies.

}

}

EXPERIMENT_DEFINITION

{

id = temperatureScan

title = Temperature Scan

baseValue = 8

scienceCap = 8

dataScale = 1

requireAtmosphere = False

situationMask = 63

biomeMask = 7

RESULTS

{

default = Collected and recorded temperature data from the environment.

KerbinSrfLanded = Temperature readings are quite literally, nominal.

KerbinSrfLandedDeserts = Large plumes of heat are rising from the surface of the desert.

KerbinSrfLandedIceCaps = It's cold enough to freeze water solid.

KerbinSrfLandedShores = Just the right temperature to go for a swim.

KerbinSrfLandedWater = The water appears to get colder as the depth increases.

KerbinSrfLandedTundra = It's cold enough to keep things permanently frozen here.

KerbinSrfLandedGrasslands = The temperature here is quite pleasant, and would be a nice place to live.

KerbinSrfBadlands = the temperature appears to fluctuate here a good bit depending on the time of day.

MohoSrfLanded = The temperature is very high and appears to fluctuate to extremes in the sunlight.

EveSrfLanded = Temperatures range between very cold and hot enough to boil water.

SpaceHigh = Measuring the temperature of space appears to be quite impossible, as there is no matter around to be either hot or cold... except the spacecraft, and the thermometer itself. This is probably going to give the R&D guys something to think about for a while.

}

}

EXPERIMENT_DEFINITION

{

id = GeigerCounter

title = Geiger Counter

baseValue = 8

scienceCap = 10

dataScale = 1

requireAtmosphere = False

situationMask = 63

biomeMask = 23

RESULTS

{

default = You observe the radiation levels.

KerbinSrfLandedLaunchPad = Radiation levels are higher than normal. You suspect someone has been testing a nuclear powered rocket system again.

KerbinSrfLandedRunway = Radiation levels are the same as it always does around here.

KerbinSrfLandedDeserts = Radiation levels are slightly higher than normal.

KerbinSrfSplashedWater = Radiation levels are normal, but the water is pretty.

KerbinFlyingLowWater = Radiation levels are normal, but the water is pretty.

KerbinSrfSplashedShores = Radiation levels are normal.

KerbinSrfLandedShores = Radiation levels are normal. Sand is getting in the detector.

KerbinFlyingLowShores = Radiation levels are normal, and you suddenly want to go to the beach!

KerbinSrfLandedKSC = Radiation levels are normal.

// KerbinFlyingLow = Radiation levels are slightly higher than normal.

// KerbinFlyingHigh = Radiation levels are higher than normal.

KerbinInSpaceLow = You have encountered some elevated radiation levels.

KerbinInSpaceHigh = You have encountered an unusual radiation zone around Kerbin. Radiation levels are much Higher than they should be, Van Kerbin was right!

KerbinFlyingHighMountains = The mountains are slightly radioactive.

KerbinFlyingLowMountains = The mountains give off higher than normal amounts of radiation. You wonder what is buried in the rock?

KerbinSrfLandedMountains = A closer scan of the mountains reveals veins of highly energetic radioactive ore. Perhaps a future space fuel?

KerbinFlyingHighBadlands = The Badlands are causing higher than normal levels of radiation?

KerbinFlyingLowBadlands = The Badlands are causing an unusual radiation spike.

KerbinSrfLandedBadlands = Danger! Danger! Radiation levels have exceeded safe limits!

KerbinSrfLandedDeserts = "It is hot here!" What an odd thing for a scientific instrument to say?

KerbinFlyingLowDeserts = Radiation levels are higher than normal.

KerbinInSpaceLow = You have encountered some elevated radiation levels.

KerbinInSpaceHigh = You have encountered an unusual radiation zone around Kerbin. Radiation levels are much Higher than they should be, Van Kerbin was right!

MohoInSpaceHigh = Radiation levels are off the scales! You better not stay here long...

MohoInSpaceHigh = The detector is going nuts. It may start melting soon.

MohoInSpaceLow = The detector has melted...

MohoSrfLanded = You stare at the blob of yellow Goo that use to be your Geiger counter and wonder how the rest of the ship survived.

MunInSpace = Radiation levels are slightly higher than normal.

MunSrfLanded = Radiation levels have returned to zero.

MunSrfLanded = You look at the Detector, your thoughts drift as you wait for a response. Then you turn off the detector and contemplate your existence in the universe.

MunSrfLanded = This thing sure is yellow! The box, I mean...

MunFlyingLow = Radiation levels are dropping.

MunFlyingHigh = Radiation levels are slightly higher than normal but falling.

MinmusSrfLanded = The box gives out a single click and then just sits there.

MinmusInSpace = Radiation levels are dropping.

EveInSpace = Radiation levels are high here.

EveInSpace = You detect much Higher than normal radiation.

EveFlyingHigh = Radiation levels are dropping.

EveFlyingLow = Radiation levels are almost zero.

EveSrfLanded = Even though your relatively close to the sun your detecting no radiation on the surface. The thick atmosphere must be blocking the radiation.

DunaInSpace = Radiation levels are slightly higher than normal.

DunaSrfLanded = Radiation levels are slightly lower than normal.

JoolInSpaceHigh = Radiation levels are higher than normal.

JoolInSpaceLow = You have encountered a radiation zone around the planet. Radiation levels are much Higher than normal.

BopInSpace = Radiation levels are slightly higher than normal.

PolInSpace = Radiation levels are slightly higher than normal.

EeLooInSpace = Radiation levels are very low here.

EeLooInSpace = Readings are 0. You check to make sure the instrument is on. Yep, its on, just nothing here...

SunInSpaceHigh = Going further from the Sun your detecting increasing levels of radiation. Maybe some sort of cosmic source?

SunInSpaceLow = Your detecting higher levels of radiation near the Sun. Maybe you should examine this more closely?

SunFlyingHigh = The detector has melted, and the rest of the ship is not far behind...

}

}

Would someone please check my syntax...I can't figure out what I'm doing wrong. I would really appreciate it.

Edited June 5, 2015 by bsooner77

[Mecripp]

I would have use looking for crew

@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[1]]:Final

and do you also have the EXPERIMENT_DEFINITION in the CFG ? If so did you change them ether way, I would have them as there own CFG.

[smjjames]

Edit: forgot to mention that I'm using MM 2.6.5

Does anybody know what would cause this exception?

InvalidOperationException: Collection was modified; enumeration operation may not execute.
  at System.Collections.Generic.List`1+Enumerator[UnityEngine.Collider].VerifyState () [0x00000] in <filename unknown>:0 

  at System.Collections.Generic.List`1+Enumerator[UnityEngine.Collider].MoveNext () [0x00000] in <filename unknown>:0 

  at Part.OnDestroy () [0x00000] in <filename unknown>:0 

I was actually able to narrow it down to Module Manager, but then after I reproduced it a couple times and then attempted to reproduce in a branchoff save, it stopped appearing. However, when I started playing my main save (decided to start up a new game), it appeared again.

For a while, I thought MJ had something to do with it (was one of the last to be eliminated though), but I'm pretty sure it's not.

It happens when I go into a command module (or otherwise crewed part) from EVA, after doing science stuff.

Edit: I did try to search the thread, nothing found.

Edit2: I tried to test it again on a branchoff save with the same pod setup as I ran into the exception in the main save and nope. It either requires very specific circumstances to trigger or it isn't module manager.

Edited June 5, 2015 by smjjames

[Starwaster]

Does anybody know what would cause this exception?

InvalidOperationException: Collection was modified; enumeration operation may not execute.
  at System.Collections.Generic.List`1+Enumerator[UnityEngine.Collider].VerifyState () [0x00000] in <filename unknown>:0 

  at System.Collections.Generic.List`1+Enumerator[UnityEngine.Collider].MoveNext () [0x00000] in <filename unknown>:0 

  at Part.OnDestroy () [0x00000] in <filename unknown>:0 

I was actually able to narrow it down to Module Manager, but then after I reproduced it a couple times and then attempted to reproduce in a branchoff save, it stopped appearing. However, when I started playing my main save (decided to start up a new game), it appeared again.

For a while, I thought MJ had something to do with it (was one of the last to be eliminated though), but I'm pretty sure it's not.

It happens when I go into a command module (or otherwise crewed part) from EVA, after doing science stuff.

Edit: I did try to search the thread, nothing found.

Edit2: I tried to test it again on a branchoff save with the same pod setup as I ran into the exception in the main save and nope. It either requires very specific circumstances to trigger or it isn't module manager.

Module Manager isn't really doing anything during actual gameplay. It does all its work before KSP compiles its parts, which it does by modifying configs. Mostly but not limited to, parts. After that, it just sits around doing nothing, unless you bring up its menu at the space center and reload the database.

It doesn't sound after all like you narrowed your problem down to Module Manager.

It's most likely a race condition between different sections of code operating on the same list. One of them made changes to the list (adding or removing from it) meaning that the second bit of code no longer has a valid list to work on

[smjjames]

Module Manager isn't really doing anything during actual gameplay. It does all its work before KSP compiles its parts, which it does by modifying configs. Mostly but not limited to, parts. After that, it just sits around doing nothing, unless you bring up its menu at the space center and reload the database.

It doesn't sound after all like you narrowed your problem down to Module Manager.

It's most likely a race condition between different sections of code operating on the same list. One of them made changes to the list (adding or removing from it) meaning that the second bit of code no longer has a valid list to work on

Well, it kept going after I removed everything else, so it just seemed like it was module manager (granted that I didn't actually know that it really doesn't do anything during gameplay), so, I just kind of made a shot in the dark hoping someone would help. Or maybe that someone else has also run into the same exception.

And yeah it feels like I've hit a dead end because the setup and steps that I was using that WAS triggering it and triggering reliably decided not to trigger all of a sudden. Note that I didn't explictly blame Module Manager, just asked if anybody knew where that exception might be coming from.

Edited June 5, 2015 by smjjames

[Starwaster]

Well, it kept going after I removed everything else, so it just seemed like it was module manager (granted that I didn't actually know that it really doesn't do anything during gameplay), so, I just kind of made a shot in the dark hoping someone would help. Or maybe that someone else has also run into the same exception.

And yeah it feels like I've hit a dead end because the setup and steps that I was using that WAS triggering it and triggering reliably decided not to trigger all of a sudden. Note that I didn't explictly blame Module Manager, just asked if anybody knew where that exception might be coming from.

One problem there is that your error doesn't positively point to any mod; it could even be a stock error