Why would you want this? This would make your game seriously vulnerable to exploiters, and exploiters would take huge advantage of this. This is basically disabling FE, which is no longer possible, but you are doing this by trying to replicate anything client side.
1 Like
I have a project of mine which would deal with those security loopholes. I haven’t started it yet, but I know how to secure it so far. It involves unique keys on the server and client to avoid network identity fraud.
Basically if you are going to see what the name of the instances are, if I where the exploiter I could execute an FE script, and make the script name the name of the instance that you are checking for to secure.This still makes your game extremely vulnerable, even if you check classtype for the script if it is a local or serverside or a model, they could make whatever that instance is and the name , and still insert a script in there.
Why not just use a RemoteEvent and pass it through there? It’s more secure & you still pass the data through.
Like Thomas said, this is a lot better option. I still do not recommend to do any of this, unless you are checking what the new instance has to replicate to all other clients.
With all due respect, I am not asking for advice on security, I simply would like to know if any such instances/properties exist. I had already considered these security drawbacks, that’s why I wanted to make this project; to experiment with anti exploiting using my own methods.
I will attempt to help you make this possible, but you are allowing exploits to be used in your game by sacrificing security.
remoteEvents are not instant, that’s why I desire an instantly replicating property.
Any BaseParts network owned by the client will have their positions specifically replicated to the server. Sounds also synchronize playback specifically, and no other properties. Locally created sounds I believe are not replicated to other clients. This is also all with SoundService.RespectFilteringEnabled false, which it is by default. Every other instance/property I know of either has to be replicated from server to client, or the client uses a remote to make the server change it for them.
1 Like
Also, no replication will ever be instant, that would only happen if the client’s computer had like an ethernet cable connected to roblox’s server or something like that.
Thanks, I suppose this
can be used to send cframe data. Was more looking for something to replicate strings, but this is still helpful!
1 Like
Not litterally “instant”. When animations are played on the client, the other clients see the animation played at the same time/nearly same time, correct? This is what I meant.
I should have replaced instant with, “faster than a remoteevent”
1 Like
This is completely dependent on the person’s internet and overall connection to the server, plus what you are doing in your script. It’s as good as instant, and you aren’t going to get any faster currently. You’d have to do your own testing to see what benefits you gain from network ownership, just know that network ownership can be extremely laggy and stuttery compared to your own Remote Event and custom interpolation methods.
2 Likes
Remote events/functions can and should follow the same behavior with the right set-up, as long as the server responds as soon as it can, aka no waits anywhere in your event listener, and your client just times their response with their server ping, aka when the response is returned.
Thanks for the helpful replies, everyone. I now realize that there is no truly “instant” communication, not faster or more reliable than a remote event any ways.
But for the heck of it, I’ll share my original idea I was going to make
It would use TagService, and detect new information by listening for new tags added to a listener object.
an example of a message would be:
“FGvH62V–Vector3 = (0,0,0), command = “Fly””
FGvH62V - ID tag
–Vector3 = (0,0,0), command = “Fly”" - actual info sent
In the server, I would make a unique ID for each client, and then send that ID to each client respectfully.
Then on the client, I would make a unique ID for the server, then send that ID to the server. Using these IDs, each client would protect against “fake” server tags by verifying the string with its unique server tag. And vice verse with the server.
I realize that tags don’t even replicate in the way that I thought, and also there’s some big loopholes in the whole “ID” system. (free editing/removing permissions from all clients ruins this)
1 Like
Is the ID tag used for full on security because a client can make use of remote spies
You seem to not understand how replication works.
To begin with, you said that animations replicate instantly. They in fact don’t. Roblox is constantly “firing their own remotes” although you can’t see them being fired.
You also seem to misunderstand how replication works. No matter what, information from the client to the server has to be sent in packets. It’s never instant. RemoteEvents aren’t noticeably slower than anything else that Roblox uses.
You should just use RemoteEvents. They’re safer and easier to use than whatever you’re trying to do.
Did you read my reply to the solution? I understand it now
I was writing that reply right when the post was created, and stopped to do something right before posting.
My bad.
1 Like
This means that any change scheduled for replication can be delayed up depending on what was sent before it. Unfortunately I haven’t found that documented elsewhere.
You can check at what stage your data was received by connecting an event and profiling it on with os.profilebegin("label"), busy waiting and then closing it with os.profileend().
local function busy()
local t = tick()
while tick() - t < 0.5 do end
end
game:GetService("ReplicatedStorage"):WaitForChild("RemoteEvent").OnClientEvent:Connect(function()
debug.profilebegin("RemoteEvent")
busy()
debug.profileend()
end)
You then can see something like this:
It usually happens after rendering (and after .Changed connected with something on TweenService) and before wait or RunService.Stepped, physics.
If you’d like to keep the remotes responsive, keep the queue low, preferably under 50 KB/s
By pressing Ctrl+Shift+F3 on studio you can see the network data debug ui
1 Like