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

[android65]

Hey you guys. This might be either a really stupid or really common question, but I am currently running a heavily modded RO/RSS 1.05 install and I noticed a lot of the loading time seems to consist of applying the modulemanager patches.

Now, since I don't plan on updating anymore mods due to the new version coming out, I was wondering if there was some way of making the modulemanager patches permanent shortening the loading time?

 

Forgive me in advance if this has been answered before, but this seemed like a straightforward option, yet I could not find mention of it anywhere.

[Seeker89]

2 hours ago, Warezcrawler said:

I don't know what to tell you.....

According to the documentation, and my past experience using MM it should work.

I've created and tested this cfg file, which works just fine. >>miniTEST.cfg<<. It is exactly what we talked about. I tested it against the stock sciencelab. Hope you are using a valid MM plugin. For KSP 1.1.2 it's currently 2.6.24.

Highlights from documentation

@PART[*]:HAS[@MODULE[ModuleEngines]]
{
  ...(stuff)
}

@PART[SomePart] // Edit a PART node named "SomePart".
{
    @mass = 0.625 // change SomePart's mass to 0.625
    @description = SomePart: now uses Xenon! // Changes the value from the "description" item. In this case, a text.

    @MODULE[ModuleEngines] // Edit SomePart's node MODULE named "ModuleEngines"
    {
        @maxThrust = 2.25  // Changes maxThrust to 225

        @PROPELLANT[LiquidFuel] // Edit SomePart's node PROPELLANT named "LiquidFuel"
        {
            @name = XenonGas // Changes the PROPELLANT node name from LiquidFuel to XenonGas.
            @ratio = 1.0 // Changes the ratio value.
        }

        @atmosphereCurve // Edit SomePart's node atmosphereCurve. Note that this node doesn't have a name.
        {
            @key,0 = 0 390 // Edits the FIRST "key" Key from the "atmosphereCurve"
            @key,1 = 1 320 // Edits the SECOND "key" Key from the "atmosphereCurve" property
        }

        !PROPELLANT[Oxidizer] {} // Removes the node PROPELLANT named "Oxidizer" from the PART.
    }

    RESOURCE // Creates a new node RESOURCE in the PART.
    {
        name = ElectricCharge // Adds a name to the node RESOURCE
        amount = 100 // Adds "amount" and its value to this node
        maxAmount = 100 Adds "maxAmount" and its value to this node
    }
}

 

Well that worked. I don't know why it wasn't before working for me... I did have other stuff in that cfg. oh well.. 

Thank you very much.. 

 

[Andem]

Probably (Almost guarunteed) super dumb, but this:

@PART[solarPanels4]
{
@attachRules = 1, 1, 1, 1, 0, 0, 0
@node_stack_right = 0.0855, 0.0, 0.0, 0.0, 0.0, 0.0
@bulkheadProfiles = size1, srf
}

does nothing. can someone get me pointed in the right direction?

[sarbian]

9 hours ago, Alewx said:

I want to edit the attach nodes of the KOMSOS parts so that they are properly useable.
 

@PART[Kosmos_*]:HAS[!~node_stack_bottom[],!~node_stack_top[]]:NEEDS[KOSMOS]:FINAL
{
	%bottom = #$node_stack_bottom$
	@node_stack_bottom = #$../bottom
	@node_stack_bottom[5,] = -1
	
	%top = #$node_stack_top$
	@node_stack_top = #$../top
}

This is my patch to modify the nodes, but I'm not so sure about the index of the bottom node.

Can anyone give me an advice?

The @node_stack_bottom & @node_stack_top are missing a $

 

8 hours ago, android65 said:

Hey you guys. This might be either a really stupid or really common question, but I am currently running a heavily modded RO/RSS 1.05 install and I noticed a lot of the loading time seems to consist of applying the modulemanager patches.

Now, since I don't plan on updating anymore mods due to the new version coming out, I was wondering if there was some way of making the modulemanager patches permanent shortening the loading time?

 

Forgive me in advance if this has been answered before, but this seemed like a straightforward option, yet I could not find mention of it anywhere.

There is a cache, but some mods write cfg file for their config outside their plugindata dir. So that cache gets invalidated and you have to full patch again. I can't do much about it

5 hours ago, Andem said:

Probably (Almost guarunteed) super dumb, but this:

@PART[solarPanels4]
{
@attachRules = 1, 1, 1, 1, 0, 0, 0
@node_stack_right = 0.0855, 0.0, 0.0, 0.0, 0.0, 0.0
@bulkheadProfiles = size1, srf
}

does nothing. can someone get me pointed in the right direction?

What do you mean by "does nothing" ? The part is not changed (I doubt it) ? The result is not what you want ?

[Alewx]

7 minutes ago, sarbian said:

The @node_stack_bottom & @node_stack_top are missing a $

Thanks.

[Styles2304]

So I've been trying to remove the smoke on jet engines...I'm not sure what I'm missing. Here's the condensed version of the part :

PART
{
	name = turboJet

	EFFECTS
	{
		running_dry
		{
			PREFAB_PARTICLE
			{
				prefabName = fx_smokeTrail_light
			}
		}
	}
}

