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

If anyone wants to help in the implementation of LFG for mangos, join to R2 fork. I wrote to their full implementation of this feature (old TC code used less then 5%), availability is currently 80%, will soon need an active alfa testing.

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?

https://github.com/TrinityCore/TrinityCore/commit/c2b0bcbd6c8155812857523681cd787059cd9bf9

my DungeonEncounter.dbc implementation

that extra flag for boss isnt needed

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.

What about CREATURE_FLAG_EXTRA_INSTANCE_BIND in creature template, flag _extra ?

Can't be used. Normal instances do not have bind but still have bosses

how about linking them to achievement system?

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.

that is quite useless;

_if_ the npc is a boss, and _if_ the boss has to be stored in some extra table (to link with stuff), then we know what bosses are: exactly all npcs who are in the linked table, so no need to add an additional custom flag there.

If you care about speed, then always can add a bool to Creature m_isDungeonFinderBoss

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

Howewere iam actually finding the best solution to identify any BOSS dying.

creature_template seem doesn't help me. The only interesting value i've found is 'CREATURE_FLAG_EXTRA_INSTANCE_BIND'

If creature make bind you to instance, there is lot of chance that creature is boss But it's not a good solution... At least adding new column on creature can help us to formely identify that creature is a boss....

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)

Ansonic, the old patch is no longuer supported. Read the whole thread.

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 )

Hi,

Some issue i have.

- When player is teleported out the dungeon it appear offline or died for other member. All my try to identify problem are failed until now.

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

Hi,

Two more question :

Assume one group with 3 guy for ex.

Leader add the group to LFG Queue.

- If leader quit group/or get disconected what happen to 1) his queue status, 2) his two member queue status?

- If candidat found (to complete group) and proposal is refused (or timed out) by one of already grouped guy, is all the group leave the queue or only the guy refused?

Thanks for any answear.

- 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.

The only good raison i see is, is not goot to mix different way to handle pointer. So the best is to have complete coherent code not using smart_ptr.

Anyway i am currently modifying my DungeonFinder implementation with the shared_ptr class because i cannot ignore the benefict of using them.

Just 3 of them

- Code is more easy to read.

- I dont bother about any delete.

- Memory management is more advanced than actual version. (anti memory leak, handle exception)

I know this can reduce chance to integrate my DF implementation but it's not my absolutly goal. Iam firstly here to learn

Greetings

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

Hi, i have some question about Official DF for my implementation.

1) Do the official one create only classic group composition like 1Tank, 1 Heal, 3 dps? For ex, 2tank, 1 heal, 2 dps or 1 tank 2 heal and 2 dps, can sometimes be a viable group?

2) When the group is created and all member teleported, if someone quit the group for error and reinvited just after, do he still gain the reward for LFG group in the end of the dungeon?

3) The teleport out/in option is aviable anytime without cooldown?

4) Actualy i choosed to keep the player in the queue if it will be logoff for a short laps of time. (<5 min) How it work on official?

5) Suppose already existed group, if leader do LFG inscription all member recieve Role proposal. If someone refuse is the inscription canceled or other member will enter in the queue without the member who refuse is role?

6) about teleportation, if member quit an LFG group and new one is added for replacement. After the teleportation this new member will be at the entrence of instence or near the group? Same question with member of the party do get out/ get in teleportation.

7) Specialy about group composition and teleport cooldown. Iam surprised about the possiblity to get out / get in from dungeon without restriction.

Thanks for advance

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.

in worst case only a non-existent spell that should be cast as achievement-criteria on encounter-end

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

Perhaps I wasn't clear enough - I am concerned about what _should_ happen, and not what is done in these hack implementations around

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

A third and important question:

- What else is needed as "communication" between boss encounters and DF?

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)

thanks Spp for your reply, this is at least an extremely interesting DBC - though it didn't yield the answer I hoped for

A bit about understanding DF:

- Player A has done an instance, then DF needs to be able to check which encounters are done in the instance?

- If a player changes the state of an instance, will there be some need to "notify" DF?

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.

Where can be modified rewards?

For example if i select random heroic dungeon it rewards 2 emblems and money but I have seen "lfg_dungeon_rewards" and rewards for those quests are not emblems and money, just things like "Satchel of Helpful Goods"

How does rewards works?

Thank you

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.

1) Don't show who is already join to group (shoul show role then cursor on LFG eya)

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)

2) One from test char wasn't telepor into dangeon

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.

3) Some players who was teleported into dangeon have name "Unknown"

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

4) I can't complite dangeon (test on VanCliff)

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.

are there _any_ ids anywhere related to "complete" a dungeon (either opcodes or DBCs)

(for Van Cleef I would expect an idea somewhere between 1000 and 3000, not related to the npc-entry)

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...

Wow the diff is clear. I have started porting one month too early.

This caused me follow the old spaghetti code. Anyway i am continuing to debug it for now. It will give me enought understainding to be more near of your next code.

Can you confirm me when a group is completed, created and all member teleported, all member of this group automatically leave the queue?

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

DungeonEncounter.dbc structure (in client memory)

struct DungeonEncounterEntry
{
 int id;
 int mapId;
 int instanceDifficulty;
 int noIdea;
 int encounterIndex;
 char *name;  // char* name[16]; int nameFlags;
 int noIdea2;
};

noIdea --> The max value of each mapId-InstanceDifficulty pair is final boss/event. Not always being the max encounterIndex.

I guess encounterIndex is the number of the boss (or more generally the encounter) in the instance/raid.

Example in ICC :

Lord Marrowgar -> encounterIndex = 0

Deathwhisper -> encounterIndex = 1

Gunship Battle -> encounterIndex = 2

etc

(I'm not sure)

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.