It's a fair question. I've been running Mighty Magick for some time, and in my current game, which I've played for several months, Wrye lists 21 nul ref objects. I don't know if that's good or bad, but it doesn't sound especially terrifying. That said, I could be wrong; and if I am, I could switch to LAME. I just prefer the amount of offensive damage done with spells in MM, that makes magical attacks dangerous but not over the top (according to my standards) as in MM:R.

So the issue for me is: are there tolerable limits to save game bloat? Or is bloat in and of itself intolerable, since it will eventually multiple and ravage life and everything about it we care for?

It depends upon the circumstances that cause the bloat to increase. Generally, bloat that occurs on something that you cannot place a reasonable upper bound on for a very long play time character is unacceptable. Per-time-you-cast-a-spell is not acceptable. Per-cell-transition is not acceptable. Per-game-day is not acceptable. Per-enemy-who-runs-away is not acceptable. On the other hand, bloat that occurs a more limited number of times on the same character is acceptable. Per-level-up is generally fine, per-uninstall-and-reinstall is generally fine, etc.

My mod Super Hotkeys creates bloat if you repeatedly uninstall it and reinstall it. Do that 100 times and some menus might slow down noticeably.

So if I follow you, the fact that bloat appears relatively limited(?) in my current game indicates it derives from some function (in the non-technical sense) not frequently employed by Mighty Magick?

Who knows? I was speaking of the acceptable bloat from a mod authors perspective. From a save game, you can't tell about that perspective.

I guess what you're asking is, should you worry about 21 nul ref objects? And my guess is no. I'm guessing that a nul ref object is a cloned form with no references... if so, 21 of those is nothing to worry about, all they do is increase your saved game size, pollute your formid hashtable a tiny bit. The saved game size increase for that should be a few kilobytes, nothing to worry about, and the hashtable pollution from that should be less than 0.1% of what it holds for a new character in a vanilla game. Or that's my understanding.

I've never understand save game file size.. mine fluctuates on the down and up but progressively increases..One file says 3,772 and the next will say 3,665, and then a new save will say 3,881. With no bloating found.

I think the fluctuating size relates to respawn. Somethings will be held in the save game, until the areas those references are in, resets. Then, that data is no longer required, and is flushed from the save.

My guess would be cell resets. When a cell is reset, all the stuff that gets reset doesn't have to be saved anymore.

As an addendum to that, items placed by the "PlaceAtMe" command become permanent references in the savegame and cannot be removed. Mods such as the "Ancient Towers" uses this command heavily, especially in the training area.

As far as cell resets go I thought the understanding was that it does not reset until you revisit the cell, hence there is no purging of information until new information is loaded - which then replaces what is purged.

Meaning that what makes the save game file grow is how much you have explored, not respawn timer limits.

I wish there was a list of known PlaceAtMe using mods so us mod browsers can avoid them. I didn't know that about Ancient Towers - a mod I was planing to add.

21 NULL ref items is probably nothing to worry about. I just cleaned 42 of them off of a test save. Those are usually caused by unloading mods from your game that left dangly bits of data behind.

Actual bloating is much more insidious and you'd be seeing save sizes much larger than what you have. Something like what old versions of Real Lights will do if you leave it installed too long. It relied heavily on PlaceAtMe calls, and worse still, used those on vanilla forms. That sort of bloat can never be removed because vanilla forms can't ever be expunged from your game.

The bloat removal feature in Bash must have some sort of threshold on it because there is a documented case for dev_akm having a save lose many megabytes of junk and work fine afterward, but when I tried to unbloat saves that got contaminated by an old Real Lights, it did nothing despite my knowing there were refs in need of removal.

I've just had an instance of finding a few objects from a mod, then deciding I didn't like the results. (Over-the-top giveaways.) I discarded the items in an outside cell, went inside, and saved. Then after quitting, I removed the mod. Those objects still showed up as null refs under bloat. Tried going back and disabling them via the console, instead. No difference.

If I want to remove a mod with items that I've previously collected, how I can do so without getting null refs? I've got Wrye Bash, if that helps.

Have you tried waiting for a cell respawn, ie. putting them in an unsafe container, and waiting for them to disappear before deactivating?

No, I never tried that. But wouldn't it achieve the same result as disabling?

AFAIK disabling doesn't remove objects, just prevents their use for anything, which would be the difference with deleting objects, which does remove them. The disabled objects are still 'there' in the game, they just can't be interacted with. I'm not really sure.

I think the crux is that they're in a place that'll get reset on cell respawn, so their reference will get removed from the savegame, as they no longer exist according to the game. I'm not sure, but based on what I know from losing items to unsafe containers, it should work. :shrug:

Disabled items definitely still exist. The Ghostly Apparitions in MMM used to continue screaming after they had both disabled and destroyed themselves.

Cobl adds a "garbage can" that you can buy from vendors. As far as I know, if you dump your trash in there it gets cleaned up properly by the game.

A trash can I can add to my house mod...? Sounds good. Didn't realize COBL included that, but I can't say I've been looking, either. I'll definitely give that a try.

Thanks to both of you!