Once the client has hit something with that bullet, you just send the ID to the clients, and they’ll cease activity of the bullet. In order to make a bullet “hit”, you’ll need to give it a unique ID and tell each client that ID. You can then re-create the CFrame on the clients using this information. In terms of sending the data, rather than sending a CFrame, send the Starting position, and the position of the start CFrame moved 1 stud in the lookVector. Stagger the raycasts, so they’re only called every couple of updates.ĭo them per-update, but have a minimal amount of projectiles as to not slow the system down. Then, using the heartbeat/stepped method, you can iterate the projectile at any speed you’d like, using delta/tick() equations.Įssentially, how far do you want a projectile to travel per second? How long has it been since the last update? Multiply together, you get the distance the projectile should have travelled in that update.įor then using hit detection, you can do a couple of things. If you’re looking at shooting in a straight line, make sure you have your direction to begin with, keep note of the bullets “CFrame” but this can be stored as data, and a seperate CFrame can be applied onto this to make a 3d model work using it. HandleBulletHit(hitPart, hitPoint, hitNormal)īulletVelocity = bulletVelocity - (Vector3.new(0, workspace.Gravity, 0) * dt)īulletPos = bulletPos + bulletVelocity * dt Local hitPart, hitPoint, hitNormal = workspace:FindPartOnRay(bulletRay) Local bulletRay = Ray.new(bulletPos, bulletVelocity) Local dt = RunService.RenderStepped:Wait() Local bulletPos, bulletVelocity = originPoint, velocity My normal approach is something like this: local function fireBullet(originPoint, velocity)
I’ve actually done this myself a few times, too. Odds are that it won’t really be that bad. I would definitely benchmark this and see how it affects your game, though. Of course, there is still a fair amount of overhead from invoking the API. So you can cast a whole bunch as long as they’re not any longer than the one single ray would’ve been.
The overhead of raycasting has a lot more to do with the length of the ray(s), rather than how many rays there are. You actually don’t have to use a low resolution, either.
0 kommentar(er)
