Been looking into the party system and there are a few issues that need to be solved.
First, there are local and non local parties. I currently don't know for sure what the difference is but I believe local teams were used in situations where all team members were in the same zone as part of an activity (think BoNS, AG Survival, etc...) and non local teams were used for everything else.
Unfortunately, there isn't much documentation on the team system and what little there is isn't completely clear. I've been able to find a TeamCreateLocal game message in the captureviewer code but no non local equivalent. The only other message I was able to dig up was TeamInviteConfirm, however, I do not know what message caused this to be sent in the first place and also not how the other team members are transmitted (if there are any).
The next issue would be the fact that non local parties may have members in multiple different instances. Solving this requires setting up a dedicated chat server (which we don't have at the moment), because world servers cannot handle parties on behalf of the other members and teams also get their own chat channel, which needs to be managed as well.
A chat server would be much easier to implement than another world server but it does need to be able to route chat packets to the correct world server instances and packets from the client need to reach it, which means the world server may have to be able to forward those as well.
The creation of a global chat server however also implies globally unique player IDs, because different world server instances would not be aware of the object IDs allocated by other instances. This means changing large parts of how our zone instance currently handles object IDs.
The only way to get around this limitation would otherwise be substituting IDs for each player locally, i.e. have differing IDs per instance and communicate changes in state using character names. However, this would be problematic if party members ever switched zones since their IDs would have to be changed as well.
Been looking into the party system and there are a few issues that need to be solved.
First, there are local and non local parties. I currently don't know for sure what the difference is but I believe local teams were used in situations where all team members were in the same zone as part of an activity (think BoNS, AG Survival, etc...) and non local teams were used for everything else.
Unfortunately, there isn't much documentation on the team system and what little there is isn't completely clear. I've been able to find a TeamCreateLocal game message in the captureviewer code but no non local equivalent. The only other message I was able to dig up was TeamInviteConfirm, however, I do not know what message caused this to be sent in the first place and also not how the other team members are transmitted (if there are any).
The next issue would be the fact that non local parties may have members in multiple different instances. Solving this requires setting up a dedicated chat server (which we don't have at the moment), because world servers cannot handle parties on behalf of the other members and teams also get their own chat channel, which needs to be managed as well. A chat server would be much easier to implement than another world server but it does need to be able to route chat packets to the correct world server instances and packets from the client need to reach it, which means the world server may have to be able to forward those as well.
The creation of a global chat server however also implies globally unique player IDs, because different world server instances would not be aware of the object IDs allocated by other instances. This means changing large parts of how our zone instance currently handles object IDs. The only way to get around this limitation would otherwise be substituting IDs for each player locally, i.e. have differing IDs per instance and communicate changes in state using character names. However, this would be problematic if party members ever switched zones since their IDs would have to be changed as well.