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

[FakelsHub]

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

[FakelsHub]

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

[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.

[NovaRain]

It doesn't work if converting EcCo's hs_barterprice to some gl_z_eccobarter to make it run after your inven filter?

[FakelsHub]

И что?, появится другой скрипт который зарегистрируется после. Я же написал что нужна некая гарантия (пусть даже псевдо), того что скрипт будет выполняться последним.
Когда появится два скрипта которые должны выполнятся последними, тогда и наступит та самая не совместимость между модами о которой вы говорите.

And what?, another script will appear that will register after. I wrote that we need some kind of guarantee (even it’s pseudo) that the script will be executed last.
When two scripts appear that should be executed last, then the same incompatibility between the mods your are talking about will come.

[FakelsHub]

Are you going to bump the major version number?

no.

[NovaRain]

And what?, another script will appear that will register after. I wrote that we need some kind of guarantee (even it’s pseudo) that the script will be executed last.
When two scripts appear that should be executed last, then the same incompatibility between the mods your are talking about will come.

IMO your register_hook_proc_spec doesn't really solve the issue, it simply creates a seperate "race" for procedures registered with the new function. I think there shouldn't be any difference between old register_hook and register_hook_proc (i.e. keep their behavior as before, their order purely based on script filenames, then hs_ script, then register_hook_proc_spec). At least you only get one more "race" with register_hook_proc_spec to deal with, not three for each function as in your current commit.

BTW, why it's called _spec not something like _last? _spec for special?

[FakelsHub]

A new register_hook option is needed to reduce one “big race” based on file names.
Moreover, register_hook is not the same as register_hook_proc, register_hook is essentially an hs_ script with one hook and an arbitrary name, and it is very limited.
I see no problem with the new register_hook, now it takes precedence, just like the hs_ script.
As for me in the sfall code there is a complete mess with registration, nothing is standardized.

[FakelsHub]

_spec for special?

yes, for exceptional situations, I think "spec" hints at it.

[NovaRain]

A new register_hook option is needed to reduce one “big race” based on file names.

But in reality you have already increase the number of races from one (filenames only) to three (filenames for each register_hook* functions). If you keep old behavior for register_hook, at least there will be only two races (new register_hook_proc_spec and old register_hook* functions). And your goal was to need some hook to "run last", which is done by the new register_hook_spec, why not just keep other old ones in their default behavior? I think that's a good compromise for keeping compatibility (existing scripts still work in exactly the same order) while solving your problem (new script with register_hook_proc_spec runs last to avoid certain issues).

For gl_001~004 + hs_* script, before the execution chain was:

• gl_004 (register_hook) -> gl_003 (register_hook_proc) -> gl_002 (register_hook_proc) -> gl_001 (register_hook) -> hs_*

The only race (or order sorting) was depend on the filenames of gl_001~004.

With your commit it becomes:

1. gl_003 (register_hook_proc) -> gl_002 (register_hook_proc) ->
2. gl_004 (register_hook) -> gl_001 (register_hook) ->
3. hs_ script ->
4. gl_005 (register_hook_proc_spec) -> gl_006 (register_hook_proc_spec)

Each register_hook* function has its own sorting to deal with, like the weight class in boxing.

Moreover, register_hook is not the same as register_hook_proc, register_hook is essentially an hs_ script with one hook and an arbitrary name, and it is very limited.
I see no problem with the new register_hook, now it takes precedence, just like the hs_ script.
As for me in the sfall code there is a complete mess with registration, nothing is standardized.

From my POV register_hook is more like a shortcut for register_hook_proc(HOOK_FOO, start) (that works the same as register_hook(HOOK_FOO), so suddenly it becomes "lower" in execution chain?), not the same as hs_* script itself.

_spec for special?

yes, for exceptional situations, I think "spec" hints at it.

For abbreviation like "spec" itself my first impression is "specification" not "special".

[FakelsHub]

I do not see a problem with the new register_hook, show me scripts that depend on the position of the register_hook script, are there any?

With the new register_hook, we can change the position regardless of the script name, this will give the outdated little-used function new features.
I think that the time has come (sfall version) when need to change something in the registration, especially since there is an analogue in the form of register_hook_proc(HOOK_FOO, start) to replace register_hook and not break anything.

Can make the new option of enable a new registration behavior for register_hook if you are so worried about compatibility?
But I repeat that I don’t see a large problem in register_hook change.

[NovaRain]

With the new register_hook, we can change the position regardless of the script name

It's not true, register_hook position is still depend on its script name, just not mixing with scripts using register_hook_proc. Like I said above, you just separate all three of them and now they have their own filename sorting, which does increase the complexity on execution order.

Can make the new option of enable a new registration behavior for register_hook if you are so worried about compatibility?
But I repeat that I don’t see a large problem in register_hook change.

Sure. But I can say the same thing that not seeing any reason changing existing register_hook/_proc, since you already got what you want with register_hook_proc_spec. And for me register_hook isn't "outdated little-used function", modder can choose what he prefers when writing hook scripts (if the script itself is a simple hook, maybe just use register_hook; if there's a need to put several hooks in the same script, use register_hook_proc)

[FakelsHub]

The documentation says it's preferable to use register_hook_proc.
And you yourself said that register_hook(HOOK) == register_hook_proc(HOOK, start)
what is the difficulty of using register_hook_proc instead of register_hook, is it a simple script or not - it makes no difference.

[NovaRain]

OK. I'm still curious if converting EcCo's hs_barterprice to gl_ script and renaming it to run after your inven filter script fixes your issue. (didn't see you answer this)

[FakelsHub]

I'm still curious if converting EcCo's hs_barterprice to gl_

yes, this solves the problem + adding function set_sfall_arg() to it
but it breaks EcCo's since it should be executed after all other scripts.
iI need to change the name to gl_#_filte,, to be sure that no one will register a hook before it, and renaming hs_barterprice to gl_a_barterprice
something like this.

[burner1024]

I may be blind but I couldn't find the explanation of the core problem - what is the conflict between 2 mods?

I keep saying that and there's no response.

I'm not sure if messing with order of hook scripts is useful at all. If one mod breaks another mod because they were loaded in the wrong order - there are 3 solutions:

* Declare them as incompatible

* Modify one of them (or both) to be compatible

* Rename script files to force correct execution order

And that too.

[FakelsHub]

I keep saying that and there's no response.

Давно уже написал, что конфликт в очередности выполнения.

[burner1024]

Давно уже написал, что конфликт в очередности выполнения.

Не знаю как кому-то еще, но мне это ни о чем не говорит. Конкретно-то в чем проблема? Может быть можно переделать, чтобы конфликта не было?