Fix ScriptHook_t initialization order

[z33ky]

When a ScriptClassDesc_t for is initialized (SCRIPTDESC), it recursively invokes its parents initializers in order to obtain their pHelper member.
Initialization is only done once, so repeated initialization is skipped. Initialization includes assignment of a vector of ScriptHook_t's (DEFINE_SCRIPTFUNC/BEGIN_SCRIPTHOOK), which must be initialized beforehand.
Both of these use (static) globals; Within a translation unit, initialization order is defined to be the same as the order of declaration. So within a translation unit we must define all ScriptHook_t's before the ScriptClassDesc_t using them. A problem occurs with the parent initialization though, since there is no defined order between translation units, meaning initialization of a ScriptClassDesc_t can happen before its ScriptHook_t's, despite being the correct order within its translation unit.

On MSVC it seems this issue is benign. On GCC/Linux however the initialization of a ScriptHook_t essentially cleared whatever happened during the initialization of the ScriptClassDesc_t, meaning many hooks simply didn't work.

This situation is remedied by delaying the initialization of the ScriptClassDesc_t's ScriptHook_t vector to only when the constructor of it is invoked from its translation unit. This is accomplished simply by adding a boolean parameter to the function (GetScriptDesc()) that is true in the global constructor invocation, and false by default (including when doing parent ScriptClassDesc_t initialization). When false, a valid ScriptClassDesc_t pointer is still returned, with the proper value for pHelper, which is all that is needed for the initialization of the child ScriptClassDesc_t. The value of the returned pointer is a fixed memory location, and does not change due to the delayed initialization.

Fixes#244.

---

Does this PR close any issues?

• [CODE] Script hook parameter reset #244

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[samisalreadytaken]

This breaks instance helper fallback assignment in BEGIN_SCRIPTDESC_NAMED for some classes. In MSVC, CBaseAnimating (baseanimating.cpp) won't be assigned a helper.

Test ToString in game with

printl( Entities.CreateByClassname("prop_dynamic") )

It should print ([0] prop_dynamic), but it prints (CBaseAnimating : 0x00)

[z33ky]

Hm yeah, I mistook this loop to initialize pHelper completely, but it's actually done through DEFINE_SCRIPT_INSTANCE_HELPER(). It is thus part of the delayed initialization and the loop won't find the proper helper instance.

One solution, which breaks compatibility with upstream vscript though, would be to include the helper as argument to BEGIN_SCRIPTDESC_NAMED(), so it can be initialized eagerly. A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros, which are the actual ones that must be delayed. We can rely on the optimizer to eliminate the redundant checks for !init. For this to work though, DEFINE_SCRIPT_INSTANCE_HELPER()must be called before the script-hook definitions, lest it silently breaks the helper.
I've gone with the first one for now, since there are relatively few script definitions that define a helper.

[samisalreadytaken]

A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros

I don't think this would be bad. There could even be something like BEGIN_SCRIPTHOOK_DEFINITIONS to indicate the definition section, or just put a note saying hooks should be defined last. Changing script hooks might be preferable over diverging from upstream. I personally don't have a strong preference of one over the other though.

[Blixibon]

