I’m currently working on the network component of my custom character controller and I’m stuck on the replication. I want the character physics to be 100% server side and it works fairly well so far, but I still can’t figure out the best way to send input data.
My first question is whether replication drops the packet if the property changed once again before being sent. So for example:
Will this replicate all 3 values, or will the first 2 be dropped? This would make it much more advantageous than using RemoteEvents.
My second question is if there is a way to directly replicate properties from client to server without using the vulnerability of Characters or RemoteEvents. For those who don’t understand what this means, here is a bug report topic regarding this.
None of this will replicate from client to server.
You should use RemoteEvents, I’m not sure what vulnerabilities you’re referring to. If properties replicated from client to server that in itself would be a vulnerability, surely?
If anything, ValueObjects are easier for exploiters to manipulate than remotes are.
Changing properties isn’t advantageous vs. firing a remote except from server to client.
I currently use ValueObjects only to send character positions. As @Halalaluyafail3 said, replication drops intermittent values. I somewhat noticed that, but wasn’t sure if it was what I expected or the effect of it being on a local server. Would be a mess if I had a massive queue of stacked events sending outdated character positions.
The vulnerability I’m referring to is Characters not fully respecting filtering, allowing them to replicate some properties to the server. I could maybe hack something up using that and make it work, but I doubt it won’t break in close future. I just wanted to know if there was a way make the same thing as with the positions I mentioned above, but with the input.
ValueObjects aren’t any more or less vulnerable than events. I could probably destroy an instance, breaking any important connections, but I could also just spam an unprotected remote event. A secure server code is the only thing that matters.
(My apologies if I came off blunt in my last post, it seems I misinterpreted what you were asking about.)
I wonder if parts would have better results for representing and replicating position? If you wanted the Character to be able to replicate position from client to server, you could set the network ownership of the part. Might be some optimisations in terms of replication you could tap into there too, though I’m not sure.
The characters are owned by the server. The main reason I created this is because my project doesn’t require immediate character reaction, so sending input to the server and have it handle all the physics is perfect. Players have no effect on physics and can only send what they want to do. I also hate default characters, so having them 100% physics based is more than ideal.
Replication of position is not an issue as we all know that the server can replicate anything to the client. The issue comes with input. I understand that it’s almost impossible to get direct replication from client to server which would avoid the issue of stacked input. For example if the player wanted to move back, but then immediately went forward. The server will receive both events, making him go back then forth, potentially ruining a quick reflex.
I think that this isn’t an issue you can really get around without making your input - and by extension your character movement - client-authoritative. You’re always going to be bottlenecked by latency. You either compromise on security or accuracy, you can’t have the best of both worlds in this situation.
My issue isn’t as much latency as is the inability to cancel previous events.
I figured out a potential fix. I’ll just queue up functions sent from the server. The client will hold onto values to replicate until it gets invoked, sending the value I want to replicate.
The issue of events stacking seems like something you could get around by simply accounting for these quick changes in desired impulse in your input handling. e.g. if the user changes inputs quickly you could artificially increase the impulse value to complement their intended input. Having an input queue isn’t a bad idea, though.