[WIP][3.3.5] Implement spawn group management in InstanceScript#20103
Conversation
…wn groups based on boss state.
|
|
||
| void InstanceScript::Create() | ||
| { | ||
| for (int8 i = 0; i < bosses.size(); ++i) |
There was a problem hiding this comment.
/home/travis/build/TrinityCore/TrinityCore/src/server/game/Instances/InstanceScript.cpp:386:24:
fatal error:
comparison of integers of different signs: 'int8' (aka 'signed char') and 'size_type' (aka 'unsigned long') [-Wsign-compare]
for (int8 i = 0; i < bosses.size(); ++i)
~ ^ ~~~~~~~~~~~~~
There was a problem hiding this comment.
Yes, I am capable of reading travis output. Thank you.
|
|
||
| #include "ZoneScript.h" | ||
| #include "Common.h" | ||
| #include "ObjectMgr.h" |
There was a problem hiding this comment.
Hrm, just use the actual type (std::unordered_multimap< etc) instead of the typedef?
There was a problem hiding this comment.
Or no, that won't work either (type itself is defined in ObjectMgr.h). I'll think of something.
| uint32 spawnGroupId; | ||
| uint8 flags; | ||
| }; | ||
| typedef std::unordered_multimap<uint16, InstanceSpawnGroupInfo> InstanceSpawnGroupMap; |
There was a problem hiding this comment.
I still don't like this, none of these headers should include each other (in any direction)
Proposed fix: change the container to std::unordered_map<uint16, std::vector<InstanceSpawnGroupInfo>>
and hold a pointer to that vector in InstanceScript
There was a problem hiding this comment.
Yeah, but where do we define InstanceSpawnGroupInfo? Class definitions need to be available at point of substitution, iirc?
There was a problem hiding this comment.
It doesn't matter. vector permits incomplete types
|
Hell yes |
|
Oh right. I see. At least we need a new table name entry and the preliminary field names, CREATE TABLE `instance_spawn_groups` (
`instanceMapId` smallint(5) unsigned not null,
`bossStateId` tinyint unsigned not null,
`bossStates` tinyint unsigned not null,
`spawnGroupId` int unsigned not null,
`flags` tinyint unsigned not null,
PRIMARY KEY (`instanceMapId`,`bossStateId`,`spawnGroupId`,`bossStates`) |
4 participants
What it says on the tin - begin dynspawn follow-up work by gradually phasing out
linked_respawnin favor of spawn groups for instance spawn control.Medium term, once all instances have appropriate DB data, this will allow us to remove the
instanceIdcolumn from the respawn tables altogether, relying exclusively on this system.New DB table
instance_spawn_groups:instanceMapId- duhbossStateId- duhbossStates- bitmask,1 << stateforEncounterStatevaluesflags- bitmask, currently allows0x1(FLAG_ACTIVATE_SPAWN) and0x2(FLAG_BLOCK_SPAWN)A spawn group is activated if any of its
FLAG_ACTIVATE_SPAWNconditions are met, unless any of itsFLAG_BLOCK_SPAWNconditions are met - this allows for some neat complex management if necessary.PS: Instance spawn data is currently being crowdsourced - check this thread.