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

[sarbian]

A cache for MM is not as trivial as it seems. Some operations (part delete or copy) make it a bit harder. And there is the whole matter of being sure the cache is up to date.

But there is already a function to dump the whole config (which help for the debugging point) so I could just drop the whole KSP config and rebuild it from that. I just have to manage the cache obsolescence... I'll have a look at how long it takes to create a check-sum of all the KSP loaded cfg and if it's fast enough I could use that.

[Starwaster]

And there's also the matter of reloading models, textures and recompiling parts. Even 4000 patches is a comparatively small part of that. (MM can apply multiple patches to multiple parts in less time than it takes to process one part)

(Edit: That doesn't mean it wouldn't be worthwhile to pursue caching. Every little bit helps I suppose)

[sarbian]

Ok, let's try this.

Dragon01 can you try this MM version : https://www.sarbian.com/sarbian/ModuleManager.2.5.2.dll

=>This is a test version. Backup your save before trying it<=

It seems to work fine for me, but I did not do much test to be sure all the patch are applied and nothing fail.

Launch once. Close KSP. Open KSP.log and look for the "[ModuleManager] Ran in" line. Paste it in the thread

Launch again. Close KSP. Open KSP.log and find the following block and paste it in the thread

[LOG 23:09:24.502] [ModuleManager] SHA generated in 0.114s
[LOG 23:09:24.503] [ModuleManager]       SHA = CD-D0-13-15-D3-ED-3A-6E-A3-12-EA-6D-4F-90-E2-53-B7-A9-90-4B-B7-58-0C-62-17-49-63-BB-ED-53-73-BB
[LOG 23:09:24.504] [ModuleManager] Cache SHA = CD-D0-13-15-D3-ED-3A-6E-A3-12-EA-6D-4F-90-E2-53-B7-A9-90-4B-B7-58-0C-62-17-49-63-BB-ED-53-73-BB
[LOG 23:09:24.505] [ModuleManager] useCache = True
[LOG 23:09:24.505] [ModuleManager] Loading from Cache
[LOG 23:09:24.764] [ModuleManager] Cache Loaded
[LOG 23:09:24.764] [ModuleManager] Ran in 0.377s

If other want to try feel free to.

DO NOT PACKAGE THIS VERSION IN A MOD.

[Black-Talon]

Ok, let's try this.

Launch once. Close KSP. Open KSP.log and look for the "[ModuleManager] Ran in" line. Paste it in the thread

Launch again. Close KSP. Open KSP.log and find the following block and paste it in the thread

The potential was exciting so I gave it a try -

[LOG 23:15:14.757] [ModuleManager] ModuleManager: 861 patches applied
[LOG 23:15:14.763] [ModuleManager] Ran in 24.166s

[LOG 23:23:37.736] [ModuleManager] SHA generated in 0.105s
[LOG 23:23:37.736] [ModuleManager]       SHA = AC-A3-5F-CF-43-2E-CF-7D-5E-3D-23-4D-64-FD-66-C5-42-27-2F-4B-B5-79-18-53-30-3D-04-F3-46-C5-C0-DA
[LOG 23:23:37.737] [ModuleManager] Cache SHA = 66-60-34-22-74-67-D3-84-EE-A7-39-0D-0F-92-67-63-75-3F-9D-00-7B-B3-1C-C2-63-93-1B-87-9F-3C-C6-78
[LOG 23:23:37.737] [ModuleManager] useCache = False
...
[LOG 23:24:02.206] [ModuleManager] Ran in 24.578s

...strange, so I ran it again...

[LOG 23:29:45.367] [ModuleManager] SHA generated in 0.086s
[LOG 23:29:45.367] [ModuleManager]       SHA = AC-A3-5F-CF-43-2E-CF-7D-5E-3D-23-4D-64-FD-66-C5-42-27-2F-4B-B5-79-18-53-30-3D-04-F3-46-C5-C0-DA
[LOG 23:29:45.368] [ModuleManager] Cache SHA = AC-A3-5F-CF-43-2E-CF-7D-5E-3D-23-4D-64-FD-66-C5-42-27-2F-4B-B5-79-18-53-30-3D-04-F3-46-C5-C0-DA
[LOG 23:29:45.369] [ModuleManager] useCache = True
[LOG 23:29:45.369] [ModuleManager] Loading from Cache
[LOG 23:29:45.808] [ModuleManager] Cache Loaded
[LOG 23:29:45.808] [ModuleManager] Ran in 0.529s

