What is the best way to make an automatic-gun server sided without lagging the game?

[ComplexMetatable]

I set a variable of mouse down and I used a while loop waiting 0.08 seconds each time to see if the value is true, and if so it will just fire the bullet. But, I can not access the player’s mouse from a Server Script. I succesfully made a client-sided automatic gun but not a server-sided and it is a relevant issue to quality.

[ComplexMetatable]

That is the exact issue I am looking to solve.

[ExcessEnergy]

The best solution, is just not to do it at all. Use both the client and server, as it will greatly balance out the work load.

What is the reason you are looking to use only the Server? If you are worried about exploits, than you would be happy to know that you can prevent most exploits, by performing server sanity checks, as I mentioned in my post above.

[ComplexMetatable]

I am worried that it will effect the quality of the game.

[nicemike40]

That didn’t make a lot of sense to me, but you don’t need to constantly loop like that. Use RemoteEvents to trigger things on the client from the server and vice-versa.

[ExcessEnergy]

Can you elaborate on this? Using the client to handle effects first, will actually greatly increase the quality of your game, as it will minimize the shot delay to almost nothing for the local player.

I still don’t understand the point of a solely Server sided gun.

[IGOTHISLOL]

This is the way that I use, referencing to a cool scripter

@ThatTimothy

local lastFire = 0
local shootDelay = 1 / 3 --3 shots a second
local held = false

local function shoot()
    local now = tick()
    if now - lastFire >= shootDelay then
        lastFire = now
        --Run code to shoot
    else
        --Let use know they have to wait, if you want too
    end
end

game:GetService('UserInputService').InputBegan:Connect(function(i, gp)
    if not gp and i.UserInputType == Enum.UserInputType,MouseButton1 then
        shoot()
        held = true
    end
end)

game:GetService('UserInputService').InputEnded:Connect(function(i, gp)
    if not gp and i.UserInputType == Enum.UserInputType.MouseButton1 then
        held = false
    end
end)

game:GetService('RunService').Stepped:Connect(function()
    if held then
        shoot()
    end
end)

[ComplexMetatable]

Well, as I reminded it’s automatic, I am just going to lag the whole server if I will fire a remote event each time.

[ComplexMetatable]

It is client sided. I am looking to make a server sided one. Do you have any ideas of making it without lagging the whole server?

[ComplexMetatable]

I’ve seen it used in some games like Jailbreak. I do not really know how they made it server-sided (the bullets) without lagging the entire server using remote events (it’s automatic).

[nicemike40]

You’re lagging the server with a loop. A few remote event invocations a second won’t hurt things. If you have a value that’s replicated from the server to the client, you’re going to have the network lag anyways, plus the busy loop.

[ComplexMetatable]

Imagine firing 30 remote events in less than 5 seconds. And the loop I am using is client-sided. And when I tested my client-sided automatic gun it did not really effect my network or lagged my game.

[ExcessEnergy]

I’m sure Jailbreak, and any of the popular games involving shooting for that matter, don’t stick completely to using only the Server. I am almost certain they process the shot on the client first, before attempting to do checks and inflict damage.

Now the visible bullets are a different story. Keep in mind that it’s not firing the remotes themselves that causes lag, but what happens when the request is received. As long as you build your bullets right, you shouldn’t have that many lag problems. 30 bullets a second is a little excessive though.

[ComplexMetatable]

I am just going to leave this idea of server-sided bullets. Thanks everybody for your answers!

[BallisticOperator]

I ran into that issue as well, roblox servers aren’t powerful enough to hold a in game complex gun script.

[ExcessEnergy]

I would try it out, and experiment with it. If performance is fine, leave it, otherwise make due without it.

Also, remember that it’s only the visual effect of the bullets you are replicating on every shot. The damage should be done separately, so that the Server only does with sanity checks, if the detects a hit first.

[ComplexMetatable]

I do plan to make the damage server-sided, but I want also the bullets to be server-sided I am worried it will effect the quality of the game. Nowadays, most Roblox games have very high quality so players are only playing high-quality games.

[ExcessEnergy]

This is why I originally was against the idea all together. However, if you do it right, and keep the visuals simple enough to process, I believe it would be doable. It’s definitely something you would need to experiment with, and only use if you find a performance cheap way to visualize bullets.

You will also notice, that games that do this, don’t have guns with a super fast fire rate. Games like Arsenal, would never attempt visualizing bullets on the Server, as with the crazy fast speed of their guns, it would break the game.

[BallisticOperator]

Right, thats alot of toying around, as long as you stay organized and constantly stress test you should be able to do it, take ACS for example.

[darmantinjr (dar)]

Bullets do not need to be rendered by the server. Quite literally the only thing the server needs to process is hit detection, damage, and replicating these changes to other clients.

Ideally the client will raycast first. If it hits, then it will render the bullet for the client only and tell the server that the gun has been fired. You should pass the mouse position to the server when doing so. The server then fires it’s own raycast to “verify” this bullet and apply any stats necessary server sided. Lastly the server will fire a remote to all clients (excluding the one who shot the bullet). This remote indicates that the other clients should render the bullet (usually only within a certain distance). This remote can also pass other valuable information such as what the bullet hit. This is useful for playing sounds or effects + the client that got hit by the bullet can render those effects as well.

You should delegate almost everything to the client that doesn’t need accurate verification.