CreateHashMapObject and performance/memory/lifetime implications of #delete

[sick acorn]

Sry for the ping @valid crane but KJW mentioned you are using this so you might know already

[valid crane]

Would this work
yes (well at least it should)
like especially in performance branch with the optimizations
idk what optimizations have to do with this
Is that a heavy impact on performance or memory?
the hashmap itself, no

tho I don't really any see any point in using a HMO here. in this setup you can clean up after exiting the while
it would be useful in more complex setups, like creating an effect somewhere else, then potentially wanting to remove it in multiple places due to different events

also not sure what would happen if you attempted to do UI cleanup there after mission ends

[sick acorn]

So some basic testing is required, check

As said, the code here just serves being a sample. Actual code will have multiple layers of theese, so having some "disposable" instead of a bunch of functions which have to be called makes the code much simpler

implications of optimizations might release that variable earlier or something like that (as it is no longer used in that scope)

[crimson jolt]

I think the destructor specifically doesn't run at mission end cleanup

[crimson jolt]

nope
Only when the scope is cleaned up when it ends

I didn't test script errors (which would be relevant here if you block user input). But I would assume that it would clean up the scope and run destructors also when script is killed due to error

[sick acorn]

That was also a concern of mine, allowing this to circumvent the "error breaking" stuff

Tho I kinda forgot that event handlers might linger on... Tho then again, mkssionNamespace should not have the variable after end of mission iirc, so any checks in the handlers would, at max, cause script errors