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

[NavyFish]

Thanks for the rundown.

.

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.

Which version of MM changed this behavior? 2.0.10?

[NavyFish]

Thinking about this a little further, I'm not sure if it exactly explains the issue I'm seeing. I'm not modifying an existing module, I'm adding an entirely new, uniquely named one. Assumedly MM should put the module at the end of this list, shouldn't it? Or is that not guaranteed?

Either way, it looks like you're working on a fix that will do the trick. I just hope (for entirely selfish reasons) you can produce something within the next 60 hrs!

[NathanKell]

It's quite possible that other MM patches add other modules "later" in the patch cycle.

[NavyFish]

okay, right. That makes sense.

[Starwaster]

Thinking about this a little further, I'm not sure if it exactly explains the issue I'm seeing. I'm not modifying an existing module, I'm adding an entirely new, uniquely named one. Assumedly MM should put the module at the end of this list, shouldn't it? Or is that not guaranteed?

Either way, it looks like you're working on a fix that will do the trick. I just hope (for entirely selfish reasons) you can produce something within the next 60 hrs!

Just curious, Have you tried ruling out MM by adding the module directly to the part? Just to make sure that the ordering issue is the cause of the problem you have?

[NavyFish]

Just curious, Have you tried ruling out MM by adding the module directly to the part? Just to make sure that the ordering issue is the cause of the problem you have?

No, I haven't. But I don't think that will work: If I manually add it to the part(s), MM will still add the other mods' modules (tweakable docking module, for example) to the end of the module list, which will likely break things. If I could force my module to be added to the end of the list of modules, it would work, but I can't think of a way to do that.

I have created a new save, using my normal KSP installation with all of the mods, and things work just fine, so I'm pretty sure it's the modules-out-of-order bug.

Am I making sense?

[Starwaster]

No, I haven't. But I don't think that will work: If I manually add it to the part(s), MM will still add the other mods' modules (tweakable docking module, for example) to the end of the module list, which will likely break things. If I could force my module to be added to the end of the list of modules, it would work, but I can't think of a way to do that.

I have created a new save, using my normal KSP installation with all of the mods, and things work just fine, so I'm pretty sure it's the modules-out-of-order bug.

Am I making sense?

yeah thats good enough I think.

Just trying to cover all possibilities.

[toadicus]

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.

This doesn't actually fix the problem, but the new version of TweakableEverything I posted this weekend runs all of the patches during FOR[TweakableEverything] (for everything that adds a module) or AFTER[TweakableEverything] (for a few things that tweak modules added during FOR for specific parts). If you need to be sure you're running after me, it shouldn't be hard anymore.

[NavyFish]

Thank you. That would almost certainly allow me to fix the issue in my particular install, but I can't guarantee other mods won't have a similar effect. I'm holding off on releasing DPAI v4 until swamp_ig brings us some goodness!

[mwlue]

errr, i think we really need a thread for a collection of code sample....

now i want to try to clone the mk1-2 pod as a boilerplate, with new texture.... how can mm to the part clone, then change mesh definition to use model{} stuff and change texture????

[swamp_ig]

mwlue: I've actually just started to do that... as in there's one example so far https://github.com/sarbian/ModuleManager/tree/master/Tests

Test cases make good examples

[mwlue]

mwlue: I've actually just started to do that... as in there's one example so far https://github.com/sarbian/ModuleManager/tree/master/Tests

Test cases make good examples

eeeerrrr ok... thanks

[jinks]

Just to clarify:

The Top post links to a Modulemanager-2.1.0.dll, sarbian's latest post links to Modulemanager-2.0.10.dll. Are those the same files?

[sarbian]

mwlue you can make it all in 1 patch :

$PART[cupola]:Final
{
	@name = cupola2

	MODEL
	{
		model = mymodel
	}

	!mesh = notused	
}

I don't know how to change the texture in .cfg however.

Edited May 6, 2014 by sarbian

[Starwaster]

mwlue you can make it all in 1 patch :

$PART[cupola]:Final
{
	@name = cupola2

	MODEL
	{
		model = mymodel
	}

	!mesh = notused	
}

I don't know how to change the texture in .cfg however.

texture = (URL to texture) in the MODEL node

[mwlue]

mwlue you can make it all in 1 patch :

$PART[cupola]:Final
{
	@name = cupola2

	MODEL
	{
		model = mymodel
	}

	!mesh = notused	
}

I don't know how to change the texture in .cfg however.

texture = (URL to texture) in the MODEL node

Ok, thanks all, i'll give'em a try.

[KerbMav]

Can I create a search for parts with one of a number of characteristics?

(e.g. parts with either MODULE1 or MODULE2 or MODULE3)

[sarbian]

no, you need 3 patch for that.

