Тема создана в качестве продолжения темы http://forums.alliedmods.net/showthread.php?t=26632 Используемые сокращения:
SP - spawn point
HLSDK - Half-Life SDK
BSP - формат файла, которых содержит все данные о карте
SP - это структура, у которой актуальны следующие свойства:
.origin - положение SP в пространстве;
.angles - угол поворота рождаемой модели SP в градусах (обычно задается параметр Y - yaw, отсальные равны нулю); в BSP файле всегда задается только один параметр - Y;
.classname - класс SP; используемые классы: info_player_start, info_player_deathmatch, info_vip_start и info_player_coop
Иногда пытаются задавать и .v_angle (куда будет по умолчанию смотреть рождемый игрок), но использования этого свойства зависит от spawn-движка. По-моему оригинальный spawn-движок не используется это свойство. А вот CSDM использует.
К SP имеют отношения следующие фрагменты из HLSDK:
player.cpp::EntSelectSpawnPoint()
player.cpp::IsSpawnPointValid()
gamerules.cpp::GetPlayerSpawnSpot()
Как именно загружаются SP из BSP файла из HLSDK вы не узнаете.
Что удалось выяснить:
1) В plugin_precache() точки еще не созданы
2) В plugin_init() точки из карты уже загружены
3) Изменение classname уже загруженной точки практически ничего полезного не дает. Влияет только на функцию find_entity(), но реально игроки исходного класса (который был до изменения classname) как рождались там, так и будут рождаться
4) удалять созданные SP (remove_entity()) нельзя, т.к. это приведет к глюкам: при рождении игроки могут оказаться по пояс в земле и торчать там пока суициднишься (видимо это происходит на месте удаленных entity, т.е. они где-то линкуются в списки)
5) SP - это не global object, т.к. свойство globalname у них пустое (а global объекты линкуются в списки)
7) SP с координатами {0, 0, 0} является служебной и не может использоваться для рождения игроков
8) при рождении в точке игрок приподнимается на 1 единицу пространства
9) при рождении игрока, если не найдены свободные SP, то придудительно убиваются все игроки в радиусе(?) 128 единиц пространства выбранного SP
Вот что мне непонятно:
1) VEN сказал, что есть механиз перехвата инициализации свойств SP перед их рождением. Я о нем вообще не в курсе. Его можно реализовать без FakeMeta? Раписывть не обязательно: примеров будет достаточно.
2) SP не обязательно рождать (т.е. применять к ним DispatchSpawn()), хотя если и рождать SP, то ничего плохого (по кр. мере я) не будет. Может все-таки правильнее их рождать?
3) Что будет если я применю DispatchKeyValue() к уже сущетсвующему объекту? (собираюсь проверить)
4) Как правильно удалять SP?
Добавлено (2006-11-27, 1:31 Am)
---------------------------------------------
УРРРРРРРРРА! 6 часов ковыряния непрошли напрасно! Я сделал это! Оказывается п.7 - это ключ к моему решению! SP можно отключить! Т.о. в precache я создал 16 нулевых точек для CT, потом когда оригинальные SP прогурзились, существующие CT я отключил (они в DM картах для монстров и не имеют стратегического назначения), потом половину из существующих точек для T я копирую (origin и angles) на созданные в precache CT точки, и тут же обнуляю, т.е. отключаю T-точки. Супер! Работает идеально! Кстати, если менять класс у SP, то это может влиять негативно: если переимновать класс у самой первой SP в очереди, то можно сразу получить сообщение, что CT или T team is full. Вот такие вот дела.