I just want to remove the entire prefab_particle named fx_smokeTrail_light. Can someone show me how to accomplish this? Nothing I try seems to work and this shouldn't be overly difficult. Just need to completely remove it.

I've tried this based on hotrockets cfg that removed stock smoke to no avail

@PART[turboJet]
{
	!fx_smokeTrail_light
}

I've tried this and a variation that says !PREFAB_PARTICLE[fx_smokeTrail_light] = DELETE:

@PART[turboJet]
{
	@EFFECTS
	{
		@running_dry
		{
			!PREFAB_PARTICLE[fx_smokeTrail_light] {}
		}

		@running_wet
		{
			!PREFAB_PARTICLE[fx_smokeTrail_light] {}
		}
	}
}

I feel like I'm dancing all around it but I'm missing something basic.

Edited May 2, 2016 by Styles2304

[Andem]

11 hours ago, sarbian said:

The @node_stack_bottom & @node_stack_top are missing a $

 

There is a cache, but some mods write cfg file for their config outside their plugindata dir. So that cache gets invalidated and you have to full patch again. I can't do much about it

What do you mean by "does nothing" ? The part is not changed (I doubt it) ? The result is not what you want ?

The part is not changed as far as I can tell, no node appears, and I can only attatch it to the surface like the original config.

[Andem]

Double post, sorry.

Edited May 2, 2016 by Andem

[Warezcrawler]

2 minutes ago, Andem said:

The part is not changed as far as I can tell, no node appears, and I can only attatch it to the surface like the original config.

Have you checked the file "ModuleManager.ConfigCache" in your GameData directory after KSP have loaded. This has all parts as they are after MM have processed. Great for checking what actually happende rather than basing it on what you expect of behavior when in KSP.

[Alewx]

@PART[Kosmos_*]:HAS[!~node_stack_bottom[],!~node_stack_top[]]:NEEDS[KOSMOS]:FINAL
{
	%bottom = #$node_stack_bottom$
	@node_stack_bottom$ = #$../bottom
	@node_stack_bottom[5,] = -1
	
	%top = #$node_stack_top$
	@node_stack_top$ = #$../top
}

Seems to not work; I checked the testpart just to make sure It would work at all.

[Andem]

29 minutes ago, Warezcrawler said:

Have you checked the file "ModuleManager.ConfigCache" in your GameData directory after KSP have loaded. This has all parts as they are after MM have processed. Great for checking what actually happende rather than basing it on what you expect of behavior when in KSP.

All right... It does what it should there, but not in game... 

[Svm420]

Would anyone be able to help with a patch? I had this patch in 1.0.5 before MM 2.6.20+ that I used to duplicate the top node of every engine without a second top nod already. Now since the changes to MM the patch just doesn't work. I was wondering how else I can write this simply to get the result I want. Thanks in advance!

@PART[*]:HAS[~node_stack_top2[],@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeA*]]]:FINAL
{
	%node_stack_top2 = #$node_stack_top$
}

 

[sarbian]

Ok there may be a bug there. I ll have a look tonight and hopefully I can fix it before I leave tomorrow...

[NecroBones]

 

@sarbian, I was wondering if I could take a few moments to discuss something relating to ModuleManager. I really don't want to pester you since I know you're busy, but I'm hoping there's something we can do. Let me know if it's not worth the time for now.

 

I've run into a some cases where the "NEEDS" conditionals aren't always reliable, which I mostly see from two main causes:

 

1. MM's cache not picking up new or removed mods (changes to the mod list) right away, which is easily corrected by the user simply by deleting ModuleManager.ConfigCache.
2. CKAN not cleaning up after itself, and either leaving empty mod folders or partially installed/removed mods.

 

For the first case, I was wondering if maybe it might be worth just dumping the cache whenever the list of mod folders changes. I don't know if that's the best solution, but it might be the simplest. I'd rather not keep asking people to delete their cache file every time something goes wrong, to rule that out. For now that works though. (for testing my mods, I've had to script up a deletion of the cache for every KSP start, so that I know I'm getting valid tests)

 

For the second case, this is entirely CKAN's fault, but they consider it a "feature" and not a "bug". Would it be possible to test for the existence of a specific variable in another mod, or in the case of plugins, the existence of only the DLL instead of the folder? I'm thinking there might be several seamless ways to do the latter in particular, such as when a DLL is found, maybe the detected mod list can include both the DLL's base name and the name with "DLL" appended, or something like that (like "Firespitter" and "FirespitterDLL"). Or maybe just additional sigils, like "#" and "~" to indicate a DLL-only NEEDS statement, or something like that?

 

The use-case I'm particularly interested in, is having FuelTanksPlus, ColorCodedCans, and SpaceY be able to reliably detect InterstellarFuelSwitch and/or Firespitter. When the InterstellarFuelSwitch-Core (via CKAN) is installed, it just places the DLL in a folder. But when they remove it, CKAN usually deletes the DLL but leaves the folder behind, and so my mods will often add mesh-switching when the functionality isn't there anymore.

 

 

[Sigma88]

