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

[ialdabaoth]

There's one thing ModuleManager doesn't do when it probably should: It can't create a part definition derived from an existing part, or if it can, this is never clearly documented.

I.e. I can't create a stock part rescale while keeping the original stock part without actually duplicating the part.cfg of that part, and keeping it inside the stock directories.

Wouldn't it be so very nice if you could do stuff like

@PARTDERIVED[strutCube]
{
    @name = strutCubeLarge
    @rescaleFactor = 2
}

Is something of the sort even possible?

... YES. Yes it is! Hahahahaha!

I think I'd actually want it to look like this, though:

PART From PART[strutCube]:Final
{
    @name = strutCubeLarge
    @etc
}

hrm. One problem, though - order of operations is going to be VERY tricky.

[Mihara]

One problem, though - order of operations is going to be VERY tricky.

Woot, thank you! I very much hope it eventually works, I'll finally be able to leave the stock parts files completely alone and untouched.

[Muji-k]

Photoncap_Medium part definition probably already contains scale and rescaleFactor parameters. Your config file says to add them, however. I'm not sure how the structure is stored in memory, but apparently Module Manager adds new copies of these parameters without removing the ones already there in such a case. Use @scale and @rescaleFactor instead and it should work.

As i said in my post...I didn't use @scale and @rescaleFactor 'cause the .cfg file of Photoncap_Medium part doesn't have this two entries, so yes, my cfg says to add them. Also if i use @scale and @rescaleFactor it doesn't do anything either.

The rescaleFactor parameter isn't the problem, it worked as it should, the part is now a little bigger but the attachment points are now inside the model, so my .cfg is addressing the proper file, but no matter how i try to write my .cfg i can't seen to be able to change the node placement, it doesn't matter if use scale = <value> , @scale = <value>, or even @node_stack_top = <value>, the nodes stay in the same place. The debug console, in the image below, shows that the changes were correctly applied, so i dunno what is causing the nodes to be stuck.

The only way that i found to make the changes in the nodes position work, was to add the "scale = 1.328" parameter directly into the Photoncap_Medium .cfg, so any thoughts on how i can make this work??

Edited June 18, 2013 by Muji-k
image was to small to read the text

[Criek]

Question: is it possible to apply the same changes to multiple parts without code duplication (and possible errors)?

something like:

@PART[Mark1-2Pod, mk2LanderCabin]

{

MODULE

{

name = CargoBay

Baysize = 15

Tanksize = 0

}

MODULE

{

name = ScienceLab

labSize = 1

}

RESOURCE

{

name = Stuff

amount = 10

maxAmount = 10

}

RESOURCE

{

name = ScientificStuff

amount = 0

maxAmount = 5

}

}

That way I can have convenient packages for a one, two and three-man cabin (including for other mods) without the risk of typos.

[ialdabaoth]

... YES. Yes it is! Hahahahaha!

I think I'd actually want it to look like this, though:

PART From PART[strutCube]:Final
{
    @name = strutCubeLarge
    @etc
}

hrm. One problem, though - order of operations is going to be VERY tricky.

On second thought: I think I'm going to deny this feature request. ModuleManager is used by way too many mods, so I need to make it do one simple thing and do that thing very well.

ModuleManager's entire job is to allow you to make modifications to other authors' existing cfg files, for the purpose of making them compatible with your own plugins.

The fact that it also happens to allow people to release "playstyle change" cfg files is a nice feature, but not its primary purpose.

You can easily create a new PART definition by grabbing another PART and copying it; that's probably how you should do it rather than ModuleManager adding part inheritance functionality.

You can add modules to other authors' works by paying attention to what mods are popular, and supporting them; that's probably how you should do it rather than ModuleManager adding wildcard functionality.

The past few days have been a nightmare of incompatabilities and patches and re-patches because of a few places where I tried to be clever, instead of being simple, robust, and thorough.

If ModuleManager really is going to be a redistributable tool for other mod authors, its functionality needs to be GUARANTEED.

The current version does this by paring down what it does to the bare minimum - it scans the entire node list at start-up, immediately after the nodes are loaded but before they are converted into PARTs and RESOURCEs and so on, and merges any node that doesn't start with a '@' with all nodes that do that match @TYPE[name] or @TYPE[name]:Final.

It does this, it does it well, and it (finally) does it without any bugs.

