Skip to content

Commit

Permalink
Creature/GameObject: Do not spawn dynguid spawns by default if they a…
Browse files Browse the repository at this point in the history
…re part of game_event
  • Loading branch information
killerwife committed Jan 1, 2024
1 parent 4232dfc commit 1a81596
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions src/game/Globals/ObjectMgr.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -2162,7 +2162,7 @@ void ObjectMgr::LoadCreatures()
else
data.OriginalZoneId = 0;

if (dynGuid)
if (dynGuid && !data.gameEvent)
{
m_dynguidCreatureDbGuids[data.mapid].push_back(guid);
}
Expand Down Expand Up @@ -2378,7 +2378,7 @@ void ObjectMgr::LoadGameObjects()
else
data.OriginalZoneId = 0;

if (dynGuid)
if (dynGuid && !data.gameEvent)
{
m_dynguidGameobjectDbGuids[data.mapid].push_back(guid);
}
Expand Down

4 comments on commit 1a81596

@evil-at-wow
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth, I think this commit is avoiding only a part of the original issue (though the most important part I suppose so that's great).

It makes creatures/gameobjects (using dynamic guid) that are part of a game event not spawn immediately, which is awesome. But consider what happens when the game event starts later. First GameEventMgr will spawn the creatures/gameobjects and add them to the map/grid, which is fine. If nothing happens and the event ends some time later, we're still fine because GameEventMgr will simply remove the spawns from the grid again. But there's usually something to spoil the fun, and I think that's this line. So creatures that die during the game event and use the new spawning system will be added to the SpawnManager after all, which will later respawn them, even if the game event has ended already at that point! Maybe there should be an extra event condition in that if statement there as well? At least I haven't come up with a better way to handle that part that doesn't require quite a bit of changes...

One way to see/test this ingame is for example to start the AQ 10h war event, then turn it off again after a few minutes when you're in Gadgetzan. A whole bunch of event objects will despawn as expected, but depending on your timing there will also be a good chunk of dead mobs that have been killed by guards (or players); these will remain in the world and will keep respawning until a server restart.

@killerwife
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really hate the outliers of this particular dynguid implementations :D Yeah, they have to be purged from the SpawnManager as well.

@evil-at-wow
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, with all these different yet related systems/places related to (de)spawning stuff, it's hard to keep a fully detailed overview. I suppose humans aren't that good pondering about such complex systems, so I can't blame you 😄

@killerwife
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spawn group system is pretty concise and easy to track of because I intentionally made it super limited based on leaked official spec. This per-spawn dynguid is more of a quickly slapped system together so the full transition to dynguid is easier and so that devs dont have to force everything into spawn group (since I suspect official does that for everything). Hence the bugs that also result from it :D :D

Please sign in to comment.