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

В том же файле ingamehud.c добавьте след функции и тогда в целом это будет выглядеть так: //первый файл ingamehud.c modded class IngameHud { override void ShowHudUI( bool show ) { m_HudHideUI = true; //делаем, чтобы всегда скрывало, независимо от приходящего show if (m_HudState) { RefreshHudVisibility(); } } override void ShowQuickbarUI( bool show ) { m_QuickbarHideUI = true; //скрываем квикбар какой бы show не пришел RefreshQuickbarVisibility(); } override void ShowQuickbarPlayer( bool show ) { m_QuickbarHidePlayer = true; //скрываем квикбар какой бы show не пришел RefreshQuickbarVisibility(); } } ну и в missiongamplay.c необходимо сделать первоначальное скрытие, тогда он будет выглядеть так: //второй файл missiongameplay.c modded class MissionGameplay { override void OnInit() { super.OnInit(); if(m_Hud) { m_Hud.ShowHudUI(false); //здесь делаем первоначальное скрытие m_Hud.ShowQuickbarUI(false); //здесь делаем первоначальное скрытие для квикбара } } }

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

Вы лучше его не удалите, а скрывайте что бы плеейр не делал. Так вы избежите кучу клиентских ошибок в лог, который будет забивать им диск 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); //здесь делаем первоначальное скрытие } }

{ "AreaName": "Tisy_Fog_1", "Type": "ContaminatedArea_Static", "TriggerType": "EffectTrigger", "Data": { "Pos": [ 1185.22, 0, 13984.8 ], "Radius": 900, "PosHeight": 50, "NegHeight": 70, "InnerRingCount": 10, "InnerPartDist": -1, "OuterRingToggle": 1, "OuterPartDist": 50, "OuterOffset": -5, "VerticalLayers": 0, "VerticalOffset": 0, "ParticleName": "graphics/particles/spooky_mist" }, "PlayerData": { "AroundPartName": "graphics/particles/spooky_mist", "TinyPartName": "graphics/particles/spooky_mist", "PPERequesterType": "PPERequester_ContaminatedAreaTint" } } Как видим, меняется TriggerType, ParticleName, AroundPartName, TinyPartName

ты скозал?