this is probably a dumb question but is this module safe to be required in every tool without heavy performance issues?
How can I blacklist all no collide able parts?
An easy way is to set them all under the same collision group. That way when you set your raycast params, set the collision group to one that doesn’t collide with that one.
https://developer.roblox.com/en-us/api-reference/datatype/RaycastParams
Alternatively, if it suits you better, group them all under the same model and blacklist the whole model.
Anyone have any advice for optimising networking with fastcast? I’m using it for my 3rd person gun scripts and the communication between client-server is taking up a lot of data, more than that is acceptable. Anyone have some solutions?
That’s weird, how come? What data are you handing over to the server? A resource I’d refer to regardless: BridgeNet | Insanely optimized, easy-to-use networking library full of utilities, now with roblox-ts! | v1.9.8-beta
This is all im handing over
FireHandler:FireServer(Gun.Barrel.FirePoint.WorldPosition,mousePos,Settings)
2 Vector3s and a Settings table for all the guns characteristics
You are barely handing over any data, also why are you handing settings over to the server that’s bad practice. You should do all checks server-sided.
I hand over settings because I have no way to check the settings on the server. Better said, I have no way to access the place settings are referenced.
Here’s how it currently works
Gun:
Client (Contains logic etc)
Settings (Contains all characteristics)
Gun sends information to server, server is a single handler that references a module script for how the gun hit detection and all that logic should behave. The Settings table provides all the info like, muzzle velocity, spread, and a multitude of other things. The server then simply uses given information to cast without any cosmetic bullets as that’s all handled client side.
Yeah that’s wrong because an exploiter can just change all that data up, also there are many ways you can go about what you said. You can have a table of different gun characteristics and then you check the gun type on the server and get the settings based off of that. If the settings are customizable by the user do datastore checks to ensure the player is eligible to use them.
Regardless, this doesn’t look like much data being sent at the server at all. Can you send a video of the guns in action and maybe provide code?
Ill show you the client fire function and the server cast and handover
Client
local function fire()
local now = tick()
--print("Fired function")
--print(mousePos)
mousePos = mouse.Hit.Position
if heldFire then
if now - lastFire >= Settings.FIRE_RATE then
--print(now-lastFire)
--print(now-lastFire >= Settings.FIRE_RATE)
lastFire = now
if Gun.ClipAmmo.Value > 0 then
FireTrack:Play()
if Settings.BULLETS_PER_SHOT > 1 then
Shotgun:FireServer(Gun,Settings)
end
for i=1,Settings.BULLETS_PER_SHOT do
print(i)
if Settings.FIRE_MODE == "Burst" then
if Burst < Settings.SHOTS_PER_BURST then
CastHandler:firePrimary(Gun,Gun.Barrel.FirePoint,mousePos,Settings,Gun.Parent,false,nil,nil) --all cosmetic
FireHandler:FireServer(Gun.Barrel.FirePoint.WorldPosition,mousePos,game.Players.LocalPlayer.Name) --Pure fastcast for hitdetection
print("Fired C")
camShake:ShakeOnce(random:NextNumber(.1,5),random:NextNumber(1,3),.1,.1)
Burst += 1
else
Burst = 0
heldFire = false
end
else
CastHandler:firePrimary(Gun,Gun.Barrel.FirePoint,mousePos,Settings,Gun.Parent,false,nil,nil)
FireHandler:FireServer(Gun.Barrel.FirePoint.WorldPosition,mousePos,game.Players.LocalPlayer.Name)
print("Fired C")
camShake:ShakeOnce(random:NextNumber(.1,5),random:NextNumber(1,3),.1,.1)
end
end
end
end
end
end
Server Caster
function CastHandler:firePrimary(FirePoint,mousePos,player)
LocalPlayer = player
LocalSettings = require(game.Players[player].Character:FindFirstChildWhichIsA("Tool"):FindFirstChild("Settings"))
CastParams.FilterDescendantsInstances = {player.Character, workspace.Bullets}
local origin = FirePoint
local direction = (mousePos - origin).Unit
local directionalCF = CFrame.new(Vector3.new(),direction)
local calculatedSpread = RNG:NextNumber(LocalSettings.MIN_SPREAD,LocalSettings.MAX_SPREAD)
local TauThing = RNG:NextNumber(0,TAU)
local direction = (directionalCF * CFrame.fromOrientation(0,0,TauThing)* CFrame.fromOrientation(math.rad(calculatedSpread),0,0)).LookVector
local modifiedBulletSpeed = direction*LocalSettings.MUZZEL_VELOCITY
--print("Recieved Direction ",direction)
CastBehaviour.MaxDistance = LocalSettings.MAX_RANGE
Caster:Fire(origin,direction,modifiedBulletSpeed,CastBehaviour)
end
Handler Handover
local RS = game:GetService("ReplicatedStorage")
local FireHandler = RS.Events.FireHandler
local CastHandlerRedux = require(RS.CastHandlerRedux)
FireHandler.OnServerEvent:Connect(function(player,FirePoint,mousePos)
CastHandlerRedux:firePrimary(FirePoint,mousePos,player.Name)
end)
Note: I took your advise and omitted settings from being sent from the client, the server now finds its own way to check the settings. This resulted in aboue 3-4 KB/s drop but still not entirely satisfactory for me.
Is this a single player game considering you aren’t showing the cosmetic effects to other players? Also you should validate the firerate on the server. Other than that it looks good to me.
Its for multiplayer, and cosmetics are being fired to other players by other means on an alternate channel using a system with slightly higher latency.
I’m still not happy with this system as a single automatic weapon can sent over 7KB/s at a .1 interval. And this bridge net you speak of, it can reduce that?
Say I don’t care about the physics of bullet drop, will client sided tween with fireallclients be smooth? Body velocity bullets are laggy right but if they are client sided cloned bullets fired with body velocity, will it still lag? To confirm this module is for physics applied projectiles that aren’t laggy correct? But to be more precise it is tailored to the physics bullet stuff?
I noticed when using this module with PartCache for machine gun bullets that random meshes in the environment would flicker when the bullet impacted the wall. I figured out it seems to be caused by the PartCache bullets being returned so far away and then being re-used right after.
Changing
local CF_REALLY_FAR_AWAY = CFrame.new(0, 10e8, 0)
to
local CF_REALLY_FAR_AWAY = CFrame.new(0, -220, 0)
fixes the issue. I assume returning it so far away does something odd with the render engine or something idk.
1 Like
How expensive is it to use FastCast.new()? Is it something I should be precaching as much as possible, or is it fine to make a new one any time I define a new gun?
edit: didn’t mean to reply but good info thanks
1 Like
It’s something you should generally cache as much as possible. On the client it’s fine to make it when respawning, for example, or when giving the player a completely new gun.
Basically, what matters is that you don’t create a new one when you could sensibly already have an old one to use that is readily accessible.
How would I measure the amount of studs fastcast has pierced through?
Hello! I was wondering how to fix the projectile rendering lag? Possibly a solution or change you could make? Or a temporary solution I could add? Thanks.
I’ve managed to reduce the amount of data being passed to the server for server based hit detection but something else is now bothering me.
There’s a noticeable delay between client and server casts. The client is obviously faster and handles all cosmetic stuff. The client fires to all other clients giving it cosmetic data on where the casts should be aimed and fired and all that.
The server handles purely casting and hit detection to reduce load on the server as my game has heavy reliance on guns.
Refer to this screenshot,
Red - Client trajectory
Blue - Server trajectory
Green - Client’s lateral movement
The server trajectory is milliseconds delayed behind the client’s which is still noticeable as in my game players move at high speeds making this delay have very noticeable effect.
A rundown on how the code works is that in the same client script, the client requires a CastHandler dedicated for simply cosmetic effect with no hit detection, while the server requires a special CastHandler dedicated for only bullet simulation and hit detection fired over the BridgeNet community module service as a foundation pre-empting high server loads.
Question now is, what can I do to minimise the delay or sync these two trajectories without sacrificing the blood sweat and tears ive put into network optimisation?