I think It would be nice to have a [Sync] option to select who gets updates from it!
It could even be a different attribute class to keep base coherence simple for people new to network programming and have a basic docs page and advanced docs (I’m not sure if this is a core pillar coherence is focusing on… managing simplicity with advanced usage)
A use case could be for Server Side + Client Input object. For stats only relevant to the player which could change frequently, like experience gained.
Where the server would update the variable and only the client with input authority would receive it. It’s definitely tedious to implement such a system myself.
I wonder though how it would work in practice. Syncing is designed to affect copies of the same object across different clients, and its purpose is to keep the state of these copies… in sync. When you choose not to send this state to everyone, you will have one or more of these copies in a different state. This might be confusing, and I’m not sure what use case it could have.
To do what you’re mentioning, I feel like it would make more sense to use Commands, which are not tied to a value that is available to all clients at all times. They can be used for some more “private” or I should say targeted communication.
But we could definitely have more parameters for commands. For instance, I’m not sure if there is a way to send a command to the input authority of a network entity (which would cover your use case of the Simulator messaging the input owner). I need to ask.
While this would be a nice feature for quick prototyping a multiplayer game, it’s not needed. I was going to delete this post but couldn’t.
To be honest, as I’m learning to work with the system I find that it’s all just syntax sugar and unnecessary to add features like this.
One thing I wish I could read more on is what data is available to the simulator or client comes from a sync.SendCommand. In a perfect networking library, “how to make something secure and un-hackable” is a really good thing to have.
I had to drop my ideas of having a purely server authoritative game because the information and tools are not available. I could continue with my idea on making it server authoritative but I don’t know how much stress I would be putting on the networking by adding something like a secret id to each command sent.
The option authority server+client side is actually kinda’ mysterious for how it works without doing a bunch of tests…
How does the CoherenceInput send client authoritative commands that the simulator can receive? Is this just sync.SendCommand under the hood?.
Is it possible to use another client to send fake Input commands through that same system? (That would mean that it’s not really Client Authoritative Input unless you are verifying the source)
Why was the types available for input syncing limited to vec3, float, bool, string?
We don’t provide a secure way to authenticate a command out of the box, though it is on the roadmap and we are planning to create a built-in solution for it. In the meantime:
No, CoherenceInput doesn’t use commands.
No it’s not possible, all of this is verified by the Replication Server.
Actually the types supported are Vector3, Vector2, float, boolean, string, int, Quaternion.
What type are you thinking you might need?
For #2. You said it was all verified by the replication server… I would really like to know how that’s done so I could use it for a system similar to CoherenceInput. Instead of sending a continuous stream of input keys I would like to infrequently send packages of data for something like an ability(position,type). So far been using commands for this but like I said, with my tests, other clients are able to find the sync object of another object and issue a command which is not secure.
For #3. I thought I tried a vec3 and it didn’t work, but maybe I didn’t and was basing it solely off the docs:
No rush for finding any of this out, I’m just poking and prodding for information so I can become a coherence expert
I’ll start from #3 as I have the answer myself, asking for #2.
You’re right! The docs are incomplete, and show some old terminology. We will work on fixing them. But if you explore the API (even using autocomplete), you’ll find all the available Get- and Set- methods.
In my project (which is based on coherence 1.0) I see this:
The team says that what CoherenceInput does is not too far away from a Command but it has an additional check about who is sending it. But unfortunately for now (and for the imminent 1.0) you won’t have the ability to create these verified commands.
But again, it’s on our roadmap, and it’s not too far in the future (it was already planned before this thread).
So my suggestion would be: if you are in the early phases of development (as I imagine you are) I wouldn’t worry too much about hacking for now, and I hope we will have a solution for when you will need it!
Back onto the topic of only syncing with specific clients.
I’m in a new situation where the player’s character is server controlled but the player has input to make things happen visually right away and has reconciliation to get it back on track if it strays too far.
I’m playing around with animations right now… my goal is to have the player see the animation go off instantly at the same time it’s telling the simulation server to play the animation. The simulation server will then use config window to sync the animator to everyone.
Obviously there’s some issues with this, because the player doesn’t need the sync from the server for the animator and it could end up looking weird / glitchy… How should I handle this?
Would I just turn predict on the animator config window and then write code so that if the client has InputAuthority to ignore the animator updates?
Just thinking about this makes me feel like it’s a bit messy
Another thought: If the server detects the player is stunned or knocked down, it should play that animation for everyone… including the player with input authority. This all feels so convoluted.
Is this just another case where I should be using [Commands] and create a system that handles this?
I think you could do exactly that. Why messy?
You don’t have to duplicate code if you work smartly. You can have the animation functions in a dedicated script that you don’t turn off for the player. So when the input gets sent to the Simulator, both the Client and the Simulator trigger the same animation code. The Simulator will then propagates its results to the other clients.
PlayerInput.cs receives the input locally (f.e. Cast Spell) > Sends the input to the Simulator, and at the same time processes it in a PlayerEffects.cs script, which results in setting an animation parameter and playing some particles, but no gameplay effect > Simulator processes the inputs, passes them to its own PlayerEffects.cs, gets to the same result, updates those same properties and sends a command to play the particles, and sends another command (f.e. Apply damage) with info on who got affected by the spell > All clients receive the new values and play animation/particles, but the player who sent the input automatically ignores it because for them prediction is on > All clients also receive a command for the gameplay effect, including the player who sent the input.
I haven’t tried myself, but that’s how I imagine it!
You also have the ability to inform the player anyway, using the method described here:
However, you probably don’t want to delegate a “Stun effect” with its gameplay meaning to that client-side misprediction method, otherwise any person could hack the client to modify that method and not apply the effect to themselves, effectively resulting in cheating.
I would use it only for visual effects.
