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

[sarbian]

@Majiir Yes it's a quick fix but I'd rather spend more time on my current MJ project.

@CAPFlyer I'll spend 100% of the money I get paid for MM to get an ISO 9001 certification. So can we move on more productive thing like having feedback on the current implementation ?

[Starwaster]

Adding "MODULEMANAGER[LOCAL] {}" to a cfg will make MM ignore all node in the same directory and its subdirectory.

Your code weeds out nodes with blank names. Won't it weed out the above?

Or for that matter, won't it also weed out the following?

!MODULE[MechJebCore]{}

[Starwaster]

Happens on all :Final directives

[ModuleManager] Exception while processing node : MyTweaks/radiator_patch/@PART[radiator1]:Final

System.ArgumentOutOfRangeException: Cannot be negative.

Parameter name: length

at System.String.Substring (Int32 startIndex, Int32 length) [0x00000] in <filename unknown>:0

at ModuleManager.ConfigManager.applyPatch (System.Collections.Generic.List`1 excludePaths, Boolean final) [0x00000] in <filename unknown>:0

[sarbian]

No, the exclusion node is dealt in a different part of the code. It should not impact anything else.

I did a quick test with a Final and they work fine. The bug I found is they are processed first instead of last, but it's just a "!" missing in my code...

Can you post the full code of one of the crashing :Final node ?

[a__gun]

If you named each version of module manager to include the version number e.g. ModuleManager_141.dll and kept it in the GameData folder, then the dll would never be overwritten by an older version. Then just run a check when it is run, and delete older versions if the dll.

In any case, I really enjoy the work you have done and are doing on this. So thanks.

This.

Specifically:

Then just run a check when it is run, and delete older versions if the dll.

It will passively keep itself up to date, there will only ever be one dll on disk and only one dll running, and the newest will always be favoured.

[sarbian]

I will not delete anything automatically for 3 reasons :

- a bug could delete something that it should not have

- some user won't like that for the same reason some don't want a DLL to call home for a version check

- on windows you can't delete a DLL while it's loaded, so that would not work

The current version works fine with more than 1 version present. The user can clean up if he feels the need to.

[KerbMav]

What if MM has a bug or gets an important update? Will we have to browse every mods subdirectory to replace the old version with a patched one/newer version?

Why not keep a single copy in gamedata and let MM check if it is the newest version present before it starts its work? As 1.4+ will have its version number in the filename, it will not be overwritten by older versions.

[Garek]

You should probably update the op about the current state (MM in GameData, folders excluded by cfg-node), otherwise you will here the same arguments again and again, because too many people don't actually read every post in a thread before responding.

[sarbian]

I'll do it in the weekend once I squashed the last bugs and had replies by the dev who had problem with the old design.

[KerbMav]

because too many people don't actually read every post in a thread before responding.

And I see no reason why. The OP was edited the last time on 03.11.

Reading the thread backwards to ignore old information lead to me enduring OT heat about how and not much about what was done.

[sarbian]

Can we have 1 page in this thread without drama ? Thanks

[Starwaster]

No, the exclusion node is dealt in a different part of the code. It should not impact anything else.

I did a quick test with a Final and they work fine. The bug I found is they are processed first instead of last, but it's just a "!" missing in my code...

Can you post the full code of one of the crashing :Final node ?

This is the file that resulted in the sample error I posted.

@PART[radiator1]:Final
{
	@mass = 0.025 
	MODULE
	{
		name = ModuleHeatPump
		heatTransfer = 50
		heatDissipation = 0.05
		RESOURCE
		{
			name = ElectricCharge
			rate = 0.01666667
		}      
	}
}

[sarbian]

Ok, fixed. That was one stupid bug on my ends...

Uploaded, same name as before ( http://www.sarbian.com/sarbian/ModuleManager_1_5.dll )

[Starwaster]

Has anyone been able to get reloading to work?

I tried it and no MM patches were reloaded at all.

[sarbian]

I looked into it and saw an other copy/paste fail on my end. After I fixed I saw that the second reload made things go strange (it seems it apply the patch before all the part are loaded).

So for now I removed the reload part and uploaded it again. I'll work on it more later since it's not the more important feature (but I agree it's really useful for writing new patch file)

[johnsonwax]

I had asked this question of the original MM author I believe after he stopped development, but I'll ask again in hopes of getting a different answer, but it is possible to disable or unload a part? For example, if I only want a subset of parts from one of the large part mods it would be very convenient to have a cfg file in the mod folder that listed everything I didn't want loaded and unload or disable them. I really only need so many fairing sets and 1.25m fuel tanks...

The previous answer was that parts are loaded first, then cfgs, then the parts were built, so the assets were already loaded by the time MM ran. There was also the (reasonable) observation that if there was a way to unload assets that someone would have come out with a mod that would just unload anything from your persistent.sfs file once you were in flight. That was hardly a definitive statement though, and it was back in .20 or so, so perhaps things have changed.

[Morgan]

but it is possible to disable or unload a part?

try "Catergory = -1", that should work

[NathanKell]

johnsonwax: the issue is not being able to unload parts. The issue is being able to unload _assets_. KSP loads assests independently of all confignode-specified data; a TGA file in GameData will be loaded irrespective of whether it's ever referenced by the game or not.

So even if you could get MM to unload gameobjects (which you can't, because they're not loaded at the time MM runs), it still wouldn't unload the assets involved. And presumably you want the ability to unload parts because you want to save RAM?

UniverseReplacer does try to unload assets (the old texture, when it's replaced by a new one); someone should do a check to see if that's really happening over time, as I don't trust KSP garbage collection.

[sarbian]

NathanKell replied perfectly, and I won't go there anyway.

NathanKell does the current version looks OK to you ? I think I'll do the release tomorrow.

[johnsonwax]

johnsonwax: the issue is not being able to unload parts. The issue is being able to unload _assets_.

Thank you. That's effectively what the previous answer was. So, no solution to reducing RAM usage, but Morgan's suggestion for Category = -1 sounds promising for just simplifying organization, which is still useful.

Thanks all.

[NathanKell]

It looks very good indeed--thank you so much for being so flexible with all of us!

johnsonwax: You can always just zip up the parts you don't want and then delete the originals. KSP won't load zips, but you can extract inplace when desired.

[johnsonwax]

johnsonwax: You can always just zip up the parts you don't want and then delete the originals. KSP won't load zips, but you can extract inplace when desired.

Yeah, the problem is when I update a module - the new versions go in next to the zipped ones and then I need to go through and re-zip everything one-by-one. I'm looking for a way to have a config file, either global or per module, and simply list out the parts of the module I don't want. I may just have to write a script that can read a MM-like file and do the zipping.

[kaldak]

I've been reading through the documentation while doing some tinkering. It instructs me to use ":Final" if I'm just tweaking other mods (which I am), but I couldn't find any explanation of what this actually does. Is it simply executing ":Final" commands after all the non-final ones?

Thanks!

[sarbian]

Yes, nothing fancy

[Starwaster]

I've been reading through the documentation while doing some tinkering. It instructs me to use ":Final" if I'm just tweaking other mods (which I am), but I couldn't find any explanation of what this actually does. Is it simply executing ":Final" commands after all the non-final ones?

Thanks!

Node processing is done in two passes

First is anything that isnt :Final

Second pass is :Final

More important however than what is why.

The answer is that you do this as a safeguard against your desired changes being undone by another patch node. If it's executed in pass #1 then you append :Final on yours and it will overlay your changes on that one.