Success! But not as I'm locked up here: http://screencast.com/t/alC5MrOiU

Dunno - happy to investigate further but that's the results thus far.

[LitaAlto]

A minor usage question--maybe I'm overlooking something but I can't get this to work:

@PART[foo*bar]{
	RESOURCE
	{
		name = Foobar
		amount = 100
		maxAmount = 100
	}
}


@PART[fooXbar]
{
	!RESOURCE[Foobar]
}

This is intended to add a resource to parts whose names start with "foo" and end with "bar", but then go back and remove the resource I just added to the part fooXbar.

It... doesn't remove anything.

Is there a gotcha, or a silly mistake, I'm missing?

[Mecripp]

Shouldn't your FooXbar look like

@PART[fooXbar]

{

!RESOURCE[Foobar] {}

}

Edited December 4, 2014 by Mecripp2

[Starwaster]

The potential was exciting so I gave it a try -

<load time texts snipped!>

Success! But not as I'm locked up here: http://screencast.com/t/alC5MrOiU

Dunno - happy to investigate further but that's the results thus far.

Well those load times do look promising, more than I'd have expected.

You should post your output_log.txt for the load where it crashed. (if you don't still have it, repro and then post the log. Not KSP.log this time because output_log.txt has more information for errors)

If you haven't posted a log before, upload it first to somewhere like dropbox and then post a link to it.

I might give it a try myself when I can grab the time to

And

@MeCripp / LitaAlto : Yes, that's exactly it. The config is missing the {}

[sarbian]

I found a couple of bug in the cache version I posted. One was a simple mistake on my part but the other look like a more complex issue and I'll have to dump the whole config DB to compare it.

I also did a "quick" test with a large RDD/RO config (5k3 patch) and the cache loads under 1s too. I just hope I can fix the bug so we can use it ...

[LitaAlto]

Shouldn't your FooXbar look like....

I dunno, should it?

Seriously, sarbian's example doesn't show empty curly braces after the name of the RESOURCE I'm deleting. I can certainly try that though.

@MeCripp / LitaAlto : Yes, that's exactly it. The config is missing the {}

Can we better document that requirement then? As I mentioned the example I was going by doesn't use them.

Thanks for the pointer, very appreciated!

Edited December 4, 2014 by LitaAlto

[undercoveryankee]

I dunno, should it?

Seriously, sarbian's example doesn't show empty curly braces after the name of the RESOURCE I'm deleting. I can certainly try that though.

Can we better document that requirement then? As I mentioned the example I was going by doesn't use them.

Thanks for the pointer, very appreciated!

MM doesn't know that the thing you want to delete is a node unless you use the curly braces. The example in post #2 is inconsistent with the text "!NODE[foo] {} deletes node foo completely." farther down the same post. Looks like the example needs to be revised when someone gets a chance.

[sarbian]

And it's fixed.*

[LitaAlto]

MM doesn't know that the thing you want to delete is a node unless you use the curly braces. The example in post #2 is inconsistent with the text "!NODE[foo] {} deletes node foo completely." farther down the same post. Looks like the example needs to be revised when someone gets a chance.

And it's fixed.*

Thank you both! Admittedly I rely too much on samples and not enough on a careful reading of text. :/

[Starwaster]

And it's fixed.*

Link? (10 chars)

[undercoveryankee]

Link? (10 chars)

Post #2 of this thread.

[FreeThinker]

Hello, I'm trying to create my first MM files to tweak some engines ElectricCharge but I haven't been successful with the following code:

@PART[ionEngine]:Final
{
    @MODULE[ModuleEngines]
    {
        @PROPELLANT[ElectricCharge]
        {
            @ratio = 10.56
        }
    }
}

@PART[ionArgon-0625]:Final
{
    @MODULE[ModuleEngines]
    {
        @PROPELLANT[ElectricCharge]
        {
            @ratio = 2.15
        }
    }
}

@PART[ionArgon-0625-2]:Final
{
    @MODULE[ModuleEngines]
    {
        @PROPELLANT[ElectricCharge]
        {
            @ratio = 5.3
        }
    }
}

@PART[ionArgon-125]:Final
{
    @MODULE[ModuleEngines]
    {
        @PROPELLANT[ElectricCharge]
        {
            @ratio = 5.15
        }
    }
}

What am I doing wrong?

Edited December 4, 2014 by FreeThinker

[BudgetHedgehog]

What am I doing wrong?

NearFuture? There's no module called ModuleEngines in those engines, they use ModuleEnginesFX instead.

[sarbian]

it looks OK. You are sure nothing else might convert the ModuleEngines to ModuleEnginesFX ?

So I found my bug with the cache implementation. So here is 2.5.2 with a new integrated patch caching.

As long as .cfg in your GamaData don't change then the launch following the first one will be faster. If there is any .cfg change then the cache is ignored, the patch done and a new cache id built. (cfg in PluginData subdirs are ignored of course)

On a RSS/RO install with 5300 patch it loads the cache in 0.8s on my PC. Stuff may be slower for HDD, so feel free to share the few timer I added in the log ( "SHA generated in 0.078s" & "[ModuleManager] Ran in 0.229s")

I m not editing the first post yet, but so far I did not find any bugs. Wait for a couple of days to package it in mods however, you never know

https://ksp.sarbian.com/jenkins/job/ModuleManager/65/artifact/ModuleManager.2.5.2.dll

Edited December 4, 2014 by sarbian

[FreeThinker]

NearFuture? There's no module called ModuleEngines in those engines, they use ModuleEnginesFX instead.

Thanks, that must be it

[ctbram]

Is there a link to the dev page? I just saw version 2.5.2 someplace but I cannot find it anywhere.

[sarbian]

Let me teach you about a cool keyboard shortcut : Ctrl-F.

It's an amazing tool that help you see that the version you search is mentioned 2 post higher with an explanation on why it's not in the first post.

[undercoveryankee]

I'm trying to do math on a part using values from a RESOURCE_DEFINITION:

@PART[AntimatterTank*]:AFTER[WarpPlugin] {
    costOfResources = #$/RESOURCE[Antimatter]/maxAmount$
    @costOfResources *= #$@RESOURCE_DEFINITION[Antimatter]/unitCost$
    @cost += #$costOfResources$
    !costOfResources = null
}

These parts have cost in the config files set to the intended empty cost. The patch is supposed to add the cost of the maximum amount of Antimatter.

The log message is:

[ModuleManager] Cannot parse variable search when editing key costOfResources = #$@RESOURCE_DEFINITION[Antimatter]/unitCost$

Is there some syntax error I'm missing, or are RESOURCE_DEFINITION nodes not accessible while patching a part?

Edited December 6, 2014 by undercoveryankee

[johnsonwax]

So, a problem many of us face is that we hit memory limits on parts under 32bit. Until that whole 64bit mess is sorted out, many of us have to resort to selectively removing parts from mods, which is a pain when it comes to updating modules.

Would it be possible to specify in MM that a part should not load at all? Or, that a part should be unloaded, since I believe MM runs after parts are loaded. In my case, I can get the parts loaded, but once I start playing I run over on RAM, so even just unloading those parts and textures would help. Doing this via MM would make it sustainable - I could just have a master unload file that I update and not have to worry about parts being re-added when I update.

[NathanKell]

johnsonwax: Nope, not possible. KSP loads all textures *before* MM processes cfgs. Textures are just textures, and they are all loaded, whether or not any models use them (let alone whether any parts use said models and textures).

[johnsonwax]

Shame. That'd be damn handy. Thanks.

[FreeThinker]

Question, I'm looking for a way to modify TECHNOLOGY_TREE_DEFINITION files. Since it has basicly the same structure as Part files, shouldn't Module Manager be able to modify these files as well?