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

[Mecripp]

Ok, so I am trying to edit the modular fuel tanks tankgtype.cfg file to add tanks to the various default tank types and to add some tank types. I noticed in the kethane patch it adds kethane to the default tank type. I noticed this because originally I just edited the tank types file by hand and noticed kethane want listed. So this is what gave me the idea. I made two files to add types to the tanks here is one when i booted all the tanks said they could not hold anything, and I have not messed with it to see what one is causing it because it's late, but I figured I would ask if this will work in theory or should I tell it it's :for(mft).

Thanks for the help, and sorry about any mistakes I'm using my phone atm... Thanks again!¡!

You have MaxAmount set to 0.0

[MrWizerd]

Yes because it should be amending the default tank type, to add those tanks. The default tank type by default has lfo at the default split. My worry is that instead of adding these to the tank types it is replacing the tank type with these properties thus losing the lfo and other stock resources.

I wish I knew a way to see the cfg files after they have been compiled so I could see exactly what was going wrong.

Edited June 1, 2014 by MrWizerd

[Mecripp]

Yes because it should be amending the default tank type, to add those tanks. The default tank type by default has lfo at the default split. My worry is that instead of adding these to the tank types it is replacing the tank type with these properties thus losing the lfo and other stock resources.

I wish I knew a way to see the cfg files after they have been compiled so I could see exactly what was going wrong.

I see my bad did you add them to the Resources file ? I didn't see some of them in MFT Resoures

[MrWizerd]

I see my bad did you add them to the Resources file ? I didn't see some of them in MFT Resoures

Yes, they are, the hope I have is to be able to have seperate cfg files for TACLifesupport and KSPI to add those resources to Modular Fuel Tanks so that someone can use tanks for whatever purpose this allows for getting rid of excess models to lower the size of KSP so it wont crash, well at least thats why I am doing it, and then I am using tanks that have FSTextureSwap so I can differentiate the tanks. Previously I just edited the TankTypes.cfg file in MFT to allow for this to happen, but I wanted to have it set sow that I could update MFT without having to worry about saving the file, and it makes it easier for other users to do a similar thing. I didn't think it was possible initially and then I saw the kethane.cfg and it has the following code for MFT for the default tank type.

@TANK_DEFINITION[Default] {
   TANK {
       name = Kethane
       fillable = false
   }
}

and I know IT works, so I am unsure as to what I am doing wrong.

[Starwaster]

Yes, they are, the hope I have is to be able to have seperate cfg files for TACLifesupport and KSPI to add those resources to Modular Fuel Tanks so that someone can use tanks for whatever purpose this allows for getting rid of excess models to lower the size of KSP so it wont crash, well at least thats why I am doing it, and then I am using tanks that have FSTextureSwap so I can differentiate the tanks. Previously I just edited the TankTypes.cfg file in MFT to allow for this to happen, but I wanted to have it set sow that I could update MFT without having to worry about saving the file, and it makes it easier for other users to do a similar thing. I didn't think it was possible initially and then I saw the kethane.cfg and it has the following code for MFT for the default tank type.

@TANK_DEFINITION[Default] {
   TANK {
       name = Kethane
       fillable = false
   }
}

and I know IT works, so I am unsure as to what I am doing wrong.