I think that compatibility with upstream should be prioritized, and the alternate solution would be easier to accept than the current one. However, I also think the current solution is acceptable due to the rarity of instance helpers, and the fact it would be more clear what needs to be changed in cases where it breaks an instance helper in a fork not covered by this PR (which I wouldn't expect to be a common occurrence).

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

[z33ky]

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

Thanks. Apart from the possible change to the "upstream-compatible but brittle" DEFINE_SCRIPT_INSTANCE_HELPER() I have nothing further to add. Feel free to tag me if I can help, should something come up.

[z33ky]

When a ScriptClassDesc_t for is initialized (SCRIPTDESC), it recursively invokes its parents initializers in order to obtain their pHelper member.
Initialization is only done once, so repeated initialization is skipped. Initialization includes assignment of a vector of ScriptHook_t's (DEFINE_SCRIPTFUNC/BEGIN_SCRIPTHOOK), which must be initialized beforehand.
Both of these use (static) globals; Within a translation unit, initialization order is defined to be the same as the order of declaration. So within a translation unit we must define all ScriptHook_t's before the ScriptClassDesc_t using them. A problem occurs with the parent initialization though, since there is no defined order between translation units, meaning initialization of a ScriptClassDesc_t can happen before its ScriptHook_t's, despite being the correct order within its translation unit.

On MSVC it seems this issue is benign. On GCC/Linux however the initialization of a ScriptHook_t essentially cleared whatever happened during the initialization of the ScriptClassDesc_t, meaning many hooks simply didn't work.

This situation is remedied by delaying the initialization of the ScriptClassDesc_t's ScriptHook_t vector to only when the constructor of it is invoked from its translation unit. This is accomplished simply by adding a boolean parameter to the function (GetScriptDesc()) that is true in the global constructor invocation, and false by default (including when doing parent ScriptClassDesc_t initialization). When false, a valid ScriptClassDesc_t pointer is still returned, with the proper value for pHelper, which is all that is needed for the initialization of the child ScriptClassDesc_t. The value of the returned pointer is a fixed memory location, and does not change due to the delayed initialization.

Fixes#244.

---

Does this PR close any issues?

• [CODE] Script hook parameter reset #244

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[samisalreadytaken]

This breaks instance helper fallback assignment in BEGIN_SCRIPTDESC_NAMED for some classes. In MSVC, CBaseAnimating (baseanimating.cpp) won't be assigned a helper.

Test ToString in game with

printl( Entities.CreateByClassname("prop_dynamic") )

It should print ([0] prop_dynamic), but it prints (CBaseAnimating : 0x00)

[z33ky]

Hm yeah, I mistook this loop to initialize pHelper completely, but it's actually done through DEFINE_SCRIPT_INSTANCE_HELPER(). It is thus part of the delayed initialization and the loop won't find the proper helper instance.

One solution, which breaks compatibility with upstream vscript though, would be to include the helper as argument to BEGIN_SCRIPTDESC_NAMED(), so it can be initialized eagerly. A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros, which are the actual ones that must be delayed. We can rely on the optimizer to eliminate the redundant checks for !init. For this to work though, DEFINE_SCRIPT_INSTANCE_HELPER()must be called before the script-hook definitions, lest it silently breaks the helper.
I've gone with the first one for now, since there are relatively few script definitions that define a helper.

[samisalreadytaken]

A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros

I don't think this would be bad. There could even be something like BEGIN_SCRIPTHOOK_DEFINITIONS to indicate the definition section, or just put a note saying hooks should be defined last. Changing script hooks might be preferable over diverging from upstream. I personally don't have a strong preference of one over the other though.

[Blixibon]

I think that compatibility with upstream should be prioritized, and the alternate solution would be easier to accept than the current one. However, I also think the current solution is acceptable due to the rarity of instance helpers, and the fact it would be more clear what needs to be changed in cases where it breaks an instance helper in a fork not covered by this PR (which I wouldn't expect to be a common occurrence).

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

[z33ky]

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

Thanks. Apart from the possible change to the "upstream-compatible but brittle" DEFINE_SCRIPT_INSTANCE_HELPER() I have nothing further to add. Feel free to tag me if I can help, should something come up.

[z33ky]

When a ScriptClassDesc_t for is initialized (SCRIPTDESC), it recursively invokes its parents initializers in order to obtain their pHelper member.
Initialization is only done once, so repeated initialization is skipped. Initialization includes assignment of a vector of ScriptHook_t's (DEFINE_SCRIPTFUNC/BEGIN_SCRIPTHOOK), which must be initialized beforehand.
Both of these use (static) globals; Within a translation unit, initialization order is defined to be the same as the order of declaration. So within a translation unit we must define all ScriptHook_t's before the ScriptClassDesc_t using them. A problem occurs with the parent initialization though, since there is no defined order between translation units, meaning initialization of a ScriptClassDesc_t can happen before its ScriptHook_t's, despite being the correct order within its translation unit.

On MSVC it seems this issue is benign. On GCC/Linux however the initialization of a ScriptHook_t essentially cleared whatever happened during the initialization of the ScriptClassDesc_t, meaning many hooks simply didn't work.

This situation is remedied by delaying the initialization of the ScriptClassDesc_t's ScriptHook_t vector to only when the constructor of it is invoked from its translation unit. This is accomplished simply by adding a boolean parameter to the function (GetScriptDesc()) that is true in the global constructor invocation, and false by default (including when doing parent ScriptClassDesc_t initialization). When false, a valid ScriptClassDesc_t pointer is still returned, with the proper value for pHelper, which is all that is needed for the initialization of the child ScriptClassDesc_t. The value of the returned pointer is a fixed memory location, and does not change due to the delayed initialization.

Fixes#244.

---

Does this PR close any issues?

• [CODE] Script hook parameter reset #244

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[samisalreadytaken]

This breaks instance helper fallback assignment in BEGIN_SCRIPTDESC_NAMED for some classes. In MSVC, CBaseAnimating (baseanimating.cpp) won't be assigned a helper.

Test ToString in game with

printl( Entities.CreateByClassname("prop_dynamic") )

It should print ([0] prop_dynamic), but it prints (CBaseAnimating : 0x00)

[z33ky]

Hm yeah, I mistook this loop to initialize pHelper completely, but it's actually done through DEFINE_SCRIPT_INSTANCE_HELPER(). It is thus part of the delayed initialization and the loop won't find the proper helper instance.

One solution, which breaks compatibility with upstream vscript though, would be to include the helper as argument to BEGIN_SCRIPTDESC_NAMED(), so it can be initialized eagerly. A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros, which are the actual ones that must be delayed. We can rely on the optimizer to eliminate the redundant checks for !init. For this to work though, DEFINE_SCRIPT_INSTANCE_HELPER()must be called before the script-hook definitions, lest it silently breaks the helper.
I've gone with the first one for now, since there are relatively few script definitions that define a helper.

[samisalreadytaken]

A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros

I don't think this would be bad. There could even be something like BEGIN_SCRIPTHOOK_DEFINITIONS to indicate the definition section, or just put a note saying hooks should be defined last. Changing script hooks might be preferable over diverging from upstream. I personally don't have a strong preference of one over the other though.

[Blixibon]

I think that compatibility with upstream should be prioritized, and the alternate solution would be easier to accept than the current one. However, I also think the current solution is acceptable due to the rarity of instance helpers, and the fact it would be more clear what needs to be changed in cases where it breaks an instance helper in a fork not covered by this PR (which I wouldn't expect to be a common occurrence).

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

[z33ky]

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

Thanks. Apart from the possible change to the "upstream-compatible but brittle" DEFINE_SCRIPT_INSTANCE_HELPER() I have nothing further to add. Feel free to tag me if I can help, should something come up.

[z33ky]

When a ScriptClassDesc_t for is initialized (SCRIPTDESC), it recursively invokes its parents initializers in order to obtain their pHelper member.
Initialization is only done once, so repeated initialization is skipped. Initialization includes assignment of a vector of ScriptHook_t's (DEFINE_SCRIPTFUNC/BEGIN_SCRIPTHOOK), which must be initialized beforehand.
Both of these use (static) globals; Within a translation unit, initialization order is defined to be the same as the order of declaration. So within a translation unit we must define all ScriptHook_t's before the ScriptClassDesc_t using them. A problem occurs with the parent initialization though, since there is no defined order between translation units, meaning initialization of a ScriptClassDesc_t can happen before its ScriptHook_t's, despite being the correct order within its translation unit.

On MSVC it seems this issue is benign. On GCC/Linux however the initialization of a ScriptHook_t essentially cleared whatever happened during the initialization of the ScriptClassDesc_t, meaning many hooks simply didn't work.

This situation is remedied by delaying the initialization of the ScriptClassDesc_t's ScriptHook_t vector to only when the constructor of it is invoked from its translation unit. This is accomplished simply by adding a boolean parameter to the function (GetScriptDesc()) that is true in the global constructor invocation, and false by default (including when doing parent ScriptClassDesc_t initialization). When false, a valid ScriptClassDesc_t pointer is still returned, with the proper value for pHelper, which is all that is needed for the initialization of the child ScriptClassDesc_t. The value of the returned pointer is a fixed memory location, and does not change due to the delayed initialization.

Fixes#244.

---

Does this PR close any issues?

• [CODE] Script hook parameter reset #244

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[samisalreadytaken]

This breaks instance helper fallback assignment in BEGIN_SCRIPTDESC_NAMED for some classes. In MSVC, CBaseAnimating (baseanimating.cpp) won't be assigned a helper.

Test ToString in game with

printl( Entities.CreateByClassname("prop_dynamic") )

It should print ([0] prop_dynamic), but it prints (CBaseAnimating : 0x00)

[z33ky]

Hm yeah, I mistook this loop to initialize pHelper completely, but it's actually done through DEFINE_SCRIPT_INSTANCE_HELPER(). It is thus part of the delayed initialization and the loop won't find the proper helper instance.

One solution, which breaks compatibility with upstream vscript though, would be to include the helper as argument to BEGIN_SCRIPTDESC_NAMED(), so it can be initialized eagerly. A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros, which are the actual ones that must be delayed. We can rely on the optimizer to eliminate the redundant checks for !init. For this to work though, DEFINE_SCRIPT_INSTANCE_HELPER()must be called before the script-hook definitions, lest it silently breaks the helper.
I've gone with the first one for now, since there are relatively few script definitions that define a helper.

[samisalreadytaken]

A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros

I don't think this would be bad. There could even be something like BEGIN_SCRIPTHOOK_DEFINITIONS to indicate the definition section, or just put a note saying hooks should be defined last. Changing script hooks might be preferable over diverging from upstream. I personally don't have a strong preference of one over the other though.

[Blixibon]

I think that compatibility with upstream should be prioritized, and the alternate solution would be easier to accept than the current one. However, I also think the current solution is acceptable due to the rarity of instance helpers, and the fact it would be more clear what needs to be changed in cases where it breaks an instance helper in a fork not covered by this PR (which I wouldn't expect to be a common occurrence).

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

[z33ky]

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

Thanks. Apart from the possible change to the "upstream-compatible but brittle" DEFINE_SCRIPT_INSTANCE_HELPER() I have nothing further to add. Feel free to tag me if I can help, should something come up.

[z33ky]

When a ScriptClassDesc_t for is initialized (SCRIPTDESC), it recursively invokes its parents initializers in order to obtain their pHelper member.
Initialization is only done once, so repeated initialization is skipped. Initialization includes assignment of a vector of ScriptHook_t's (DEFINE_SCRIPTFUNC/BEGIN_SCRIPTHOOK), which must be initialized beforehand.
Both of these use (static) globals; Within a translation unit, initialization order is defined to be the same as the order of declaration. So within a translation unit we must define all ScriptHook_t's before the ScriptClassDesc_t using them. A problem occurs with the parent initialization though, since there is no defined order between translation units, meaning initialization of a ScriptClassDesc_t can happen before its ScriptHook_t's, despite being the correct order within its translation unit.

On MSVC it seems this issue is benign. On GCC/Linux however the initialization of a ScriptHook_t essentially cleared whatever happened during the initialization of the ScriptClassDesc_t, meaning many hooks simply didn't work.

This situation is remedied by delaying the initialization of the ScriptClassDesc_t's ScriptHook_t vector to only when the constructor of it is invoked from its translation unit. This is accomplished simply by adding a boolean parameter to the function (GetScriptDesc()) that is true in the global constructor invocation, and false by default (including when doing parent ScriptClassDesc_t initialization). When false, a valid ScriptClassDesc_t pointer is still returned, with the proper value for pHelper, which is all that is needed for the initialization of the child ScriptClassDesc_t. The value of the returned pointer is a fixed memory location, and does not change due to the delayed initialization.

Fixes#244.

---

Does this PR close any issues?

• [CODE] Script hook parameter reset #244

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[samisalreadytaken]

This breaks instance helper fallback assignment in BEGIN_SCRIPTDESC_NAMED for some classes. In MSVC, CBaseAnimating (baseanimating.cpp) won't be assigned a helper.

Test ToString in game with

printl( Entities.CreateByClassname("prop_dynamic") )

It should print ([0] prop_dynamic), but it prints (CBaseAnimating : 0x00)

[z33ky]

Hm yeah, I mistook this loop to initialize pHelper completely, but it's actually done through DEFINE_SCRIPT_INSTANCE_HELPER(). It is thus part of the delayed initialization and the loop won't find the proper helper instance.

One solution, which breaks compatibility with upstream vscript though, would be to include the helper as argument to BEGIN_SCRIPTDESC_NAMED(), so it can be initialized eagerly. A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros, which are the actual ones that must be delayed. We can rely on the optimizer to eliminate the redundant checks for !init. For this to work though, DEFINE_SCRIPT_INSTANCE_HELPER()must be called before the script-hook definitions, lest it silently breaks the helper.
I've gone with the first one for now, since there are relatively few script definitions that define a helper.

[samisalreadytaken]

A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros

I don't think this would be bad. There could even be something like BEGIN_SCRIPTHOOK_DEFINITIONS to indicate the definition section, or just put a note saying hooks should be defined last. Changing script hooks might be preferable over diverging from upstream. I personally don't have a strong preference of one over the other though.

[Blixibon]

I think that compatibility with upstream should be prioritized, and the alternate solution would be easier to accept than the current one. However, I also think the current solution is acceptable due to the rarity of instance helpers, and the fact it would be more clear what needs to be changed in cases where it breaks an instance helper in a fork not covered by this PR (which I wouldn't expect to be a common occurrence).

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

[z33ky]

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

Thanks. Apart from the possible change to the "upstream-compatible but brittle" DEFINE_SCRIPT_INSTANCE_HELPER() I have nothing further to add. Feel free to tag me if I can help, should something come up.

[z33ky]

When a ScriptClassDesc_t for is initialized (SCRIPTDESC), it recursively invokes its parents initializers in order to obtain their pHelper member.
Initialization is only done once, so repeated initialization is skipped. Initialization includes assignment of a vector of ScriptHook_t's (DEFINE_SCRIPTFUNC/BEGIN_SCRIPTHOOK), which must be initialized beforehand.
Both of these use (static) globals; Within a translation unit, initialization order is defined to be the same as the order of declaration. So within a translation unit we must define all ScriptHook_t's before the ScriptClassDesc_t using them. A problem occurs with the parent initialization though, since there is no defined order between translation units, meaning initialization of a ScriptClassDesc_t can happen before its ScriptHook_t's, despite being the correct order within its translation unit.

On MSVC it seems this issue is benign. On GCC/Linux however the initialization of a ScriptHook_t essentially cleared whatever happened during the initialization of the ScriptClassDesc_t, meaning many hooks simply didn't work.

This situation is remedied by delaying the initialization of the ScriptClassDesc_t's ScriptHook_t vector to only when the constructor of it is invoked from its translation unit. This is accomplished simply by adding a boolean parameter to the function (GetScriptDesc()) that is true in the global constructor invocation, and false by default (including when doing parent ScriptClassDesc_t initialization). When false, a valid ScriptClassDesc_t pointer is still returned, with the proper value for pHelper, which is all that is needed for the initialization of the child ScriptClassDesc_t. The value of the returned pointer is a fixed memory location, and does not change due to the delayed initialization.

Fixes#244.

---

Does this PR close any issues?

• [CODE] Script hook parameter reset #244

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[samisalreadytaken]

This breaks instance helper fallback assignment in BEGIN_SCRIPTDESC_NAMED for some classes. In MSVC, CBaseAnimating (baseanimating.cpp) won't be assigned a helper.

Test ToString in game with

printl( Entities.CreateByClassname("prop_dynamic") )

It should print ([0] prop_dynamic), but it prints (CBaseAnimating : 0x00)

[z33ky]

Hm yeah, I mistook this loop to initialize pHelper completely, but it's actually done through DEFINE_SCRIPT_INSTANCE_HELPER(). It is thus part of the delayed initialization and the loop won't find the proper helper instance.

One solution, which breaks compatibility with upstream vscript though, would be to include the helper as argument to BEGIN_SCRIPTDESC_NAMED(), so it can be initialized eagerly. A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros, which are the actual ones that must be delayed. We can rely on the optimizer to eliminate the redundant checks for !init. For this to work though, DEFINE_SCRIPT_INSTANCE_HELPER()must be called before the script-hook definitions, lest it silently breaks the helper.
I've gone with the first one for now, since there are relatively few script definitions that define a helper.

[samisalreadytaken]

A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros

I don't think this would be bad. There could even be something like BEGIN_SCRIPTHOOK_DEFINITIONS to indicate the definition section, or just put a note saying hooks should be defined last. Changing script hooks might be preferable over diverging from upstream. I personally don't have a strong preference of one over the other though.

[Blixibon]

I think that compatibility with upstream should be prioritized, and the alternate solution would be easier to accept than the current one. However, I also think the current solution is acceptable due to the rarity of instance helpers, and the fact it would be more clear what needs to be changed in cases where it breaks an instance helper in a fork not covered by this PR (which I wouldn't expect to be a common occurrence).

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

[z33ky]

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

Thanks. Apart from the possible change to the "upstream-compatible but brittle" DEFINE_SCRIPT_INSTANCE_HELPER() I have nothing further to add. Feel free to tag me if I can help, should something come up.

[z33ky]

When a ScriptClassDesc_t for is initialized (SCRIPTDESC), it recursively invokes its parents initializers in order to obtain their pHelper member.
Initialization is only done once, so repeated initialization is skipped. Initialization includes assignment of a vector of ScriptHook_t's (DEFINE_SCRIPTFUNC/BEGIN_SCRIPTHOOK), which must be initialized beforehand.
Both of these use (static) globals; Within a translation unit, initialization order is defined to be the same as the order of declaration. So within a translation unit we must define all ScriptHook_t's before the ScriptClassDesc_t using them. A problem occurs with the parent initialization though, since there is no defined order between translation units, meaning initialization of a ScriptClassDesc_t can happen before its ScriptHook_t's, despite being the correct order within its translation unit.

On MSVC it seems this issue is benign. On GCC/Linux however the initialization of a ScriptHook_t essentially cleared whatever happened during the initialization of the ScriptClassDesc_t, meaning many hooks simply didn't work.

This situation is remedied by delaying the initialization of the ScriptClassDesc_t's ScriptHook_t vector to only when the constructor of it is invoked from its translation unit. This is accomplished simply by adding a boolean parameter to the function (GetScriptDesc()) that is true in the global constructor invocation, and false by default (including when doing parent ScriptClassDesc_t initialization). When false, a valid ScriptClassDesc_t pointer is still returned, with the proper value for pHelper, which is all that is needed for the initialization of the child ScriptClassDesc_t. The value of the returned pointer is a fixed memory location, and does not change due to the delayed initialization.

Fixes#244.

---

Does this PR close any issues?

• [CODE] Script hook parameter reset #244

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[samisalreadytaken]

This breaks instance helper fallback assignment in BEGIN_SCRIPTDESC_NAMED for some classes. In MSVC, CBaseAnimating (baseanimating.cpp) won't be assigned a helper.

Test ToString in game with

printl( Entities.CreateByClassname("prop_dynamic") )

It should print ([0] prop_dynamic), but it prints (CBaseAnimating : 0x00)

[z33ky]

Hm yeah, I mistook this loop to initialize pHelper completely, but it's actually done through DEFINE_SCRIPT_INSTANCE_HELPER(). It is thus part of the delayed initialization and the loop won't find the proper helper instance.

One solution, which breaks compatibility with upstream vscript though, would be to include the helper as argument to BEGIN_SCRIPTDESC_NAMED(), so it can be initialized eagerly. A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros, which are the actual ones that must be delayed. We can rely on the optimizer to eliminate the redundant checks for !init. For this to work though, DEFINE_SCRIPT_INSTANCE_HELPER()must be called before the script-hook definitions, lest it silently breaks the helper.
I've gone with the first one for now, since there are relatively few script definitions that define a helper.

[samisalreadytaken]

A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros

I don't think this would be bad. There could even be something like BEGIN_SCRIPTHOOK_DEFINITIONS to indicate the definition section, or just put a note saying hooks should be defined last. Changing script hooks might be preferable over diverging from upstream. I personally don't have a strong preference of one over the other though.

[Blixibon]

I think that compatibility with upstream should be prioritized, and the alternate solution would be easier to accept than the current one. However, I also think the current solution is acceptable due to the rarity of instance helpers, and the fact it would be more clear what needs to be changed in cases where it breaks an instance helper in a fork not covered by this PR (which I wouldn't expect to be a common occurrence).

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

[z33ky]

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

Thanks. Apart from the possible change to the "upstream-compatible but brittle" DEFINE_SCRIPT_INSTANCE_HELPER() I have nothing further to add. Feel free to tag me if I can help, should something come up.

[z33ky]

When a ScriptClassDesc_t for is initialized (SCRIPTDESC), it recursively invokes its parents initializers in order to obtain their pHelper member.
Initialization is only done once, so repeated initialization is skipped. Initialization includes assignment of a vector of ScriptHook_t's (DEFINE_SCRIPTFUNC/BEGIN_SCRIPTHOOK), which must be initialized beforehand.
Both of these use (static) globals; Within a translation unit, initialization order is defined to be the same as the order of declaration. So within a translation unit we must define all ScriptHook_t's before the ScriptClassDesc_t using them. A problem occurs with the parent initialization though, since there is no defined order between translation units, meaning initialization of a ScriptClassDesc_t can happen before its ScriptHook_t's, despite being the correct order within its translation unit.

On MSVC it seems this issue is benign. On GCC/Linux however the initialization of a ScriptHook_t essentially cleared whatever happened during the initialization of the ScriptClassDesc_t, meaning many hooks simply didn't work.

This situation is remedied by delaying the initialization of the ScriptClassDesc_t's ScriptHook_t vector to only when the constructor of it is invoked from its translation unit. This is accomplished simply by adding a boolean parameter to the function (GetScriptDesc()) that is true in the global constructor invocation, and false by default (including when doing parent ScriptClassDesc_t initialization). When false, a valid ScriptClassDesc_t pointer is still returned, with the proper value for pHelper, which is all that is needed for the initialization of the child ScriptClassDesc_t. The value of the returned pointer is a fixed memory location, and does not change due to the delayed initialization.

Fixes#244.

---

Does this PR close any issues?

• [CODE] Script hook parameter reset #244

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[samisalreadytaken]

This breaks instance helper fallback assignment in BEGIN_SCRIPTDESC_NAMED for some classes. In MSVC, CBaseAnimating (baseanimating.cpp) won't be assigned a helper.

Test ToString in game with

printl( Entities.CreateByClassname("prop_dynamic") )

It should print ([0] prop_dynamic), but it prints (CBaseAnimating : 0x00)

[z33ky]

Hm yeah, I mistook this loop to initialize pHelper completely, but it's actually done through DEFINE_SCRIPT_INSTANCE_HELPER(). It is thus part of the delayed initialization and the loop won't find the proper helper instance.

One solution, which breaks compatibility with upstream vscript though, would be to include the helper as argument to BEGIN_SCRIPTDESC_NAMED(), so it can be initialized eagerly. A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros, which are the actual ones that must be delayed. We can rely on the optimizer to eliminate the redundant checks for !init. For this to work though, DEFINE_SCRIPT_INSTANCE_HELPER()must be called before the script-hook definitions, lest it silently breaks the helper.
I've gone with the first one for now, since there are relatively few script definitions that define a helper.

[samisalreadytaken]

A compatible, but brittle, solution would be to move the early if (!init) return pDesc; to the script-hook macros

I don't think this would be bad. There could even be something like BEGIN_SCRIPTHOOK_DEFINITIONS to indicate the definition section, or just put a note saying hooks should be defined last. Changing script hooks might be preferable over diverging from upstream. I personally don't have a strong preference of one over the other though.

[Blixibon]

I think that compatibility with upstream should be prioritized, and the alternate solution would be easier to accept than the current one. However, I also think the current solution is acceptable due to the rarity of instance helpers, and the fact it would be more clear what needs to be changed in cases where it breaks an instance helper in a fork not covered by this PR (which I wouldn't expect to be a common occurrence).

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

[z33ky]

I'm approving and merging this with the assumption that no further changes are going to be made regarding that subject (or regarding the fix as a whole), although another PR can be opened before the next update if needed.

Thanks. Apart from the possible change to the "upstream-compatible but brittle" DEFINE_SCRIPT_INSTANCE_HELPER() I have nothing further to add. Feel free to tag me if I can help, should something come up.