[Guide] Fixing the party matching 1-hour DC bug (0x386f)

These might help somebody to fill in the blanks:

PHP Code:

    /// <summary>
    /// Represents a generic Party Match entry.
    /// PartyMatch might exist while there is no underlying Party instance, depending on a the guild master action.
    /// Although both are independent of each other, they are still associated with one another.
    /// </summary>    
    public class PartyMatch
    {
        public DateTime formedTime = DateTime.Now;
        public readonly int MatchingID;
        public readonly PartySettings PartyType;
        /// <summary>
        /// This value may be assigned and reassigned after the Party form is editted
        /// </summary>
        public int AssociatedPartyID { get; set; }
        public PartyPurpose PartyObjective { get; set; }
        public byte MinLevel { get; set; }
        public byte MaxLevel { get; set; }
        public string Title { get; set; }
        /// <summary>
        /// The amount of time that the PartyMatch entry is active (Shown in the Party Matching window)
        /// </summary>
        public int EntryActiveMinutes { get { return PartyActiveTime(formedTime); } }
    } 


SERVER_PARTY_MATCH_EDITED_RESPONSE = 0xB06A
SERVER_PARTY_MATCHING_RESPONSE = 0xB069

PHP Code:

public static int EditPartyMatch(Packet packet, AgentModule session, bool overrideInstance = false)
        {
            // Called when a user successfully register (Form) a party to the party matching system
            // Party should be removed from the matching system after 1 hour by default 
            // 0045055C address for the party matching time out (1 hour)
            try
            {
                if (packet.ReadInt8() == 0x01) // Success flag
                {
                    int partyMatchNumber = packet.ReadInt32();
                    int associatedPartyID = packet.ReadInt32(); // 0 = No Party instance associated.
                    PartySettings partySettings = (PartySettings)packet.ReadUInt8();
                    PartyPurpose partyPurpose = (PartyPurpose)packet.ReadUInt8();
                    byte partyMatchEntryLevel = packet.ReadUInt8();
                    byte partyMatchMaxLevel = packet.ReadUInt8();
                    string partyMatchTitle = packet.ReadAscii();

                    // Create an instance of PartyMatch, automatically handles it in the main container
                    new PartyMatch(partyMatchNumber, associatedPartyID, partySettings, partyPurpose, partyMatchEntryLevel, partyMatchMaxLevel, partyMatchTitle, session);

                    // Check if the reason this snippet was executed was because the Party Master
                    // Modified the Party Match instance
                    if (overrideInstance)
                    {
                        // An instance of PartyMatch with this ID already exist
                        // Update the old one with the new values that can be changed
                        if (Parties.partyMatchings.TryGetValue(partyMatchNumber, out PartyMatch partyMatch))
                        {
                            partyMatch.AssociatedPartyID = associatedPartyID;
                            partyMatch.PartyObjective = partyPurpose;
                            partyMatch.MinLevel = partyMatchEntryLevel;
                            partyMatch.MaxLevel = partyMatchMaxLevel;
                            partyMatch.Title = partyMatchTitle;
                        }
                    }
                    return partyMatchNumber;
                }
                return 0;
            }
            catch (Exception ex) { Utils.WriteLine($"EditPartyMatch failed: {ex}"); return 0; }
        } 


I should mention that if the Party ID is 0, there is a Party Match while there is no Party object associated with it. This also may change depending on the Party Master behavior.
The Party ID is stored on SR_ShardManager and it is index based, that is to be zeroed once the module is reinitialized.

To wrap it all up:

PHP Code:

            // We loop through all of our PartyMatch records
            foreach (var ptMatch in Parties.partyMatchings)
            {
                // Calculate if 1 hour has passed since the PartyMatch was formed
                int activeTime = ptMatch.Value.EntryActiveMinutes;

                if (ptMatch.Value.formedTime != default && activeTime >= 59)
                {
                    // Signal to stop checking after a single attempt to close.
                    ptMatch.Value.formedTime = default;

                    // We preemptively close the PartyMatch before the 1 hour is up
                    // That way, the character won't get disconnected by the server modules. (0x386f on GS)

                    AgentModule masterSession = null;
                    // Get the Party
                    if (ptMatch.Value.AssociatedPartyID == 0)
                    {
                        // There is no associated Party, the only session is the Party Master
                        // Its safe to assume that the current record MatchID only resides within the Paty Master session
                        masterSession = SocketServer.agCons.FirstOrDefault(s => s.Value.PartyMatchingID == ptMatch.Key).Value;
                    }
                    else
                    {
                        if (Parties.parties.TryGetValue(ptMatch.Value.AssociatedPartyID, out Party party))
                        {
                            PartyMember ptMaster = party.PartyMaster;
                            if (ptMaster != null)
                            {
                                masterSession = ptMaster.Session;
                            }
                        }
                    }
                    // Delete the entry if we have found a session to work with
                    if (masterSession != null)
                    {
                        // Prepare the Party deletion packet
                        Packet deleteEntry = new Packet(AgentModule.CLIENT_PARTY_MATCHING_DELETE);
                        deleteEntry.WriteUInt32(masterSession.PartyMatchingID);

                        // Send the packet across the network and the security protocol
                        masterSession.remoteSecurity.Send(deleteEntry);
                        masterSession.BeginSendTo(ProxyEndpoint.Module);

                        Utils.WriteLine($"Party Match ID: {ptMatch.Key} has been forcefully closed on behalf of the Party Master.", Log.Special);
                    }
                }  
            } 


