Jump to content

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


sarbian

Recommended Posts

@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 ?

Link to comment
Share on other sites

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]{}

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

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.

×
×
  • Create New...