Until you get evidence that ping is handled by the server, please do not reply. thank you.
There is no evidence.
The first image you attached is a completely irrelevant Google instant-answers result. The âanswerâ it presents is stating that the ping utility (a command-line program used in various operating systems, not necessarily something to do with latency as a concept or anything that weâre discussing now) can be considered a client, and it goes on to explain that it is so because the program sends requests and processes the responses it receives. The fact that you either refuse to read what you picked as an argument or outright have no capacity to understand it is infuriating to say the least.
The second image shows documentation for the GetNetworkPing function, which is one implementation of ping and one which is specifically designed to output the server-client latency from the client side, as opposed to measuring latency from the server. This is cherrypicking and irrelevant as itâs just one non-traditional implementation, and was never even considered ever in this thread until you pulled it out of nowhere to fuel your idiotic agenda.
Youâre copy-pasting random irrelevant information you found on the web without even reading it.
1 Like
Hmmm, okay, so whatâs your evidence ping is in charge of the server?
And I think I know exploiting WAY more than you If you donât know that an exploiter can spoof any RemoteFunction arguments; meaning this can also be bypassed.
Now please; lets end this as I donât want to ruin this resource topic.
when you send evidence and then the guy says âhmm Iâm blind so no evidenceâ
just shut up please. apologies if itâs harsh but youâre completely wrong.
1 Like
The basic concept involves two connected network devices. For reference, devices A and B.
Device A sends a âpingâ packet to device B.
Device A starts a timer.
Device B is programmed to react to a âpingâ packet by sending a response after receiving one.
Device B receives a ping packet.
Device B sends a response packet.
Device A receives the response packet.
Device A stops the timer and calculates the time it took for the client to respond to the packet.
Device B cannot spoof its latency because of the following:
- It does not know when the server is going to send the âpingâ, therefore it will not know when to respond.
- The packet may contain a payload with a challenge that the client cannot respond to before receiving said packet.
- The packet shouldnât contain (but may in some implementations) any kind of timestamp or otherwise a self-reported time from the client that can be altered.
- The actual latency calculations are performed on the server as all that needs to be done is for a round-trip time to be calculated, which is restricted by hardware, therefore a client may artificially raise the response time but due to reasons above, as long as the implementation is correct, cannot lower it.
1 Like
Did you bother to read my response that points out how his supposed evidence has absolutely nothing to do with the topic at hand?
At this point Iâm just not gonna reply⌠You know nothing about ping, client.
When I test GetNetworkPing at server, it returns 0 both in game and studio.
The client may alter the RemoteEventâs payload, delay it from being sent or block it altogether, but as proven by me prior, as long as the ping implementation is solid, they cannot make their ping anything less than what hardware allows them to be. This is basic logic and basic networking.
Youâre assuming that the payload (or what you just refer to as arguments) carry data thatâs crucial for the server to calculate the ping off of. This is not true.
I presented an extremely oversimplified example of the model. If Iâm wrong about it, feel free to send your own idea on how the ping model works (which Iâd be happy to see to understand what kind of next-level networking concepts youâve come up with).
Very interesting, not sure what exactly youâre replying to, though, certainly not my post.
yes your post. it can be spoofed in seconds if this was even allowed. Here is why
You can use metatables to return a fake value when GetNetworkPing is called.
It certainly can, but you see the issue here is that no one is even discussing the GetNetworkPing function. This current topic revolves entirely around the concept of pinging, not one of Robloxâs implementations of it which specifically retrieves the value from the clientâs perspective rather than the serverâs. Neither OP nor I have ever suggested using this function because of its obvious security implications, it was only brought into this thread by âJeremyâ who thinks it has any relevance (which there is in reality none of), simply because itâs the only piece of irrelevant information he has to cling to.
I think you ignored my half of the post. It can be spoofed with your magical metatables.
Please stop. Being aggressive doesnât make your point any stronger, youâve consistently failed to provide any evidence of your claims in addition to to attacking anyone who disagrees with you.
2 Likes
This threadâs been derailed so far from its original intent â is it going to be closed or the above replies removed? The current discussion isnât constructive.
â
I donât understand â the underlined simply states that when the methodâs used in a LocalScript it can only be called on the LocalPlayer.
-- LocalScript
local plrz = game.Players:children()
table.remove(plrz, table.find(plrz, game.Players.LocalPlayer))
for _, plr in ipairs(plrz) do
print(plr:GetNetworkPing()) -- I assume either a value of 0 or nil for every other player
end
If it can only be used in a LocalScript I think the DevHub should be updated to note this.
â
I canât use this module, and there are few tutorials
Iâve stated I am making a new anti-cheat and discontinuing this one.
OK, Iâll try it when youâre finished, ha ha