TLDR:
During animation, at a precise time a trail is getting enabled on client. I want it to be replicated to server (or at least other clients), but remote events are not an option, because again, it needs to be enabled for a short time at a precise time, and remote events may replicate it late depending on the ping.
More Details:
I’m making a melee combat system. I want the hit detection to be client-sided, because the hitbox depends on the animations, and if I make it server-sided, then animations have to be server-sided too, which will feel very unresponsive (especially cuz there is a precise timing combo system).
So when animation plays, after the windup of animation is completed (I know it’s completed by :GetMarkerReachedSignal), a hitbox starts and a trail is enabled. When animation stops (ends), both hitbox and trail get disabled too.
The problem is this is client sided, and while for the damage I don’t care about even 1-2 seconds latency, the trail needs to be precise to miliseconds. So I can’t use remote events to replicate the trail to server or other clients.
How can I replicate it without latency?
2 Likes
I don’t believe there’s a big delay between animations and remote events nor do I think animations will lag if the host player lags (though I did minimal testing) so you should be able to send a signal saying the animation started and put the trail on a startup delay, but to get more precision I suppose you could run :GetPlayingAnimationTracks() on the attacking player, see how far along it is and wait the remaining duration before toggling the trail if it really is offset by a short amount. edit: or use the markers you talked about!
I’ve also found it’s nice to keep the visuals to the clients so you don’t have to worry about jittering that appears when moving/tweening server objects
2 Likes
This might work, I’ll try it out later today. Thanks for the advice.
Still looking for other solutions too, if anybody knows of any.
If you mean keep it only to the client that is attacking, that is not really an option, because I want the players to have as much feedback from each other as possible, for successful blocking/dodging.
If you meant keep it to all the clients, but not the server, also not an option, because I’d rather have very little and very rare jittering on the server, than double the latency by doing client-server-all clients, instead of a simple client-server
1 Like
Can you emphasize what you’re referring to when you said “Double the latency by doing client-server-all clients”? I think I’m misunderstanding what you’re trying to say.
The way I understand it (which may be wrong, as I haven’t done actual latency testing), is this:
If you’re replicating to the server, you just do 1 remote event firing Client-Server.
If you’re replicating to clients only, you do 2 firings Client-Server, and Server-All Clients.
So by my understanding it takes double the ping to do the same action. Correct me if I’m wrong.
Think of it as there’s a delay from everything on the client to everything on the server and vice versa, regardless of what it is. The data has to take time to travel to each medium (client to server to client) and is never instantaneous. Remotes are just a way of sending that data, they’re affected by the players ping (time it takes to contact the server) as much as updating properties, moving character models, running animations, or anything else is.
1 Like
A good way to see this for yourself is to go into the studio settings under the network tab and upping the Incoming Replication Lag setting, then start a local server with two players and observe the 1s delay between movements from one player to the other.
Here’s a tutorial (which I believe is an archive of an official Roblox one) that can help you work around these issues, and here’s the laggy cannons place which is utilized in the tutorial.
1 Like
What’d you end up doing, if anything?
