Hi
I’m working on displaying a graphic, that is different from player to player. Consider a flag you capture. When your team has the flag, its displayed as yellow you to, when some other team has the flag, its blue.
I’m tired…perhaps I just need to send more information across the line to the client.
Well, something tracks the captured state of the flag.
Use that to color the flag on the client.
Yea, I have a FlagState on the server. I see no other way than to send the ownership information to the client and let the client set the color.
Thats exactly how you do it. The server tells the client the state. The client is a visual representation of that state.
Yea. So I guess I have to send both flag ownership as well as player relation - to let the client set the correct color based on both.
Well, there are two ways to do it:
(1) is more flexible in general and keeps the custom code in one place. You can also swap out the whole model which could include particle effects, different meshes, whatever.
(2) requires extra client-side systems and so on… and in the end can only change the color or whatever you code in.
I’m not sure which one I’d do personally so it may be game specific. I initially thought (2) but after I wrote them out I realized I already have cases in my games where I do the equivalent of (1) in a couple different cases… so lumping “captured” into that would just be another one. In those cases, the current model info component is largely based on a lot of different potential state. Thing door open/closed, chest open/closed, torch lit/unlit, etc.
The only issue is that if I do it with updating the model info component (which I also do in other places) - then every player, regardless of team will see the same state of the flag.
Edit: I want player A, on team 1 to see flag as owned if team 1 has the flag. I want Player B on team 2 to see the flag as not-owned if any other team than team 2 has the flag.
No, because the ‘factory’ code for that particular model info will set the color based on the local team or pick the appropriate model for that client.
ModelInfo != spatial. That’s the whole point of keeping the view separate. The model info just says “This is team X’s flag.” It’s up to the client to decide how to render that.
Well, perhaps here I am missing something. The model info is currently just a model - saying “show this”. Every client will then “show this”. My model info does not embed the info about it being team X’s flag.
Edit: Team is not just team A or team B. Its an arbitrary number indicating who’s side you are on (so in theory an infinite number of teams, in practice, perhaps 10-100 teams)
The model info is just an ID (or string converted to an ID) so it could be anything. It’s up to the client to decide how to turn that into a visual.
But given your description, maybe it’s better to have a separate component.
I’ve used it before, for this purpose, when I have a limited number of different different values within a given context (i have 8 different ship models, so I added 8 different modelinfo lines)
I recknognize now, discussing it, that I would need to send the information any way, to have the client hud be able to update the information on how many flags the team has etc. So there was never really any way around it.
I personally have Team component to sort such things out. This component is also send to client. I plan to do more things with this component, maybe as well have team based chats, colour/texture my ships depending which team. As well my “team killer” feature will benefit from it.
Maybe this is also a solution for you? Would be that extra component you are talking about, but still a generic usable one?!
And this is quite an interesting idea, I never thought of more than 2 teams 
The idea being that anyone can form a team if they want. You can even go one vs. all on your own ‘private’ team. The first 100 teams are public, the teams with ID 101+ are created with a password - so you can have personal teams