SetScopeAlways also automatically scopes the object to all clients, which is not ideal. The second is obviously not an option if you want to use it for any in-game purpose.
Mm, ideal i-shmeal. I can think of uses for it. Say- I have a game where each client has a certain goal that only they should know about. I could keep a certain number of unghosted objects to use as visual indicators, and then assign and ghost an object to a client when they need it.
Reghosting would only be used if the server needed to use more objects than it has in the pool. Say- if the server host changed the max number of players, then the new objects required would need to be made invisible to the clients already in the server.
enum NetFlags
{
IsGhost = BIT(1), ///< This is a ghost.
ScopeAlways = BIT(6), ///< Object always ghosts to clients.
ScopeLocal = BIT(7), ///< Ghost only to local client.
Ghostable = BIT(8), ///< Set if this object CAN ghost.
MaxNetFlagBit = 15
};
:D thank you
Dunno what 1 would do, I assume it is used on the client side?
6 has known use cases. Setting an object so that it must be manually ghosted.
7... would be useful if you were to modify the game live. Adding new datablocks without updating the clients is a no-go. But if objects that use said datablocks were never ghosted to a client, the client wouldn't crash. ... right?
8... showing trigger objects and waypoints. Or hiding objects that will never need to be seen, such as if I had a collision box surrounding the map. Unghosted collision shapes work ok, and do not impact a clients frame-rate. ... Though there is a sort of jitter if a client stands on them.
I think there are possibilities for using these sorts of tools to add terrain to the game. The main problem I've had with making terrain is that the massive number of collision shapes required will impact a client's framerate. But if those shapes are only ever ghosted when a moving object is near them, a section of terrain could be made very very large without major negative effects.