My current project involves a hovercraft that can shoot lasers. I’ve noticed that the lasers have a very small delay after creation before they actually begin moving. In order to eliminate all variables, I decided to isolate the issue with some simple scripts and parts, but I still get the same issue.
I used the following script:
while wait(3) do
ball = workspace.Ball:Clone()
ball.Anchored = false
ball.Transparency = 0
ball.Velocity = Vector3.new(30, 0, 0)
ball.Parent = workspace
ball:SetNetworkOwner(nil)
end
I then modified the loop so that the parts were created ahead of time (and hidden due to transparency), and then revealed and given velocity later, which gave a much more desirable result, using this code:
nextBall = nil
while wait(3) do
if nextBall then
nextBall.Transparency = 0
nextBall.Velocity = Vector3.new(30, 0, 0)
end
ball = workspace.Ball:Clone()
ball.Parent = workspace
ball:SetNetworkOwner(nil)
nextBall = ball
end
So I thought maybe I could do this in my game, and just create the lasers ahead of time and hide them out of sight until they’re actually fired, at which time I’d reveal them and teleport them to the correct starting point. However, I used the same script as the one above, adding one line that changes the CFrame of the part before giving it velocity, and it looked exactly the same as the first video, with a short delay before it actually moved.
Is there any way I can create a part and have it instantly begin moving from the client’s perspective? (I noticed that on all of these tests, it did in fact move instantly from the server’s perspective)
To start off, for your laser shooting system or what-not, if this something the server does alone, disregard what I’m about to say, however, if you desire for select players to be shooting these lasers, then I would actually recommend to set the NetworkOwner of each laser brick to the player who is shooting them. That alone might yield you some success. As far as the whole concept of creating the lasers ahead of time and keeping them hidden, well, that may not be the best route to go, as that potentially could cause some lag overtime, depending on a variety of factors.
Unfortunately the way I have my game setup, and the way it needs to be for this particular game, that’s not really an option. The network owner needs to be the server.
This didn’t work as an option anyway. As I said…
It has the same delay effect whether it was just instantiated or just teleported via cframe. If I create the object ahead of time, it won’t be located where it needs to be and must be teleported, which doesn’t wield any better results.
Oopsy, guess I didn’t comprehend the last part of your post. My bad!
Well, one method I’ve used for making weapon projectiles for an old game worked pretty well, keeping the bullets smooth and spawning immediately when the player shoots a gun. The method I came up with worked pretty well, however, I don’t take pride that it’s the best possible system. (It probably isn’t even close.)
Any way, one way you could do it is so like, you draw the lasers on the client and when the lasers touch something they damage, just call in a remote event to the server from the client to damage whatever that is. Then, destroy the laser from the client.
assuming that for your game you have FilteringEnabled on
EDIT:
Totally forgot I missed an important concept in there. If you decide to go that route, other players won’t see the lasers. Only the players who fire the lasers will see them. So what I did to solve this was I called into a remote event to draw another laser to every other client in the game, with the same orientation and launch angle, all that stuff. Therefor, every player will get to see the laser you fired.
who doesn’t these days? non-filtering enabled games can only be played by people on your friends list now so they’re pretty much dead.
Also, couldn’t the same thing be accomplished by keeping the same shooting system I have with the server right now, but in addition make the client create its own copy of the laser, and delete the server’s copy locally from the client?
Well, I suppose you could do that. It might get tricky to keep track of everything, but I mean, it could work.
Not really sure the whole system you have or anything, but it’s just something to try. It definitely makes it smoother because if it’s created on the client alone, it renders for said client and there’s no communicating between the server to render that object. I hope that makes sense… xd
I get the whole server-client delay thing, and I may try this approach. But I’m still confused though, because the behaviour I’m getting still isn’t what I’d expect. What I’d expect to see with the delay between server and client is potentially a bit of delay before the part is created, but when it is actually created, that it would already be moving. This still wouldn’t be ideal for making it shoot instantly, but I just find it bizarre that there’s a delay between two actions in the script even though there is no yielding, rather than simply a delay before both actions happen simultaneously.
Well, it could possibly be because you’re setting the Velocity of the part. Maybe, I’m not sure on that, I just sort of remember something like this happening to me in the past, and it was related to the Velocity property.
But I would recommend rendering the lasers client-sided alone, then just casting the data over to the other clients by some means. This way would definitely give you instant results for sure.
the obvious potential downside to this is desync though. If you’re lagging significantly, it may look like you hit someone on your client but in reality you hit nothing on the server. Guess it depends whether you value instant shots or reliable shots.
That’s true. The only time I’ve actually practiced using a system like this was in a game where you had to destroy a bunch of NPC’s. Looking back on it, I see no risk for anything, as it’s not a PvP kind of game.
But yeah, that is definitely a factor. At the same time, however, I’ve heard that Fortnite does the projectile checking on the client to take damage, pretty sure that’s true honestly. It’s really a matter of preference, I guess. If you stick to the server you’ll get more consistent results regardless of client latency, but the result of that would be delayed or slower bullets.
The only apparent reason this occurs is server lag, even when nothing is putting stress on the game, this was an important aspect for the laser effects on my game here:
The only way I was able to make the effects lag free was doing local replication of the bullets effects themselves, when a client creates a laser, it’s replicated to all other clients and deletion is also replicated. This surprisingly did not cause any lag to the clients and will overall help your game running smoother without potentially thousands of moving parts running on the server.