Revenge of the Crafting Leak
Hey Folks! Hope everyone had a good weekend. Rochelle's licensing exam seems to have gone quite well, and we visited friends to boot. So, successful trip!
Unfortunately, my memory leak fixes from last week were lying in wait for my return. And upon playtesting a mere 3 minutes, snapped shut the jaws of null reference.
It seems my memory leak fixes were overly aggressive, and somehow during crafting of broad spears, I end up trying to clone a component that doesn't exist anymore. The frustrating thing is that I can't figure out whether the mistake is destroying the item or trying to clone it. Only one of those things is correct, but neither seems wrong in the context.
I spent almost the whole day adding trace output and poring over the logs to try and peer into what's going on. From what I can tell, there is a section where consumed ingredients are scheduled to be destroyed, and those ingredients' components are also scheduled separately. In theory, this is redundant, as destroying an item destroys the components, too.
However, this results in a null reference as the game tries to clone the components after they've been destroyed. And if I remove them from scheduled destruction, I get no errors, but they're left over in memory when the game ends.
My best guess so far is that the troublesome components are being detached from their parent somewhere in the code, probably after they are scheduled for destruction. So when it comes time to destroy the parent, they are no longer listed as attached to said parent, and get skipped in clean-up.
Of course, that doesn't deal with the problem of them getting cloned later (the thing resulting in a null reference if they're destroyed). Should they be cloned at all? Am I missing some code to remove these unnecessary components from the code that creates the final, cloned output?
I'll need to look into this tomorrow. The one bit of good news is that in the process of debugging, I cleaned up a minor bit of code that created a lot of redundant looped code and log spam. It's a minor victory, but helps both in performance and debugging just a tiny bit.
But that null/component bug, though...not looking forward to grappling with it again. Worst-case, I suppose I could just back-off a bit and let the memory leak a little more to avoid the null ref, and maybe we can live with it. But I'll try one more day, at least.