Таблица лидеров

Globals.xml ? DeadAnimal ищи (параметр в секундах)

задержка скорее всего из за синхронизации идет и того, что после спавна игрока идет телепорт. Игрок спавнится в координатах что выпали. Выдается лут. Следом он получает комманду на телепорт в другую точку. И если для сервера телепорт это лишь секундная комманда, которая меняет координату объекта в памяти, перемещая его. То для клиента игры это смена расположения с обновлением синхронизации, исходя уже из новой точки, в том числе и прогрузка окружения, объектов, местности, лута и т.п. Да, она быстрая, но эта доля секунды весьма чувствительна и заметна. И если игрок спавнится, у него клиент игры только приступил к прогрузке той точки, где персонаж соспавнился изначально. Затем следом бац, и резко место меняется. Чем дальше игрок находился от точки телепортации тем больше шанс на длительную прогрузку (радиус синхронизации от игрока примерно 2-3к, в этом радиусе должно быть быстро все) А поскольку компы у всех разные, как и точки могут поумолчанию падать разные, то и синхронизация смены местности может быть как незаметная, так и заметная с такими приколами. Увы, с этим ничего не сделать, ну разве что убрав из сета телепорт в локацию игрока для всех и задав его либо в ините миссии CreateCharacter (функция вроде эта, параметр pos="7500 0 7500";), либо в соответствующем xml файле миссии, ка это авторами игры задумано.

1 сервер, игроков 40-60, тут опять же от того какую частоту выставите или в стоке оставите (дополнительно сколько зомби будет на локации на каждого игрока увеличенный спавн оных не есть гуд). Плюс памяти 32Гб высокоскоростной за глаза должно хватить и SSD: - но это скорее для быстрого старта больше. P.S. сами игроки если их собрать всех в кучу не сильно просаживают серверный ФПС, тут скорее влияют события от их присутствия на локациях и спавн объектов и прочего, можно как например спавн порезать не на 400м а меньше. Проверял на R5 1600AF в разгоне до 3,9Ггц. А вот заспавнив 500 зомбаков в несколько куч сервак повис на добрых 45сек. А по поводу зиона, ядер много а частота низкая, лучше тогда I7 берите, игре больше скорость важна нежели количество ядер. У зионов в многопотоке производительность хороша, но только в том случае если если программа умеет использовать все ядра. Поправьте если ошибаюсь.

Альтернатива есть, называется руки из правильного месте. Для начала правильно настроить в types время жизни ваших объектов (центральная экономика может делать все что душе угодно с тем, что в нее не прописано, все притензии к авторам игры, потому прописываем. Чтобы не спавнило в здания - смотрим пример у любой крафтовой вещи.). Затем - правильно выставляем lifetime и restock ограничения в конфиге скрипта, чтобы было время жизни у нашего отспавненног оскриптом объекта, была корректная очистка после спавна и таймаут ожидания нового. Скрипт сам очищает после удаления события землю в той точке, где спавнил объект. Разумеется при условии, что указана верная координата, т.к. радиус скана от точки спавна на наличие прописанного объекта весьма мал, ну и при условии, что объект на точки, а не некий Вася его унес. Ну и перед спавном нового тоже чистит на всякий, если есть. Единственный баг, о котором уже говорил хрен знает сколько - переспавн до рестарта будет в той же точке, что выпала. Исправление этого на внутреннем тестировании уже 2 года, и из-за критической нехватки времени, без понятия когда будет в релизе. Но это единственный способ исправить эту проблему, т.к. более 50% кода для этого пришлось переписать. Также, сам скрипт берет таймаут отсчета от момента старта сервера постоянно. Он не запоминает тайминги с рестартами, после старта спавн и таймауты текут с нуля заного у объектов. И соответственно, с рестартами он также проверяет также точки, что в конфиге у вас стоят. Но тут также есть нюанс. Вангую, у вас рестарт сервера в 50% случаев не плановый. Так вот, если вы меняли json, правили точки спавна и не сделали вайп карты после этого - можете быть счастливы, скрипт оставит где-то на карте старый отспавненный объект, и его вычищать буквально ручками. В остальном, если у вас объект ушел из точки спавна, не верно выставлено время, он также может остаться. Иных причин ему остаться попросту не может быть.

Вы лучше его не удалите, а скрывайте что бы плеейр не делал. Так вы избежите кучу клиентских ошибок в лог, который будет забивать им диск C. Для этого модифицируйте в своем моде 2 класса: InGameHud (5_Mission/gui/ingamehud.c) и MissionGameplay (5_Mission/mission/missiongameplay.c) Предлагаю вам сделать это следующим образом: //первый файл ingamehud.c modded class IngameHud { override void ShowHudUI( bool show ) { m_HudHideUI = true; //делаем, чтобы всегда скрывало, независимо от приходящего show if (m_HudState) { RefreshHudVisibility(); } } } //второй файл missiongameplay.c modded class MissionGameplay { override void OnInit() { super.OnInit(); if(m_Hud) m_Hud.ShowHudUI(false); //здесь делаем первоначальное скрытие } }

....эээ,каким модом то? Как и скриптом из предыдущего поста-сферический скрипт в вакууме? интересно как он решает проблему что запрыгнув тупо на машину-игрок в домике?