Здравствуйте. Пытаюсь понять логику работы Npc и Spawn движка в ПТС-ах, и по некоторым вопросам уже весь мозг сломал в догадках и предположениях. А посему, любые подсказки от знающих людей были бы крайне ценными. Вопросы такие:
1) Те, кто спавнятся функцией CreateOnePrivateEx(...) по сути являются такими же миньонами, как и созданные функцией CreatePrivates() и добавляются в пати с нпц, чья аишка вызвала эту функцию? Или это просто функция для спавна моба в том же мейкере, где и тот нпц, через чью аишку идет спавн, и призывающий с призванным никакими пати не связаны?
2) В какую группу мейкера(SpawnDefine) добавляются нпц, которые не были изначально прописаны в npcpos, а были доспавнены АИшкой через CreatePrivates() или CreateOnePrivateEx(...)? Ведь тот же миньон далеко не всегда исчезает сразу же после удаления хозяина, но если сказать мейкеру убрать всех мобов в том или ином SpawnDefine - все призванные аишками нпц должны также удалиться. А для этого им, по идее, нужно принадлежать к тому же SpawnDefine. Но при этом, если посмотреть, как устроен контроль респа в том или ином дефайне мейкера, то возникают вопросы. Например, код из default_maker:
Он принимает ссылку на SpawnDefine удаленного моба и, как я понимаю, вешает отложенный таск на спавн моба. Но это ведь должно распространяться только на "родных" мобов этого дефайна. И если "доспавненные" аишкой мобы находятся в той же группе, то как оно отличает, удален родной моб или доспавненный? А если доспавненные мобы не добавляются в ту же группу, где и владелец призвавшей его аишки, то каким образом сервер понимает, каких доспавненных нпц нужно удалить при деспавне всего Define? Вот это противоречие заставляет меня ломать мозг в догадках, как оно на самом деле устроено и куда добавляются такие вот "доспавненные" нпц.
3) Хотелось бы точно знать, как работает функция мейкера AtomicIncreaseTotal(SpawnDefine, int, int). Это просто потокобезопасная реализация примерно такого кода? Она проверяет и увеличивает только пару define.total и define.npc_count или учитывает также и maximum_npc и npc_count самого мейкера? Если учитывает счетчики мейкера - зачем тогда перед ней обычно идут прямые проверки на maximum_npc мейкера в их аишках? А если нет, то значит атомарное увеличение счетчика заспавненных в мейкере мобов происходит где-то "под капотом" в ядре?
4) Не смог понять, как ПТС-ка определяет статус дружественности\враждебности того или иного нпц по отношению к игроку. Не агрессивности, а именно того, с кем бы без ctrl говоришь, а кого бьешь, кого задевают массухи, а кого нет. В АИшках и пара метрах npcdata толком не нашел параметров, намекающих на такой смысл. Думал, дело в типах, прописанных в нпцдате(типа boss, warrior, citizen, zzoldagu) как аналогов Npc, Monster, RaidBoss, Minion в яве. Но в результате тестов выяснил, что двух разных нпц типа citizen воспринимает по-разному - одного как моба и пытается сразу бить, а второго - как нпц, с которым персонаж пытается говорить. Так где же прописывается этот статус условно npc/monster в ПТС?
5) Есть четкий список возможных хендлеров типа ON_NPC_DELETED, ON_NPCPOS_EVENT и т.д. Однако. в одних АИшках они прописаны с одной сигнатуркой, в других - с другой, и вариаций могут быть сотни. Зачастую, они таким образом просто объявляют локальные переменные метода в его сигнатурке - это я понимаю. Но есть ли какой-то хитрый способ узнать некую базовую сигнатуру, то есть, аргументы, которые ядро передает всегда в тот или иной хендлер, чтобы отличить нормальные аргументы от таких вот "объявлений локальных переменных"? Или только анализировать каждое применение вручную и пытаться прослеживать закономерности, делая из них вывод? Нужно это, разумеется, для формирования правильной структуры аишек и взаимодействия ядра с ними в своей говнояве, при попытке реализации оффлайк-структуры мейкеров/аишек мейкеров/аишек нпц с их частичным парсом + постепенным допилом руками.
1) Те, кто спавнятся функцией CreateOnePrivateEx(...) по сути являются такими же миньонами, как и созданные функцией CreatePrivates() и добавляются в пати с нпц, чья аишка вызвала эту функцию? Или это просто функция для спавна моба в том же мейкере, где и тот нпц, через чью аишку идет спавн, и призывающий с призванным никакими пати не связаны?
2) В какую группу мейкера(SpawnDefine) добавляются нпц, которые не были изначально прописаны в npcpos, а были доспавнены АИшкой через CreatePrivates() или CreateOnePrivateEx(...)? Ведь тот же миньон далеко не всегда исчезает сразу же после удаления хозяина, но если сказать мейкеру убрать всех мобов в том или ином SpawnDefine - все призванные аишками нпц должны также удалиться. А для этого им, по идее, нужно принадлежать к тому же SpawnDefine. Но при этом, если посмотреть, как устроен контроль респа в том или ином дефайне мейкера, то возникают вопросы. Например, код из default_maker:
C-подобный:
EventHandler ON_NPC_DELETED(deleted_def, i0, i1, maker0, reply) {
if (deleted_def.respawn_time != 0) {
if (myself.maximum_npc >= myself.npc_count + 1) {
if (AtomicIncreaseTotal(deleted_def, 1, 1)) {
deleted_def.Spawn2(1, deleted_def.respawn_time, deleted_def.respawn_rand);
}
}
}
}Он принимает ссылку на SpawnDefine удаленного моба и, как я понимаю, вешает отложенный таск на спавн моба. Но это ведь должно распространяться только на "родных" мобов этого дефайна. И если "доспавненные" аишкой мобы находятся в той же группе, то как оно отличает, удален родной моб или доспавненный? А если доспавненные мобы не добавляются в ту же группу, где и владелец призвавшей его аишки, то каким образом сервер понимает, каких доспавненных нпц нужно удалить при деспавне всего Define? Вот это противоречие заставляет меня ломать мозг в догадках, как оно на самом деле устроено и куда добавляются такие вот "доспавненные" нпц.
3) Хотелось бы точно знать, как работает функция мейкера AtomicIncreaseTotal(SpawnDefine, int, int). Это просто потокобезопасная реализация примерно такого кода? Она проверяет и увеличивает только пару define.total и define.npc_count или учитывает также и maximum_npc и npc_count самого мейкера? Если учитывает счетчики мейкера - зачем тогда перед ней обычно идут прямые проверки на maximum_npc мейкера в их аишках? А если нет, то значит атомарное увеличение счетчика заспавненных в мейкере мобов происходит где-то "под капотом" в ядре?
Java:
public boolean AtomicIncreaseTotal(final SpawnDefine define, final int count, final int unk)
{
lock.lock();
//if(maximum_npc < npc_count + count)
//return false;
if(define.getTotal() < define.getNpcCount() + count)
return false;
//npc_count += count;
define.increaseNpcCount(count);
lock.unlock();
return true;
}4) Не смог понять, как ПТС-ка определяет статус дружественности\враждебности того или иного нпц по отношению к игроку. Не агрессивности, а именно того, с кем бы без ctrl говоришь, а кого бьешь, кого задевают массухи, а кого нет. В АИшках и пара метрах npcdata толком не нашел параметров, намекающих на такой смысл. Думал, дело в типах, прописанных в нпцдате(типа boss, warrior, citizen, zzoldagu) как аналогов Npc, Monster, RaidBoss, Minion в яве. Но в результате тестов выяснил, что двух разных нпц типа citizen воспринимает по-разному - одного как моба и пытается сразу бить, а второго - как нпц, с которым персонаж пытается говорить. Так где же прописывается этот статус условно npc/monster в ПТС?
5) Есть четкий список возможных хендлеров типа ON_NPC_DELETED, ON_NPCPOS_EVENT и т.д. Однако. в одних АИшках они прописаны с одной сигнатуркой, в других - с другой, и вариаций могут быть сотни. Зачастую, они таким образом просто объявляют локальные переменные метода в его сигнатурке - это я понимаю. Но есть ли какой-то хитрый способ узнать некую базовую сигнатуру, то есть, аргументы, которые ядро передает всегда в тот или иной хендлер, чтобы отличить нормальные аргументы от таких вот "объявлений локальных переменных"? Или только анализировать каждое применение вручную и пытаться прослеживать закономерности, делая из них вывод? Нужно это, разумеется, для формирования правильной структуры аишек и взаимодействия ядра с ними в своей говнояве, при попытке реализации оффлайк-структуры мейкеров/аишек мейкеров/аишек нпц с их частичным парсом + постепенным допилом руками.
