azerothcore / azerothcore-wotlk

Complete Open Source and Modular solution for MMO
http://www.azerothcore.org
GNU Affero General Public License v3.0
6.48k stars 2.59k forks source link

Exploitable chests in Plaguelands (and other zones too) with too low respawn timer (+not pooled) #4928

Closed ghost closed 3 years ago

ghost commented 3 years ago

Exploitable chests in Plaguelands (and other zones too) too low respawn timer (+not pooled)

CURRENT BEHAVIOUR:

1) If chests are not pooled you can park a lvl 1 alt there for hours and farm them whenever they respawn.

2) The current respawn is 3 minutes.

3) Many chests are "safe" if you approach them carefully, even at lvl 1.

This issue is in almost every zone, but I list here some in the Plaguelands which can be exploited.

EXPECTED BLIZZLIKE BEHAVIOUR:

Chests should have a much, much slower respawn and/or be pooled so if you take 1 chest another appears elsewhere.

STEPS TO REPRODUCE THE PROBLEM:
  1. Go to Crown Guard Tower in Plaguelands
  2. Click chest
  3. Wait
  4. Click chest again
EXTRA NOTES:

For example;

ID 45949 GUID 153453 Solid Chest

Short respawn, not pooled, infinitely exploitable. Especially if you set up an autoclicker to just right click the chest with autoloot on every 10-15 mins, leave overnight, make 1k gold.

AC HASH/COMMIT:

AzerothCore rev. 8bacb39d5334 2021-03-20 18:26:35

OPERATING SYSTEM:
MODULES:
OTHER CUSTOMIZATIONS:
FrancescoBorzi commented 3 years ago

@Stifler82 @Zoidwaffle can one of you guys please pick this up?

Zoidwaffle commented 3 years ago

Sure, I can take a look and fix this zone, but I don't have time before Monday or Tuesday. Fixing all zones at once is a bit much, but I did plan to pool all herbs/minerals/treasures eventually, taking one zone at a time.

Zoidwaffle commented 3 years ago

As written above, I will not get around to fix this today. I self-assigned it and will do it soon (did the same for some other zones already, so should be trivial).

FrancescoBorzi commented 3 years ago

@Zoidwaffle thank you!

markvetx commented 3 years ago

@Zoidwaffle Hi there! Wanted to ask you, where do you collect the data before making new pools? Do you check all the nodes/chests etc. before making a new pool?

I'm asking, so that may be I could try to make the same SQL commits as you've already done just for another zones. :)

Zoidwaffle commented 3 years ago

@markvetx : sure, if you use Linux I can share the way I do it (maybe it will work on Macs as well, not sure). If you use Windows, I can share some of my ideas, but it's more manual work.

But the idea is like this... Go to the zone of interest, then visit the upper left and lower right corner and get coordinates and map number. Use those to look for treasure in the database - check if there are already pools for those objects.

Basically:

.tele zonename
.go zonexy 10 10
gps
.go zonexy 90 90
gps

Notice the X,Y and Map values. Adjust if needed (like, fly around with your GM if the locations are not quite right).

For EP I then found treasures with these commands:

SET
@X1       =3435,
@Y1       =-2690,
@X2       =1285,
@Y2       =-5915,
@MAP      =0,
@TREASURE  ='2744,19017,19018,2843,2844,2849,106318,106319,2845,2847,3715,4096,105578,105579,105581,111095,2850,2852,2855,2857,4149,153451,153453,153454,74447,74448,75293,123330,123331,153468,131979,157936,164958,178244,178246,179488,179486,179490,179487,179489,179491,179496,179492,179494,184741,179497,179493,181665,181798,181800,181802,181804,182053,184740,184793,184930,184931,184936,185915';

-- Now find the treasures...
SELECT `guid` FROM `gameobject` WHERE `map`=@MAP AND `position_x`<@X1 AND `position_x`>@X2 AND `position_y`<@Y1 AND `position_y`>@Y2 AND FIND_IN_SET (`id`,@TREASURE);

Check if they are pooled already:

SELECT * FROM `pool_gameobject` WHERE `guid` IN (45734,45735,45740,45741,45742,45743,45744,45745,45746,45747,45748,45749,45910,45915,45931,45933,45938,45949,45950,85791,85792,85793,85795,85797,100086);

If not, find an available pool number, Decide the size of the pool and respawn time - usually there's no exact numbers to use... So what I have done is use a fast respawn for low level spawns (they are pretty worthless anyway) and longer respawn for high level chests (so they cannot be abused, but not make them super rare either).

Check out the file here, should be very easy to read: https://github.com/azerothcore/azerothcore-wotlk/pull/4947/files

To verify everything appears OK, I use the addon "Gathermate" and I have a script that teleports me around and clicks automatically. It's made in Bash and that's why you probably need Linux for it to work.

