Hello im made a beam attack but recently discovered the multiple rotation changes and position changes in the script makes the server become more and more laggy each time a beam is fired, is there a way I can decrease the performance? if not, then which beam design is better in terms of performance?
( The old one )
( The new one ( The triangular bit is the bit that is scripted to constantly rotate and the actual beam is scripted to constantly go big and small in size ))
i recommend rendering all visual effects like beams on the client instead of the server. That should fix most of the performance issues
How do I do that, do I use FireAllClients(the objects,their position) in a server script then OnClientEvent(objects,positon) in a local script
One way I would do it is by firing an event to all players within a ~400 stud radius (players further away than that don’t really have to render the effect), along with all the data required for the client to start rendering it. For example, the effect name, position, and duration.
It’s best to keep the event request data as small as possible to avoid excessive bandwidth usage and potential high ping when a lot of effects are being spammed.
So I should only put the tweens, the time of the effect, the actual objects in the effect in a FireAllClients()
The tweens (managed by TweenService) and objects (stored in ReplicatedStorage) should be exclusively handled on the client side, without the need to pass them through the event. By only sending the effect name and, if necessary, additional data like position and specific duration, you can let the client do the majority of the “heavy” workload.
As mentioned before, i recommend to fire the remote event only for clients within a certain distance from the effect’s spawn location (e.g. 400 studs). This makes it so that players on the other side of the map, who won’t be able to see the effect, won’t need to render it.
Example of the server code:
for _,Player in Players:GetPlayers() do
local Character = Player.Character
if Character then
local Distance = (Character:GetPivot().Position - EffectPosition).Magnitude
if Distance < 400 then
-- fire remote
end
end
end
Hey bro im having a lil problem, I got the orientation to replicate just fine but the size doesn’t replicate properly because the script makes it move forward ( as it’s the hitbox ) but the local script makes it get bigger and smaller in size as an effect but the two seem to clashing which makes the beam bug, so should I tween the hitbox on the server and the rest on client
How are you doing this? Seems like you are explicitly firing a remote with the specific size multiple times. Just fire the final size once and handle all tweening/animation on the clien.
heres what im doing
this is the local script for the vfx
spawn(function()
while Object ~= nil and wait(Duration) do
local Info = TweenInfo.new(Duration,Enum.EasingStyle.Linear,Enum.EasingDirection.Out,0,false,0)
local Goals = {Size = Object.Size + One}
local tween = game:GetService("TweenService"):Create(Object,Info,Goals)
tween:Play()
tween.Completed:Wait()
local Info = TweenInfo.new(Duration,Enum.EasingStyle.Linear,Enum.EasingDirection.Out,0,false,0)
local Goals = {Size = Object.Size - One}
local tween = game:GetService("TweenService"):Create(Object,Info,Goals)
tween:Play()
end
end)
then here’s the server script (dont mind the indenting it bugged when I pasted)
spawn(function()
while wait(0.01) and v.Size.Z ~= 1000 do
repeat wait() until vd.Value == true
v.Size = v.Size + Vector3.new(0,0,24) -- this makes the hitbox go forward
v.CFrame = v.CFrame * CFrame.new(0,0,-12) -- this is so that the hitbox doesnt detatch from the point it's created and start flying mid air
end
end)
I’m sorry but this seems like the worst way to go about doing this. Would you mind elaborating what you are tryna achieve?
You don’t need to move the part every time your resize, instead rather than adding to the size, just do vfx:Resize(Enum.NormalId.Front, 24).
Should I put this in the server script or the local script
Edit- Nvm this worked ty
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.