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.

Don't understaind, can you (or anyone else) make screenchot of this? Probably he means mouse over the eye, roles don't get updated (wich code does in ::Update every 15 secs) Is that player have all dungeon/map unlocked? (anyway the code must handle this case) If people don't get teleported for any reason they get a msg (Ex: Jumping). They can use the eye and select teleport to dungeon. If it's a core fail then you will find a line in server.log about failing to teleport. It appen sometime i cannot reproduce it. It's perhaps lied to the posistion of the player i need make more test. Known bug i can't manage to reproduce. Seen blizz way to solve it is send the Group update multiple times... but, i can't believe it's the solution What you mean? VanCliff doesn't appear? To get rewards Achievement system have to call to sLFGMgr. Cyberium forgot to add it to the patch. Will do some test about someone not accepting the role assigned. DungeonEncounters.dbc, but neither Mangos or Trinitycore use that dbc (you can find some info about it in another post). This implementation of DF uses Achievements, which have the problem that not all dungeons have counter achievements, so some of the dungeons (low level) will only get rewards the first time you do them. Need to move to a system that uses DungeonEncounters to mark a dungeon. Boss kills will be easy to add, but there are cases when you don't need to kill a boss, those cases will need to be handled by scripts.

::SetLfgUpdate(bool) will soon disappear in next patch.

All task are done in ::UpdateProposal, in the else of "if (!allAnswered)" // Save wait times before redoing groups ... some code ... // Create a new group (if needed) for (LfgPlayerList::const_iterator it = players.begin(); it != players.end(); ++it) { // (comment not in code) Send update if needed if (sendUpdate) plr->GetSession()->SendUpdateProposal(proposalId, pProposal); // (comment not in code) inform a group have been found if (plr->GetGroup()) { plr->GetSession()->SendLfgUpdateParty(LFG_UPDATETYPE_GROUP_FOUND); <------------- HERE Client is informed group have been found if (plr->GetGroup() != grp) plr->RemoveFromGroup(); } else plr->GetSession()->SendLfgUpdatePlayer(LFG_UPDATETYPE_GROUP_FOUND); <------------- HERE Client is informed group have been found // (comment not in code) Create new group or move from old group to new group if (!grp) ... some code... else if (plr->GetGroup() != grp) grp->AddMember(plr->GetGUID(), plr->GetName()); // Update timers ... some code... } // Remove players/groups from Queue ... some code... // Teleport Player ... some code... // (comment not in code) Clear stuff ... some code...

Yes, in ::UpdateProposal // Remove players/groups from Queue for (LfgGuidList::const_iterator it = pProposal->queues.begin(); it != pProposal->queues.end(); ++it) RemoveFromQueue(*it); // Teleport Player for (LfgPlayerList::const_iterator it = players.begin(); it != players.end(); ++it) TeleportPlayer(*it, false);

Check /src/server/scripts/World/dungeon_finder.cpp Group Hooks: AddMember, RemoveMember, Disband, ChangeLeader, InviteMember Player Hooks: LevelChanged (Not used atm), Logout Move all functions in dungeon_finder file to LFGMgr.cpp. Now go to Group.cpp and compare Trinity with Mangos. Where you find sScriptMgr.OnGroupXXX change that line with a call to the dungeon_finder function. Ex. Group::AddMember, change sScriptMgr.OnGroupAddMember(this, guid); with sLFGMgr.OnAddMember(this, guid); Will try to find time to finish the other changes in Player.cpp/Group.cpp. General idea is this patch (Trinitycore repo) it's not up to date, just to get the idea http://aokromes.pastebin.com/iftjjAFt

Cyberium, check Trinity core again. Interaction between core and LFGMgr is done using ScriptMgr. We have Hooks in Player/Group classes, so i've moved code from those classes to a script (/scripts/world/dungeon_finder.cpp). As Mangos don't have those hooks just replace those calls with direct calls to script file functions or just move those functions from scriptfile to LFGMgr.cpp I'm in the process to move all LFG data from Player / Group to LfgData Struct inside LFGMgr.cpp. The idea is to try to keep the maximum LFG code inside that file (+ LFGHandler) and modify the minimum parts of core. AccessRequeriment table is an evolution of AreaTrigger table, so you can just readapt the code to use AreaTrigger table. My idea (before we moved to AccessRequeriment) was to update id's to id of LFGDungeons.dbc, and just use new values for the existing areatriggers that are not used with LFG (2nd doors/exits of dungeons existing in that table) Boots = Kicks. When you are in a LFG group anyone can propose to kick someone and a vote is init. Uninvite option is replaced with a Init vote boot. In order to get rewards you also have to check Achievement and Quest system, as there are modifications done to fit DF. Any doubt you have porting DF to Mangos feel free to ask me

as you said, 0x04 only appears with 0x08. But sometimes only 0x08 appears. Will do some tests about joining random or selecting dungeon, alone or as a group. about (2), again you are right, is player role. As SMSG_GROUP_LIST only list other people stats, that's your own role (values 0, 2, 3, 4, 5, 8 and 9) pushing a patch and giving you credits

noIdea --> The max value of each mapId-InstanceDifficulty pair is final boss/event. Not always being the max encounterIndex. When you join a raid with save, asap you get in the instance you get a popup asking if you wanna get linked to that save. The popup shows the bosses that have been killed, encounterIndex is the index in the mask variable. Same with proposals in Dungeon Finder, when you join in the middle of a dungeon in progress.

(2) only seen 1 and 0 in packets, but will check again. (3) correct - status and dungeonId (from LFGDungeons.dbc) (*) correct - player role With check group flag GROUPTYPE_RANDOM = 0x04. In my Dungeon Finder implementation only used 0x08. "Kick" and "Dungeon guide" is show with 0x08, will also check with 0x04, but i can confirm 0x08 is working as my implementation of Dungeon Finder works.

if it's not implemented then STATUS_UNHANDLED should be used (otherwise that status should be unused at all and removed from code) STATUS_NEVER should only be used for server side and obsolete opcodes.