I do some logic using MySQL + Bash, but it could probably be done in MySQL alone... So a JOIN would simplify some of this stuff when cross-checking with pools.

Edit: A video of the teleporting-script in action is here: https://www.youtube.com/watch?v=im2-mRj-Qs0&t=4s

markvetx commented 3 years ago

@Zoidwaffle Thank you for this detailed answer! Yes, I'm using Linux. I've got the idea and have a few more questions if I may ask you.

  1. I suppose this type of process can be applied to mines/herbs as well (just change the treasure GUID's to herb/mines GUID's)?
  2. When I asked about where do you collect the data, I meant do you use any external DB's like This one for example?
  3. I guess for herbs and mines the alternative query would look like this one?

SET
@X1       = corner coords,
@Y1       = corner coords,
@X2       = corner coords,
@Y2       = corner coords,
@MAP      = map where the zone is located,
@COPPERVEIN (or any other name, it's just a variable) ='1731, 2055, 3763, 103713, 181248';

-- Now find the veins in this case
SELECT `guid` FROM `gameobject` WHERE `map`=@MAP AND `position_x`<@X1 AND `position_x`>@X2 AND `position_y`<@Y1 AND `position_y`>@Y2 AND FIND_IN_SET (`id`,@COPPERVEIN);
Zoidwaffle commented 3 years ago

Yeah, for minerals and herbs I made these:

@MINERALS ='1731,2055,3763,103713,181248,1610,1667,1732,2054,3764,103711,181249,2653,1735,2040,150079,176645,123310,324,150082,176643,123848,175404,181555,181556,181569,181570,181557,185877,1733,73940,177388,165658,2047,150081,123309,1734,150080,73941',
@HERBS    ='1617,3725,1618,3724,181166,1619,3726,1620,3727,1621,3729,2045,1622,3730,1623,1628,1624,2041,2042,2046,2043,2044,2866,142140,142141,176642,142142,176636,142143,183046,142144,142145,176637,176583,176638,176584,176639,176586,176640,176587,176641,176588,176589,181270,183044,181271,181272,183045,181277,181275,183043,181276,181279,181282,181280,181285,181281,181284,185881',

I often cross-check data with vmangos and TrinityCore if I'm in doubt - I just downloaded their databases and have them locally. But in the case of Eastern Plaguelands, I just used what was in AC already.

I used the Gathermate Data addon when reworking Bloodmyst Isle... It's not exactly a database, but I did use it as a reference for almost all the nodes I placed there. I'm well aware that the Gathermate data isn't 100% accurate and it's poisoned with data from private servers etc. and so on, but I still consider it a fairly accurate reference in most cases.

If you want to rework a lot of zones, you need to pay attention to some zones using a pool of pools - it's done in some zones but not all.

markvetx commented 3 years ago

@Zoidwaffle

I used the Gathermate Data addon when reworking Bloodmyst Isle... It's not exactly a database, but I did use it as a reference for almost all the nodes I placed there. I'm well aware that the Gathermate data isn't 100% accurate and it's poisoned with data from private servers etc. and so on, but I still consider it a fairly accurate reference in most cases.

I see. What's your opinion on external DB's like this one again? I guess they are filled with data from different private servers as well. Should it be used as a reference?

If you want to rework a lot of zones, you need to pay attention to some zones using a pool of pools - it's done in some zones but not all.

You mean like Westfall for example? A zone with a little sub-zones in it like mines. I saw several times that the mines have a lot of mine nodes spawned inside of it.

Zoidwaffle commented 3 years ago

I also Google for whatever info I need, so using external DB's is fine. Just remember that they are not necessarily the absolute truth.

For pools, I was thinking more like Duskwood. A lot of mineral veins (maybe all, I didn't check) have a pool with 3 minerals inside it. So 10% for silver, 30% for tin and 60% for copper (or something like that). So only 1 of those will be there at a time. The same is true for a lot of other minerals. They are then grouped into the pool_pool template, so you can say that there should be 30 spawns taken from 80 pools with each 3 options (I made those numbers up, but the logic should be fine).

For stuff like mines, I would suggest they get a pool of their own - so it's outside of the "zone" pool spawning things in the open world.

However, I'm no authority here - it's just what I think sounds about right.

Also an important factor here - having a raid encounter, then the accuracy really matters for the game. So it should be as close as possible to what it was.

But if a node spawns a bit next to where it spawned back in WoTLK, it's hardly a game-breaker... and at least to me, it doesn't matter much as my gaming experience should be indifferent.

A lot of zones need a lot of love - and fixing all this takes a long time. Treasures is the easy one - minerals and herbs are far worse :grin:

markvetx commented 3 years ago

@Zoidwaffle Okay, I'll try to do something with this when I have a free time. Thank you for the detailed answer again! :)

Zoidwaffle commented 3 years ago

@markvetx : You're welcome. I can share some Bash-scripts with you as well if interested.