[NavyFish]

I've been looking into the MM source code and playing around with .craft and .sfs files. I wrote a quick program (not a plugin) which will strip all MODULE{} blocks from a craft file. If I then load this stripped craft file in the editor, KSP re-populates all of the module definitions, assumedly from the 'template' found in GameDatabase.Instance.Root.

Unfortunately I haven't had much time to play around with this, but I'm willing to bet sarbian and swamp_ig have spent some time delving into this area, so I'd like to ask a few questions in the hopes of catching me up to speed.

I assume that if I do the same process (strip its MODULE{} blocks) with an .sfs file, then load it in-game, KSP will also repopulate all of its MODULE{} blocks from the same source (GameDatabase? or are those definitions pulled from elsewhere?).

If one were to 'rebuild' a persistence file in such a way, then load a craft file in the editor which has NOT had its MODULE{} configurations stripped, and there exists a difference in the ordering of MODULE{} blocks between the .craft and database, will it modify the craft file at all, or just silently fail in some undefined way (likely throwing-out the non-matching MODULE definitions)?

In theory, would the following work as a way to make MODULE ordering irrelevant (note that this is currently using out-of-game modification, but could assumedly be executed at runtime, possibly by intercepting some form of 'on load' event):

Step 1) Strip all .craft and .sfs file of MODULE{} blocks, but save them in another file (or in memory), using a key-value for each .craft file and each vessel in the .sfs, with the keys being a combination of the name of PART(uid), the MODULE, and its index (if there are multiple copies of the same MODULE), and the value being the entire contents of the MODULE{} block.

Step 2) Allow KSP to re-build the .craft and .sfs files, which will include any modified configurations provided by MM (confirmed this works, at least for craft files but assumedly for .sfs as well).

Step 3) Scan through the .craft/.sfs files that KSP has just rebuilt, and whenever a MODULE{} is encountered, look-up the value for that block in the key-value set we created before, then replace the MODULE{} block with the saved data. Again, the key-value pairs are saved for both craft files as well as for instantiated vessels (using their vessel ID), so no data should be lost.

In summary, this procedure allows KSP and MM to order MODULE{} blocks however it wants to, then re-writes the .sfs or .craft file to match that defined order, restoring data in the process.

I'm not yet familiar enough with KSP's GameDatabase / ConfigNode to do this in-game. But I can only assume that some form of OnLoad event is provided, hopefully for both .craft and .sfs files, which would allow this procedure to modify the appropriate files at runtime and at the moment before they're actually de-serialized. If it's possible, then this should make the ordering of MODULE{} blocks unimportant, as they'll always be re-ordered to match what KSP expects.

I'll poke around with this idea for the next two days, but as I mentioned, I'm going away for a month thereafter and won't be able to mess around with this stuff until I'm back.

Hopefully you're already well ahead of me

Navy

Edited May 6, 2014 by NavyFish

[swamp_ig]

In summary, this procedure allows KSP and MM to order MODULE{} blocks however it wants to, then re-writes the .sfs or .craft file to match that defined order, restoring data in the process.

I'm not yet familiar enough with KSP's GameDatabase / ConfigNode to do this in-game. But I can only assume that some form of OnLoad event is provided, hopefully for both .craft and .sfs files, which would allow this procedure to modify the appropriate files at runtime and at the moment before they're actually de-serialized. If it's possible, then this should make the ordering of MODULE{} blocks unimportant, as they'll always be re-ordered to match what KSP expects.

That's basically how the fix works, it's almost done and is in testing.

[NavyFish]

I think I love you...

Heh, if you want a beta tester just shoot me a pm!

[mwlue]

so, that mm patches will apply to saved crafts as well? which will be really great feature if that works.

[swamp_ig]

not exactly - MM will still patch the part definitions (and the other stuff in .cfg files in GameData of course) only it will update the save files for modules so that you can change the order of definition of modules without old saves breaking.

I'm in the process of writing a wiki entry about it

It's very much under construction, but you can keep a watch on it as I go if you want.

[mwlue]

not exactly - MM will still patch the part definitions (and the other stuff in .cfg files in GameData of course) only it will update the save files for modules so that you can change the order of definition of modules without old saves breaking.

I'm in the process of writing a wiki entry about it

It's very much under construction, but you can keep a watch on it as I go if you want.

Arr ok, bookmarked. Thank you.

and managed to get part cloning works (only for the first load, too bad db reload will break it).

[phoenix_ca]

I think I love you...

Heh, if you want a beta tester just shoot me a pm!

I hope this is that thing that you were talking about needing to be fixed for your new DAI update to work. So that there's more awesome. My KSP needs more awesome NavyFish! MOAR!

>.>

Don't look at me like that.