Jump to content

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

sarbian

By sarbian
in KSP1 Mod Releases

 Share

Recommended Posts

android65

android65

Posted
Posted

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.

Link to comment
Share on other sites
Seeker89

Seeker89

Posted
Posted
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.. 

 

Link to comment
Share on other sites
Andem

Andem

Posted
Posted

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?

Link to comment
Share on other sites
sarbian

sarbian

Posted
  • Author
Posted
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 ?

Link to comment
Share on other sites
Styles2304

Styles2304

Posted
Posted (edited)

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 by Styles2304
Link to comment
Share on other sites
Andem

Andem

Posted
Posted
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.

Link to comment
Share on other sites
Warezcrawler

Warezcrawler

Posted
Posted
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.

Link to comment
Share on other sites
Alewx

Alewx

Posted
Posted 
@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.

Link to comment
Share on other sites
Andem

Andem

Posted
Posted
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... :huh:

Link to comment
Share on other sites
Svm420

Svm420

Posted
Posted

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$
}

 

Link to comment
Share on other sites
NecroBones

NecroBones

Posted
Posted

 

@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. :wink: 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.

 

 

Link to comment
Share on other sites
NecroBones

NecroBones

Posted
Posted
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.

Link to comment
Share on other sites
sarbian

sarbian

Posted
  • Author
Posted
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 ...

Link to comment
Share on other sites
NecroBones

NecroBones

Posted
Posted
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.

 

Link to comment
Share on other sites
Jacke

Jacke

Posted
Posted (edited)
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 by Jacke
Link to comment
Share on other sites
nli2work

nli2work

Posted
Posted (edited)

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 by nli2work
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...