Приоритет для hs_* скриптов.

[FakelsHub]

Изменить порядок выполнения для hs скриптов, так чтобы они выполнялись перед подписанными обработчиками в gl скриптах.

[FakelsHub]

Так же добавить функцию позволяющей задать приоритет выполнения hook обработчика для register_hook_proc функции относительно других обработчиков, при этом register_hook должен всегда иметь наивысший приориет, но не выше чем у hs_ скрипта..

[FakelsHub]

(После реализации добавить описание порядока выполнения скриптов в документацию sfall.)

[NovaRain]

Oh, I thought hs_ always has higher priority than global script.
I tried running a hs_tohit and a gl0tohit (both just print msg) and gl is executed before hs_. I think that means hs_ can override the result in gl?

[FakelsHub]

Сейчас выполняется все в обратном порядке (метод LIFO), т.е первый добавленный обработчик выполняется последним, ( самым первым добавляемым скриптом является hs_ скрипты.) Тогда получается, что обработчик в hs_ скрипте является последним головным обработчиком куда стекаются все изменения произведенные в gl обработчиках, в принципе это логично сделано, и тогда менять ничего не нужно.

!!! Но сейчас имеется не разрешаемый конфликт скриптов hs_barterprice из ECCO и gl_ обработчика в скрипте фильтра. Т.е. при такой конфигурации скрипт из Ecco должен всегда выполняться первым, а затем уже обработчики из gl скриптов.

[FakelsHub]

Oh, I thought hs_ always has higher priority than global script.
I tried running a hs_tohit and a gl0tohit (both just print msg) and gl is executed before hs_. I think that means hs_ can override the result in gl?

yes, that’s what it was intended to be.

[FakelsHub]

Хм. Тогда получается, что нужна дополнительная функция позволяющаяя зарегистрировать скрипт после hs_ скриптом, (т.е. в программном смысле поместить скрипт в начало вектора).

Hm. Then it turns out that an additional function is needed that allows you to register the script before the hs_ script (i.e., in the programmatic sense, put the script at the beginning of the vector).

[FakelsHub]

Нужно ли изменять поведение для register_hook так, что бы зарегистрировать скрипт непосредственно перед hs_ скрипта? или же это оставить как есть.

Do I need to change the behavior for register_hook so that I register the script immediately after the hs_ script? or leave it as is.

[NovaRain]

Нужно ли изменять поведение для register_hook так, что бы зарегистрировать скрипт непосредственно после hs_ скрипта? или же это оставить как есть.

Do I need to change the behavior for register_hook so that I register the script immediately after the hs_ script? or leave it as is.

I'm not sure what's the current order of execution for the same hook. Is it:
register_hook in global script (because of start proc) -> register_hook_proc in global script -> hs_* script (executed at the last, highest priority)

The global scripts themselves are executed by filename order, at least for two global scripts gl_0000 and gl_0001 the 0000 runs first.

[FakelsHub]

The execution order of the register_hook_proc handlers and register_hook is carried out according to the LIFO principle. The last registered is executed first.

[FakelsHub]

Gl_01 - register_hook_proc
Gl_02 - register_hook
Gl_03 - register_hook_proc
Order chain in game:
execute Gl_01 -> hook trigger -> run hook_proc gl_03 -> hook gl_02 -> hook_proc gl_01-> hs_hook -> (execute GL_02) -> execute Gl_03
To:
-> hook trigger -> run hook_proc gl_03 -> hook_proc gl_01-> hook gl_02 -> hs_hook ->

[NovaRain]

Uh, now my head hurts... Let's see if I understand the example correctly:
When the game starts, sfall should first check and register hs_blah.int in the chain.
Then it runs through all global scripts and registers register_hook:

• Run gl_02's start, register the script in the chain.

Then it registers register_hook_proc, following the filename order:

• Run gl_01's start, register its hook_proc in the chain.
• Run gl_03's start, register its hook_proc in the chain.

Since the chain itself follows LIFO (stack) principle, when HOOK_BLAH is triggered, sfall runs:

1. gl_03 hook_proc
2. gl_01 hook_proc
3. gl_02 (start)
4. hs_blah.int (last, can override the result from all above)

EDIT: OK, I made four test scripts like the example. The current order of execution in game is:
gl_0003 hook_test -> gl_0002 -> gl_0001 hook_test -> hs_tohit
for both 4.x and 3.8.
hook_order_test.zip

[FakelsHub]

Changes to the start of scripts will not be affected.

    Run gl_01's start, register its hook_proc in the chain.
Run gl_02's start, register the script in the chain.
    Run gl_03's start, register its hook_proc in the chain.

We get it as you wrote.

    gl_03 hook_proc
    gl_01 hook_proc
    gl_02 (start)
    hs_blah.int (last, can override the result from all above)

[NovaRain]

We get it as you wrote.

Do you mean you got a different result in the current build (my test scripts should be the same as your example right?), or you're proposing to change the order like in your example above?

[FakelsHub]

It is how I suggest changing.

Current: gl_0003 hook_test -> gl_0002 -> gl_0001 hook_test -> hs_tohit

[FakelsHub]

But then if don't make many changes in the sfall code for register_hook, the principle will change from LIFO to FIFO

gl_01 - register_hook_proc
gl_02 - register_hook
gl_03 - register_hook_proc
gl_04 - register_hook

Run:
1.   gl_03 hook_proc
2.   gl_01 hook_proc
3.   gl_02 (start)
4.   gl_04 (start)
5.   hs_blah.int (last, can override the result from all above)

So I think it's worth changing it.