It's a bit janky, but it works.

[Only registered and activated users can see links. Click Here To Register...]

Quote:

Originally Posted by Isoline* Great work, I actually thought of this from an entirely different angle. I can simply initiate the delete of the Party entry on behalf of the Party Master using a filter, I keep track of the Party and Party Match data, (which I assume most servers should do anyway since the rise of custom events), moments before the impending DC is taking place. This way, I'm preemptively calling the deletion of the Party match prematurely, just like it was intended to do in the first place, no harm no foul.

Quote:

Originally Posted by #HB Never thought anyone would want parties to be auto deleted from the matching (personally think there's no point of that), that's why I gave out the timeout skip fix.

Quote:

Originally Posted by pushedx Nice, thanks for sharing! I guess I should have mentioned that as the third viable solution, since I did see a few people talk about just solving the problem using a filter, which is totally valid and perfectly fine. My main goal was looking for a simple way to solve the problem in the files themselves, in relation to the two types of fixes that have been posted so far that involve making changes to the module. The main reason is just simplicity/security. Giving out a proxy means you need to give out a reliable, performant, and safe solution, and that's not easy to do. One of the things I first played with, was using a module proxy to drop the 0x386f packet. Then, it was to make ShardManager also send the party id, so I could then inject the packet the user should send from Agent->Shard. It was then I realized, all I need to do is change the packet being sent in ShardManager to accomplish the same, because ShardManager is already sending GameServer a packet on behalf of the client. That was fortunate, because I'm not quite ready to post a module proxy, which is more headache than a simple fix like this. With a ShardManager patch, virtually anyone can get access to the solution without introducing another element like a specific proxy (or code) to their setup. How people want to implement the fix is up to them though. JellyBitz has a great GameServer addon project: [Only registered and activated users can see links. Click Here To Register...] I'm sure everyone is aware of. Doing the same for ShardManager and starting with a fix like this would certainly make things simple for people who want to just download and have ready to use solutions. However, I always try to focus on the initial process and solving a problem in a way that works, and then working towards making it better. Now that I've done a bunch of testing, I'm positive this works correctly. However, there's no need for me to try and make the best implementation for it. That's why I do guides like this with explanations, if someone wants to create a patcher that does this, great. If others want to offer doing the work for someone as a service, I'm fine with that too. This is just one little thing that needs to be fixed out of a ton of others, so it's more about keeping the cycle going of things that need to be done better, rather than just giving handouts that people will never need to do anything themselves again (which I'm against, but it's a nuanced conversation). As I've started reversing the server files the past several months (since I started in June), and begun getting an understanding of the backend network and stuff, I'm beginning to see a lot of opportunity to doing things differently. I'll only briefly mention it, because it deserves its own topic along with examples and comparisons, but why are people still using filters that sit between the client/agentserver? I've seen a few projects from DaxterSoul and someone else who explored doing module filters, but it largely seems like people aren't building around the backend. I still have a few bugs/exploits to check out, but right now I'm thinking there's a far easier, superior way to do filtering from the server side rather than the public facing client->server side. My old releases were not for server stuff, as they were from the pre-leaked files era, but it is painful seeing people use dev tools in a way they weren't intended. I understand people just using what's available to make do, but there's more to doing this stuff than just whatever implementation I choose to go with. For this particular bug, if I were to try to solve it via a proxy, I'd want to use a new different type of proxy where I have support for process memory interaction, so rather than having to parse packets and rebuild state, I can just access it from the server via some means of interop. Basically, it's more like just exposing what the server already has access to, to server sided proxies, to avoid having to do "double the work" with parsing packets. To me, that's the "new and interesting" element of revisiting this stuff, so I'd not want to just settle on doing packet driven stuff like before because it works unless it was the only way to solve a particular problem. That's not to take away from your solution or any solutions like that, because at the end of the day, we just need something that fixes the problem, and being able to fix the problem sets you apart from not being able to fix the problem. For me though, it's that pursuit of trying to find new and better ways to do things that keeps me going. I'd start with this module patch first, just to get an understanding of what the underlying code is doing (and what's what in memory), and then start to look for alternative ways to do things. The fruits of that labor are for a different thread though, but anyways, cheers! Who wants to play a mmo in a party anyways :kappa: I kinda feel the same. I myself don't care about the actual problem/solution in terms of it being a game feature. Rather, I'm just interested in the dev aspect of it. To me it just seemed like a long time problem without a solution that fixes the underlying issue, so my goal was to make such a solution, that's it.

Quote:

Originally Posted by Syloxx hmm... pretty interesting apporach but that makes me think... if the disconnect if caused by the shard sending packet 0x386F what would happen if we send this packet to the agent server?

Quote:

First, to re-explain the problem. After a party match entry has existed for 1 hour, ShardManager will send GameServer 0x386f on behalf of the party leader, and then removes the party match entry. GameServer does not have a packet handler for 0x386f though, and since it thinks the client sent it an unknown opcode, it will disconnect the player, despite the fact it was ShardManager who sent the packet.

[2293237][4:29:51 PM][Agent->GameB][C->S][7005][5 bytes]
0000000000   02 2F 60 0B 00                                    ./`.............

[2293284][4:29:55 PM][GameB->Shard][C->S][7005][5 bytes]
0000000000   2F 60 0B 00 04                                    /`..............