I need to quit while I'm ahead, so that the rest of the community can know that if they include ModuleManager.dll, there won't be any hidden surprises or incompatabilities with someone else who choose to include ModuleManager.dll earlier or later than them.

Hopefully 0.21 will do this natively, and we can all put ModuleManager.dll behind us.

[theSpeare]

Can someone help me with finding out what's wrong with my ModuleManager? (or which mods I have installed that's messing with it?)

My mods:

B9 Aerospace

Crew Manifest

Engineering Kerbal

KAS

Kethane

KSPX

KWRocketry

MechJeb2

Mission Controller

Orbital Construction

Part Catalog

Protractor

RemoteTech

Romfarer Stuff

TAC Fuel Balancer

Telemachus

[s20dan]

Is there a way to add a module to every part?

For example I want to add this to every part:

MODULE

{

name = ReflectiveShaderModule

CubeMapSize = 1024

OneFacePerFrame = true

ShaderName = Reflective/VertexLit

}

Cheers.

[s20dan]

Is there a way to add a module to every part?

For example I want to add this to every part:

MODULE

{

name = ReflectiveShaderModule

CubeMapSize = 1024

OneFacePerFrame = true

ShaderName = Reflective/VertexLit

}

Cheers.

I take the silence to be a NO...?

[loppnessmonsta]

actually, the answer is yes. you can. but you need to list the change to each part, not just once. more work, but still less work than changing them every time you update.

[s20dan]

actually, the answer is yes. you can. but you need to list the change to each part, not just once. more work, but still less work than changing them every time you update.

Thats not what I meant, but I went ahead and did that anyway.

I was hoping to make the change to all parts with one config entry

Earlier in the thread some people spoke of 'wildcards', it seems if they were implemented they would allow for this.

Anyway I think that would be a nice feature... Change any parts with XXX in their name, or perhaps change any parts containing XXX module.

[CaptainArbitrary]

I have the weirdest, and least helpful, bug report ever.

Somehow it's possible for ModuleManager to screw up the order of PartModules attached to a part.

Now, this description is gonna be wonky, because at the moment I'm working with a very hacked configuration. I was testing out some engine designs (through ModularEngines), so I had just two engines installed in my game: a modified version of liquidEngine1 (the LV-T30) and a modified version of liquidEngine2 (the LV-T45). What I noticed first is that in the VAB, the part info for liquidEngine2 was all screwed up; instead of being listed in the normal way, with the ModuleEngines info first and then other lines after, it was backwards, listing the info in the reverse order from what I have in my part.cfg.

After two solid days of investigating, including writing my own debugging PartModule that does nothing but print out the names of the modules in this.part.Modules in order at OnAwake(), I discovered that on liquidEngine2  and only liquidEngine2  the part module order was getting screwed up sometime between OnLoad() and OnAwake().

Now, in this game directory I had just a few parts, but several core mods installed, 'cause it was a copy of my normal game directory. I had FAR and Deadly and RemoteTech and such like that … all of which call ModuleManager, so obviously I had a ModuleManager.dll in my game data folder too (the latest one, 1.3).

In a fit of just-isolate-the-damn-problem I started by pulling ModuleManager.dll out … and poof. The problem went away.

