Author Topic: setNetFlag - SelectiveGhosting  (Read 2825 times)

What does setNetFlag do?  I've seen it used in Server_EnvironmentZones:
Code: [Select]
%this.sky.setNetFlag(6, true);
Setting "6" to "true" allows me to use scopetoclient() and clearscopetoclient().

But where did Zeblote get the number 6 from?  Can I do other things using different numbers?

If I remember right, flag 6 is for GhostAlways. If that's set, the engine won't automatically scope/unscope the object.
(not really the intended usage, but it works)

There aren't any other flags that have useful effects when you change them.

I remember someone had this part of the source to tell which flag does what

If I remember right, flag 6 is for GhostAlways.
This seems to be correct.

...  I've found that this flag can also be set by running %obj.setScopeAlways() and then removing the object from the GhostAlwaysSet.
When combined with %client.resetghosting() and %client.clientwantsghostalwaysretry(), it is possible(with a great deal of lag),  to cause an object to disappear without using a DLL.

I remember someone had this part of the source to tell which flag does what
I would very much like to see that.

This seems to be correct.

...  I've found that this flag can also be set by running %obj.setScopeAlways() and then removing the object from the GhostAlwaysSet.
When combined with %client.resetghosting() and %client.clientwantsghostalwaysretry(), it is possible(with a great deal of lag),  to cause an object to disappear without using a DLL.
I would very much like to see that.
Code: [Select]
   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
};

Ghostable (8) is useful when used on Trigger objects, as it makes clients display the bounding box. It is normally not set, and is only enabled by the mission editor.

...  I've found that this flag can also be set by running %obj.setScopeAlways() and then removing the object from the GhostAlwaysSet.
When combined with %client.resetghosting() and %client.clientwantsghostalwaysretry(), it is possible(with a great deal of lag),  to cause an object to disappear without using a DLL.

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.

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.


Code: [Select]
   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.

everything but flag 6 is basically useless

make it so it doesnt always ghost and clear it from scope to make it not ghosted and then manually ghost it to whoever needs to see it

everything but flag 6 is basically useless

make it so it doesnt always ghost and clear it from scope to make it not ghosted and then manually ghost it to whoever needs to see it
This is exactly what I do.

So note to everyone with triggers make sure to unscope it from everyone before deleting it or console spam happens and then you crash. Unless there is a better way