Reproduction Steps
I’ll do my best to explain this in some detail.
I have this place open so you may freely test it:
RoClans Sword Fighting Arena
Check out RoClans Sword Fighting Arena. It’s one of the millions of unique, user-generated 3D experiences created on Roblox. Lametta, the King of Blades. An ideal environment for sword fighting at the most optimal level. Don’t let people cheat you…
The version of the sword inside of the game I linked above is currently using GetPartBoundsInBox, formerly it used GetTouchingParts and experimented with GetPartsInPart.
Onto the issue…
I’ll simply refer to all WorldRoot functions listed above and GetTouchingParts as WorldRoot functions collectively to simplify it, as they function nearly identically from what I’ve seen.
Although WorldRoot functions are supposed to gather information from the server exclusively, it would seem that manipulating the Grip has some strange ability to replicate the information of the tool’s position on both the individual client and the server.
Replicating: It’s very simple:
while wait() do game.Workspace.Player2.RCSword.GripPos = Vector3.new(0, 0, -5) end
Expected Behavior
This should not typically be possible because the server should only define one possible object within its “view” as the definitive frame of parts. In this case, the handle for the sword is the subject. The behavior is strange, it would seem to imply that both the client’s version of the sword and the server’s version of the sword are replicated but… that shouldn’t be the case because the WorldRoot functions are determined on the server which means the client should not have had an impact unless their part was replicated to the server.
I expect a possible reason for this behavior is due to the character model replicating to the server or how the tool replicates and behaves on the server. Expected behavior would be that the sword handle position as a result of changing the grip from the client would not be read by the WorldRoot functions run from the server. Otherwise if there ARE two different parts in this case, it should be visible as such from the server. Control should not be contested by client and server. In my opinion the server should definitely have complete control over this behavior but if the client has control over this behavior and replicates it to the server successfully, it is at least easy to catch. It currently exists in some limbo where it cannot be detected because while it is replicated to the server in its effects according to the WorldRoot functions, it does not actually have a visible change in the server.
Actual Behavior
Here is a simple loop changing the grip position from the character from the client side:
https://gyazo.com/6ce82a3a31b8bfc6120b15ebafeeab93
The WorldRoot functions reads both the client’s version of the handle and the server’s version of the handle as replicated and viable parts which is strange to me.
Context: I’ve been working on an anti for classic swords for a while and we’ve been constantly upgrading and making use of these swords for a while now. By exclusively determining physics logic from the server the sword is capable of preventing issues such as being resized or its hurtbox being manipulated in any regard. In short, it provides the client with less power but the trade off is obviously accuracy. In that same vain, however, I’ve created a system that actually just improves the accuracy of the character model. You can change the settings to make the character models more accurate using the gear icon on the top right. Auto-predict attempts to give an idea of where the opposing client is on their screen compared to the server and the position of the character model is re-positioned to their most accurate placement on the server.
I do this by essentially skipping the normal movement process roblox goes through when determining replicating movement from client to server. It is not intended for all environments above a number higher than 50, hasn’t even been tested with a number higher than 50 before, but to make it work is very simple: I have an event fire with the character’s position on their client and when it reaches the server, it determines how long it took for that call to occur and then it includes that difference to the algorithm for “auto-predict”. It re-positions the character model based on where their client is minus the quickness of the event fired on their behalf.
That was a longer explanation than I intended but I hope that gives some context for the swords.