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
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.
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
Could you elaborate what you mean by ‘sanity check’? as in, check how performant it is? or something alike unit testing?
sanity testing as in check if they arent exploiting and stuff since it could be a security issue if there is no sanity check
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.
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
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.
yk its not tht hard to do the hitbox casting on the client with swordphin’s module
well wht did u do different to fix it
I know, but it’s still more cumbersome than using this module. I’ve limited knowledge on how using swordphin’s module to support client context would work, but at least with ClientCast you don’t need to setup anything on client - all you need to do is just Caster:SetOwner(Player)
, and you’re set.
Switched to ClientCast as stated. It was only a year later that I got more paranoid about exploiters being able to slightly increase their hitboxes, and so I improved the security through implementing backtracking.
i meant wht did u do diffeent on client cast to fix it
…Natively supported client-server communication, which is the purpose of this module.
Also, if you have any further questions please take it to PMs because this thread is starting to get filled with clutter.
random though but would u be able to use this for large scale attacks like per say a meteor
As it is now, probably a bad idea. I’m too unmotivated to continue developing any projects right now, so only hope would be that someone would make a fork to add this:
I’ve read around and had an interest in using this for my game with large, fast moving projectile orbs. I have tried to implement many solutions but due to replication lag it seems impossible to make these fast projectiles have accurate hitboxes if not on the client.
However, these projectiles come from an enemy boss and I am unsure of the thought process I can take to ensure that exploiters can’t just delete the projectiles and their hitboxes to immunize themselves. Would you be willing to give me any insight into what to do about this? I don’t know if a backtracking method like you’ve described would work if a client could just completely delete the hitbox and prevent any calls to do damage from happening at all.
Why would your hitboxes have replication lag? You should follow a structure where the server creates a hit box, and the client creates effects. The server should not need to replicate anything other than sending the client a remote to create the effects on client.
Update 1.0.4.3
- Addressed a bug with
Caster::Destroy
accidentally destroying the whole object - this was a bug related to how debug trails were cleaned up. cc @rohangulapa
Update 1.0.4.4
- Switched to
task.defer
instead of having await()
at the top of the script - Removed
RBXWait
and switched totask.wait
, asRBXWait
is meant to be used for heavy bulk-yield tasks, which ClientCast is not meant for anyway - Errors are now shown better due to the
Signal
implementation switching to thetask
API, which propagates errors properly - Fixed an internal bug
Is there a difference between ClientCast:Stop() and ClientCast:Destroy()?