GAMEOBJECT_TYPE_TRAP = 6 (заселение)
 

Если верить вики, то го тип 6 встречается у го:
GAMEOBJECT_TYPE_BUTTON = 1: data3: linkedTrap
GAMEOBJECT_TYPE_CHEST = 3: data7: linkedTrapId
GAMEOBJECT_TYPE_SPELLFOCUS = 8: data2: linkedTrapId
GAMEOBJECT_TYPE_GOOBER = 10: data12: linkedTrapId

При этом го тип 6 должен находиться в точке основного го и обрабатываться вместе с ним.
Сейчас его тупо прописывают в базе в точках спавна основных го, при деспавне которых остается го тип 6.

В теории можно не хранить в базе "заселение" таких го, а загружать их в мир сразу с основным го в те же координаты, с теми же фазами и масками, но:
Как я понимаю, данные о го в мире получаются по гуиду, значит, надо как-то загрузить го тип 6 для основного го с каким-то гуидом, чтобы не было повторений.
Также обработка основного го (смена видимости, фаз, масок и т.д.) должна вызывать обработку го тип 6, прописанного в шаблоне.

1. Правильно ли я понимаю реализацию работы го тип 6, прописанных в шаблонах других го?
2. Какие есть более простые варианты?

В режиме теста:
1. Сделал загрузку го типа 6 в точку основного го с теми же параметрами (координаты, фаза, маска и т.д.) по всем шаблонам го, гуид брал по счетчику = максимальный неиспользуемый гуид + порядковый номер в цикле загрузки го.
2. Удалил из базы все го тип 6, которые встречаются в заселении, загрузил сервер и проверил на примере http://ru.wowhead.com/object=195344 - го тип 6, указанный в шаблоне данного го, заспавнен.

Далее надо заставить оба го отрабатывать вместе.
Возможно, в структуру основного го надо добавить гуид заспавненного го тип 6, чтобы не выполнять поиск второго при использовании первого.

Есть ли вообще смысл в такой реализации?

можно попробовать сделать для объектов нечто вроде недавно заимлеменченной фичи creature_linking_template. будет куда логичнее, да и пригодится не только здесь.

Тогда в таблицу придется заносить записи, которые уже хранятся в шаблоне объекта, а это, на мой взгляд, нелогично.

GO type 6 вроде еще и независимо могут быть на карте - ловят касты и т.д.

Так я же написал, что подобный прием надо применять к го тип 6, указанных в шаблонах других го в качестве визуального оформления, т.е. это просто антураж.

Если го идет отдельно, то точки спавна прописываются в базе, а для указанного мной случая "заселение" и обработку надо производить параллельно с основным го.

Если в объекте основного го хранить гуид привязанного к нему го, то можно без проблем обрабатывать последний в зависимости от действий с первым.
При таком раскладе го тип 6 должен правильно обрабатываться при взаимодействии с основным го, в эвентах и пуллах.

Это избавит от лишних данных в таблице `gameobject` для антуража, которые дублируют данные основного го, за исключением двух полей.
Кроме того, не будет косяков, когда основной го антураж и антураж оказались в разных точках, имеют разные параметры видимости или чего-то просто нет в мире.

Давайте я вам открою страшную тайну:
https://github.com/mangos/mangos/blo...bject.cpp#L819

Не знаю что там в YTDB но в UDB уже давно не должно быть слинкованных GO type 6.

Страшная тайна - это хорошо, только не пашет.

1. По коду SummonLinkedTrapIfAny() вызывается только в эффектах спеллов, которых при добавлении го в мир нет.
2. Скомпилил чистое ядро без сд2, удалил из базы все го тип 6, прописанные в шаблонах других го, вошел в игру - пустота, нет го тип 6, как и раньше.
В моем варианте на той же базе го-антураж были в точках основных го.

Возможно, вызов SummonLinkedTrapIfAny() должен быть при добавлении основного го.

Проверял на го 195344, у которого антураж 195346.

Что я сделал не так, что у меня "рабочий код" чистого ядра не сработал?

Теперь понял проблему, возможно вы правы. Я явно подзабыл детали. Там единствеено могут быть проблемы с тем что основной ГО не полностью добавлен в мир.

В момент заполнения mGameObjectDataMap в методе ObjectMgr::LoadGameObjects() добавляем в mGameObjectDataMap го тип 6, если он указан в шаблоне основного го.
Спавн го-антуража идет после основного го с учетом эвентов и пуллов.

В чем именно может быть проблема, в каких случаях основной го может быть неполностью добавлен в мир?

Я имел ввиду если делать в ::Create

В чем минусы того, что предложил я?

Я просто пояснил для какого места (_если_ его использовать) была бы возможно проблема. Я не предлагаю использовать там и т.д.

Для добавления го-антуража в mGameObjectDataMap пришлось создать функцию
Функцию писал для теста спавна го, но мне не нравится, что приходится тягать параметры из
, да и возможен более правильный вариант.

Каким образом лучше сделать заполнение mGameObjectDataMap?

Во вложении тестовый патч на суммон го-антуража для основных го.
Получилось как-то громоздко и сомнительно, должно быть более простое и правильное решение.

Нужны советы по данному вопросу.

Возвращаемся к старой теме.

В ObjectMgr.cpp есть метод void ObjectMgr::AddGameobjectToGrid(uint32 guid, GameObjectData const* data), который вызывается при загрузке го из таблицы `gameobject`, при старте эвента и в пулл-системе, но туда надо передавать реальный гуид объекта.
Если происходит каст спелла с суммоном го, то там вызывается свой метод добавления ловушки: void GameObject::SummonLinkedTrapIfAny().

При спавне, использовании и деспавне оба го (основной и ловушка) должны отрабатывать вместе.

1. Надо ли сразу загружать го-ловушки или добавлять при появлении основного го в мире (эвент, пулл, каст и т.д.)?
2. Может, в структуре основного го должен храниться гуид ловушки и наоборот, чтобы можно было правильно определить связь между ними?
3. Где лучше всего разместить обработчик хотя бы для спавна, чтобы учесть все случаи появления го в мире?