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.
- Addressed a bug with
Caster::Destroyaccidentally destroying the whole object - this was a bug related to how debug trails were cleaned up. cc @rohangulapa
- Switched to
task.deferinstead of having a
wait()at the top of the script
RBXWaitand switched to
RBXWaitis meant to be used for heavy bulk-yield tasks, which ClientCast is not meant for anyway
- Errors are now shown better due to the
Signalimplementation switching to the
taskAPI, which propagates errors properly
- Fixed an internal bug
Is there a difference between ClientCast:Stop() and ClientCast:Destroy()?
Destroy fully destroys the caster object, cleaning everything up and not letting it be used again. Stop allows you to temporarily stop the hitbox, and then resume it again by using Start.
You can think of it as Part:Destroy() vs temporarily parenting the part to somewhere else.
Thank you for the reply. Do I need to edit the module or is there a way to show the debugrays when :Start() is called. The same applies for when :Stop() is called to hide the rays? I thought
would initialize and not activate the rays until :Start() has been called.
I don’t really understand your issue. Are you saying that the debug rays are being shown even before
Start is called? or are you saying you want the debug rays to show without having to call
Start? Or something else completely?
The debug rays are shown before ClientCast:Start() is called. It shows as soon as
is being called on the server.
That’s weird - shouldn’t happen. Go into the main module and in the
Settings table, set the debug value to
false. If that doesn’t work, then try calling
:StopDebug() right after creating the caster.
Thank you for answering. Just to elaborate what I was trying to do. I want the rays to be shown when calling ClientCast:Start(). setting debugmode to false removes the rays.
-- DebugMode is set to true in the module -- Initialize parameters local ClientCaster = ClientCast.new(Tool.Blade, RaycastParams.new()) -- Server gets attack input -- AttackRemote.OnServerInvoke = function(player) -- connecting "touch/raycast" event of the clientcast ClientCaster.HumanoidCollided:Connect(function(RaycastResult, HitHumanoid) end) -- Start damage when marker is reached in the animation AttackTrack:GetMarkerReachedSignal("StartDamage"):Connect(function() ClientCaster:Start() -- here i wish the rays would be visible end) -- Stop damage when marker is reached in the animation AttackTrack:GetMarkerReachedSignal("StopDamage"):Connect(function() ClientCaster:Stop() end) end
Some thoughts afterwards: Can you Initialize ClientCaster inside the attackfunction or will it leak?
I realized my mistake. Turning off debug and setting ClientCast:StartDebug() manually before ClientCast:Start() solved my issue. I believe there are no ClientCast:StopDebug(), but ClientCast:Stop() will remove the debugtrails regardless. Thank you for your help.
You know the server hitbox backtracking thing might be more plausible with the upcoming workspace:GetServerTimeNow(): Release Notes for 488