I glanced through the ModuleManager.cs source file (https://github.com/Ialdabaoth/ModuleManager/blob/master/moduleManager%20copy.cs) just long enough to see that it does include code that removes all modules from a part then re-adds them … but weirdly, that code doesn't seem to be called anywhere that I can see. The rest of the code involves game database features that I'm not familiar with, so I haven't studied it too closely to figure out where exactly the problem lies.

For myself, I've disabled ModuleManager.dll just for the moment, so I can get on with what I'm doing. I'm hoping that even this unacceptably vague "bug report" (as if it deserves being called that) will be enough, since you're so familiar with the code, to make you go "Oh, yeah, I totally know what's going on there." But if not, I'll try to come back with more info once I get my current project squared away and get back to a not-entirely-insane game setup.

[ialdabaoth]

Note! That isn't actually the current code at all; that's an old fork. This is the actual code: ModuleManager.cs

Note that this doesn't actually touch the modules at all; ALL it does is edit the config node before the PartLoader gets to it.

[Subcidal]

Thats not what I meant, but I went ahead and did that anyway.

I was hoping to make the change to all parts with one config entry

Earlier in the thread some people spoke of 'wildcards', it seems if they were implemented they would allow for this.

Anyway I think that would be a nice feature... Change any parts with XXX in their name, or perhaps change any parts containing XXX module.

This would be extremely useful when you've got mods like Deadly re-entry. I really want to use it but I just haven't summoned the willpower to chug through every single part. I would much rather set a base level and then tweak parts here and there that I want to fail at lower/higher temps. I'm sure theres many more mods to come in the future that this type of feature would really compliment as well, judging from the explosion of high quality mods recently.

[CaptainArbitrary]

Note! That isn't actually the current code at all; that's an old fork. This is the actual code: ModuleManager.cs

Oh, okay, my mistake. Sorry.

Note that this doesn't actually touch the modules at all; ALL it does is edit the config node before the PartLoader gets to it.

In point of fact, it seems to anyway. I've got the problem conclusively narrowed down, I think. I created a whole new game folder (0.20.2, just for the record) and removed all the Squad parts except probeStackSmall, fuelTank, liquidEngine1 and liquidEngine2. Then I installed ModuleManager, just by copying the latest .dll file into my GameData directory. Then I threw a little debugger I wrote on the two engines; all it does is, during OnAwake, print out the names of the part modules attached to it. Here's the source code:

using System;

namespace ProjectArcturus
{
	public class ArcturusDebugger : PartModule
	{
		public override void OnAwake ()
		{
			base.OnAwake ();
			print ("*** Debugger.OnAwake() on " + this.part.name);
			print ("*** " + this.part.Modules.Count + " PartModules found");
			foreach (PartModule m in this.part.Modules) {
				print ("*** " + m.ToString());
			}
		}
	}
}

And here's the relevant output:

[LOG 10:49:44.641] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine1/part/liquidEngine'
[LOG 10:49:44.653] Added sound_rocket_hard to FXGroup running
[LOG 10:49:44.655] Added sound_explosion_low to FXGroup flameout
[LOG 10:49:44.659] *** Debugger.OnAwake() on liquidEngine
[LOG 10:49:44.659] *** 0 PartModules found
[LOG 10:49:44.680] *** Debugger.OnAwake() on liquidEngine(Clone)
[LOG 10:49:44.681] *** 5 PartModules found
[LOG 10:49:44.681] *** liquidEngine(Clone) (ProjectArcturus.ArcturusDebugger)
[LOG 10:49:44.681] *** liquidEngine(Clone) (ModuleEngines)
[LOG 10:49:44.681] *** liquidEngine(Clone) (ModuleJettison)
[LOG 10:49:44.681] *** liquidEngine(Clone) (ModuleAnimateHeat)
[LOG 10:49:44.681] *** liquidEngine(Clone) (ModuleAlternator)
[LOG 10:49:44.688] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine2/part/liquidEngine2'
[LOG 10:49:44.694] Added sound_rocket_hard to FXGroup running
[LOG 10:49:44.694] Added sound_explosion_low to FXGroup flameout
[LOG 10:49:44.696] *** Debugger.OnAwake() on liquidEngine2
[LOG 10:49:44.696] *** 0 PartModules found
[LOG 10:49:44.712] *** Debugger.OnAwake() on liquidEngine2(Clone)
[LOG 10:49:44.712] *** 6 PartModules found
[LOG 10:49:44.712] *** liquidEngine2(Clone) (ProjectArcturus.ArcturusDebugger)
[LOG 10:49:44.712] *** liquidEngine2(Clone) (ModuleEngines)
[LOG 10:49:44.712] *** liquidEngine2(Clone) (ModuleJettison)
[LOG 10:49:44.712] *** liquidEngine2(Clone) (ModuleGimbal)
[LOG 10:49:44.713] *** liquidEngine2(Clone) (ModuleAnimateHeat)
[LOG 10:49:44.713] *** liquidEngine2(Clone) (ModuleAlternator)

As you can see, the order of part modules in the list is the same as the order in which they appear in the config file. Unsurprisingly, the VAB info GUI looks normal:

Next, I put a test.cfg file in my GameData folder, to call ModuleManager. It just looks like this:

@PART[liquidEngine]
{
	@maxTemp = 1800
	@MODULE[ModuleEngines]
	{
		@heatProduction = 200
	}
}

@PART[liquidEngine2]
{
	@maxTemp = 1800
	@MODULE[ModuleEngines]
	{
		@heatProduction = 200
	}
}

That should look familiar; you wrote it. It comes from Deadly Reentry. Here's the resulting debug log:

[LOG 10:52:24.040] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine1/part/liquidEngine'
[LOG 10:52:24.052] Added sound_rocket_hard to FXGroup running
[LOG 10:52:24.055] Added sound_explosion_low to FXGroup flameout
[LOG 10:52:24.058] *** Debugger.OnAwake() on liquidEngine
[LOG 10:52:24.058] *** 0 PartModules found
[LOG 10:52:24.079] *** Debugger.OnAwake() on liquidEngine(Clone)
[LOG 10:52:24.079] *** 5 PartModules found
[LOG 10:52:24.079] *** liquidEngine(Clone) (ProjectArcturus.ArcturusDebugger)
[LOG 10:52:24.079] *** liquidEngine(Clone) (ModuleJettison)
[LOG 10:52:24.079] *** liquidEngine(Clone) (ModuleAnimateHeat)
[LOG 10:52:24.079] *** liquidEngine(Clone) (ModuleAlternator)
[LOG 10:52:24.079] *** liquidEngine(Clone) (ModuleEngines)
[LOG 10:52:24.086] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine2/part/liquidEngine2'
[LOG 10:52:24.091] Added sound_rocket_hard to FXGroup running
[LOG 10:52:24.091] Added sound_explosion_low to FXGroup flameout
[LOG 10:52:24.093] *** Debugger.OnAwake() on liquidEngine2
[LOG 10:52:24.093] *** 0 PartModules found
[LOG 10:52:24.109] *** Debugger.OnAwake() on liquidEngine2(Clone)
[LOG 10:52:24.109] *** 6 PartModules found
[LOG 10:52:24.109] *** liquidEngine2(Clone) (ProjectArcturus.ArcturusDebugger)
[LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleJettison)
[LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleGimbal)
[LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleAnimateHeat)
[LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleAlternator)
[LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleEngines)

Notice how ModuleEngines has gotten moved down to the bottom, where previously it came second (because it was second in the config files, after my debug module). You wouldn't think this matters, but here's what the VAB GUI looks like now:

In order to generate the VAB GUI, apparently the game sends GetInfo() to each PartModule in the order they appear in part.Modules, so the result ends up in the wrong order if the order of the modules in the list gets rearranged.

To test it just one step further, I changed my test.cfg file to look like this:

@PART[liquidEngine]
{
	@maxTemp = 1800
	@MODULE[ModuleEngines]
	{
		@heatProduction = 200
	}
}

@PART[liquidEngine2]
{
	@maxTemp = 1800
	@MODULE[ModuleGimbal]
	{
		@gimbalRange = 2
	}
	@MODULE[ModuleEngines]
	{
		@heatProduction = 200
	}
}

And here's the debug output:

[LOG 10:55:47.334] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine1/part/liquidEngine'
[LOG 10:55:47.346] Added sound_rocket_hard to FXGroup running
[LOG 10:55:47.349] Added sound_explosion_low to FXGroup flameout
[LOG 10:55:47.352] *** Debugger.OnAwake() on liquidEngine
[LOG 10:55:47.352] *** 0 PartModules found
[LOG 10:55:47.373] *** Debugger.OnAwake() on liquidEngine(Clone)
[LOG 10:55:47.373] *** 5 PartModules found
[LOG 10:55:47.374] *** liquidEngine(Clone) (ProjectArcturus.ArcturusDebugger)
[LOG 10:55:47.374] *** liquidEngine(Clone) (ModuleJettison)
[LOG 10:55:47.374] *** liquidEngine(Clone) (ModuleAnimateHeat)
[LOG 10:55:47.374] *** liquidEngine(Clone) (ModuleAlternator)
[LOG 10:55:47.374] *** liquidEngine(Clone) (ModuleEngines)
[LOG 10:55:47.380] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine2/part/liquidEngine2'
[LOG 10:55:47.386] Added sound_rocket_hard to FXGroup running
[LOG 10:55:47.387] Added sound_explosion_low to FXGroup flameout
[LOG 10:55:47.389] *** Debugger.OnAwake() on liquidEngine2
[LOG 10:55:47.389] *** 0 PartModules found
[LOG 10:55:47.404] *** Debugger.OnAwake() on liquidEngine2(Clone)
[LOG 10:55:47.404] *** 6 PartModules found
[LOG 10:55:47.404] *** liquidEngine2(Clone) (ProjectArcturus.ArcturusDebugger)
[LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleJettison)
[LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleAnimateHeat)
[LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleAlternator)
[LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleGimbal)
[LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleEngines)

The part modules appear in the order in which they appeared in the config file, except for modules touched my ModuleManager. Those ones get appended to the end of the list, in the order in which they appear in the relevant .cfg file … is my guess.

[ialdabaoth]

The part modules appear in the order in which they appeared in the config file, except for modules touched my ModuleManager. Those ones get appended to the end of the list, in the order in which they appear in the relevant .cfg file … is my guess.

That is correct, but it has nothing to do with deleting or reloading the modules, it's purely a matter of what the in-memory ConfigNode ends up looking like.

ANY sub-node within a ConfigNode that gets modified has to be removed and re-added. If you look at ModuleManager.cs, you will see this happening on line 93 and 94. This is because funky things occasionally happen if you just modify a subnode that is parented to a larger configNode (or at least they did in 0.19; I didn't want to risk introducing new bugs in 0.20 so that code remained untouched).

As a consequence of this, yeah... it looks like every subnode that gets modified gets bumped to the bottom of the subnode list. One simple solution might be to include a blank patch node for the nodes that you want to ensure show up after the node you're modifying, so you'd wind up with something like this:

@PART[liquidEngine2]
{
	@maxTemp = 1800
	@MODULE[ModuleGimbal]
	{
		@gimbalRange = 2
	}
	@MODULE[ModuleEngines]
	{
		@heatProduction = 200
	}
	@MODULE[ModuleGimbal] {}
	@MODULE[ModuleAlternator] {}
	@MODULE[ModuleJettison] {}
}

Note that this has the additional advantage of allowing you to position an inserted node precisely between any two existing nodes, by spelling out the entire new node order explicitly.

[CaptainArbitrary]

Well, yeah, that would work …unless it's somebody else's ModuleManager config file that's screwing you up. As it was in this case; it was actually Deadly Reentry, not my own config file, that caused the original problem.

I guess for the time being, at least, the workaround is to have a custom ModuleManager config file that touches every part where the order of part modules matters, as it does with engines. That's …*bleurg. I'm not loving that, but it'll work, I guess.

[ialdabaoth]

Well, yeah, that would work …unless it's somebody else's ModuleManager config file that's screwing you up. As it was in this case; it was actually Deadly Reentry, not my own config file, that caused the original problem.

In this case, it was mine. I can make the necessary changes. But in the larger scope, you're right. I'm not sure that there's a good solution to this.

I guess for the time being, at least, the workaround is to have a custom ModuleManager config file that touches every part where the order of part modules matters, as it does with engines. That's …*bleurg. I'm not loving that, but it'll work, I guess.

I'm not loving that either. One of the problems that I frequently have when I look at ModuleManager, is figuring out use-case tradeoffs. (This is one of the reasons I'm so adamant about not doing wildcards, for example).

The sheer number of ways that things can go subtly wrong in specific circumstances, while being completely logical and not in-point-of-fact incorrect, is staggering.

At this point in my modding career, my sole evaluation criterion for whether to implement a new feature - or even fix an existing bug - is "will this cause more, or fewer people to bitch that it's broken?"

[CaptainArbitrary]

At this point in my modding career, my sole evaluation criterion for whether to implement a new feature - or even fix an existing bug - is "will this cause more, or fewer people to bitch that it's broken?"

Yeah, man, I know exactly what you mean. I hope my thing didn't come across as bitching. It was less frustrating and more "Huh, that's a weird one." Being a combination of how the ConfigNode structure works (I guess) and the fact that the game calls GetInfo() on each module in the order they appear in part.Modules, it was just a bizarre and pretty funny situation.

Fortunately there's no functional problem here. As near as I can tell, everything works, as long as you don't do something stupid and make modules throw uncaught null-reference exceptions if they don't get initialized in just the right order (ahem). The only lingering effect is a cosmetic thing, which drives my OCD completely freaking bananas but which doesn't actually change the way the game works at all.

Frankly, stuff like ModuleManager is kind of like what they say about the singing dog at the circus. It doesn't have to sing perfectly. The fact that it sings at all is really impressive.

[malkuth]

This is pretty nice. Im new to Modding and want to make a resource.. Sounds like this will help me add a new Resource to the stock Crew Modules..

[somnambulist]

ialdabaoth -

I'm trying to use model nodes to reduce KW Rocketry's memory footprint without entirely reorganzing the folder structure. Problem --

@PART[KW2mNoseCone]:Final
{
    @MODEL
        {
        model = KWRocketry/test
        texture = model000, KWRocketry/test
        scale = 1.0, 1.0, 1.0
        }
}

Will switch the mesh and texture to the test mesh and texture but KSP won't purge the original assets from memory. Is there any way to work around this or is that well beyond the scope of MM? (I tried "!mesh = delete" but no go.)

Edited July 2, 2013 by somnambulist
forum ate the formatting

[praise the suuun]

I have the weirdest, and least helpful, bug report ever.

Somehow it's possible for ModuleManager to screw up the order of PartModules attached to a part.

Now, this description is gonna be wonky, because at the moment I'm working with a very hacked configuration. I was testing out some engine designs (through ModularEngines), so I had just two engines installed in my game: a modified version of liquidEngine1 (the LV-T30) and a modified version of liquidEngine2 (the LV-T45). What I noticed first is that in the VAB, the part info for liquidEngine2 was all screwed up; instead of being listed in the normal way, with the ModuleEngines info first and then other lines after, it was backwards, listing the info in the reverse order from what I have in my part.cfg.

After two solid days of investigating, including writing my own debugging PartModule that does nothing but print out the names of the modules in this.part.Modules in order at OnAwake(), I discovered that on liquidEngine2  and only liquidEngine2  the part module order was getting screwed up sometime between OnLoad() and OnAwake().

Now, in this game directory I had just a few parts, but several core mods installed, 'cause it was a copy of my normal game directory. I had FAR and Deadly and RemoteTech and such like that … all of which call ModuleManager, so obviously I had a ModuleManager.dll in my game data folder too (the latest one, 1.3).

In a fit of just-isolate-the-damn-problem I started by pulling ModuleManager.dll out … and poof. The problem went away.

I glanced through the ModuleManager.cs source file (https://github.com/Ialdabaoth/ModuleManager/blob/master/moduleManager%20copy.cs) just long enough to see that it does include code that removes all modules from a part then re-adds them … but weirdly, that code doesn't seem to be called anywhere that I can see. The rest of the code involves game database features that I'm not familiar with, so I haven't studied it too closely to figure out where exactly the problem lies.

For myself, I've disabled ModuleManager.dll just for the moment, so I can get on with what I'm doing. I'm hoping that even this unacceptably vague "bug report" (as if it deserves being called that) will be enough, since you're so familiar with the code, to make you go "Oh, yeah, I totally know what's going on there." But if not, I'll try to come back with more info once I get my current project squared away and get back to a not-entirely-insane game setup.

this is my exact problem!

finally i've found other victims . ive written up my perspective of this bug in the support tab.

http://forum.kerbalspaceprogram.com/showthread.php/38899-Stock-air-breathing-engine-s-values-remaining-frozen-at-a-different-value-than-stock?p=502877#post502877

[ialdabaoth]

ialdabaoth -

I'm trying to use model nodes to reduce KW Rocketry's memory footprint without entirely reorganzing the folder structure. Problem --

@PART[KW2mNoseCone]:Final
{
    @MODEL
        {
        model = KWRocketry/test
        texture = model000, KWRocketry/test
        scale = 1.0, 1.0, 1.0
        }
}

Will switch the mesh and texture to the test mesh and texture but KSP won't purge the original assets from memory. Is there any way to work around this or is that well beyond the scope of MM? (I tried "!mesh = delete" but no go.)

As soon as I have a computer that can run KSP, I'll look into this. In the meantime, I have a feeling it's out of scope But I'll try my best to find a solution.

[praise the suuun]

hey buddy id like to use ion cross, B9, remotetech, deadly reentry for my clean install. some how module manager is messing up my stock part values. will having multiple copies of module manager in the game directory be nickleback?

[Elros]

Where is the dl link?

[praise the suuun]

if you develop modifications then the build can be downloaded from the first page. if you want a mod with modulemanager.dll included theres a few out there.