I’ve ranted about deferred signal behaviour is you are interested
The new CharacterDestroyBehavior is actually something that should have been done a while ago, and I am all for it. However, deferred signals make very little sense in my eyes, and this very thread is a good example. The solution I’ve given relies on immediate signal behaviour, but not on CharacterDestroyBehaviour, since, with immediate signals, you are able to get your code to run before the character is destroyed
There are things that can be done with immediate signals that cannot be done with deferred signal behavious (or without a workaround), this thread being one of them. Any situation where you need to do something before something is destroyed, or acted upon in general, is a pain with deferred signals. Execution order is important
(though it seems that the solution given by @NinjaFurfante07 is able to clone the Character even after it is destroyed? Dunno if it’s the archivable, that might just be that characters have archivable to false by default, unless that was changed)
This is even worse considering that games have relied on immediate signals since forever, and this will break a lot of unmaintained games. I encountered too many bugs caused by deferred signals for my liking