Actions which must be done every frame should be scaled to match the length of time between frames, this is commonly referred to as the frame delta time. Ie if you want to move a block at 1 stud per second then you would do the following
function updatePosition(delta)
part.Position = part.Position + Vector3.new(1, 0, 0) * delta
end
This block will now move at 1 stud per second along the x axis regardless of the current fps.
For more complicated actions (such as firing a gun at 3000 rpm (50 rounds per second) when the client is only rendering at 30 fps) you need an accumulating delta value. On each frame you add the frame delta to a value, then when you fire a bullet you subtract a set value. Here is a quick example which an fps around 30 and a target fire rate of 50 rounds per second (or a shot every 20 ms).
etc. As you can see this will fire multiple shots per certain frames to keep up with the target frame rate.
Now with Spawn() I wouldn’t worry about performance concerns. You can think of it as like running a new script alongside. I doubt you will see any performance hit unless you are being super wasteful. As for the slight delay after calling Spawn(), the scheduler will schedule it to run on the next Lua frame which is typically around 33ms.
A while loop is a standard feature of Lua and is not specific to Roblox or to you. It has nothing to do with ‘frame rate’ unless you set it up so that each iteration yields until the next frame or something similar.
Regarding your original post: magnalite gave some helpful advice. The code that FracturedSoftware posted unfortunately will not work because they haven’t called the Connect method of the RenderStepped Event. What I imagine he is suggesting you do is use the parameter passed when the Event fires (time since last render frame) - this will help you follow magnalite’s advice:
to add to magnalite’s reply, also be aware of the difference between a variable time step as opposed to a fixed time step. RenderStepped’s step param is an example of a variable time step, because the user’s frame rate can change over time (i.e. each step is not exactly equal). Depending on what you’re doing (esp. physics calculations) this can introduce some subtle, hard-to-crack bugs; I learned this the hard way when I was attempting to create a deterministic billiard sim in Roblox Lua (TL;DR variable time step is neva eva deterministic)
to solve this problem, implementations typically use something called a time accumulator. Here’s a quick and dirty example:
local RenderStepped = game:GetService("RunService").RenderStepped
local GameRunning = true
spawn(function()
local deltaT = 1/30 -- the fixed time step
local currentTime = tick()
local accumulator = 0
while GameRunning do
local newTime = tick()
local frameTime = newTime - currentTime
currentTime = newTime
accumulator = accumulator + frameTime
while accumulator >= deltaT do
-- sim is ticked with the deltaT arg here
accumulator = accumulator - deltaT
end
RenderStepped:Wait()
-- interp can be done here
end
end)
edit: something I forgot to mention - if you want to do interpolation, then the state of the last tick has to be cached (otherwise you have nothing to interpolate)
also, this example is not optimized - it can be by utilizing that step parameter from RenderStepped for frameTime instead of calculating it ourselves. Additionally, the above code will run VERY HOT, so you have to be extremely careful about what you’re doing in it
ANOTHER thing to consider (I know I’m making many edits ) for more consistent performance: it may be a better idea to use RunService.Heartbeat rather than RunService.RenderStepped if what’s being done in this code is game logic (rather than visual effects), due to how the rendering pipeline works. @buildthomas provides a good overview of why here (I swear this is my last edit)
You mean 1.6 seconds per bullet for the pump shotgun and 0 seconds for Minigun? How does that work? You can’t have a 0 second wait, that’ll crash your game…
Doesn’t seem to crash for me, unless I have some kind of wait function in place already.
All I know is that the Minigun shoots as fast as it’s supposed to when the game’s not running badly. Which is about 10-20 bullets a second last I checked.
Lag is a problem that you need to attack by determining what you can make more efficient. Do this by following this procedure:
Are my users complaining about lag?
Is this affecting gameplay?
If you answer yes to any of those questions there is a problem, and your next step is determining what is causing all this lag you are facing.
You said that your pain screen lags… What is the current code for that ? There’s no reason for that to lag.
Last question, are the bullets being ceased to exist? (Meaning they dissapear from the map entirerly)
If so it’s probally the script overcharge that the game has, probally the other scripts are lagging the other one because that one is charging while the other ones are charging.
If not, it may be the splashing amount of accumulated bullets from the world, if it’s a pump shutgon, it makes 6-8 bullets per 2 seconds (If spamming click) if you do the maths, that will be 4 bullets maximum stored.
Also, when you first join a map, the Console is spammed with remote event errors, saying that a RemoteEvent is exhausted.
I might have a separate event to handle sending said projectiles to the clients, instead of relying on a single one to receive the single and send it to the rest of the players.
) for more consistent performance: it may be a better idea to use 