[DEV] Dungeon Finder

[shauren]

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

my DungeonEncounter.dbc implementation

that extra flag for boss isnt needed

[ascent]

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

my DungeonEncounter.dbc implementation

that extra flag for boss isnt needed

we are not trinitycore. remeber

[Undergarun]

we are not trinitycore. remeber

Shauren is sharing his own idea trying to help Cyberium and co. in Dungeon Encounters development for MaNGOS!

Please, be more polite with people who tries to help you ;-)

[cyberium]

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

my DungeonEncounter.dbc implementation

that extra flag for boss isnt needed

Thank you i will look on it.

[Spp_]

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.

[Unkle Nuke]

I can forgive ascent for his MaNGOS "patriotism". Some people hold strong opinions, which is why there's a Trinity Core.

However... I applaud those of you from Trinity, who are here to contribute your work and ideas, and commend you for helping to make MaNGOS that much better with your generous assistance.

You are helping to bridge a rift that should never have happened and I hope both MaNGOS and Trinity will be stronger because of people like you, who are examples to all of us for working together toward the betterment of the community.

I prefer MaNGOS for learning, but you still do brilliant work at TC and I'm glad you're here to help.

[ascent]

any update info?

[cyberium]

WIP when i have time

[ascent]

bump up;~

[ankso]

bump up;~

Why?

[michalpolko]

Someone wants to join The Banned Crew...?

[singlem]

Any repo or updated patch for this?

[vladex]

read the other posts... its still under development

[singlem]

I know that...but thanks for the reminder:|

Any I was asking due to the fact that I have been porting the trinity one for the past week and would like to know if there is some repo that being worked on. Always better to have more than one person looking at new code

[kbz]

the difference is: you're just porting...

cyberium is writing it from scratch

as they say... "patience is a virtue"

[cyberium]

I know that...but thanks for the reminder:|

Any I was asking due to the fact that I have been porting the trinity one for the past week and would like to know if there is some repo that being worked on. Always better to have more than one person looking at new code

No online repo (at least of my version) at this moment.

Be sure i will considere all your remark and if you are skilled no problem for me to add you as collaborator of the project when it will be released.

Some news :

- No enought time to work on the code but...

- At this point i choosed to delete all the code related to reward, Yes, this part need realy a global look on it, so i don't have time/knowledge to code it in the good way.

- Main code is now threaded so normaly this will reduce any bad impact to mangos performance. I know this feature need to be tested on big server to validate it.

- I am curently rebasing the code. I need to work on new class to make it more clear.

- I need more time to have a global look on the code to delete any duplicate stuff or optimise some function. (Actual patch is 5400 lines longs...)

If you whant to know all, this monday i created new branch on my local repo called "LfgToUp" so yes i plan (like two month ago lol) to release the code asap

[Undergarun]

- Main code is now threaded so normaly this will reduce any bad impact to mangos performance. I know this feature need to be tested on big server to validate it.

I'm the 3k+ realm tester ;-) Don't worry about that.

[sart13]

I ported Shauren implementation of Encounters.dbc. May use this for LFG work...

[burninsky]

any update??

[sart13]

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.

[Spp_]

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?

[sart13]

thanks for the comment, be sure to use this on the work.

I'm using is not 2 but 14 queues - separate by type of dungeons. This is to speed data compare, and matches due to fundamentally different from the original method of creating groups.

Proposals not require update - exists only to the acceptance or rejection. not TC way

comments on the encounters I have not understood - it is a separate system, and do not need cash for it - is very fast.

team-dependent queues - not need, time for open std:: container comparable with time on count 40-50 members of this container.

LFG_MEMBER_FLAG_UPDATE - my custom flag, used only for clear cache in client (creating guid list for clear cache). don't send this to client ^)

[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

[darkstalker]

whats the "R2" repo?

[sart13]

whats the "R2" repo?

see members of team.

PS now LFG system in R2 branch - in alphatest stage.