Count your braces and make sure that you have one } for every {

I can tell you right now you're missing one at the very end of that file. Since I apparently can't copy the contents I can't easily give it an in depth dissection.

Also, I have a few concerns with some 'fillable=false' that I'm seeing. That's in no way related to your current trouble and I'm not familiar with the mod that uses those resources (helium 3 was one I think?) so maybe it's supposed to be like that. Basically if fillable=false then it cannot be filled in the VAB or on the launch pad from the feeder lines. If that's how it's supposed to be then no problems.

[Mecripp]

Yes, they are, the hope I have is to be able to have seperate cfg files for TACLifesupport and KSPI to add those resources to Modular Fuel Tanks so that someone can use tanks for whatever purpose this allows for getting rid of excess models to lower the size of KSP so it wont crash, well at least thats why I am doing it, and then I am using tanks that have FSTextureSwap so I can differentiate the tanks. Previously I just edited the TankTypes.cfg file in MFT to allow for this to happen, but I wanted to have it set sow that I could update MFT without having to worry about saving the file, and it makes it easier for other users to do a similar thing. I didn't think it was possible initially and then I saw the kethane.cfg and it has the following code for MFT for the default tank type.

@TANK_DEFINITION[Default] {
   TANK {
       name = Kethane
       fillable = false
   }
}

and I know IT works, so I am unsure as to what I am doing wrong.

Moved a couple braces and added 1 https://www.dropbox.com/s/h9fpzcautxkhaav/KSPI_MFT.cfg

[Biotronic]

A user of one my mod TweakScale - Rescale Everything! asked for a MM config to add TweakScale to all parts. I kinda expected this to work, but it doesn't seem to care about the :HAS block:

@PART[*]:HAS[!MODULE[TweakScale]]
{
    MODULE
    {
        name = TweakScale
        type = free
    }
}

The intent here is: if it doesn't already have a MODULE called TweakScale, then add it. Like I said, it seems to ignore the :HAS block, so all parts that already have a TweakScale module gets to have two. I don't want that.

...halp?

Edited June 1, 2014 by Biotronic

[MrWizerd]

Moved a couple braces and added 1 https://www.dropbox.com/s/h9fpzcautxkhaav/KSPI_MFT.cfg

Thanks, cant believe I missed that last brace. I figured out the problem, it was a conflict between the two entries for water. KSPI tanks and TACLifeSupport tanks have a different utilization rate. which is problematic, I am going to have to figure out a work around, but for now I redacted one, and since it is heavy I figured it should pack less in the space of the others at least for now... I think I may be creating a thread to help with balance issues for both.

Thanks again for the help.

[Mecripp]

A user of one my mod TweakScale - Rescale Everything! asked for a MM config to add TweakScale to all parts. I kinda expected this to work, but it doesn't seem to care about the :HAS block:

@PART[*]:HAS[!MODULE[TweakScale]]
{
    MODULE
    {
        name = TweakScale
        type = free
    }
}

The intent here is: if it doesn't already have a MODULE called TweakScale, then add it. Like I said, it seems to ignore the :HAS block, so all parts that already have a TweakScale module gets to have two. I don't want that.

...halp?

Could you use

@PART[*]:HAS[%MODULE[TweakScale]]

{

%MODULE

{

name = TweakScale

type = free

}

}

[Biotronic]

Could you use

@PART[*]:HAS[%MODULE[TweakScale]]
{
    %MODULE
    {
        name = TweakScale
        type = free
    }
}

Afraid not. The type and other values inside the module would differ between parts.

[Starwaster]

Could you use

I dont think % works as a condition. Only for modifying/adding.

[Kaput]

Constantly getting the save game fixer making backups of my save with this in the backup.log

Save Game: Career 1

Save file: Career 1\persistent.sfs

Vessel: SDHI SM Sci

Part: Mark1-2Pod

* Module "" is present in the part but is no longer available. Saved config to backup, will be restored if you reinstall the mod.

Save file: Career 1\quicksave.sfs

Vessel: SDHI SM Sci

Part: Mark1-2Pod

* Module "" is present in the part but is no longer available. Saved config to backup, will be restored if you reinstall the mod.

Not really sure whats going on because other than a cfg to add mechjeb to all pods I don't have any MM configs and can't see any of my mods that do.

Even creating a new ship from scratch brings up the same message in the log when the game is reloaded with said ship active.

Mod list in case it matters:

Any ideas?

[swamp_ig]

Thanks for the log

Looks like something is adding a module that is unnamed. My bet would be your MJ.cfg file isn't set up correctly.

Note that save game fixer is only tangentially related to the MM patcher - it processes all save games and configs regardless of if they have anything to do with MM or not.

Edited June 4, 2014 by swamp_ig

[Kaput]

MJ.cfg contents:

@PART

[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final

{

MODULE

{

name = MechJebCore

}

}

When it happens the only difference I can find between the original save file and the backup one is that the original file has:

MODULE

{

name = ModuleConfigBackup

isEnabled = True

EVENTS

{

}

ACTIONS

{

}

}

And the backup just has

MODULE

{

}

In it's place.

No idea which of the mods would possibly be adding it as none of them have obvious MM configs that I can see. Ultimately it doesn't seem to be affecting the game other than causing the save game fixer to spam me with save backups.

[swamp_ig]

Will have a look into it

[Starwaster]

I've noticed a problem with Module Manager recently (using 2.1.5) where if a module is changed/removed/renamed in one part, unrelated modules in other parts are being deleted. I assume by the save game fixer because it's happening at the save file level. (checked after loaded to main menu). I believe one factor is that the deleted modules are added on the fly by another module. What's odd though is that MM is deleting them when it detects that other parts have had modules altered. And it's not even trying to back them up, which is a problem given that at least one of the affected modules has persistant data on it. It never bothers that module at any other time... at all.

Example:

Porkjet's centrifuge1 part has MODULE { name = ModuleAnimateGeneric; <stuff>; }

mk1pod has several Ioncross modules: IonModuleGenerator and IonModuleCollectorAtmosphere (added dynamically, not explicitly by any config)

I rename ModuleAnimateGeneric to FSanimateGeneric on centrifuge1

When I run the game, mk1pod (all of them, everywhere and probably other parts too...) is stripped of its Ioncross modules in the save file. What's ironic here is that the CO2 scrubber on this mod has historically tended to reset to an inactive state, which I fixed when I branched that mod off. This issue has reintroduced that problem

So, a few things I think are at issue here are:

#1 Module alterations on part 1 shouldn't be affecting part 2 when they have absolutely nothing in common.

#2 Even if there are legitimate reasons why those modules might have to be removed at some point, there should be some way of either making them immune to deletion or forcing them to be backed up since they might have persistant data.

Here's a link to an archive that contains save files (normal save file and afflicted save file), player.log, the affected mk1pod part extracted from the save. (before and after)

https://www.dropbox.com/s/b3zbkeavm40j58h/MM-troubleshooting.zip

[swamp_ig]

I've noticed a problem with Module Manager recently (using 2.1.5) where if a module is changed/removed/renamed in one part, unrelated modules in other parts are being deleted.

I could be totally wrong on this, but AFAICS dynamically added modules (as in added with AddModule in either flight or the VAB) might as well just toss out their persistence data because there's no way to recover it once its written. OnLoad is never called for a dynamically added module with stuff from the save, it's just reset to the default state during AddModule, and the module doesn't get recreated when you load up the save either. All it does is go into the persistence file and never come out again. That's why save game fixer just deletes the code.

The way save game fixer detects a deleted mod, is that the module is present in the save, but the class is not available. In that case the module data gets put into backup and the save itself is also backed up. If you reinstall the mod the module data backup gets restored. If the module is in the save file, the class exists in memory, but the module doesn't exist in the PART (or in the MM patched PART) then it's a dynamic module and gets purged.

I hope that makes sense. There's quite a few conditions there, took me a while to nut out

Have a read of this and tell me if it's not right.

Edited June 6, 2014 by swamp_ig

[Starwaster]

I could be totally wrong on this, but AFAICS dynamically added modules (as in added with AddModule in either flight or the VAB) might as well just toss out their persistence data because there's no way to recover it once its written. OnLoad is never called for a dynamically added module with stuff from the save, it's just reset to the default state during AddModule, and the module doesn't get recreated when you load up the save either. All it does is go into the persistence file and never come out again. That's why save game fixer just deletes the code.

The way save game fixer detects a deleted mod, is that the module is present in the save, but the class is not available. In that case the module data gets put into backup and the save itself is also backed up. If you reinstall the mod the module data backup gets restored. If the module is in the save file, the class exists in memory, but the module doesn't exist in the PART (or in the MM patched PART) then it's a dynamic module and gets purged.

I hope that makes sense. There's quite a few conditions there, took me a while to nut out

Have a read of this and tell me if it's not right.

I'll have to look and see exactly where the module is being added, but definitely NO to parts of what you're saying. It needs that persistence data to know when it's been activated and deactivated. (CO2 scrubbers) and OnLoad is definitely called for it. The document you linked to mentions a few properties that can be saved with the MODULE. Do any of those say 'don't delete me!'?

[swamp_ig]

Hmm... If AddModule calls OnLoad with the old data, then what SGF is doing is undoubtedly wrong.

Will have a look into it.

[Starwaster]

Hmm... If AddModule calls OnLoad with the old data, then what SGF is doing is undoubtedly wrong.

Will have a look into it.

This is a little spammy so I'll hide it with a spoiler. But this is debug information generated by Ioncross when it loads in a CO2 Scrubber. It's getting added in via AddModule() at the Main Menu.

IonModuleGenerator.OnLoad() mk1pod CO2Scrubber

(Filename: /Applications/buildAgent/work/d3d49558e4d408f4/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)

IonModuleGenerator.OnLoad(): node
MODULE
{
name = IonModuleGenerator
isEnabled = True
isActive = True
lastLoaded = 1832.11999999866
generatorName = CO2Scrubber
generatorGUIName = Scrubber
EVENTS
{
ActivateButton
{
active = False
guiActive = True
guiIcon = Activate Generator
guiName = Activate Scrubber
category = Activate Generator
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
ShutdownButton
{
active = True
guiActive = True
guiIcon = Shutdown Generator
guiName = Deactivate Scrubber
category = Shutdown Generator
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
IncreaseButton
{
active = False
guiActive = True
guiIcon = Increase Output
guiName = Increase Scrubber Output
category = Increase Output
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
DecreaseButton
{
active = False
guiActive = True
guiIcon = Decrease Output
guiName = Decrease Scrubber Output
category = Decrease Output
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
}
ACTIONS
{
ActivateAction
{
actionGroup = None
}
ShutdownAction
{
actionGroup = None
}
ToggleAction
{
actionGroup = None
}
IncreaseAction
{
actionGroup = None
active = False
}
DecreaseAction
{
actionGroup = None
active = False
}
}
OUTPUT_RESOURCE
{
name = CarbonDioxide
guiName =
rateBase = 0
ratePerKerbal = 0
ratePerCapacity = -3.1558E-06
rateBaseMod = 1
ratePerKerbalMod = 1
ratePerCapacityMod = 1
resourceLow = False
resourceDepleated = False
effectOnEfficency = 1
cutoffMargin = 0
}
}

[Unknown9593]

Found a very annoying bug with this mod. basically when I start KSP, when I'm on the loading screen it will say "Processing module manager patch", no big deal so I wait patiently but then when the game reaches the half-way point in the loading, it crashes. I tried re-installing this mod and the interstellar mod (it would freeze when it was attempting to load Warpplugin/model01 or something) but no change, don't know if its because I accidently deleted the module manager 2.1.5 and installed module manager 1.5.7 whatever a few days ago, help would be very appreciated.

[Renegrade]

Just a little issue we've found over at the BTSM mod thread -- there seems to be some issue with 2.1.5 and atmosphereCurves.

BTSM involves some changes like so:

		@atmosphereCurve
		{
			@key, 0 = 0 385
			@key, 1 = 1 300
			key = 5 0.01
		}

However, it seems like key 1 is overriding key 0 somehow. At least...on the NASA/ARM parts.

This doesn't seem to be a problem in 2.1.0, or 2.0.7, or older historical versions, but is an issue with 2.1.5.

Any ideas what might be causing this?

(Unknown9593, I found that the save file upgrade can take a LOT of time, making it appear like KSP crashed. Try letting it run for a while.. and by a lot of time, I mean like ten-fifteen minutes)

[swamp_ig]

I'm going to be doing a bit of work with the save file fixer so that it doesn't run as frequently, and displays some progress as it does so in the near future. Just finding some time to do it is the issue

Any delay imposed will be at the end of the loading sequence as you enter the main menu. If you're getting hangs halfway through loading, then this is generally caused by some mod throwing an exception during it's initialization phase.

Best bet is to check the KSP.log.

[swamp_ig]

Just a little issue we've found over at the BTSM mod thread -- there seems to be some issue with 2.1.5 and atmosphereCurves.

If I were to hazard a guess, it would be the space after the comma for the key index

Try this and see if it works:

		@atmosphereCurve
		{
			@key,0 = 0 385
			@key,1 = 1 300
			key = 5 0.01
		}

If not, let me know and I'll see what I can sort out.

[Renegrade]

If I were to hazard a guess, it would be the space after the comma for the key index

Yep, that did work, thanks! I'll relay that back to FC.

But um, just as a note, the above config works just fine in ModuleManager 2.1.0 and earlier.. was there a syntax change or something?