sarbian

[1.3.0] Module Manager 2.8.0 (May 26th 2017) - Better late than never

5125 posts in this topic

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

1 person likes this

Share this post


Link to post
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]{}

Share this post


Link to post
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

Share this post


Link to post
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 ?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

1 person likes this

Share this post


Link to post
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
}
}
}

Share this post


Link to post
Share on other sites

Has anyone been able to get reloading to work?

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

Share this post


Link to post
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)

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
but it is possible to disable or unload a part?

try "Catergory = -1", that should work

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

Share this post


Link to post
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!

Share this post


Link to post
Share on other sites

Yes, nothing fancy :)

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now