You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Move the loader logic from sourcemod to the upper level (metamod).
Metamod sends the information itself: sdk suffix, major version, architecture, etc. (so that we can quickly get the module name: myext.<major_version>.<sdk_suffix>.<architecture>.<platform_ext>).
What will it give?
(Theoretically) Adds module loading depending on the SDK (the way sourcemod does it).
You will not need a deeper analysis in custom loaders.
The text was updated successfully, but these errors were encountered:
Sending sdk suffix is a good idea. Architecture is implied in the build and the only major version is "6", so suffix is all you need. MM:S could even send the entire suffix string "6.whatever.arch.dll"
zer0k-z
pushed a commit
to zer0k-z/metamod-source
that referenced
this issue
Jun 7, 2024
While looking at the source code, I noticed that metamod translates SE codes (that are given in the manifests) into its own codes, which it then uses.
metamod-source/core/provider/source/provider_source.cpp
Lines 202 to 255 in 9fbe7f3
This creates problems (for example, if we want to create our own loader inside the extension) that we then have to translate these codes back.
So we have 2 different interpretations of the SE code and every time we want to add new SDK support, we have to add new logic to our loader.
https://github.com/alliedmodders/sourcemod/blob/4e8b66bf998cc1b0d40afd49a14856fde6a2e773/loader/loader.cpp#L202-L360
Possible solution:
myext.<major_version>.<sdk_suffix>.<architecture>.<platform_ext>
).What will it give?
The text was updated successfully, but these errors were encountered: