[3.3.5] DB/spawns: mining nodes/veins spawning on top of each other

Smileynator commented 7 years ago

Description: Ore spawning seems to spawn on itself. Might be due to duplicate entries in the database, or the server not checking if an ore is already spawned. It looks like this, and i have seen it happen 3 in just 1 area (Silverpine forest in this case) http://puu.sh/tJZcs.png Also happens with different types together.

Current behaviour: (Tell us what happens.) Ores spawn duplicates

Expected behaviour: (Tell us what should happen instead.) It should not spawn on top of one another.

Steps to reproduce the problem:

Start server, check ores in the area.

Branch(es): Probably all, I found no issues before this one mentioning this problem.

TC rev. hash/commit: 39b20b4431a1a67446e9cc4c2221fd42cc907291

TDB version: TDB 335.62 + updates up to and including 2017_01_17_00_world.sql

Operating system: Windows 7

Staleness89 commented 7 years ago

Probably needs pooling entries.

MrSmite commented 7 years ago

Probably needs pooling entries.

Perhaps but I think there is also bad data. In Westfall and Ashenvale there are a few nodes that show on the minimap but are actually underground or too high on a non-climbable hill and cannot be mined.

I just never bothered to report them because they are usually copper or tin which there is already enough of.

NOTE: The ones in Westfall are actually unreachablle, not just below in the Deadmines.

ghost commented 7 years ago

Is this the same as 2 different nodes (like tin+silver) spawning on top of each other (or partial overlapping)?

Smileynator commented 7 years ago

@tkrokli i can not confirm if they are the same issue. The one i screenshotted almost seems like near duplicate data. But the tin/silver on top of eachother seems like a pooling issue. Since they are in the exact same spot.

I also can not find any wowhead data to confirm or deny that these veins were or were not duplicate in live. But i have never seen nodes closer than "viewing distance" from one another in all my 3 years of live if that adds any value.

Kittnz commented 7 years ago

Ghostlands has this issue aswell

r00ty-tc commented 7 years ago

tin+silver spawning on top of eachother is something you might not be able to avoid in current pool system.

I think on retail the rare types of ore shared spawn points with the normal ore for the area, at a MUCH lower spawn chance.

Nagrand adamantite:

Nagrand khorium (rare)

Nagrand Fel iron

Now, if you look at those three pictures what you'll see is that Khorium has more spawn points.. Does that make sense? Yes, because if you look at the other two pictures you will see the Khorium spawn points are ALL the points for Adamantite and ALL the points for Fel Iron. Thus for ore there would be two pools for ore.

Pool 1: Adamantite (98% + Khorium 2%) Pool 2: Fel Iron (98% + Khorium 2%)

So, when it's spawning the zone it first picks a spawn point, then one of the possible node types to put there (say 4% silver, 96% tin, or the example above). That way you don't get the overlapping spawns in this case.

Multiple "normal" nodes, might be that those kinds also share a possible spawn point, but in current limited pooling, it doesn't know that only one kind should spawn there.

Ultimately I don't know if we should have an algorithm to "avoid" close placement.

I've discussed with @malcrom and others about a different pooling system (for game objects and creatures) which would allow this kind of pooled spawns to be created. But, it's something to do after the dynamic spawn stuff is merged.

Smileynator commented 7 years ago

I think that if you want to solve it, you have to do the new spawn pooling like you described. Clearing "near points is obviously useless, and thus i think we should merge spawn points for the "shared rare spawns" or just throw the rare spawn out and have it spawn on the points of known normal ores rarely. Which results in a cleaner database. If no duplicate entries are in the database. There is no need to check if spawned, just that it spawned something there and shouldn"t attempt again. And the pool probably should only spawn on X out of Y points. As to not spawn on every single available point. Since that is what live does. Often your 2nd round in an obviously deserted area would give you totally different set of spawns. I'd guess that even below 50% of all spawn locations were used at one single time. But i have no confirmed values to back this, just my ingame experience.

r00ty-tc commented 7 years ago

Yes, the idea of limiting spawns from the pool already exist, and it would be precisely that. There's two ways of implementing. Which one is correct I don't know.

1: Per spawn group (creature or go) have a minimum spawned/maximum spawned value. So, the system always ensures that the minimum is maintained (by expediting a respawn if the pool total alive/spawned drops below that value) and otherwise will respawn random items/locations in the pool until the maximum is met.

2: Only have a maximum. Spawn normally, but increase respawn time based on either number alive/spawned in pool, or number of players in the zone/area.

As I say we've talked about this to death. But, it's not in the core yet.

Smileynator commented 7 years ago