@NecroBones @sarbian

I don't think removing the folder check is a good idea since not all mods have a .dll file (many planet packs don't)

But I think it would be possible to remove from the folder list those folders that do not contain any .cfg or .dll files

[NecroBones]

1 minute ago, Sigma88 said:

@NecroBones @sarbian

I don't think removing the folder check is a good idea since not all mods have a .dll file (many planet packs don't)

But I think it would be possible to remove from the folder list those folders that do not contain any .cfg or .dll files

 

I'm not suggesting removing the folder check, but rather adding a separate syntax for checking for only DLLs, optionally.

[Sigma88]

2 minutes ago, NecroBones said:

 

I'm not suggesting removing the folder check, but rather adding a separate syntax for checking for only DLLs, optionally.

Oh, my fault then

[NecroBones]

Just now, Sigma88 said:

Oh, my fault then

 

No worries!

 

[sarbian]

25 minutes ago, NecroBones said:

For the first case, I was wondering if maybe it might be worth just dumping the cache whenever the list of mod folders changes. I don't know if that's the best solution, but it might be the simplest. I'd rather not keep asking people to delete their cache file every time something goes wrong, to rule that out. For now that works though. (for testing my mods, I've had to script up a deletion of the cache for every KSP start, so that I know I'm getting valid tests)

I added that for dll in 2.6.22 and it was there for cfg already. Currently If a cfg is added/removed/moved/changed or if a dll is added/removed the cache should be invalidated.

 

I could have different test for dll and folder but it would break a lot  of current mods ...

[NecroBones]

Just now, sarbian said:

I added that for dll in 2.6.22 and it was there for cfg already. Currently If a cfg is added/removed/moved/changed or if a dll is added/removed the cache should be invalidated.

 

OK that's good to know! Thanks

 

Quote

I could have different test for dll and folder but it would break a lot  of current mods ...

 

Yeah that's why I was suggesting optional separate syntax for it, or adding additional names to the detected mod list, so that it doesn't interfere with any existing configs.

 

[sarbian]

You typed it while I was replying

Ok, a DLL only check is doable. Poke me next week when I am back from my extended weekend.

[NecroBones]

19 minutes ago, sarbian said:

You typed it while I was replying

Ok, a DLL only check is doable. Poke me next week when I am back from my extended weekend.

 

OK great. Will do. Thanks!

 

 

[Phineas Freak]

@sarbianjust a question (not a request by any means): how difficult would be for MM to implement a functionality so it can load just one user - selected .cfg file? Like the quick cache loading function but for a specific file.

[Jacke]

10 hours ago, NecroBones said:

I've run into a some cases where the "NEEDS" conditionals aren't always reliable, which I mostly see from two main causes:

1. MM's cache not picking up new or removed mods (changes to the mod list) right away, which is easily corrected by the user simply by deleting ModuleManager.ConfigCache.
2. CKAN not cleaning up after itself, and either leaving empty mod folders or partially installed/removed mods.

For the first case, I was wondering if maybe it might be worth just dumping the cache whenever the list of mod folders changes.  ....

For the second case, this is entirely CKAN's fault, but they consider it a "feature" and not a "bug". Would it be possible to test for the existence of a specific variable in another mod, or in the case of plugins, the existence of only the DLL instead of the folder? I'm thinking there might be several seamless ways to do the latter in particular, such as when a DLL is found, maybe the detected mod list can include both the DLL's base name and the name with "DLL" appended, or something like that (like "Firespitter" and "FirespitterDLL"). Or maybe just additional sigils, like "#" and "~" to indicate a DLL-only NEEDS statement, or something like that?

I think CKAN's problems come at least partly from trying to do something like Debian's package system, but without the standards hashed out in the Debian Policy Manual.  Now I realise another facet of that issue: the problem of trying to turn KSP's mod system into a package system without those standard practices, which include having a standard package handling system with dpkg and the apt library, which also allow programs to figure out exactly what state a package is in.  And there's not just 2, installed or removed.

I imagine CKAN doesn't want to remove a mod's directories when it finds files created by the mod, things like plugin data, created configs, and/or log files.  This is equivalent to a Debian's package's "configured" state.  With Debian, when a package in status "installed" is removed and has those config and package related generated files still around, it gets put into "configured" status.  The package can also be purged, which removes those files and any package directories now empty, with the package going back to the "purged" status, which uninstalled packages start at.  Other programs (and sysadmins) can make inquiries to determine what a package's status is, "purged", "configured", or "installed", as well as others that happen in certain circumstances.

So, it comes down to CKAN when removing a mod can leave it in the "configured" state.  While Module Manager, if it sees the directories, it thinks the mod is "installed".  Thus, the conflict.

Edited May 5, 2016 by Jacke

[nli2work]

mediocre question... when MM adds a MODULE{}... is it added at the end of the config after all the other MODULE{}? or at the beginning before all the other MODULE{}?

my config has a number of modules, two depends on two others and references their index. If MODULE{} added by MM is at the beginning, I can adjust the index references accordingly; if MODULE{} is added at the end, then all is well. 

Edited May 5, 2016 by nli2work