Callback Priority System

[Kutez]

Callback Priority System

Make callbacks don't select a random function to run each time ("in pairs" order is randomized)
Now it's ordered based on when you registered it.

Example:
When you have 2 scripts, "aaa.script" and "zzz.script" register its call back in "on_game_start" function. The "zzz" one will run later, hence register its callback after aaa's. That's mean the order of the callback function would be: aaa first, then zzz.

But what if aaa's callback want to override the changes of zzz's callback?
Then, aaa can re-register its callback again, in a later time, like using TimeEvent or register its callback in the "actor_on_first_update", to put it at a higher priority.

Re-register callback will move the function to the highest priory, without the need to unregister it first.

This changes mainly to solve the clear priority issue in callbacks like on_before_play_hud_sound that require Lua code to return value to the engine. But can be used further to manipulate values in the same callback without the fear of priority.

This info is also in axr_main_patches.script

[Kutez]

I've tried to do it further by allowing modder to see their callback's order and manipulate them, but it can't seem to return the value for some reason.

[themrdemonized]

Here are my thoughts.

1. For now let's not implement "re-registering" of callbacks, it's unknown how it will affect existing mods, the behavior of registering should be exactly the same of vanilla
2. When registering a new callback, vanilla scripts just creates new key and assigns true to it. So I propose Instead of copying the intercepts table in your solution, when registering nee callback, assign a size_table(intercepts[name]) number. That will be a priority number. When removing a callback you get that number and all callbacks with greater than this number will get it decreased by 1. For actually executing the functions you would use spairs iterator which allows for iterating through table in a certain order, in this case it would be by ascending priority number

[Kutez]

Here are my thoughts.

1. For now let's not implement "re-registering" of callbacks, it's unknown how it will affect existing mods, the behavior of registering should be exactly the same of vanilla

This is not really a new feature. In the vanilla script, when you re-register the callbacks, it just do nothing, since it just set the value to the same key again. And if you’re concerned about priority, my point is that we have been using the callbacks with completely random orders each time, and there is no problem with it. I’ve tried keep everything the same but just open new possibilities for new scripts

[Kutez]

2. When registering a new callback, vanilla scripts just creates new key and assigns true to it. So I propose Instead of copying the intercepts table in your solution, when registering nee callback, assign a size_table(intercepts[name]) number. That will be a priority number. When removing a callback you get that number and all callbacks with greater than this number will get it decreased by 1. For actually executing the functions you would use spairs iterator which allows for iterating through table in a certain order, in this case it would be by ascending priority number

I agree on the spairs implementation, definitely going to make the code much cleaner than my implementation. Ok seem like spair doesn't exist, only in some libary. So my code will stay for now. Ok ok, edit again, apparently, spairs does exist in Anomaly lua for some reason, so I will do it
Tho I don't agree with the reduce the number by 1, I have also specifically avoided table.remove because it does the same thing. My reason is I want to keep the priority number the same, because I was planning to expand on the feature by allow you to set/edit/inject your function to a specific priority number, so keeping them as a constant is important. I might do that again (didn't work last time), so probably not. but I don't see any benefit of reduce the number either, it just complicates the code, keeping the priority number to like 1,3,4,5,8,10, isn't really a problem, at least for me, we still can just keep going up, doesn't matter how tall the step.

I will avoid reduce the order by avoid using size_table and instead just create a separate table to handle the next order number will be.

[themrdemonized]

I moved the changes to axr_main.script file since they are rather crucial for script side, patching it like in PR would lead to strange behaviour like you've got with main_menu callback.

[Kutez]

I moved the changes to axr_main.script file since they are rather crucial for script side, patching it like in PR would lead to strange behaviour like you've got with main_menu callback.

I didnt think its allowed for modded exe but ok, thats good