ClientCast - A Client-based, Idiosyncratic Hitbox System!

No, because I cannot implement it for you - each game has different type of hitboxes, there is no universal solution. The model which ClientCast follows, I.e client calculates hitbox and server verifies, is a standard industry practice - not to talk down the other module, but a server-sided solution is not of any help towards high-ping players at all.
Also, I don’t see why it’s hard to implement a Magnitude check…?


Adding onto this, it’s not hard to fork it and implement your own safe hit-verification system. My game follows this model:

  • the client sends a message to the server telling it to attack

  • the server validates whether the client is able to attack, plays the animation and the hitbox

  • the client calculates the hitbox, and when the client detects it hitting something it sends that to the server. The client sends three pieces of info to the server:

    1. position of where the collision / hit occurred
    2. How long into the animation the client was in when they hit
    3. The client’s ping
  • the server receives this data and:

    1. Backtracks to see where the player’s position was during X seconds ago, where X is the player’s ping
    2. calculates where the sword’s position would be from the animation-time and calculates how plausible that hit was (simple magnitude check between hit-position and sword-position)
    3. and finally determines whether the hit was real enough or not

This model provides one of, if not the most accurate hit-verification systems, that I could come up with.


Exactly, which I am wondering why you can’t implement a basic universal magnitude check on your own.

1 Like

Because magnitude checks need to be hard-coded. I do not know the size of your hitbox, and how lenient you want to be with high-ping players.

Maybe you should add code that checks the magnitude and allow us devs customize the max magnitude. It would be a good idea.

1 Like
How interested would you be for having this module expand the available hitbox types, to more than just raycasting (i.e., for example using @EgoMoose’s rotated region3 module for a cuboid-shaped hitbox)?
    • Sure!
    • No thanks. (Please let me know as to why!)

0 voters

1 Like

Out of curiosity, How much more diffrent is this than swordphin123’s hitbox system?

If there’s any diffrence could you tell me them so i can see if i should use this one?

Please read the thread fully before replying. This module is created for easy switching between client and server contexts - clientcast pretty much communicates between the clients for you. It is stated (& elaborated more thoroughly) in the ‘Introduction’ paragraph at the top.

does this use the raycast hitbox module?

No, ClientCast is designed by me from the ground-up because Swordphin123’s is mostly designed with server in mind. Another issue with Swordphin123’s is that it’s pre-designed; by that I mean that it’s less customizable, for instance you can’t hit multiple players with only one hitbox with their module, which you can with ClientCast.

PSA: I added a Why this module? section.


u can hit multiple players tho i used his system to create a sword system with part wise health parrying stamina and a lot of maths behind it and like it doesnt give too many issues also how exactly r u sanity checking?

I’m talking about the same player. It’s even stated on their thread:

There’s many more limitations to that module, such as this:

OnHit events no longer needs to be disconnected as the issue of multiple damages is fixed. Please do not try to disconnect OnHit as the event is now managed entirely by the module and doing so can break certain functions.

You can’t disconnect your own events either - clarifying my point further.

there is a part mode in it and for the disconnecting just do hitstop and hitstart since it disconnects when u do hitstop and u cn just do hitstart again its not a problem

1 Like

Problem or not, that’s debatable - I’d rather just code in my own debounce than having to call two functions each time.
The philosophy of ClientCast is to be as barebones as possible whilst offering powerful features to give room for as much of customization as possible.

1 Like

ok and again how do u sanity check

edit: also wht is tht game in the example like if its in devolopment wat will its name be

1 Like

Could you elaborate what you mean by ‘sanity check’? as in, check how performant it is? or something alike unit testing?

1 Like

sanity testing as in check if they arent exploiting and stuff since it could be a security issue if there is no sanity check

1 Like

I don’t really. That is up to the end-user to implement, as there’s no perfect solution for every game (see the Important notice under How to Use).

For my game, I sanity check by backtracking the animation on server, get the attachment the client raycast from, and calculate how far off the line the sent position was.
The “line” is the direction between the backtracked attachment’s positions.

Also: if you don’t feel comfortable making your hitboxes more lenient in exchange for ping compensation, you can always just set no owner for the ClientCaster and instead just calculate it on server.

1 Like

tht kinda just beats the point of me shifting 20 different scripts to use this and also i feel this is just a version of raycasthitbox which is harder to use and has lesser features… but its alr i cn tell u put a lot of work in it

1 Like

It’s up to you to determine how useful you deem it. I’ve actually been using Swordphin’s hitbox before, but my playerbase complained about hitboxes missing and being inaccurate, so I ended up making ClientCast to fit for these new fits. While it’s hard to re-create complex systems like in CS:GO where they accurately backtrack from where the client shot due to Roblox’s packets being unordered, it is nevertheless industry practice to calculate hitboxes on client, and validate them on server - and that’s for a reason.

1 Like