Store Page
Garry's Mod
All Discussions Screenshots Artwork Broadcasts Videos Workshop News Guides Reviews

Garry's Mod

Store Page
Garry's Mod >  Workshop > wget's Workshop > Clientside Hitreg > Discussions
Clientside Hitreg
Description Discussions1 Comments79 Change Notes
 This topic has been pinned, so it's probably important
wget  [developer] 19 May, 2023 @ 6:52pm
Here's some compatibility features for addon coders
This provides a few things for addon coders to use in case this addon's behaviour causes some incompatibility with their code:

You can check for the global variable CLHR to tell if this addon is installed or not:
if CLHR then -- clientside hitreg is installed else -- clientside hitreg is not installed end

You can put weapon classnames in the CLHR.Exceptions table to exclude them from being able to use clientside hitreg:
CLHR.Exceptions.weapon_example = true

Alternatively, you can also set a CLHR_Disabled field in a weapon's swep table instead:
SWEP.CLHR_Disabled = true

-----

There are two new hooks available, the first one is:

CLHR_PreShouldApplyToBullet( Player ply, table data )

ply = The player that is shooting the bullet
data = The bullet's data <structure>[wiki.facepunch.com]

This hook runs inside CLHR's hook for EntityFireBullets[wiki.facepunch.com] which runs before the bullet is actually fired

Return false to disallow a client-registered hit for the bullet

The second new available hook is:

CLHR_PostShouldApplyToBullet( Player ply, table trace, CTakeDamageInfo dmginfo )

ply = The player that shot the bullet
trace = The bullet's trace results <structure>[wiki.facepunch.com]
dmginfo = The bullet's damage event data <class>[wiki.facepunch.com]

This hook runs inside CLHR's bullet Callback override[wiki.facepunch.com] which runs after the bullet has been fired

Return false to disallow a client-registered hit for the bullet

-----

Note that the Callback function in the Bullet table for Entity:FireBullets will be executed a second time by this addon when a client-registered hit is successful
(this only happens serverside, obviously)

This might be unexpected behaviour, so the TraceResult table in the Callback function will have the CLHR_CommandNumber field on the second execution that you can check for, which also stores the usercmd number from the first execution if you need it

Here's an example of how to use that:
bullet.Callback = function(attacker, trace, dmginfo) -- some example code that you're ok with running twice if trace.HitNonWorld and trace.Hit then trace.Entity:Ignite(30) end -- if you want the original command number, you can do something like this local cmdnum = trace.CLHR_CommandNumber or attacker == GetPredictionPlayer() and attacker:GetCurrentCommand():CommandNumber() -- if this isn't nil, that means this function was called for the second time if trace.CLHR_CommandNumber then return -- early return to stop executing the rest of this function end -- some example code that you want to occur only once per shot local eff = EffectData() eff:SetEntity(attacker) eff:SetOrigin(trace.HitPos) util.Effect("HL1GaussBeam", eff) end

You can also store something in the CLHR_StoredData field of the TraceResult table of the first execution, and then this addon will automatically put its value in the same field of the new TraceResult table of the second execution, which is useful for example when you're using some value that might change between the first and second executions of the Callback function

Here's an example of how to use that:
bullet.Num = 8 local number = 0 -- will be an upvalue in the callback function bullet.Callback = function(attacker, trace, dmginfo) number = number + 1 local num = trace.CLHR_StoredData or number trace.CLHR_StoredData = num print(num) -- output should be 1, 2, 3, 4, 5, 6, 7, 8 -- then the client-registered hits should print the correct number -- if CLHR_StoredData wasn't used, then numbers past 8 would be printed end
Last edited by wget; 26 Sep, 2023 @ 10:19pm