[DEV] Dungeon Finder

[Feanordev]

Look at this like that:

If he had any news (and still would be intrested) he would share them, no ?

Why so impatient then and asking about it (news related to dungeon finder) every ~5th post ?

[cyberium]

Still analising sniff and try tro found some solution.

[xnxx10]

offtopic:

@Feanordev: coz salja wanna have "Cereals incoming" title not seed

[cyberium]

Can anyone confirm me, http://www.wowhead.com/spell=72221 is applied

- When one member of the new group is pickup one AND dungeon is Heroic

Or

- When you use random dungeon heroic

Or

- When you use random dungeon heroic AND one member in the group is pickup.

Or

Any other case that i don't know?

[kbz]

if any of the members from the group joined via "random dungeon" (normal or heroic) gets this buff, dont have an active sub atm, but my guess is: as soon as a member joins the group via Random Dungeon the group gains this "buff"

[Wojta]

I thought this buff is present always when you are in dungeon via DF, but i was only some heroics on offi.

[kbz]

quoting the first 2 comments from wowhead:

By ArgentSun on 11/06/2009 (Patch 3.2.2)

Buff given to all party members in a group for a random dungeon/heroic.

A couple of clarifications: it only works if you select random dungeon/random heroic. There is no random raid option anywhere.

ReplyBy JohnsonQPew on 12/09/2009 (Patch 3.3.0)

As I understand it, this buff is applied when your group has a random MEMBER from the LFG tool -- it does not matter if the dungeon itself is random. So as long as you filled one spot with the LFG tool, it was not bugged.

[cyberium]

As I understand it, this buff is applied when your group has a random MEMBER from the LFG tool -- it does not matter if the dungeon itself is random. So as long as you filled one spot with the LFG tool, it was not bugged.

Finaly implemented this way. Thanks.

[kbz]

you're welcome

[ascent]

'A' waiting you~

[cyberium]

In each step of the implementation i realise "I cannot get this information this way but if i implemented that code other way i was able"...

So i change often the base of the code and this realy take lot of time to only make compatible all already implemented function.

Anyway here is the advancement.

- join queue solo

- join queue group

- all leave situation

- rolecheck

- proposal

- find group (with possibility to complete queued group by another queued group)

- create group

- teleportation (and exit instance handled)

- statisitc (windows information)

- KickVote

- buff and debuff.

- reward

Same point has before

Except...

- Now buff "Luck of the draw" is reimplemented using "spell_area" table. This way i can be sure this buff will not be seen in other place than dungeon.

- Worked a lot of time about "Unknown name bug" after teleport but didn't found solution. Realy frustated about that.

- Starting play with 'ACE_Thread' class. Why? If you not have an idea (what i doubt) you will see

- I was a bit leazy (mainly due to lot of invest for nothing in 'unknown name bug') so i choosed to work on another part. Reward. I must at least know how i will implement it to not get a need of a big readaptation of existing code. I finaly choosed (after lot of analysing) to add new table (dungeons_encounters) will contain all the encounters info (encounter_id, bossguid, map, index, importance). This table will permit to get all boss contained in one instance. 'bossguid' is the guid of the boss founded in 'creature' table. So for LFG data we have all we need. I am not able to know if boss is killed or not.

But it's not enought. The question is how i can generate correctly event only when creature is boss?

I actualy test some of the possibility, database modification seem to be mandatory at this point... Mainly creature table.

- Lot of check added for security reason and i probably need more of them...

TODO this week :

- Work on stabilisation of my message system.

- Do more isolation of my class to make less modification possible of original mangos code.

- Think (or implement it if i have time) on caching some info constantly asked by client (CMSG_LFD_PARTY_LOCK_INFO_REQUEST and CMSG_LFD_PARTY_LOCK_INFO_REQUEST) (SPP Idea)

So in place of pushing not finalised code (at least in my point of vue) i prefer to let you waiting a little more Sorry about that.

[Schmoozerd]

- I was a bit leazy (mainly due to lot of invest for nothing in 'unknown name bug') so i choosed to work on another part. Reward. I must at least know how i will implement it to not get a need of a big readaptation of existing code. I finaly choosed (after lot of analysing) to add new table (dungeons_encounters) will contain all the encounters info (encounter_id, bossguid, map, index, importance). This table will permit to get all boss contained in one instance.

Use the NPC-entries, this should be good enough and makes live easier for database-maintainers.

However I see a few problems:

- multi-boss encounters (like 4 horseman, difficult how to handle, but should be possible)

- boss encounters, where the boss doesn't die (afaik Keepers in Ulduar only turn friendly, or Majordomo in MC)

Perhaps we really should start to implement a simple messaging system..

[cyberium]

You are right but i can confirm you now i am not able to handle all the situation. This patch is very complex and i started the coding with first analyse that was at least 50% wrong actualy.

So iam in the stage to found possible solution and choose the best, some situation like you described will be investigated if the rest are working

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

Do anyone know how i can generate identify 'cVictim' is boss around

in uint32 Unit::DealDamage(Unit *pVictim, uint32 damage, CleanDamage const* cleanDamage, DamageEffectType damagetype, SpellSchoolMask damageSchoolMask, SpellEntry const *spellProto, bool durabilityLoss)

823           DEBUG_FILTER_LOG(LOG_FILTER_DAMAGE,"DealDamageNotPlayer");
824           Creature *cVictim = (Creature*)pVictim;

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

[Spp_]

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)

[Schmoozerd]

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

[kbz]

some kill credits are granted through spells... others via direct killing X mob...

[Spp_]

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

[cyberium]

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)

After quick view i just noticed that 'flags_extra' is not sended to client so we can use it like you do.

Is it the best idea?

Doing something like

if(cVictim->GetCreatureInfo()->flags_extra & CREATURE_FLAG_EXTRA_INSTANCE_BOSS)

appear to be fast enough to be integrated in this havy used function.

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

You are right about the existence of recognize a boss without adding new flag. But here is the only way.

- if elite creature is killed in instance

- if creature guid is table encounterMap[instancemap]

So finaly we need test for each elite creature killed if there is same guid in a table. It's slow test...

Adding IsBoss to creature class with m_IsBoss initialised at creation of the object will result at the same situation has before. For all elite creature created we must verify if there guid exist in one table. Same slow test.

So there is redundant stuff if i add flag like SPP but it's not useless in term of speed.

some kill credits are granted through spells... others via direct killing X mob...

That must be implemented in the future. For now i take care of big majority of situation.

[Curious]

What about CREATURE_FLAG_EXTRA_INSTANCE_BIND in creature template, flag _extra ?

[shauren]

how about linking them to achievement system?

[Spp_]

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.

[shauren]

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.

im well aware of that, and i already have an idea how to link encounters (will implement in trinity)

[kbz]

im pretty sure low level instances dont bind on boss kill so this CREATURE_FLAG_EXTRA_INSTANCE_BIND doesnt cover all bosses..

[Unkle Nuke]

Why have an extra flag?

Could it not be done using the map IDs instead? Wouldn't that allow you to determine if an NPC or Boss were killed in a specific instance by simply checking the map?

[cyberium]

Why have an extra flag?

Could it not be done using the map IDs instead? Wouldn't that allow you to determine if an NPC or Boss were killed in a specific instance by simply checking the map?

And then? How you can know when a boss is killed? How you make diff between 10 bosses and 200 trash mob?

List of name? List of guid? Do check in every mob killed if it appear in boss list?

Found a better way, and i'll implement it...

Anyway iam stopping this part for now :

- lazy about some reaction...

- it's too much for me adding this part to DF while DF not finished.

Greetings