Yeah realistically that should be the main concern I’ve done lots of optimizations myself you should be able to get your game down to 87 ping by connecting to changed signals instead of loops doing calculations only when needed replication lag etc
In that case only thing that lags is the Player itself
Somethign funny
POV: being the OP right now:
Opens phone
87 replies, InvokeClient Alternative?
on an empty baseplate i get 3000 ping, so doesn’t matter to me
it’s a joke
For example you are generating bullets in a game I noticed the replicated lag of something similar so i had the game build a cache of bullets and only replicate in batches when the cache is empty. Things like replication will cause lag so its best to streamline replication as much as possible. It’s a lot easier for server to parent an object rather than replicate one. So you will notice massive performance boost with this method on a large scale.
1 Like
what we can do to “look” smooth is if the raycast on the client work then show the damage to the player, then send it to the server
That makes sense, but it still doesn’t solve OP’s problem (which is unsolvable, by the way)
1 Like
I’ll probably just try and make it smoother by increasing/decreasing the hitbox Z position offset whenever the character is moving forward or not. Thank you @ARandomGuy_WasTkn @Dede_4242 @Magus_ArtStudios for trying to help though, really appreciate it!
2 Likes
well like i said you can do 3 raycasts one from client to the hittarget
one from server to hittarget
and one from a player hittarget. Also consider this idea for the replication of bullets. Say you have a magazine of bullets you replicate them all while the weapon is reloading and just grab one when you need it. This would make high firerate weapons work much better.
I did something similar recently with particle effects. I have my game randomly generate particle effects based on how high the player hit. But it was laggy so instead made it create a cache, it grabs the particle out of the cache and its completely lagless!
1 Like
Also, only one problem, with this there would be a higher lag spike when reloading, while replicating them when shooting makes the lag be homogeneous, it’s just which one you like the most (I think?)
that is simple because while the lag would be minimal all you would have to do is add task.wait() to each step so it waits a heartbeat for each bullet but realistically bullets are low poly not that hard to replicate but ive notice miniguns from free models have this issue with lag on high firerate due to replication. Especially when done on the server the player wouldn’t notice it much it all. but it would provide much smoother gameplay.
1 Like
Could you just weld it(probably with a WeldConstraint) to the humanoid root part? Then it would be very accurate.
Just make sure to mess around with its properties(massless, etc.) so that it doesn’t mess with the player’s movements.
I assume that this should work, but if it doesn’t please tell me!
EDIT: I just realized that this suggestion has already been proposed. However, I don’t understand why it wouldn’t have worked. I believe you can still get the position of a welded object, and this can be done completely on the server.
Yes but as it is welded to the Client, it still updates it’s position with a delay
Why is it welded to the client? Why isn’t it done in the server?
Because it is welded to the HumaniudrootPart, and it is controlled by the Ckient is updates on the Client and then tells the Server, thus making delays
OH. And i assume setting the network ownership of a player to the server might bring across some glitches.
Well then, maybe the hitbox should be moved to the player every time it moves, if there’s an event for that. If that’s not possible, then maybe make the hitbox bigger to accommodate for the potential lag.
And, as a wild idea, maybe add custom movement controls, but it’s probably more trouble than it’s worth.
Welp, if it doesn’t work, at least I tried. 
EDIT: Maybe try just detecting how close an attack is to the player, and then doing damage.
1 Like
You could use a mix of asking the client for their hitbox and making one on the server. If the clients hitbox is unreliable, like it’s too far off from their server htibox or there’s too much of a delay, you can just temporarily use the server hitbox instead.
Do not use InvokeClient(), unless you really, really know what You are doing.
You must have properly wrapped it in couroutines - it may yield for a very long time for lagging players or even indefinitely for exploiters. I am also unsure how it will behave if the player crashes or leaves the game during an invoke. You may also wrap it in a pcall(), but at this point I think it is better to simply use RemoteEvent anyway.
Fire in on server and have a “fire back” function ready. This way you are prepared if the fire back arrives late or not at all and there is really not any significant difference in execution time (if at all).
2 Likes
Your hitbox should be on the client, and the server should determine if the thing the player is hitting is really in range. If not, do nothing.
So, really, this isn’t a good system design.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.