nlight

[CKAN plugin] CKAN PartManager v1.2 - Selectively remove parts from mods

Recommended Posts

I've personally tried it on 1.6.6 thru the latest, 1.6.10 it will not work on any of them under Windows 7. Not sure about other OS but at least not here. I've been sticking to 1.6.5 in order to maintain functionality and there's been nothing huge in the CKAN updates that have forced me away from it yet. Just my 2 cents...

Share this post


Link to post
Share on other sites

Looks like this plugin just needed to be recompiled to work with newer versions of CKAN, so I went ahead and did that since this looked like a really neat plugin!

Here's the dll: https://github.com/savagerose/CKAN-plugins/releases/download/1.2.1/PartManagerPlugin-v1.2.1.zip

This is just a recompile of nlight's latest code: https://github.com/AlexanderDzhoganov/CKAN-plugins

I've only done minimal testing so backups are a good idea as always, although it's worked for me so far. :)

Thanks nlight! Let me know if I should take this down or anything at some point.

Share this post


Link to post
Share on other sites

Awesome, thanks for the recompile! - Though I can't seem to activate the plugin after adding it?

EDIT: It messed up when trying to add via "add new" and the .dll was not in "<KSP>/CKAN/Plugins", but after exiting CKAN, removing it from that folder, restarting CKAN, exiting CKAN, manually putting dll in the Plugins folder, and restarting CKAN, it seems to be working.

Edited by curiousepic

Share this post


Link to post
Share on other sites
I wanted to use this to lower RAM usage so I disabled a bunch of parts and then by looking at the folders it seems "removing" them with this plugin simply moves the .cfg files to another place. Looking at the bar when starting the game it would appear it still works the textures and whatnot? Wouldn't it be better to move everything to the cache, or do the things loaded not affect memory footprint?

Can this do what the AutoPruner does (whatever that it is that it does)? The description

Save RAM by pruning files from your KSP installation, and hiding them from the loader.

It modifies parts to where the unique resources do not get loaded, yet preserves them for quick quick restore. Its all cmdline stuff with a plain text config file ( .prnl), which recurses the targets, so perhaps that author (Felger, part of SETI mod team I think) would be interested in integrating with this? I'm not sure of the license but it is on Github here

I'd love to see this!

Share this post


Link to post
Share on other sites
Can this do what the AutoPruner does (whatever that it is that it does)? The description

It modifies parts to where the unique resources do not get loaded, yet preserves them for quick quick restore. Its all cmdline stuff with a plain text config file ( .prnl), which recurses the targets, so perhaps that author (Felger, part of SETI mod team I think) would be interested in integrating with this? I'm not sure of the license but it is on Github here

I'd love to see this!

It very well could, AutoPruner just renames files to a file extension KSP doesn't recognize. This is a way better solution than Autopruner anyway, always thought it'd need to be a CKAN or ModuleManager solution.

Share this post


Link to post
Share on other sites

Hmm. Well if we can hide the .cfg file like this does, and rename the accompanying parts resources files like Autopruner does, then that's probably what is needed. The pruning method saves resources, and the .cfg method reduces the config file processing grinding and loading. Need them both

Share this post


Link to post
Share on other sites

Alternately, just use texture replacer, as it unloads unused game assets. No config file, no references to it in game, the textures get unloaded.

Share this post


Link to post
Share on other sites
Alternately, just use texture replacer, as it unloads unused game assets. No config file, no references to it in game, the textures get unloaded.

I am using that, but I still have a ton of bloat, and the initial load is taking longer and longer. I even managed to run out of memory during the load with the right combo of addons (ony about 40-45 of them total IIRC - Kerbinside, KSIE, both of which have addons to them, FASA and a couple big parts collections IIRC). So I'd rather not load some of these parts in the first place (asctually just a few from the set is all I use in a lot of my stuff - most of those sit unused). Its a shame we cannot keep a reference pair for parts and the resources, make it a lot easier to "delete" unneeded part, resopurce and all before the load grabs it.

