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

swamp_ig · May 5, 2014

I've realized there's going to be an issue with the latest version of module manager.

The latest version does *not* change the order of modules when a patch runs against the part, unless adding new modules obviously. This is to ensure that adding a new patch won't break old saves.

Unfortunately this means that any parts that have had their modules modded with the old version of MM, added to a ship, and then saved will break.

This is due to a problem / bug with KSP which has been reported, but I don't hold up high hopes for a fix since it's largely about mods. I'm working on getting something in place to rectify the problem, but in the mean time you will probably want to back up any save files prior to upgrading.

Will write a more detailed post about how to edit your saves by hand so they don't break some time later today.

Edited May 5, 2014 by swamp_ig

NavyFish · May 5, 2014

I do believe my save is broken

Despite that, thank god I checked this on my actual installation vice my dev install (where it was working fine). I'm two clicks away from releasing the next version of my plugin, which was going to include 2.0.10.

Any chance you could provide some quick guidance (doesn't have to be anything fancy or detailed) on recovering the save?

Also... what version of MM is stable for release with other plugins?

*edit* Phew! I loaded my last quicksave and it hadn't been corrupted.

Edited May 5, 2014 by NavyFish

NavyFish · May 5, 2014

To clarify my question/problem a little bit, here is how I'm using MM:


@PART[*]:HAS[@MODULE[ModuleDockingNode],!MODULE[ModuleDockingNodeNamed]]:FOR[DockingPortAlignment]
{
	MODULE
	{
		name = ModuleDockingNodeNamed
		portName = default
		initialized = false
	}
}

This config file is bundled with my plugin (which uses a dll). Even using MM 2.0.1, things break, badly. I'm getting a ton of null ref errors as well as some GUI warning that I'm pushing more GUIClips than I'm popping.

Interestingly, on my development install, everything works perfectly fine. I have only 1 other mod (blizzy's toolbar) installed on that, so that's almost certainly the reason. But even on that build, when I created vessels without my plugin, saved and quit, added my plugin (which adds the above modules), the re-launched, everything worked fine. The existing vessels received the new module just fine.

I'm a bit at a loss here. Any suggestions would be wonderful.

-Navy

Edited May 5, 2014 by NavyFish

sarbian · May 5, 2014

jinks : Ah, there was something for those but It got lost it seems.

swamp_ig : yeah, that module loading thing is annoying. I was unable to unlock my lander for its base yesterday after the port save was corrupted.

Squad should fix the damn bug ...

NavyFish : stick with the one ferram4 uses for now ( 2.0.5 ).

NavyFish · May 5, 2014

I can try that. Did just try it with 1.5.6, and had the same exact issue.

Another symptom is that I cannot undock once the save has been corrupted, seemingly the same as what you experienced.

swamp_ig · May 5, 2014

Another note: Once you have broken a save and resaved it it will stay broken. Downgrading won't help.

KSP will just dump any modules it can't load, and they're then lost to the save forever.

Anyhow, am working on a fix.

NavyFish · May 5, 2014

Hadn't quicksaved. Just persistance.sfs was corrupt. Was able to quit, downgrade, relaunch, and hold f9, got my save back Or so it appears. When corrupted, I couldn't undock, with the 'recovered' file, I can. I really hope that's the case, because it's a career with lots of progress.

Testing with 2.0.5 now..

*edit* 2.0.5 doesn't work. So this probably has something to do with the way I'm using MM, no?

Edited May 5, 2014 by NavyFish

NavyFish · May 5, 2014

My log file (for the corrupted save) contains the following immediately upon transition to the flight scene:

[WRN 02:29:23.031] PartModule is null.
[ERR 02:29:23.720] Cannot find fx group of that name for decoupler
[ERR 02:29:23.762] Cannot load Module ModuleDockingNode because the associated module on the part doesn't match the saved module
[WRN 02:29:23.762] PartModule is null.
[ERR 02:29:23.763] Cannot load Module ModuleTweakableDockingNode because the associated module on the part doesn't match the saved module
[WRN 02:29:23.764] PartModule is null.

So it looks like part modules have been removed. I suspect this is what's causing all the NREs and inability to undock. Hrm.

Edited May 5, 2014 by NavyFish

psyper · May 5, 2014

I have a modulemanager script which replaced kethane with water to produce oxidizer and it had (somehow) worked in the older version of MM but now doesn't when I upgraded.

The code for the 2m converter was:

@PART[kethane_2m_converter]:HAS[@MODULE[KethaneConverter]:HAS[@InputRates[*]:HAS[#Kethane], @OutputRatios[*]:HAS[#Oxidizer]]]
{
   @MODULE[KethaneConverter]
   {
   }
   @MODULE[KethaneConverter]
   {
	@InputRates
		{
			@Kethane = 0
			Water = 8.25
		}
   }
}

As you can see its totally wrong but it worked - I'm pretty sure it just ignored the HAS operators in the first line but it ignored the first KethaneConverter module which is the liquid fuel one and zero'ed the kethane and added water to the oxidizer. I could probably just turn the first line in to "@PART[kethane_2m_converter]:HAS[@MODULE[KethaneConverter]]" and it'll still probably work but 'if it aint broke don't fix it' came to mind and I left it!!

Now running MM 2.1.0 it come up with a space error so I correct it to this:

@PART[kethane_2m_converter]:HAS[@MODULE[KethaneConverter]:HAS[@InputRates[*]:HAS[#Kethane],@OutputRatios[*]:HAS[#Oxidizer]]]
{
   @MODULE[KethaneConverter]
   {
   }
   @MODULE[KethaneConverter]
   {
	@InputRates
		{
			@Kethane = 0
			Water = 8.25
		}
   }
}

Which doesn't error but now doesn't touch the part at all. I tried removing the first @MODULE[KethaneConverter] and just had the first one which should 'in theory' work but it doesn't. Finally doing this:

@PART[kethane_2m_converter]:HAS[@MODULE[KethaneConverter]]
{
   @MODULE[KethaneConverter]
   {
	@InputRates
		{
			@Kethane = 0
			Water = 8.25
		}
   }
}

Just changes the liquid fuel but not the oxidizer. No matter what combination of the above scripts I use I can't get it to recognise the 2nd kethane converter entry!

The part page is:

//Kethane Pack Asset

PART
{
// --- general parameters ---
name = kethane_2m_converter
module = Part
author = Keptin

// --- asset parameters ---
mesh = model.mu
rescaleFactor = 1.15

node_stack_top = 0.0, .308, 0.0, 0.0, 1.0, 0.0, 2
node_stack_bottom = 0.0, -.310, 0.0, 0.0, 1.0, 0.0, 2

cost = 3500
category = Utility
subcategory = 0
title = KE-C190 Heavy Converter Unit
manufacturer = Organization of Kethane Equipment Producers
description = The KE-C190 features deployable heat sinks to aid in keeping the unit cool during operation. When it's not overheating, this heavy unit can rapidly and efficiently process Kethane into other fuels.

TechRequired = veryHeavyRocketry
entryCost = 50

attachRules = 1,1,1,1,0

mass = 2
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.3
angularDrag = 2
crashTolerance = 6
breakingForce = 200
breakingTorque = 200
maxTemp = 5200
fuelCrossFeed = True

MODULE
{
    name = HeatSinkAnimator
    HeatAnimation = M2_converter_EmissiveAnimation
    OpenAnimation = M2_converter_converting
    OpenTemperature = 300
    MaxTemperature = 3600
    InternalDissipation = 0.04
    HeatSinkDissipation = 0.28
    PressureDissipation = 0.14
    AirSpeedDissipation = 0.007
    RadiatorNormal = 0, 0, 1
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 600
    InputRates
    {
        Kethane = 6.75
        ElectricCharge = 12
    }
    OutputRatios
    {
        LiquidFuel = 1.03
    }
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 800
    InputRates
    {
        Kethane = 8.25
        ElectricCharge = 8
    }
    OutputRatios
    {
        Oxidizer = 0.99
    }
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 1200
    InputRates
    {
        Kethane = 3
        ElectricCharge = 10
    }
    OutputRatios
    {
        MonoPropellant = 0.85
    }
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 300
    InputRates
    {
        Kethane = 2
        ElectricCharge = 8
    }
    OutputRatios
    {
        XenonGas = 0.25
    }
}
}

what am I doing wrong? Many thanks in advance

sarbian · May 5, 2014

Try with


@PART[kethane_2m_converter]
{
   @MODULE[KethaneConverter],*
   {
	@InputRates
		{
			@Kethane = 0
			Water = 8.25
		}
   }
}
}

The HAS in the first line is not really useful since you name the part.

psyper · May 5, 2014

Try with
@PART[kethane_2m_converter]
{
   @MODULE[KethaneConverter],*
   {
	@InputRates
		{
			@Kethane = 0
			Water = 8.25
		}
   }
}
}
The HAS in the first line is not really useful since you name the part.

Thanks for the reply but that removes the kethane on all the kethaneconverter modules and adds water to them

sarbian · May 5, 2014

ok, I don't understand what you want your final part to look like then

psyper · May 5, 2014

ok, I don't understand what you want your final part to look like then

Sorry I didn't make it clear. I want the part file to ideally turn from this:

MODULE
{
    name = KethaneConverter
    HeatProduction = 600
    InputRates
    {
        Kethane = 6.75
        ElectricCharge = 12
    }
    OutputRatios
    {
        LiquidFuel = 1.03
    }
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 800
    InputRates
    {
        Kethane = 8.25
        ElectricCharge = 8
    }
    OutputRatios
    {
        Oxidizer = 0.99
    }
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 1200
    InputRates
    {
        Kethane = 3
        ElectricCharge = 10
    }
    OutputRatios
    {
        MonoPropellant = 0.85
    }
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 300
    InputRates
    {
        Kethane = 2
        ElectricCharge = 8
    }
    OutputRatios
    {
        XenonGas = 0.25
    }
}

to this:

MODULE
{
    name = KethaneConverter
    HeatProduction = 600
    InputRates
    {
        Kethane = 6.75
        ElectricCharge = 12
    }
    OutputRatios
    {
        LiquidFuel = 1.03
    }
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 800
    InputRates
    {
        Water = 8.25
        ElectricCharge = 8
    }
    OutputRatios
    {
        Oxidizer = 0.99
    }
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 1200
    InputRates
    {
        Kethane = 3
        ElectricCharge = 10
    }
    OutputRatios
    {
        MonoPropellant = 0.85
    }
}

MODULE
{
    name = KethaneConverter
    HeatProduction = 300
    InputRates
    {
        Kethane = 2
        ElectricCharge = 8
    }
    OutputRatios
    {
        XenonGas = 0.25
    }
}

Basically changing the oxidizer input fuel from kethane to water.

BudgetHedgehog · May 5, 2014

Hmm.. would something like directing the change at 'a module that has an output ratio of oxidiser' instead of the actual part work? Then you could change the input ratio to use water etc..

Something like:

@PART[kethane_2m_converter]
{
   @MODULE[KethaneConverter]:HAS[@OutputRatio[Oxidizer]]
   {
	@InputRates
		{
			@Kethane = 0
			Water = 8.25
		}
   }
}
}

I don't know all MM syntax rules so you'll need some symbol in front of OutputRatio, but I don't know which. @ seems logical.

Edited May 5, 2014 by ObsessedWithKSP

psyper · May 5, 2014

Hmm.. would something like directing the change at 'a module that has an output ratio of oxidiser' instead of the actual part work? Then you could change the input ratio to use water etc..
Something like:
@PART[kethane_2m_converter]
{
   @MODULE[KethaneConverter]:HAS[@OutputRatio[Oxidizer]]
   {
	@InputRates
		{
			@Kethane = 0
			Water = 8.25
		}
   }
}
}
I don't know all MM syntax rules so you'll need some symbol in front of OutputRatio, but I don't know which. @ seems logical.

Nope sorry that didn't work although I think you're on to something in addressing the individual module elements somehow - ideally I want this in place so if I create a different MM script I wont need to worry about which order the modules are in!

From your idea I also tried along the lines of:

@PART[kethane_2m_converter]
{
   @MODULE[KethaneConverter]:HAS[@OutputRatio[*]:HAS[#Oxidizer]]
   {
	@InputRates
		{
			@Kethane = 0
			Water = 8.25
		}
   }
}

but that didn't work either

Mecripp · May 5, 2014

I'm guessing you did add water to Kethane Resource list and how are you testing it ?

Edited May 5, 2014 by Mecripp2

psyper · May 5, 2014

I'm guessing you did add water to Kethane Resource list and how are you testing it ?

yep. It worked in previous version of MM but now its not changing it and the changes I make to the cfg file is either adding water to liquid fuel or to all the modules. I test it by changing the cfg file, reloading ksp, bringing up the debug and checking the relevant parts - I know its having an effect as these do change but not correctly.

NavyFish · May 5, 2014

Anyhow, am working on a fix.

Sorry to keep harping on this particular issue. Any chance you could provide us with an estimated timeline for this fix? I ask because I'm about to release a new version of my plugin, but seeing as it currently corrupts save files, I may need to remove the culprit feature. If you're getting close to a solution, however, I'll wait to release my update with the hope of using your fix.

In another vein, can you think of any work-arounds for this issue? As this is my first time using MM in my plugin, I'm not completely certain that it's not something I'm just doing wrong. Other mods that use MM have been pretty plug-and-play from a user's standpoint, so what makes mine different?

At this time, I'm currently adding a custom module to all parts with a ModuleDockingPort. That's it. I reference that module several times from my DLL.

If I can use MM to force the new module to be added at the end of each parts' list of modules/nodes, perhaps it would work. Although, if I understand the bug correctly, if someone else were to add modules after my custom module, save, then uninstall my plugin, their save would break. Is that correct?

Thanks for your time, I know how precious it can be.

Navy

jinks · May 5, 2014

I've realized there's going to be an issue with the latest version of module manager.
The latest version does *not* change the order of modules when a patch runs against the part, unless adding new modules obviously. This is to ensure that adding a new patch won't break old saves.
Unfortunately this means that any parts that have had their modules modded with the old version of MM, added to a ship, and then saved will break.

Can you give a bit more detail on this?

I don't really understand what the issue is and if/how this affects me as a user. Why would not reordering modules (I assume you mean MODULE{} sections on parts) break my save?

I have mostly MM configs which add MODULE sections, maybe a few @MODULE which modify specific lines. What should I expect to break and how will it manifest itself?

BudgetHedgehog · May 5, 2014

As I understand it, the game loads a part from a cfg file, right? In that file, the various MODULEs are in a certain order. In the persistent.sfs, it includes details on ships, including the MODULEs its parts contain. If the order of those differ, the game thinks it's a different part or something and refuses to load the sfs because it contains invalid parts (I think). The problem comes when you uninstall a mod/delete a MM cfg that added a MODULE or otherwise changed existing MODULEs on a part because now, the parts cfg contains different information to what the sfs file says it should.

This is just my personal speculation though, what might actually be happening could be different.

Edited May 5, 2014 by ObsessedWithKSP

Starwaster · May 5, 2014

As I understand it, the game loads a part from a cfg file, right? In that file, the various MODULEs are in a certain order. In the persistent.sfs, it includes details on ships, including the MODULEs its parts contain. If the order of those differ, the game thinks it's a different part or something and refuses to load the sfs because it contains invalid parts (I think). The problem comes when you uninstall a mod/delete a MM cfg that added a MODULE or otherwise changed existing MODULEs on a part because now, the parts cfg contains different information to what the sfs file says it should.
This is just my personal speculation though, what might actually be happening could be different.

No, it'll load the part but you can have things happen where modules just dont work properly to the ship not coming off rails properly. That last one is really bad. Physics might not load for it. or it will seem to explode, except it doesn't except that it doesnt matter if it really exploded because you cant interact with it. Or time might totally freeze. And no interaction means you cant recover crew from it or undock ships from it.

also, if a part is truly invalid, affected craft in the sfs file wont load but everything else does. the world and unaffected ships load.

BudgetHedgehog · May 5, 2014

Then I was mostly wrong. But thank you for correcting me, TIL...

NavyFish · May 5, 2014

There's more going on, though. When I add my config file to a working install, it immediately breaks the save. I assume this is because MM is not adding my config to the end of the part's module list.

I have tweakable everything installed, which adds a module to docking ports as well. By checking the log file, I've confirmed that my config is loaded prior to the twekable module, which loads during the :FINAL block. Thus when an sfs compares its modules to the loaded proto configs, it finds an extra module (mine), where the tweakbale module used to be, and viola, the save breaks.

At the very least, I'd like to be able to force my module to load last, but that's a Band-Aid and not a solution.

I think the important question is whether or not sfs files can be modified at runtime. If so, then a solution would be to scan the persistence/quicksave sfs just prior to it being loaded and reconfigure all modules to match the proto part. I'm not certain, but that might do the trick.

sarbian · May 5, 2014

I think the important question is whether or not sfs files can be modified at runtime. If so, then a solution would be to scan the persistence/quicksave sfs just prior to it being loaded and reconfigure all modules to match the proto part. I'm not certain, but that might do the trick.

swamp_ig is actually looking into that.

swamp_ig · May 5, 2014

Ok here's the rundown.

When you define a part you have something like:


PART
{
	name = myPart
	// .. some other stuff
	MODULE
	{
		name = module1
		// .. more stuff
	}
	MODULE
	{
		name = module2
		// .. yet more stuff
	}
}

Now if you were to go launch a ship that used that part, the part would save for the modules list "module1", "module2" IN THAT ORDER

So if you were to produce a patch such as:


@PART[myPart]
{
	@MODULE[module1]
	{
		addedValue = added
	}
}

then the previous version of MM would grab module1, edit it, and put it at the end so the order you would end up with would be module2, module1.

If you'd had any saves from before this patch, they'd now be dead. This means you can never patch a defined part, which kinda defeats the purpose of having MM in the first place.

My fix to MM doesn't mess with the original order, so if it's defined originally as module1, module2, then it stays in the same order therefore NOT breaking saves from before the patch.

Unfortunately, if you'd created a save gave with the old MM, and then upgraded, then the modded saves are saves like module2, module1, which will break. Although technically this really is a bug in KSP, and probably really a bug in the previous version of MM, we appreciate that it's not a desirable thing to break saves

Currently I'm working on a fix to this problem which will remove the sensitivity to order permanently. This is a Good Thing because there's occasions where you want to change the order of things in your parts. As for the time frame... it's a high priority that's all I can say

Edited May 5, 2014 by swamp_ig

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation