Metamod-r vs Metamod-P: Which One Should You Use in 2026?

Both are forks of Will Day's original Metamod, both load the same plugins.ini, and both answer meta list. The difference is what they were built for. Metamod-P is the mature, conservative fork of the classic engine era. Metamod-r is the rewrite aimed at ReHLDS, with a faster hook dispatcher. If you want the short answer: on ReHLDS, use Metamod-r. On stock Valve HLDS you can use either, and Metamod-P is the safer bet.

The actual differences

Where the performance difference actually comes from

Metamod intercepts every engine and game-DLL function that any plugin has expressed interest in. Classic Metamod builds its dispatch tables so that a hooked function walks the plugin list on every single call — and CS 1.6 calls some of these functions thousands of times per second per player (PlayerPreThink, StartFrame, AddToFullPack). Metamod-r reduces the per-call overhead of that walk. On an empty server you will never see it. On a 32-slot public with AMXX, a stats plugin, a shop and a mod, it is the difference between comfortable headroom and a server that starts choking when the twenty-fifth player joins.

This is not the only thing that affects server FPS, and it is not a fix for a badly-written plugin that runs a MySQL query in client_PreThink. If your server chokes, profile before you swap forks: see how to find the plugin at fault.

Which to pick

Use Metamod-r if

• You run ReHLDS — which you should.
• You run a busy public server (20+ slots) with a real plugin set.
• You want something that is still being maintained.
• You use ReAPI-based plugins; that whole ecosystem assumes the modern stack.

Use Metamod-P if

• You are stuck on stock Valve HLDS and cannot change the engine (some panels/hosts).
• You have an old binary Metamod plugin that misbehaves under Metamod-r and you cannot replace it.
• You are maintaining a legacy server and stability today outranks performance tomorrow.

How to switch from Metamod-P to Metamod-r safely

The two use the same directory and the same plugins.ini, so the switch is a binary swap plus one line in liblist.gam if the filename changes.

1. Back up the whole cstrike/addons/metamod/ directory and cstrike/liblist.gam.
2. Drop the Metamod-r binary in place:

   cd /home/steam/hlds/cstrike/addons/metamod
   cp metamod_i386.so metamod_i386.so.p.bak
   cp /path/to/metamod-r/metamod.so ./metamod.so

3. Update liblist.gam to the new filename:

   gamedll_linux "addons/metamod/metamod.so"

4. Leave plugins.ini exactly as it is.
5. Restart and run:

   meta version
   meta list

Every plugin that was RUN before must still be RUN. If one is now bad load, that specific plugin is the incompatibility — not the fork as a whole. Read the bad load guide, and if you cannot resolve it, roll back to the .p.bak binary and the old liblist.gam line while you find a replacement plugin.

Common misconceptions

• "Metamod-r requires ReHLDS." It is built for ReHLDS and that is where it is tested, but it does not refuse to load on stock HLDS. That said, if you are willing to change Metamod you should be willing to change the engine — the engine is where most of the wins are.
• "Switching Metamod will break my AMXX plugins." AMXX plugins (.amxx) are not Metamod plugins. Only the AMXX module (amxmodx_mm_i386.so) talks to Metamod. Your .amxx files are untouched by this decision.
• "Metamod-r gives me ReAPI natives." No. ReAPI is a separate AMXX module and requires ReGameDLL.

Verification after any switch

1. meta version reports the fork and version you expect.
2. meta list — every plugin RUN, zero bad load.
3. amxx plugins — every AMXX plugin running.
4. Play a full map with real players, then change map. Most Metamod-level breakage shows up at map change, not at boot.

If all four are clean, the switch is done. The full recommended chain is described in the modern CS 1.6 stack.