@r00ty-tc I would like to think the 2nd. Simply because of the behaviour i saw on the real servers. If you start killing quickly with a few people or alone on a high level for the area, the oldest kills would respawn first, and it WAS possible to run out of mobs or clear an area of ores completely (i often had issues waiting for ores when others were around). So there was no minimum to my knowledge. I would however like to check if my recollection is accurate, and have someone murder a small tribe of gnolls or whatever on an open visible area where they only spawn in 1 camp/spot, to make sure this behaviour is still correct. (I recommend a hunter to use tracking for that creature) It has been 3 years for me so.

Either way, i would recommend to build the system to allow for a minimum, and have the default be 0 to indicate natural spawning on timers is desired. (as is current) and just enforce the max (percentage wise i would assume?)

r00ty-tc commented 7 years ago

That's the idea. Each possible creature/go in a group would have a weight attached and the same pool group would be assigned a spawn pool with all the possible locations. I did consider whether to code both and let people choose the mode. But then, it's dead weight if we know for sure which method is the right one.

Smileynator commented 7 years ago

I can't imagine that having the 0 minimum check in an if statement is going to cause performance issues. I think you would rather have it flexible, or have 2 copies of the same method if you want to force some code to just use A or B and never want to have it check where you know the answer. But at that point your are basically micro optimizing. Which is the root of all evil.

I can imagine that at some point it will be handy to have both. As mobs would have no minimum. Nor ores. But i could imagine mechanics involving "make sure that of this pool always X are alive" for raids or whatever needs such a pool in special occasions. (Code wise i might be talking out of my ass now, i have no idea if this code could even be remotely shared to that extend, i am just hoping it might/will, but i know TC core can be a mess.)

r00ty-tc commented 7 years ago

Pretty sure it's minimum actually. If you have a mage on retail go to Mulgore, to Bael'dun digsite. Where the little elementals are.

Zerg them, fast and observe that around 10 will respawn very quicky. I think it's minimum for sure. Man, my first guess was right.

Smileynator commented 7 years ago

Huh, then maybe i never found a pool that small. But good to have it confirmed then. They respawn fast, but now the question is how fast. Like the instant the 10th gets killed, 1 is added? Or is their respawn time just halfed or quartered?

r00ty-tc commented 7 years ago

Well I count exactly 10 again. So I want to wait to be sure that the total is more than 10, and they don't just happen to have a really fast respawn :P

Yep. Now they're all respawning back some 10-15 mins after I started. So actually I think on retail respawn time is longer than 5 mins as we use. But, this minimum baseline is used to ensure there's always something to kill.

Smileynator commented 7 years ago

Do make sure to document results. Also i would like to confirm if other mob types have the same setting or not. Like is it always 10? or is it always X percentage of total? This is kind of hard to confirm though.

Edit: @r00ty-tc Neat. And i did think that questing alone i did not have time to get to "the boss" and back out without getting ambushed on my way out. It sometimes happened, like 2 or 3 mobs that i started to kill with. But now i just get ganged upon leaving the building i just entered. So maybe it makes sense to actually use blizzards timers. I still wonder if they are global, percentage wise compared to pool or otherwise, but that would take a large amount of datasamples to confirm or deny any of it.

r00ty-tc commented 7 years ago

It won't be always 10. It might be a fixed percentage of the number in the group. Have a search around the world for a small enclosed group of creatures that are clearly going to be grouped as one. Preferably part of a quest. They might not assign dynamic respawn times to creatures that aren't attached to a quest.

Smileynator commented 7 years ago

This is hard to make accurate assumptions on sadly. Not documentable by convential sniffing :P

r00ty-tc commented 7 years ago

Well it is. If you know the entry/ies in the area you're in. You run sniff. Keeeel zem all. Wait a 20 secs, keel zem all again etc. Then analyze sniff result by entry + guid to see how many unique were up at the various points in time you want to check.

Should see that it would only drop below a set number for a short time. So whatever number it seems to respawn upto regularly is the minimum. The number of uniques you found when you arrives (assuming no-ne else was there) is the maximum. Find several small enough areas where it can be assured that the sniff will catch all respawns and, if there's a constant %age between min/max you have the magic number. If there isn't a magic number, then you know the min/max is done per group and is not fixed percentage.

Smileynator commented 7 years ago

And then we could only guestimate most of the spawned groups, since we do not know what is or is not a group etc. I hope it is a magic number, i really do.

r00ty-tc commented 7 years ago

For me, it's enough to make the core support. Then someone else has the harrowing job of working out the numbers :P

Smileynator commented 7 years ago

Good on you :P Lets see how this goes!

bumbummen99 commented 7 years ago

So you need a sniff of all ores in the area? i can sniff it next time i play.

r00ty-tc commented 7 years ago

I think we have sniffs. The problem is that currently there are spawns close together. Like silver + copper on the same spot. When converting a zone to pooled spawns in the new way, there will be some work to convert the data. That's all. The newer system (in development) will ensure this doesn't happen.