client network variables #37
Conversation
|
|
||
| ## Private Mode | ||
|
|
||
| So that developers can choose to replicate the `ClientNetworkVariable` just on the server but **not** to the other clients, a `OwnerOnly` mode is avaiable. |
There was a problem hiding this comment.
I'm wondering, couldn't this use the interest system instead of having its own system? This way, we'd be able to set custom replication rules (for example, only broadcast to team members or only broadcast to steam friends)
There was a problem hiding this comment.
Very interesting. The thinking behind it was, ClientNetvars are a distinct, special type. A CNV will not be snapshotted. A client can never write to a regular NV. A CNV can be private to the owning client. We could, rather than make it its own type, have attributes on a regular NV, and then those attributes could be read / processed by the interest system. I guess the spirit was to really keep CNV and NV as distinct types so as to not imply to the user that CNV's are treated by the SDK just like NV's (mainly, that they aren't snapshotted / predicted). But I'm open to more feedback
There was a problem hiding this comment.
Ah interesting. Yes having attributes on a regular NV, with no new CNV class, read by interest management would indeed make this a cohesive solution
Will CNVs "never" be snapshotted? I thought Jeff had plans to allow this?
| In considering the feature and talking with developers the common feedback was this was the level of involvement they wanted from the SDK. Moreover, while we felt reasonably confident that we could define variable use case, we were less certain we could define a full client authority system with local manifestation given all the different use cases. Note however such additions could be added later, building on this system. | ||
|
|
||
| Technial advantages of this approach: | ||
| - programmer interface is just like before |
There was a problem hiding this comment.
Before, we had the same netvar for both server and client, but with permissions. People porting to Netcode 1.x from 0.1.0 would still have to create new code to use the new ClientNetworkVariable.
| - The `SomeClientVar` for the client on which the code ran is immediately udpated | ||
| - The client then communicates this variable update change to the server | ||
| - The server then broadcasts this to the other clients | ||
| - Note, unlike pre-1.0 versions of NGO when clients could write to network variables, the server can **not** write to client network variables. |
There was a problem hiding this comment.
What about hosts? They are clients, they should be able to write to ClientNetvars too.
Any reasons we're not doing an Owner check and no client/server check? This way, a server that owns a netvar could write to the same netvar a client would if they were the owner.
With the proposed design, in boss room we'd have to have two sets of variables for each state and duplicate our gameplay state assignment everywhere :(
There was a problem hiding this comment.
Ok, good catch on host stuff, I need to double check the behavior. The intention is the client who is the host shouldn't be special.
|
Looks like a great step forward! |
2 participants
No description provided.