Maybe set the NetworkOwner to the player who attacked and then set it back to the original player?
1 Like
The problem might be just the studio built-in-lag: It tries to simulate an actual game server lag but its waaay too overpowered. You should try this is the roblox client and see if its still that laggy… I don’t see any other solutions if this doesn’t work.
2 Likes
Not a good idea, would open up major security issues
Doing that means the attacker has full physics control of the victim’s character
1 Like
This is actually a clip of a live server. The second player is my alt on mobile, I thought what you said was the problem so I tried a live game and it persisted
I know it’s possible to accomplish smooth and instant knockback because Grand Piece Online has done it:
Anyone have any ideas on how?
1 Like
Can’t you set the NetworkOwner back to the player after the attack?
Pretty sure this would make it laggy on the victim’s screen then.
Making another player own someone else’s character is just a bad idea in general
That is true, you shouldn’t be giving a player control of a character that doesnt belong to them. It could lead to errors and more lag i guess.
Still need help on this
This game has also accomplished knockback really smoothly, how do I do it?
On the client on successfully hit clone the enemy and do the effects on the local clone while making the server side invisible.
Simultaneously do a remote function by the server if it’s ok then continue else cancel it and interpolate tween the local clone to the server sided enemy and make the original server sided one visible.
Something about doing client sided effects.
Luckily knockback should be predictable and describable both on server and client through projectile motion equations which can be time synced.
Doubt any game with heavy combat does that (opens up too much extra work, also you’d be able to see if the character is getting cloned) but thanks for your suggestion
Do you have any other ideas? I’ve been stumped on this for about 3 days now.
I’ve switched to BodyPositions which gave me a better result, but the delay is still there, and it’s only smooth on the victim’s client like before
You could also try creating a hitbox on the attacking client and when it hits an opponent, it moves them on the attacking client’s side
You can prevent this by cloning the character ahead of time.
Maybe you are just lucky to have good enough internet. In my olden fighting game experience on roblox, it’s usually what I remember from these two videos below, perhaps a better test would be to stand far away from your router so your internet is 1 MBps and then play grand piece online and see what happens:
Maybe you are overthinking this problem, It should be good enough for people with good internet, maybe focus on other areas of your game instead.
Otherwise, go for the completely client sided and custom replication approach, no other way.
Maybe even @octav20071 set network owner with sanity checks should work especially for the attacker, if the character gets flinged with abnormal velocity or destroyed then you know something is sus. Might even be the simpler method.
1 Like
That’s what I thought too, but my internet is fast and my ping is always really low, but this problem happens consistently only in my own game. It’s a widely known problem with BodyMovers and using them for things like this, I’m just trying to find a fix (no actual fix info I’ve found yet).
I’m going to keep trying (probably going to try setting .Velocity next) , because thanks to these games, I know that it’s possible. (And I’m positive the client clone method isn’t the way although thanks for the suggestion)
Getting this right is crucial to how the game will feel, hence why I’m trying so hard
If you haven’t found out, just tween~
1 Like
I don’t think that is true. BodyVelocity is an outdated object I strongly advise not to use it.
FireClient then ApplyImpulse on the client. SetingNetworkOwnership to Server is not recommended as not only do you have to detect when the player landed and set the networkownership back to the player. You will always have latency. It’s something unavoidable.
You could use an invisible part and fireclient() the opposing player’s position to the part with a tween
1 Like
The problem with tweening is that it gets abit glitchy especially if you’re being moved around while tweening and it has a kinda laggy jittery effect on players. I don’t experience the same issue as these guys but I wouldn’t recommend using tweening to fix it tbh.
Ye, I’ve long since changed my method of KB. Forgot about this post and didn’t correct it.
3 Likes
So I have done some testing since this is a frequent recurring and interesting topic. So I have done testing with the server network ownership method, the only cons I see is that it’s not smooth for the victim perspective.
Video testing, with 0.25 seconds incoming network replication lag:
Video uses:
-
.AssemblyLinearVelocity += knockbackVelocity (simple instantaneous velocity method)
-
Humanoid platformstand (to disable humanoid physics interference)
-
Network ownership on server (In order for the server to be actually able to control the client physics)
Here is the place file, fire it up with two or more players:
KnockBackTesting.rbxl (35.0 KB)
That’s true but it seems to be overcome able by setting an arbitrary time like 0.2 seconds. The only major issue is as aforementioned with the victim client perspective being not that smooth.
Plus the fire client method seems odd for the responsiveness of the attacker
attacker client → server → victim client → server client → attacker client
Compared with the server method
attacker client → server → attacker client and victims client
However it seems to guarantee to be more smoother for the victim got a test file or video to share?
6 Likes
If the attacker is an exploiter
They can just fling the oponent out of nowhere before the attack even ends