Inaccurate interpretation of SE codes
Classes123 opened this issue · 1 comments
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:
- 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.
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"