[BUG] Loot chests

[Auntie Mangos]

I also notify about -Group-loot-mode-is-ignored&highlight="][bUG] Group loot mode is ignored

[Auntie Mangos]

Wojta, for me not igoniring, and master loot in chest-case for me is working . I notify about this post

also i saw your version, and i think this

go->GetGoType() == GAMEOBJECT_TYPE_CHEST && go->GetGOInfo()->chest.groupLootRules

always pass for GAMEOBJECT_TYPE_CHEST cuz GetGOInfo()->chest.groupLootRules always return something. You can do experement with 0 and 1, and always you will get group-rules.

BTW, DB ( like YTDB and UDB have right DATA in this field)

[Auntie Mangos]

Wojta, for me not igoniring, and master loot in chest-case for me is working . I notify about this post

also i saw your version, and i think this

always pass for GAMEOBJECT_TYPE_CHEST cuz GetGOInfo()->chest.groupLootRules always return something. You can do experement with 0 and 1, and always you will get group-rules.

BTW, DB ( like YTDB and UDB have right DATA in this field)

Well I thought that if I use this in if(), then its false when chest.groupLootRules = 0 and true when chest.groupLootRules = 1..?

[Xfurry]

Fixed in [11878]

I think this bug is old but I've noticed that nobody actually reported this. I have tested this both on my server's custom core and on a clean mangos core without sd2 and the results are the same, so I believe it's a general Mangos bug.

The bug is about looting the loot chests while in a group.This bug can be exploited and players can fill their pockets with tons of items and emblems in just a few min. I will explain how it happens.

Mangos Version: MaNGOS/0.16.0-DEV (* * Revision 9611 - *) for Win32 (little-endian)

Custom Patches: no custom patches

SD2 Version: no sd2

Database Name and Version : YTDB_0.10.9_R533_MaNGOS_R9311_SD2_R1565_ACID_R302_RuDB_R34.9

How it SHOULD work: If you are in a party group or raid group, if someone loots a chest with green, blue, violet or orange items the group loot interface should be displayed and you should be able to choose need or greed. Or if the group is using master loot then the master looter should be able to choose from a drop down menu a player from a list, to which he should give the item.

How it DOES work: There are 2 major bugs and exploits:

1. While in a group which uses group loot, master loot or other types of loot, the loot award system doesn't work for loot chests. So the items can be stolen from the chest by anyone. This is the minor bug.

