ClientCast - A Client-based, Idiosyncratic Hitbox System!

[PysephDEV (Pyseph)]

You shouldn’t let clients calculate those sort of hitboxes - I recommend just setting the owner to nil (default).

[PysephDEV (Pyseph)]

Note

Not an update, but the GitHub repository has been updated with an MIT license due to it being requested.

[Stygian_Fleur]

Works well with my melee weapons.

But I wanna ask if it’s a good idea to use this for range too?

[PysephDEV (Pyseph)]

[Update 1.0.4]

• Re-structured the hierarchy - there is now no folder, but rather all scripts are parented under the main ClientCast modulescript.
  
• Added Settings.DebugAttachmentName
• Added Caster:SetRecursive(Bool) - when set to true, the Caster object will search for Raycast points (DmgPoints) from the whole object’s descendants, rather then the object’s direct children. Useful for models and characters.
• Due to the above change, ClientCast now accepts types other than BaseParts.
• Added read-only Caster.Recursive property
• Fixed Caster:SetObject not working as expected
• When destroying a caster or switching invoking Caster:SetObject, the debug trails are deleted alongside it

[Splixent]

If you add and remove DmgPoints the DebugBeams duplicate them selves. I’m not trying to have 300 Attachments in my character at all times, so can you make it so it only creates the debug beams with the current DmgPoints that are inside of the Object you are raycasting from?

[PysephDEV (Pyseph)]

[Update 1.0.4.2]

• You can now parent and destroy DmgPoints without any mishaps (cc. @Splixent)

[LordEmotionless]

add something to auto ignore the tool or the model where the DmgPoints are

[iamtryingtofindname]

Is there any type of anti-cheat for this? Players can easily spoof this. For now I think I’ll use ray cast hit box.

[OminousVibes0 (OminousVibes)]

You can just use .Magnitude and tick() to check if the hit was valid.

[PysephDEV (Pyseph)]

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…?

[PysephDEV (Pyseph)]

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.

[iamtryingtofindname]

@PysephDEV

Also, I don’t see why it’s hard to implement a Magnitude check…?

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

[PysephDEV (Pyseph)]

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.

[iamtryingtofindname]

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

[PysephDEV (Pyseph)]

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!)

[Nerbzzz (Nikki)]

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?

Raycast Hitbox 4.01: For all your melee needs!

Current Version: V.4.01 Stable (09/21/2021) Upgrading from 3.xx to 4.0 Please note that V4 is not backwards compatible with V3. There are a few API changes that were introduced in V4 to better suit modern code etiquette. Here are the changes you need to know if you want to make your code compliant with V4: Raycast Hitbox 4.01: For all your melee needs! - #597 by TeamSwordphin Notable Features Accurate, performant, and easy to use! Use attachments or vectors to make your hitboxes in secon…

[PysephDEV (Pyseph)]

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.

[crazygamer817]

does this use the raycast hitbox module?

[PysephDEV (Pyseph)]

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.

[crazygamer817]

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?