Hitboxes are annoying. For regular melee one time hitboxes i use :GetPartsInBox and other spatial queries, I have no problems with that. But even after searching and asking this question many times. This question still has been on my mind: how can i make proper projectile hitboxes? What I know so far is the fire the server for the hitbox, and fire all clients for the projectile model. But the server part is still what’s confusing me. Some examples of projectiles are:
Tiny projectiles moving really fast
Large projectiles that are moving slow
Curving projectiles that are affected my alv
If anyone has done projectile hitboxes or know a good responsive way It would be helpful if you would leave a comment.
Because im trying to find out my own way instead of using something already made easy. If i were to always use someone else’s resource instead of trying my own way I would be a horrid dev
I think you should practice using shapecasts, also base yourself on other developers’ code. Perhaps this way you will be able to develop your own methods, based on others.
Personally I dont like the feel of using raycasts for this sorta thing so I use a part, that I then move based on the size of it, I then use workspace:GetPartsBoundInBox in order to get anything it is touching.
The reason I dont use velocities to move the bullet is the strain on the server it causes, although Im not sure my method is better than using velocity at all.
Anyhow if you really cared you could always make is so the client that shot the bullet simulates the projectile, whilst doing server checks to make sure its following the right behavior.
Your right about the strain on the server but the server doesnt need to see the bullet itself thats why you i use a remote event with :FireAllClients so each client has a replicated copy with smooth movement. Only thing important on the server is the hitbox.
This could be inefficient. Too many requests on the server and the bullet will only be seen on the client. I see what you mean though.
You could create your own raycast module and add all the features you need by defining the volume / hitbox of the projectile using a Region3, then, use custom logic to move the region and and add features like projectile drop. For collision detection, you can use GetPartBoundsInBox and specify collision behavior with the default RaycastParams data type. If you encounter performance issues, consider using some form of batch processing or lower the frequency of collision checks to reduce lag.
You’ll need to move the hitbox forward the same length as the projectile to avoid skipping collisions. You can use the force to determine the length of the projectile, allowing it to move faster without missing collisions. For projectile drop, store the creation time of the projectile using Tick() and use the time difference as a parameter in an interpolation formula (Something like this).
Move the collision detection to the server and send the necessary information to the client for rendering. Relying on clients for collision detection can make your game vulnerable to exploiters and affect performance.
If your projectile is 2 studs long, you should move it forward by 2 studs per heartbeat. Moving it more than that could cause it to skip collisions, while moving it less could cause inefficiencies due to overlapping positions. Increasing the size of the projectile can make it move forwards faster, while not skipping any collisions.
I never rely on the client? My hitbox with the collision detection IS on the server but the projectile which is affected by velocity is on the client.
Hitbox and projectile’s are 2 different thing’s in my game
This is where we got it confused because my projectile’s use assembly linear velocity and linear velocity. I dont use heartbeat events to move them I use instances
If i were to use your logic, count the hitbox as the projectile to move with the heartbeat event. the actual projectile model, example: a baseball would be unimportant and just a model with effects.
I didn’t know your projectiles were actual parts. I don’t recommend using unanchored client side parts to represent the projectiles, as it could affect performance, require manual garbage collection, and Roblox physics are generally unreliable on the client.
How does it affect performance? If I manually anchor and use heartbeat its not gonna create the physic’s effects a regular projectile has. But this is for alv, for a regular linear projectile ill probably use your method, but it can also cause lag on the server cant it? And especially if i have many projectiles at the same time. Its better to put some of this work on all client since it doesn’t have the job of replicating everything to every player
As I mentioned here, you can simulate the physics to ensure you know exactly where the projectile will be at any time, allowing you to replicate the positions accurately.
I tested it with 2600 projectiles, and it ran fine even without optimizations like streaming. However, performance can vary depending on the player’s computer.
Can you show me some code of how it would look like?
I thought you said it was bad for performance?
Setup:
–Local Script:
UIS.InputBegan:Connect(function()
--Client code for when a button is pressed to tell the server to replicate the projectiles
Event:FireServer()
end)
–Server Script
local Force = 100
Event.OnServerEvent:Connect(function(Player)
ReplicateProjectileEvent:FireAllClients(Force)
--Code for the hitbox here, what im trying to figure out
end)
–Local Script 2
ReplicateProjectileEvent.OnClientEvent:Connect(function(Force)
--Creates the projectile with the linear velocity
local Direction = --Mouse position from the sent player minus the sent players charcter
LinearVelocity.VectorVelocity = Direction.Unit * Force
end)
This is what i roughly do to set it up but im willing to change it because idk what to even do atp