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
Does reapi compatable with game valve? Because as I understood, regamedll only for cs, reapi for amxx, which based on cstrike fork.. SO, reapi's optional for HL1? Now I've disable this feature.
meta list
Currently loaded plugins:
description stat pend file vers src load unload
[ 1] Reunion RUN - reunion_mm.dll v0.1.0.137 ini Start Never
[ 2] Revoice RUN - revoice_mm.dll v0.1.0.34 ini Start Never
[ 3] AMX Mod X RUN - amxmodx_mm.dll v1.8.2 ini Start ANY
3 plugins, 3 running
version
Protocol version 48
Exe version 1.1.2.2/Stdio (valve)
ReHLDS version: 3.8.0.711-dev
Build date: 13:13:38 Feb 6 2021 (2492)
Build from: rehlds/ReHLDS@722e19d
No — ReAPI is a Counter-Strike module by design: it is a bridge over the ReGameDLL_CS and ReHLDS server-module APIs (see the README: "AMX Mod X module, using API regamedll & rehlds"). On a plain Half-Life server there is no ReGameDLL_CS and none of the rg_*/CS member/hook API exists, so loading the module there has no purpose — disabling it (as you did) is the correct setup.
For HL1 you would need fakemeta/hamsandwich-style generic modules instead. Closing as not planned (out of scope for this project).
Follow-up for completeness — what happens if you load ReAPI on a Half-Life (non-CS) server with ReHLDS only, no ReGameDLL:
The module does load. Native tables are split per API: when an API is not detected, its natives are registered as stubs that log "...: isn't available" and return FALSE — see natives_misc.cpp L3911-L3914 (Misc_Natives_RG/Misc_Natives_RH stubs, the same message this issue's log showed).
RG_* hookchains are registered behind an api_cfg.hasReGameDLL() guard (hook_list.cpp L114), so the whole rg_*/RG_*/get_member/set_member layer (offsets are laid out for the CS CBaseEntity) is inert.
What does work is the engine-level ReHLDS layer: the RH_* hookchains (RH_SV_StartSound, RH_SV_DropClient, RH_PF_precache_generic_I/_model_I/_sound_I, RH_SV_CheckUserInfo, …) and the rh_* natives, because the ReHLDS API is gamedll-independent.
Caveat: some shared/native code still assumes CS — CHECK_CONNECTED reads has_disconnected (a CS CBasePlayer field) and virtual calls go through CS vtable offsets (detailed analysis in The rh_emit_sound2 native is broken #242). #390 fixes the reported cases, but officially HL1+ReHLDS remains an untested configuration (README/CI target CS only).
So: as a ReHLDS-level hooker the module is partially usable on HL1, but the valuable CS-specific surface is absent by design — the module stays scoped to CS, as stated when this issue was closed.
Activity
Nord1cWarr1or commentedon Aug 31, 2026
No — ReAPI is a Counter-Strike module by design: it is a bridge over the ReGameDLL_CS and ReHLDS server-module APIs (see the README: "AMX Mod X module, using API regamedll & rehlds"). On a plain Half-Life server there is no ReGameDLL_CS and none of the
rg_*/CS member/hook API exists, so loading the module there has no purpose — disabling it (as you did) is the correct setup.For HL1 you would need fakemeta/hamsandwich-style generic modules instead. Closing as not planned (out of scope for this project).
Nord1cWarr1or commentedon Aug 31, 2026
Follow-up for completeness — what happens if you load ReAPI on a Half-Life (non-CS) server with ReHLDS only, no ReGameDLL:
"...: isn't available"and returnFALSE— seenatives_misc.cppL3911-L3914 (Misc_Natives_RG/Misc_Natives_RHstubs, the same message this issue's log showed).RG_*hookchains are registered behind anapi_cfg.hasReGameDLL()guard (hook_list.cppL114), so the wholerg_*/RG_*/get_member/set_memberlayer (offsets are laid out for the CSCBaseEntity) is inert.RH_*hookchains (RH_SV_StartSound,RH_SV_DropClient,RH_PF_precache_generic_I/_model_I/_sound_I,RH_SV_CheckUserInfo, …) and therh_*natives, because the ReHLDS API is gamedll-independent.CHECK_CONNECTEDreadshas_disconnected(a CSCBasePlayerfield) and virtual calls go through CS vtable offsets (detailed analysis in The rh_emit_sound2 native is broken #242). #390 fixes the reported cases, but officially HL1+ReHLDS remains an untested configuration (README/CI target CS only).So: as a ReHLDS-level hooker the module is partially usable on HL1, but the valuable CS-specific surface is absent by design — the module stays scoped to CS, as stated when this issue was closed.