2. The major bug is that the loot chest can be farmed infinitely. I will explain how is this done. While in a group one of the members loots the chest pressing "shift + right click" and he takes the emblem and some items. Then comes the second group member which loots the chest using the same keys (shift + right click) and takes the emblem and some of the remaining items. The other group members use the same pattern. Only two players are requiered in order to exploit this bug. After the second group member has looted the chest, the first group member can loot the chest again using the same keys and taking the same items (because the items are respawned or the chest isn't deleted). And this can happen over and over again, until they get borred.

For a better understanding I will post an exploit screen from my server:

Image link

I've searched on many git hubs and even on trinity core in order to find a fix for this major exploit, but I haven't found anything. I've even tryed to implement some custom fixed, but those didn't work either.

Maybe some of you will take a look at this problem and find a solution. Loot chests are important because many encounters from Northrend and escpecially Ulduar use this type of loot.

[Wowka321]

On offi loot-rules working with chests? Or free for all?

[The_Game_Master]

Yes, on offi loot-rules are working with chests.

[darkstalker]

chest gameobjects have a flag in DB that indicates if they use group loot or not.

i had to remap lots of loot tables to creatures instead of chest because of this, and the loot code is pretty confusing

[Xfurry]

Well, I have tried to set the field's value to 1 from 0 but it didn't change anything. (data15 is the field according to UDB )

[darkstalker]

that field is not used at all

[Wowka321]

Something like this. Attempt to implement Chest rules loot.

http://paste2.org/p/734973

May be not fully correct, but seems working

[Xfurry]

Many thanks. It really works.

I have completed the patch.

Mangos loot chests fix

Also don't forget to update the gameobject template like this:

update `gameobject_template` set `data15` = 1 where `entry` in ( -- chest ids here -- );

I strongly recommend this to be implemented in revision. It would solve a lot of problems with the loot in Ulduar and some other dungeons.

[Wojta]

Something like this. Attempt to implement Chest rules loot.

http://paste2.org/p/734973

May be not fully correct, but seems working

hmm does master loot work to chests with this? I ve tried to make my own version(i did not know about this patch), but I think that client ignore SMSG_LOOT_MASTER_LIST for chests...(on blizz servers theres only FFA and group loot for chests, http://www.wowwiki.com/Loot + one player told me that).

[NoFantasy]

Also don't forget to update the gameobject template like this:

update `gameobject_template` set `data15` = 1 where `entry` in ( -- chest ids here -- );

The database content provider must make sure they have proper data in the _template, this is not something Mangos should do.

The basic concept of using data15 for type 3 GO is still valid though. Just adding query for others to see it more easy:

SELECT entry,name FROM gameobject_template WHERE type=3 AND data15=1;

[Xfurry]

hmm does master loot work to chests with this? I ve tried to make my own version(i did not know about this patch), but I think that client ignore SMSG_LOOT_MASTER_LIST for chests...(on blizz servers theres only FFA and group loot for chests, http://www.wowwiki.com/Loot + one player told me that).

There are 2 types of loot chests:

1. World loot chests which are placed on the main map and contain only normal items (escpecialy food and potions). These type of chests use only free for all and group loot.

2 Instance loot chests which are spawned inside the instances when a special event, which involves something else than killing a boss, is done. These chests contain superior or epic items and use the same rules as any instance boss: Group loot, Master loot, Need before greed, Round robin, free for all.

This info is checked from blizz players which are raiding Ulduar weekely.

The database content provider must make sure they have proper data in the _template, this is not something Mangos should do.

I agree, but it seems that YTDB didn't bother with this, because the loot rules for chests (I'm refering only to dungeon chest which I've described above) were not implemented officially in Mangos. That is why I've made this bug report.

Maybe you will take a look on that patch, and implemented in the revision if everything is in ok.

[NoFantasy]

If some database doesn't bother to keep their data up to date or add custom values, they are free to do so. After all, it's your choice what database to use And i wish i could comment on the code itself, however i'm of little use with the loot-code, i have hardly had a look at it. Leaving it to others who has more knowledge, then i'm free to comment and review code parts i'm familiar with and know how works.

[Wowka321]

Like in zulaman script part

//increase or decrease chance of mojo?

if (!urand(0, 49))

DoCastSpellIfCan(caster, SPELL_PUSH_MOJO, CAST_TRIGGERED);

urand always return value (Zero is value too), and DoCastSpellIfCan never to be happened here =\\ Tested many-many times.

in operator if we should use operators of comparison or boolen value. groupLootRules - not bool, that why groupLootRules = 0 value too and pass check in if. 0 != NULL. 0 it's Zero - it value true.

Maybe i'm wrong and someone can explain it more clearly?

[Smak_]

Check it on 9612.

Here is a serious bug:

Set loot type to grouploot. Player1 loots chest, all players see rolls, player1 loots all loot from chest(but should be message "doesn't rolled yet"), click "pass" at all loot, after that another players roll items and get it! So party/raid get double loot.

I hope you understand me Sorry for bad English!

[Wowka321]

Really get loot? I can't reproduce this. It's only visual. btw same bag with creature.

[maly32167]

Like in zulaman script part

urand always return value (Zero is value too), and DoCastSpellIfCan never to be happened here =\\ Tested many-many times.

in operator if we should use operators of comparison or boolen value. groupLootRules - not bool, that why groupLootRules = 0 value too and pass check in if. 0 != NULL. 0 it's Zero - it value true.

Maybe i'm wrong and someone can explain it more clearly?

You can do boolean check for values, i use it a lot for 1/2 chance checks like if(urand(0,1) ? do smth if true : do smth if not ), false will be always returned for 0 with boolean check for numeric value

[darkstalker]

typo? this is dead code

+                    if(Group* group = GetGroup())
+                    {
+                        if (group == this->GetGroup())

seems that because recipient implementation is missing

[dardennf]

Chests need some love .

[darkstalker]

this fixes looting unspawned chests (double loot bug):

diff --git a/src/game/GameObject.cpp b/src/game/GameObject.cpp
index 1d08d73..d1088cc 100644
--- a/src/game/GameObject.cpp
+++ b/src/game/GameObject.cpp
@@ -205,6 +205,10 @@ void GameObject::Update(uint32 /*p_time*/)
                    }
                    return;
                }
+                case GAMEOBJECT_TYPE_CHEST:
+                    if (isSpawned())
+                        m_lootState = GO_READY;
+                    break;
                default:
                    m_lootState = GO_READY;                         // for other GOis same switched without delay to GO_READY
                    break;
@@ -413,7 +417,7 @@ void GameObject::Update(uint32 /*p_time*/)
            }

            loot.clear();
-            SetLootState(GO_READY);
+            SetLootState(GO_NOT_READY);

            if(!m_respawnDelayTime)
                return;