Spp_

I checked wrong repo, i was checking the repo you have linked as your web. A first quick look to R2 repo, makes me think you going to do the same mistakes i did in matchmaker algorithm. Will give a deeper look when i have some time and give you feedback

Some minor comments: * Join: - You can join DF even if you are in a raid (tested to join heroic dungeons while in a raid). The correct process is check all dungeons, if you have dungeons + raids give the "mixed" error, or if you have random + any other give "invalid" error - if Join fails LFG_UPDATETYPE_ROLECHECK_FAILED should only be sent if you are in a group - Error given when you or another member have deserter/cooldown are not the same, you using the same. - When someone on your party can't join you have to send the list of the dungeons he can't do and reason. I suggest you send the dungeons to the SendLfgUpdateParty opcode (i've made a custom struct to send all info i need so i don't need to change the headers each time i find i need to send new info) * Locks: Add support for seasonal is easy, you can check flag = 15. * WorldSession::SendLfgUpdateProposal - Code related to silent and continue vars. A new var inside proposal struct should be used to determine if it's a new proposal or not. Lfg group can do a new dungeon after finished last one and shouldn't be considered as continue. - Encounters should be calculated at proposal creation and stored in internal proposal variable for speed I suggest to use separate queues for each team. Will improve matching algorithm if there are too much people using the system. Also, check for compatible dungeons before joining, will save some time later in the matching process. If level 80 + level 20 trying to join, faster to return an error before even joining the group. * LFGDungeonStatus enum, if you took it from TC, needs further investigation as i found in the past some cases that do not match the given values. When you set flag LFG_MEMBER_FLAG_UPDATE to players? I only managed to send the first update and after that i make the client crash. Will take a closer look at the changes i have with you raid browser implementation Why you using two different queues, one for group and one for players?

The flag is not needed with that implementation because you using an extra table to identify the bosses, the original idea of that flag was to identify all bosses at load time with no predone table.

Can't be used. Normal instances do not have bind but still have bosses Never been the best solution as many of the classic dungeons are not covered by this system. The way to go is Encounters and that will cover 100% cases. Cyberium is doing, at first place (like Manuel is doing for Trinity) the encounters that are done by killing the boss, and later will implement those that are not boss kill.

The final point is how to have a relation between encounter id and creature entry. Cyberium solution is to add a new table. In that way, as you said, it's not needed a new flag. It can be checked for any npc that dies (under certain circunstances) if it exists in that table. I'm doing my own implementation of encounters and i don't need any extra table, and as a way to minimize the number of checks done i just added that flag. As i've done with many of my DF work i just expose Cyberium how i have address same kind of problems

There is no way, as far as i know, to check if a creature is a dungeon boss, not even checking AI, so i added new extra flag to determine if a creature is a boss or not (https://github.com/TrinityCore/TrinityCore/commit/fd66517473b772c3b2d3adfbdabae47d2088c77d)

In fact shouldn't be used IMO. It's based on old tc work. Too much work have been done since that 1st port. New code from cyberium is far better than that. (like actual TC work is )

Check this commit https://github.com/TrinityCore/TrinityCore/commit/4fba0830d02e350918c7b3f9deae67338538055a

- If someone leaves group while queued, other still get queued with same roles they already selected, but queue time is reset (leave + autojoin). - if someone leaves group and it gets disbanded all are removed from queue - if someone goes offline group is removed from queue - If someone from your group refuses the proposal all group is removed from queue.

I ended with the same problem in my DF implementation. Now i am In the process of moving the use of pointers to references to avoid having to deal with new and delete. Code ended being easier to read. The first try was having warnings about returning local variables, but later fixed those problems returning cost references and problem solved. Will take a look at the class Ambal talked about, just to learn, as i don't think going to re-redo it. As far as i've read (haven't done any test myself) compilers can optimize all those calls using value parameters. Anyway i still prefer to use const & wherever i can PD (offtopic) I am waiting to see your DF implementation it's always good to see how another one has solved the same problem to see any improvement you have added

1) Tank, Healer, Dps x 3 is the unique combination 2) No, he doesn't get any reward nor have rol assigned as it haven't been added to group by LFG System 3) No cooldown 4) If it's client logout then its removed from queue. If it's disconnect by some error i don't know what happens. 5) If someone refuses to select a role, the rolecheck is aborted. Note: If leaves the party before selecting a role then it's just removed from rolecheck. Also, if someone joins the party while group is queued, the player is prompted to select a role (None of this features in the "Note" is coded in my implementation) 6) Teleported to group (farthest member from final boss). If you use the eye you get teleported to entrance. 7) Offy have a cooldown if you leave LFG group. I didn't added to my implementation because i had some errors.

As far as i know those encounters that do not kill a boss have a server side spell casted.

Instances should have a list of Encounters to complete, when a boss is killed the linked encounter should be marked as complete. If is not a boss then it should be done by scripters. When the final Encounter is complete and the group is LFGGroup, it should call sLFGMgr to give rewards. Also it should call Achievement system. Nowadays all is done by scripters and complete encounters are just stored by each of the scripters Group should be LFGGroup and final encounter complete. Then just call Reward (as a Group), DF Then will check for any extra condition needed (Player being added as random)

Current system just rely on Achievements. So when boss dies achievement is called, also it can be called by scripters when the final encounter is not a boss. Achievement system will check if that achievement is marked to notify DF. The day DungeonEncounter is fully supported then achievement system wont be needed at all.

You only get rewards when you finish a dungeon you have joined as random. So each field in that table contains the id of a random dungeon and 2 quests. 1st completion and 2nd. So rewards just rely on quest system. So if you wanna modify the rewards just modify the quests. Note: Quest system was also modified in Trinity to fit DF quests as some of them are daily and others repetable and both of them are not shown in the client.