search

alliedmodders / metamod-source

Metamod:Source - C++ Plugin Environment and Detour Library for the Source Engine
http://www.metamodsource.net/
Other
370 stars 84 forks source link

Inaccurate interpretation of SE codes #168

Open Classes123 opened 4 months ago

Classes123 commented 4 months ago

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. https://github.com/alliedmodders/metamod-source/blob/9fbe7f37ab96f06fad73b92446f2d738a1b64ac7/core/provider/source/provider_source.cpp#L202-L255

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:

  1. Move the loader logic from sourcemod to the upper level (metamod).
  2. 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?

  1. (Theoretically) Adds module loading depending on the SDK (the way sourcemod does it).
  2. You will not need a deeper analysis in custom loaders.
dvander commented 4 months ago

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"