JCL is right.

If you have a system that selective update clients, we have found that it's easier to "link" the join/update procedure with this selective update.

In other words, a client is going to get updated on what other users are close to it's avatar. Upon joining, the only user close to itself is itself... so we do a self-update. After this, this self-update continues to work (with less information) until we meet another person at which point this update is now sending two pieces of information: your updates and the person in range of you. As you can see, the join event should be no different than the update event except for whatever extra information is needed at login on the client.

Hence the solution (once again) is to either re-write the GS Network Architecture such that selective updating is natural and login is taken care of that way
or
not use GS Architecture at all and make it part of your selective update routine like we have.