ClientCast - A Client-based, Idiosyncratic Hitbox System!

I made a small example
Example broken.rbxl (33.4 KB)
It kills the humanoid then does not stop after doing damage.

I’ve pushed an update to ClientCast.lua on the GitHub. Could you try replacing your ClientCast ModuleScript’s source with the new version, and see if the bug has been addressed?

1 Like

Yes, I did it, and it works!
Thank you for the quick update.

A quick notice, I believe you have two values named “Debug”, one is a boolean, and the other is a method. Lua seems to confuse these two, I hope you can fix that some time.

1 Like

I’ll push an update to change the Debug method to SetDebug and GetDebug. Unsure when I’ll push the update though, as I want to add a way to also get a player’s ping easily for the next update.


Hey I checked his module out a month or so ago, and I see you have been working on it still, great!

I need a solution to help me visually sync up ranged attack in my game, these are slow-moving projectiles that are tweened on the client while the hitbox (using .Touched) is tweened on the sever. I am of course getting some de-syncing between the damage being a applied and the visual effects being played on the client.

I am considering between this module and RaycastHitbox module. How does your module differ from RaycastHitbox in terms of my use case? My primary issue is that I want to make hits appear as smooth as possible between server an client, how exactly can you perform calculation on the client and trust anything they send to the server?

What is to stop the player from moving the hitbox wherever they want it to go?


Basically, ClientCast takes the load off of using .Touched on server. On the other hand its slightly more exploitable, maybe by one or two studs. Although for fast moving objects, its much better for you to use FastCast for accuracy, this is mostly for melee hitboxes.

These are slow moving, and large, projectiles and fastcast is way overkill for my needs. In short, I’m trying to figure out how to show a projectile hitting on the client at the same time the server hit box does the hit

FastCast still works for slower moving projectiles. But however, if its slow projectiles, you can probably use it to detect hits on the client and then pass it to server. Then the server checks magnitude.

By using ClientCast you avoid the annoyance of having to setup a hitbox on server and visualization on client (i.e the part only exists on client for visualization) - the easiest way to have smooth effects for your projectile would be to change that projectile’s network owner to the client who’s shooting it, which would allow you to still have the part on the server, calculate hitbox on client, and calculate hitbox results on server.

1 Like

Thanks for responding. By network ownership, you mean the ClientCast method of Caster:SetOwner(Player) ?

Let me set up a step-by-step situation:

  1. create hitbox part on server
  2. create ClientCast object on that hitboxpart, set it to Caster:SetOwner(Player)
  3. Tween hitbox part on the server
  4. Create visual projectile on client
  5. Tween visual projectile on client

Obviously the server and client parts wont be synced, because the server could be facing lag and of course there would be some latency based on the players ping.

The server hitbox part being tween would be replicated to the client, facing the same ping issues as the RemoteEvent sending the tween instructions. Since they face the (theoretically) same ping, but different lag circumstances, I guess I am not sure how this will play out.

Does anyone have any thoughts?


I tried to implement FastCast once and I found the example gun to be overly-complex for something as simple as casting a projectile. The projectiles I am shooting are not a major focus of my game and I opted to implement simple tweens to move these relatively slow-moving projectiles. I do wish wish FastCast were simpler to implement, but besides the provided gun example (which was too complex for my taste) I have not been able to find any other example code implementations.

network ownership. Caster:SetOwner simply determines who will calculate the hitbox - BasePart:SetNetworkOwner determines who should update the physics (i.e movement) of the object.

I am actually implementing a Caster:GetPing() method, which would return the ping of the Caster’s set owner (0 if it’s the server). This would allow you to handle latency in your own way, such as doing what CSGO does, i.e backtracking where the hitbox was for example 0.2 seconds ago, depending on player ping.

There will always be latency, and trying to fully eliminate that would either lead to you having to be slightly more lenient towards exploits (which is ClientCast’s ideology), or stricter but experience issues with players that have high ping.

Ah, the example gun was rather complex due to being made for easy customization and a few other modules that weren’t actually required (PartCache, for example).

Just a reminder, ClientCast can be spoofed, so you have to have at least a sanity check on the server.
Your idea definitely can work, although I’d still suggest FastCast because ClientCast was never made for ranged projectiles.

I’d argue using ClientCast is fine for ranged projectiles, as it eliminates the need of having to visualize objects on client, which is partly why FastCast is too convoluted IMO. If you’re going for super optimized performance, visualization on client and hitbox on server is definitely the way to go, if you’re willing to setup such a big system.

1 Like

I have a concern though. For high speed/velocity objects, would it be unable to detect some collisions with small objects? I’m not sure if I could use this system for faster melee attacks.

Can you explain your setup you have in mind though? How does it eliminate the need to visualize on the client?

I cannot simply have the server tweening all of my visual effects. I only have it tweening the hitbox.

ClientCast raycasts between the object’s current and last position every Heartbeat event, so if it directly passes through an object then it should be detected.

1 Like

Because you can directly update all visuals on the server directly rather than having to use remotes as a proxy to communicate with the client and telling them to update their visuals.

Ah, I previously thought it simply casts a raycast with a length of 0 to detect if the ray is currently in an object.

OK this is where you completely lost me, trying to understand. I am tweening a complex assembly of parts on the client because the server simply cannot handle this work. The server is only tweening the hitbox. How does ClientCast lend a hand in this situation?

The only reason to do things on client is to save performance on the server, otherwise we could just run it all on the server and be done with all this nonsense.

I think you are suggesting that I should just skip rendering visual effects on the client, but I cannot do that. It would lag the server too bad.

Note: This isn’t discussing ClientCast related topics. This will be better answered in #help-and-feedback:scripting-support

1 Like