@hide command
Forum rules
NO LONGER BEING MAINTAINED!
NO LONGER BEING MAINTAINED!
@hide command
Not sure if you guys are experiencing this but after the last update I noticed @hide GM command works until you zone anywhere then it wears off. I remember using it before and it stayed on no matter which zone you went to until you turned it off manually. Basically it turns off any time you zone. I know it's a little issue but just ignore it if its irrelevant at the moment. Thanks
Re: @hide command
every command is reset on zone now (except godmode). just a side effect of how I changed the zoning process
Re: @hide command
Any reason the player object can't be passed between the servers to prevent this? Rather then going the DB route of storing current states.kjLotus wrote:every command is reset on zone now (except godmode). just a side effect of how I changed the zoning process
Re: @hide command
sounds like more work for almost nothingatom0s wrote:Any reason the player object can't be passed between the servers to prevent this? Rather then going the DB route of storing current states.kjLotus wrote:every command is reset on zone now (except godmode). just a side effect of how I changed the zoning process
Re: @hide command
Thanks KJ and Atom0s. It's no big deal but I was just curious if it was noticed. Thanks again
Re: @hide command
Send it as a "message" maybe?atom0s wrote:Any reason the player object can't be passed between the servers to prevent this? Rather then going the DB route of storing current states.kjLotus wrote:every command is reset on zone now (except godmode). just a side effect of how I changed the zoning process
-- Whasf
Re: @hide command
there's way too many things that would have to be deep copied, it's not really feasible just to make @hide work through zoneswhasf wrote:Send it as a "message" maybe?atom0s wrote:Any reason the player object can't be passed between the servers to prevent this? Rather then going the DB route of storing current states.kjLotus wrote:every command is reset on zone now (except godmode). just a side effect of how I changed the zoning process
Re: @hide command
The idea was to just send the full player object, so no manual shit would need to be done. Just cast to a byte array, and on the receiving server, cast it back and make the needed modifications after zoning etc.kjLotus wrote:there's way too many things that would have to be deep copied, it's not really feasible just to make @hide work through zones
Something like @hide failing to persist across zones makes it kind of useless to even have now.
Re: @hide command
how are you going to send pointers to a different process?atom0s wrote:The idea was to just send the full player object, so no manual shit would need to be done. Just cast to a byte array, and on the receiving server, cast it back and make the needed modifications after zoning etc.kjLotus wrote:there's way too many things that would have to be deep copied, it's not really feasible just to make @hide work through zones
Something like @hide failing to persist across zones makes it kind of useless to even have now.
Re: @hide command
The send/recv part wouldn't use the pointer objects. You'd send the raw data of that structure. Then the receiving server would populate the structure (create a new instance of the object, copy the data over it etc).kjLotus wrote:how are you going to send pointers to a different process?atom0s wrote:The idea was to just send the full player object, so no manual shit would need to be done. Just cast to a byte array, and on the receiving server, cast it back and make the needed modifications after zoning etc.kjLotus wrote:there's way too many things that would have to be deep copied, it's not really feasible just to make @hide work through zones
Something like @hide failing to persist across zones makes it kind of useless to even have now.