Priority of calling the final function of scripts in different collections when the game closes

Questions
#1

There is a main collection that uses a proxy to load another collection. Both collections contain game objects and their attached scripts. Within a collection, the execution order of the init functions is undefined according to the documentation. However, we can be sure that the init function of any script in the main collection will be called sooner than in the dynamically loaded collection. That’s fine so far.
When we close the game, I would expect this behavior to be reversed. So first, the final function of the scripts in the dynamically loaded collection is called in any order. Then, the final function of the scripts in the main collection is called in any order. But that’s not what happens.
It appears that the final functions of the scripts in the dynamically loaded collection are invoked after the final function of the script loading the dynamic collection in the main collection is called. I think in this case, the expected behavior would be to call first the final functions of the scripts in the dynamically loaded collection and then the final function of the loader script in the main collection.

I don’t know if I’m thinking correctly. If the current behavior is correct, it may be worthwhile to explain the operation of the final calls in the documentation. Does anyone have an opinion on this?

Practical example:
My game (on android) crashes on exit, which I only got feedback from the logcat. I use a native extension that I initialize and finalize in the main collection, and in various dynamically loaded collections I call the interface functions of the native extension. For example, the script subscribes to and unsubscribes from various events in the native extension. On exit, however, due to the behavior described above, finalizing the native extension runs earlier than unsubscribing. Of course, this can be prevented with various controls, but in some cases, priority may even be important.

Test case:

image
image1244×644 54 KB

Expected behavior on exit:
DEBUG:SCRIPT: DYNAMIC COLLECTION SCRIPT FINAL Script: 0x0268da96ba70
DEBUG:SCRIPT: DYNAMIC COLLECTION SCRIPT FINAL Script: 0x0268da96bbd0
DEBUG:SCRIPT: MAIN COLLECTION LOADER SCRIPT FINAL Script: 0x0268da96acd0
DEBUG:SCRIPT: MAIN COLLECTION SCRIPT FINAL Script: 0x0268da964dd0
DEBUG:SCRIPT: MAIN COLLECTION SCRIPT FINAL Script: 0x0268da964f30

#2

Can’t you do this in the lifecycle functions of your extension, or does it have to happen from Lua?

I agree that I would probably also expect the reverse order during shutdown. I don’t know the reason why it’s done like it is today. Perhaps @JCash knows?

1 Like
#3

My guess is that it’s just a simple for loop and no thought was put into it.
I agree that a reverse-order deinitialization is pretty logical.
Notable though that this is the first we’ve heard of a problem with it though.

2 Likes
#4

You’re right britzl, I can do it in the lifecycle function in my extension as well. Currently, only initialization returns value for success to lua. I will solve this.

The crash really only drew my attention to how the finalization works. As you mentioned, the behavior I have described is logically correct but may not be a problem. Probably that’s why it hasn’t been mentioned before.

I really only intended the issue to be a call for attention, maybe it might be worth addressing. I can’t judge you alone.

1 Like