Ironic since I have 32GB of ram and an i7 proc, 64bit Win8.1, SLI nvidia cards, etc... so plenty more room than the engine is capable of saturrating. Kinda sad that the limit is in the code, not the hardware (32bit memory space). And I've heard so many bad things about Unity64bit that I'm hesitant to even try it - ultimately that will be what fixes this by allowing the inefficient code more room.

Edited by Murdabenne

Share this post


Link to post
Share on other sites

This plugin might not be working again. I don't see any of my mods listed in "Installed mods that contain parts". Using CKAN v1.6.22

Share this post


Link to post
Share on other sites
This plugin might not be working again. I don't see any of my mods listed in "Installed mods that contain parts". Using CKAN v1.6.22

Not working for me as well, 1.6.23

Share this post


Link to post
Share on other sites
Not working for me as well, 1.6.23

Not working in CKAN 1.8.1. I can see something that says "Installed mods that contain parts" but I can't click on it:

hL3IWmW.png

Also it shows the plugin as dormant. Clicking activate doesn't seem to do anything.

k9O6ExU.png

Share this post


Link to post
Share on other sites

Crashes CKAN (latest release) with:

Missing method CKAN.Registry::Installed() in assembly /home/steve/KSP_linux-1004-CKAN/ckan.exe, referenced in assembly /home/steve/KSP_linux-1004-CKAN/CKAN/Plugins/PartManagerPlugin.dll
System.MissingMethodException: Method not found: 'CKAN.Registry.Installed'.
at PartManagerPlugin.PartManagerUI.PartManagerUI_Load (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0

Share this post


Link to post
Share on other sites

I recompiled against the most recent CKAN and it didn't work, but then I started tinkering with the insides to make it more usable (and work again) and I think I've finally got a version that works the way it should and has some better usability features like multi-select, Space to enable/disable all selected parts at once, and a part viewer window to compare configs.

After reading the comments here, and working on my own GUI based alternative to the console-only pruner app, I had considered trying to find a way that this plugin could rename the parts like the pruner does so that they don't load at all. However, I couldn't think of a method that would work very well. If you try to assume that every part is in its own folder and all the files in that folder pertain to that one part, well, you quickly run into a bunch of cases where that's not true and you'd mess things up. This already doesn't handle mods where multiple parts are defined in one file (bad design that that is anyway).

The ideas for solutions to that issue that I've come up with are either to

  1. Have a set of files for any mod that you want to remove parts for that you create independently of PartManager, and just enable through part manager.
    • Pros - Easy to implement (I've already done most of it), easy to use
    • Cons - Harder to make, requires a lot of external work (though I have made a small app that does most of the work)

[*]Give an advanced option that enables a listing of ALL files in a folder and lets users disable whatever they want that way

  • Pros - Fairly easy to implement, uses the current interface
  • Cons - Looooong list of files for some mods, no clear indication of what is needed by what without some kind of tree view for folders

Share this post


Link to post
Share on other sites
I recompiled against the most recent CKAN and it didn't work, but then I started tinkering with the insides to make it more usable (and work again) and I think I've finally got a version that works the way it should and has some better usability features like multi-select, Space to enable/disable all selected parts at once, and a part viewer window to compare configs.

After reading the comments here, and working on my own GUI based alternative to the console-only pruner app, I had considered trying to find a way that this plugin could rename the parts like the pruner does so that they don't load at all. However, I couldn't think of a method that would work very well. If you try to assume that every part is in its own folder and all the files in that folder pertain to that one part, well, you quickly run into a bunch of cases where that's not true and you'd mess things up. This already doesn't handle mods where multiple parts are defined in one file (bad design that that is anyway).

The ideas for solutions to that issue that I've come up with are either to

  1. Have a set of files for any mod that you want to remove parts for that you create independently of PartManager, and just enable through part manager.
    • Pros - Easy to implement (I've already done most of it), easy to use
    • Cons - Harder to make, requires a lot of external work (though I have made a small app that does most of the work)

[*]Give an advanced option that enables a listing of ALL files in a folder and lets users disable whatever they want that way

  • Pros - Fairly easy to implement, uses the current interface
  • Cons - Looooong list of files for some mods, no clear indication of what is needed by what without some kind of tree view for folders

Something I had considered doing for a while in a new version of the autopruner was using the ModuleManager.ConfigCache to determine what parts were where. From there you can do some inferences to get smart.

If the mesh = model.mu is used, you can get the model from there, and potentially guess the texture name that goes with it.

If the MODEL node is used instead, you have a direct URL to the model, and sometimes the texture file, otherwise you can assume the texture is in the same directory, and are in the same position as before.

Finally, what might be the best solution is something of a game plugin solution. TextureReplacer unloads unused textures in-game. You could look at the source code there, and figure out how to tell which assets go with which parts in-game, and only require that the user launch the game once to populate the "part database" so the CKAN Pruner knows exactly what parts go with what.

In fact, with 64 bit coming out soon (fingers crossed it's as stable as they say it is), that might be the best option. Have a GUI at the main screen, somewhat like KSP AVC that gives you the opportunity to prune parts out of the game's database, it renames the part.cfg and all its constituent assets and tells you to relaunch the game. If you make use of the ModuleManager.ConfigCache, could even implement part filtering, like prune all fuel tanks with liquid fuel that aren't procedural, or something.

Share this post


Link to post
Share on other sites
....

Wow umm, that's way more than I was thinking of doing :P

The pruner system that I had written as a standalone app works great, handles files or folders, and is a single click to disable or reenable all parts from a single mod, select mods, or all mods. I also made a sidealong app that lets you easily drag files or folders into a list to create a file with those paths, which are used by the pruner. It'll prune individual files or entire directories. It has the benefit of being user selective and not trying to guess anything. This would probably be what I'd roll into Part Manager if I were to roll anything in, though not quite sure how to align it with the mod update handling it has now.

I guess my biggest issue with any attempt at having the program guess extra files beyond the config that should be disabled is for mods that used shared textures and models. Guessing the file and removing them (without doing a ton of lookup as you suggest using the MM cache) could cause lots of bugs that would be difficult to track down, frustrating for users, and could lead to bad bug reports to modders, frustrating them as well. If TR does indeed unload unused textures, then I would not even bat an eye at telling people to use it to unload textures for their disabled parts, and there's no reason this plugin should even bother trying. Models are very tiny memory wise compared to textures, so I don't even care if they get loaded.

Your final point about 64-bit is my biggest argument for not even caring about unloading unused textures and models. The RAM usage won't matter anymore as far as ability to play the game is concerned, only startup time will be affected and I'm sure worse than ever with more mods and textures.

I think that what I've done is sufficient to at least allow people to use this plugin again. It does everything it's supposed to do, is slightly more intuitive to use (I think), and most importantly it runs on the newest versions of CKAN. I'll probably commit to my fork and do an alpha build for people to use.

Share this post


Link to post
Share on other sites
Wow umm, that's way more than I was thinking of doing :P

The pruner system that I had written as a standalone app works great, handles files or folders, and is a single click to disable or reenable all parts from a single mod, select mods, or all mods. I also made a sidealong app that lets you easily drag files or folders into a list to create a file with those paths, which are used by the pruner. It'll prune individual files or entire directories. It has the benefit of being user selective and not trying to guess anything. This would probably be what I'd roll into Part Manager if I were to roll anything in, though not quite sure how to align it with the mod update handling it has now.

I guess my biggest issue with any attempt at having the program guess extra files beyond the config that should be disabled is for mods that used shared textures and models. Guessing the file and removing them (without doing a ton of lookup as you suggest using the MM cache) could cause lots of bugs that would be difficult to track down, frustrating for users, and could lead to bad bug reports to modders, frustrating them as well. If TR does indeed unload unused textures, then I would not even bat an eye at telling people to use it to unload textures for their disabled parts, and there's no reason this plugin should even bother trying. Models are very tiny memory wise compared to textures, so I don't even care if they get loaded.

Your final point about 64-bit is my biggest argument for not even caring about unloading unused textures and models. The RAM usage won't matter anymore as far as ability to play the game is concerned, only startup time will be affected and I'm sure worse than ever with more mods and textures.

I think that what I've done is sufficient to at least allow people to use this plugin again. It does everything it's supposed to do, is slightly more intuitive to use (I think), and most importantly it runs on the newest versions of CKAN. I'll probably commit to my fork and do an alpha build for people to use.

Actually, there is a point in favor of removing the model as well as the texture. If you don't remove the model, and your tool misses a part config, then you'll end up with a textureless model in game cluttering up the editor.

I've been procrastinating on the autopruner for a long time, would you consider adding the ability to import prunelists as a "here's what to prune" file? Could even set up a system like how CKAN uses CKAN-Meta as a database. Then this would truly be a replacement for autopruner, and integrated with CKAN no less!

Finally, is it possible to install CKAN plugins via CKAN? If so, that's awesome!

Share this post


Link to post
Share on other sites

I'd love if this could be expanded to do more than just hide parts. I'd love a UI which made it easy to Tweak things like research and part cost, mass and capacity, thrust and fuel use, m/s and heat limits, and research node. It would make balancing the game between multiple part mods easier, as well as make it much easier to make third-party patches to support part pack x with tech tree y.

Share this post


Link to post
Share on other sites

Using the current version of CKAN, this plugin loads, but the "these mods have parts" list is always empty.

I think it's due to the plugin being in the "dormant plugins" list rather than the active list, but clicking activate doesn't actually do anything. What's going on?

Share this post


Link to post
Share on other sites
Using the current version of CKAN, this plugin loads, but the "these mods have parts" list is always empty.

I think it's due to the plugin being in the "dormant plugins" list rather than the active list, but clicking activate doesn't actually do anything. What's going on?

having this happen too. considering I have a few mods that overlap in tech, this working would be nice.

Share this post


Link to post
Share on other sites

OK, went ahead and cleaned up and pushed a release of the plugin as I have it now. I can consider adding a few new things in the future like an editor and stuff, though that's probably beyond the scope of this plugin and into the realm of another plugin.

Unofficial Download: PartManager 1.3

@Prezombie

A part editor would be neat, especially if it respected the part tree, was module aware, and you could batch edit multiple parts at a time between mods, etc. I might look into that for another plugin, because that would save time and be pretty useful. Plus I love the idea of CKAN being a one-stop shop for all my KSP editing needs.

Share this post


Link to post
Share on other sites

Is it just delete/rename cfg's? If so, models and textures will still load in memory i gues. Correct me if i wrong

Edited by vgamble

Share this post


Link to post
Share on other sites

As there's no good way to detect what textures/models are shared between parts, yes, it just moves the .cfg files into another directory, so the textures and meshes would still load I suppose. I think there might be some mods that unload unused assets after launch, but I'm not sure.

I've worked on and I think fixed up a CKAN plugin version of part pruner. Uses the same files in the same locations, just provides a GUI to work with them directly in CKAN, with an easy one click run all button, as well as the ability to make new ones and easily modify old ones in a drag and drop text interface. I need to stop being lazy and upload that.

Share this post


Link to post
Share on other sites
On 5/6/2016 at 5:23 PM, Gribbleshnibit8 said:

As there's no good way to detect what textures/models are shared between parts, yes, it just moves the .cfg files into another directory, so the textures and meshes would still load I suppose. I think there might be some mods that unload unused assets after launch, but I'm not sure.

I've worked on and I think fixed up a CKAN plugin version of part pruner. Uses the same files in the same locations, just provides a GUI to work with them directly in CKAN, with an easy one click run all button, as well as the ability to make new ones and easily modify old ones in a drag and drop text interface. I need to stop being lazy and upload that.

Any news on this? :3

Share this post


Link to post
Share on other sites
On 8/19/2016 at 0:59 AM, DracoSilverpath said:

Any news on this? :3

Yep. I took a while to clean it up a little more, but I think I've finally got it to a releasable point. I just get kind of nervous about releases because as soon as it's out there will be bugs found I've gotta fix :P

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.