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.
Thanks for responding. By network ownership, you mean the ClientCast method of Caster:SetOwner(Player) ?
Let me set up a step-by-step situation:
- create hitbox part on server
- create ClientCast object on that hitboxpart, set it to Caster:SetOwner(Player)
- Tween hitbox part on the server
- Create visual projectile on client
- 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?
Also:
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.
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.
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
I am EXACTLY asking ClientCast related questions. Not sure what you mean?
This is about how to visualize bullets, not specifically using ClientCast for hitbox detection/other stuff.
Besides that, in this thread, only two people would be reading your questions. In that category, multiple people can give their expertise/suggestions.
I prefer to have the dev/OP respond if they can since they have stated that somehow detecting ray hits on the client precludes the need to update visual effects on the client. This same question posed on your suggested topic page, or any other, would all lead back to here since the questions is about these specific claims related to this module.
What I dont follow is the reasoning in this thread that detecting ray hits on client has anything to do with visual effects on the client.
The Module is great but Iâm just confused on how to turn Debug mode off
Open the ClientCast
modulescript and set DebugMode
to false.
EDIT: Do the same in the ClientHandler
localscript, too
Do the same for ClientHandler
too, and it should work