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

Описание: ServerMonitor - это управляемый на PowerShell автономный мониторинг сервера DayZ с настраиваемыми опциями, такими как автоматическое обновление модов (включая копирование ключей модов), автоматическое обновление файлов сервера, автоматическое архивирование логов для сохранения чистой папки профиля с полной поддержкой параметров-mod и-servermod. Это альтернатива популярным CFTools с одним существенным отличием: все ваши данные хранятся на вашем сервере и нет никакой зависимости от веб-службы для использования этого инструмента (пока ваш сервер подключен к интернету, этот инструмент будет работать). Возможности: автоматический запуск сервера в случае его включения автоматическое обновление сервера до актуальной версии игры в Steam при рестарте (Stable ветка) автоматическое обновление модификаций до актуальной версии в Мастерской Steam при рестарте (Stable ветка) Поддержка BEC Копирование и сортировка логов Требуется: Steamcmd Steam аккаунт с наличием приобретенной DayZ (для загрузки модификаций с мастерской) Выделенный сервер с возможностью запуска windows-приложений Установка: Создать папку SteamCMD и скачать steamcmd в нее Войти в steamcmd используя свои логин и пароль от Steam (как - читаем тут) Закрыть steamcmd вводом `quit` и нажатием `enter` Создать папку ServerMonitor и распаковать в нее файлы из архива с программой. Провести настройку в ServerMonitor.cfg Настроить списки модов в playersmodslist.txt и servermodlist.txt (для уточнения: playersmodslist.автоматически загружает модов на клиенте и сервере, в то время как servermodslist.txt-это моды, которые должны загружаться только на сервере, ни в коем случае это не должны быть одни и те же моды в обоих файлах) Пример заполнения файлов: BuildAnywhere - https://steamcommunity.com/sharedfiles/filedetails/?id=1574054508 KillFeed - https://steamcommunity.com/sharedfiles/filedetails/?id=1567872567 Запустить ServerMonitor.exe из папки ServerMonitor Дополнительная установка для автоматических рестартов: Загрузите, установите и настройте BEC (читаем тему) (программа должна соединяться с сервером успешно) Загрузите BECMonitor (ссылка ниже) и распакуйте zip-файл в нужном вам месте Настройте BECMonitor.cfg Запустите BECMonitor.exe Notes: Если DayZServer не установлен в указанный каталог, он будет установлен в указанный каталог Не копирует файлы конфигурации для модификаций в профиль, так как Моды должны автоматически создавать их, если они не существуют В настоящее время поддерживается только стабильный релиз DayZ Чтобы полностью выключить сервер, обязательно выключите ServerMonitor перед выключением DayZServer Не забудьте настроить файлы конфигурации сервера (указанный вами serverDZ.cfg) Может использоваться для нескольких экземпляров DayZServer, для достижения этого вы просто создаете 2-й экземпляр этой программы в другом каталоге с настроенной конфигурацией Убедитесь, что у Вас установлен SteamGuard на используемом вами аккаунте, так как данные вашего аккаунта будут храниться в виде обычного текста на вашем сервере и могут быть похищены. Также обратите внимание, что если учетная запись не предназначена для сервера, то код SteamGuard может потребоваться ввести вручную при каждом запуске. Файлы программы должны находиться в корневой папке с самой программой Рекоммендуется устанавливать корневой каталог сервера игры в корень диска (т. е.: C:\DayZServer или D:\DayZServer и т.д.) License: CC BY-ND 4.0 Ссылки: ServerMonitor.rar (ServerMonitor.rar ) BECMonitor.rar (BECMonitor.rar) Описание и авторские пояснения сохранены! Был выполнен только перевод статьи и зеркалирование файлов на момент написания. Авторская тема разработчика программы на официальном форуме: https://forums.dayz.com/topic/245162-servermonitor-with-updater-including-mod-updates/ Видео установки ServerMonitor: P.S. Пришлось тестировать на WIndows 8.1 т.к. на Windows 7 программа отказалась работать (старенький семерочный powershell ее чем-то не устроил, видимо)

По всем законам жанра, название функции не меняет цвет, а выделяется только тип просто это вообще не читаемо щя облазил нотепад с его десятком стилей не нашел не один который был менял само название функции, может стоит исправить?

Обновление 1.1.1.0 -Добавлено расписание авторестартов -Исправлен не открывающийся редактор сервера

а на другом хостинге игра другая ?)) почему на одном хостинге всё нормально а на другом просто поддержка отписывается общими фразами?))) потому что им пофиг скорее всего. я даже написал им ребята ищите проблему там то там то . не у нас всё норм." с батей мы курили рыбий корм, батя помер а мне норм"

Корпус что то такое не обязательно с RGB это на вкус и цвет. Главное чтобы вдув был хороший и выдув. Чтобы циркулировал поток внутри. p.s забыл добавить чтобы в корпусе были фильтры ещё, это как бы лучше для пк чтобы не бегать чистить его часто. А так фильтры достал помыл поставил на место. По умолчанию они идут спереди точно, снизу под БП и сзади вроде смотрю по своему сейчас. Но думаю есть и те производители что экономят на этом и могут их не быть.

Все настройки в стандартном конфиге serverDZ.cfg serverTime="SystemTime"; //."SystemTime" Как на сервере на часах или делаешь своё "2015/4/8/17/23" по формату "YYYY/MM/DD/HH/MM" у меня стоит serverTime="2015/4/8/07/00"; то есть 7 утра... serverTimeAcceleration=4; // если ставишь своё время, его можно ускорить от стандартного в 24 раза... Я поставил в 4 раза... serverNightTimeAcceleration=6; // тоже самое для ночи (0.1-64) у меня значение 6, ночь где то примерно 30 минут... serverTimePersistent=0; // Persistent Time (value 0-1)// если 1 сохраняет время которое было до рестарта, если 0 то с 7 утра если значение serverTime="2015/4/8/07/00";

В данной теме я распишу возможность создания серверного мода для сервера на собственном примере и объясню как его собрать.Работающий на момент публикации статьи на версии сервера игры 1.04.152050. Темы к ознакомлению, связанные с данным материалом: https://s-platoon.ru/topic/8701-enscript-uchimsya-osnovam-skriptinga/ https://s-platoon.ru/topic/8622-enscript-delaem-skript-dlya-moda-i-osnovnye-principy-skriptinga-modov/ Нам понадобятся: 1. Сервер игры актуальной версии, не ниже патча 1.04. Как установить можно узнать тут: До версии 1.04 параметра servermod у сервера игры не существовало!!! 2. Программа 'PBO manager' с состава инструментария армы из сети: https://www.armaholic.com/page.php?id=16369 Зеркало: https://yadi.sk/d/_gmzoNSDpNJTt Еще зеркало: Pbo manager.rar 3. Скрипты для упаковки в наш мод, сформированные и подготовленные нами вручную. Как - смотрите тему 4. Notepad++ https://notepad-plus-plus.org/download P.S. Вместо 'PBO manager' можно использовать DayZ Tools, но как им пользоваться разбираемся сами ? И так, приступим: 1. Предположим, что у нас имеется свой некий набор скриптов (если нет - читаем выше), который необходимо добавить серверу, но не на уровне миссии сервера, а на более ранних уровнях его загрузки. Например, добавить свой killfeed, модифицировать или изменить какой-либо из родных скриптов сервера игры, либо вовсе модификации, подключенной у вас. Для примера в этой теме и данного гайда я взял вот этот набор скриптов, собранный непосредственно для данной темы за 5 минут, и не изменяющий в сервере ровным счетом ничего. Он может послужить базой для создания своих модов, функций, переменных или классов. Данный гайд будем описывать, исходя из этого архива. Архив: MyScripts.rar Подробнее о создании скриптов для своих целей - читайте вот эту тему! 2. Создаем папку с нашим модом. Для примера, это будет папка '@My_Server_Mod'. В созданной нами папке создаем папку 'Addons', а в ней папку 'My_Server_Mod'. 3. Помещаем содержимое распакованного архива в папку 'My_Server_Mod'. Должно получиться так: 4. В папке 'My_Server_Mod' создаем файлик 'config.cpp' и заполняем его следующими данными (советую использовать Notepad++ для этого): class CfgPatches // требуется обязательно { class My_Server_Mod // требуется обязательно, совпадает с именем мода { units[]={}; // may be not worked weapons[]={}; // may be not worked requiredVersion=0.1; // may be not worked requiredAddons[]={}; /* requiredAddons[]= { "DZ_Data", // Перечисляем требуемые и используемые модом аддоны (pbo-файлы игры и модов по их внутренним скриптовым именам) }; */ }; }; class CfgMods // // требуется обязательно, совпадает с именем мода { // https://community.bistudio.com/wiki/DayZ:Modding_Structure#Mod_presentation class My_Server_Mod { dir = "My_Server_Mod"; // Имя папки мода, совпадает с именем мода picture = ""; // Картинка в описании мода action = ""; // Ссылка, например вот так: action = "https://dayz.com/"; hideName = 1; // Не уверен, что этот параметр работает hidePicture = 1; // Не уверен, что этот параметр работает name = "My_Server_Mod"; // Имя мода (а также его внутреннее скриптовое имя) logoSmall = "Mods/TestMod/modlogosmall.tga"; // значок рядом с именем мода, если описание не развернуто logo = "Mods/TestMod/modlogo.tga"; // логотип под меню игры logoOver = "Mods/TestMod/modlogohover.tga"; // при наведении курсора мыши на логотип tooltip = "tooltip"; // подсказка при наведении курсора мыши overview = "My Server Mod"; // Описание credits = "123new"; // credits author = "123new"; // author authorID = "0"; // author steam ID version = "1.0"; // version extra = 0; // Не уверен, что этот параметр работает type = "mod"; // требуется обязательно, остается неизменным // inputs = "mods\testmod\inputs\my_new_inputs.xml"; // необязательно, при использовании пользовательских inputs dependencies[]={"Core","GameLib","Game","World","Mission"}; // необязательно, если необходимо установить зависимость класса class defs { class engineScriptModule { value=""; // если значение пустое, используется функция ввода по умолчанию files[]={"My_Server_Mod/scripts/1_Core"}; // вы можете добавить любое количество файлов или каталогов, и они будут скомпилированы вместе с оригинальными скриптами игрового модуля }; class gameLibScriptModule { value=""; files[]={"My_Server_Mod/scripts/2_GameLib"}; }; class gameScriptModule { //value="CreateGameMod"; // когда значение заполнено, имя функции ввода модуля скрипта по умолчанию перезаписывается им value = ""; files[]={"My_Server_Mod/scripts/3_Game"}; }; class worldScriptModule { value=""; files[]={"My_Server_Mod/scripts/4_World"}; }; class missionScriptModule { value=""; files[]={"My_Server_Mod/scripts/5_Mission"}; }; }; // Если какой-то из разделов скриптинга вам не нужен и вы не сибираетесь его паковать, сотрите необходимый блок с ним выше и в массиве dependencies }; }; Пояснения в файле оставил. Файл готовый: config.cpp Как видите, в 'deffs' названия классов и путей соответствуют родным из 'scripts.pbo', но с допиской имени мода. Имя мода в данном случае и есть идентификатор для обращения к своему моду извне. А в 'dependencies' перечисляются используемые классы оригинальных скриптов без дописки номера секции. Количество используемых 'dependencies' и блоков 'deffs' должно быть идентично. Пояснения есть также и в официальной документации от разработчика: https://community.bistudio.com/wiki/DayZ:Modding_Structure#Mod_presentation 5. Запаковываем нашу папку 'My_Server_Mod' в pbo-файл 'My_Server_Mod.pbo' через 'PBO manager', как на скриншоте ниже: Можно использовать и другие способы запаковки, если знаете их или привычны вам. 6. Добавляем в параметры запуска сервера параметр: "-servermod=@My_Server_Mod;" -FilePatching 7. Радуемся, наш серверный мод готов. Пример готового серверного мода: @My_Server_Mod.rar P.S. Создавать bikey файл для мода и bisign подписи для него не требуется, иначе это может привести к неработоспособности серверной модификации (возможно, недоработка сервера игры разработчиком) Отмечу сразу, что данный способ подходит для модификации и переписывания оригинальных классов скриптов сервера от разработчиков и модификации чужих модов с помощью моддинга, применяется исключительно на стороне сервера игры и клиент игры не затрагивает. Распространять такой мод игрокам НЕ НУЖНО! Изменение оригинальных скриптов, для которых не предусмотрена операция 'modded class' в движке игры, а также классов и функций, которые защищены языком и движком игры от такого рода действий через серверные моды не получится. Если вы столкнулись с этим, вам проще распаковать scripts.pbo и поместить папку scripts в корень сервера игры, добавить в параметры запуска сервера параметр -FilePatching и изменять напрямую в папке необходимые вам файлы.Запаковывать назад в pbo папку и размещать в dta в таком случае не нужно! P.P.S. Процедура создания своего собственного клиент-серверного мода на основе скриптов работает таким же образом. В случае создания такого мода, файл 'config.cpp' может быть для стандартного мода более разнообразным, а также после требуется обязательная подпись такого мода в bisign и создание bikey файлов. Более подробно это освещать требуется отдельно!

Всем известный инструмент для дистанционного управления и мониторинга сервера для DayZ Standalone Требует наличия .NET Framework на компьютере. Особенности: Подключение к серверу через RCon Отображение логов, чата, входа и выхода игроков с сервера Показывает список игроков Показывает список банов Показывает из какой страны игрок Автоматическое обновление информации о сервере Возможность сообщать о читерах в DaRT Ban Создание локальной базы данных игроков Возможность кикать, банить, банить по IP, банить когда игрок оффлайн Возможность писать в чат Возможность использовать консоль (если всё ещё нужно вводить какие-то команды вручную) Общение в игроком Копирование информации об игроке Поиск по игрокам Возможность перезагрузить скрипты на стороне сервера Интеграция с GameTracker DaRT.zip

Друзья, некоторое время ранее я в теме вот этой описывал создание как своего серверного мода, так и самой базовой общей структуры любого клиент-серверного мода с нуля. Но я не затрагивал момент о написании собственных скриптов для такого мода. Собственно, этот момент в данной теме и рассмотрим. Данная тема размещена в разделе не гайдов, а описания по игре, так как она носит более информативный характер, нежели гайд. Всем новичкам. пытающимся создать свой сервер советую прочесть. эксперты могут смело проходить мимо. едва-ли что-то новое узнаете. Предупреждаю, статья длинная, 'много текста'. Заранее оговорюсь, что в теме буду рассматривать пример для серверного мода, но этот же принцип работает и в клиент-серверных модификациях. Разница в клиент-серверных модификациях исключительно во взаимодействии между клиентом и сервером по протоколу RPC. Предположим, что у нас имеется свой чистый сервер игры, и мы хотим добавить какое-то свое действие, например, после присоединения игрока на сервер игры. Например, некая своя запись в лог-файл сервера. Темы к ознакомлению, связанные с данным материалом: Небольшое отступление с пояснениями: Как мы знаем, базовые скрипты игры находятся у нас в 'scripts.pbo' в папке 'dta'. Эти скрипты, на минуточку, на стороне клиента игры и сервера игры идентичные, т.е. вне зависимости от того, что у нас запускается, они одинаковы и там, и там, но с одной лишь разницей, с определенного момента начинается разделение в выполнении кодов. Т.е. для сервера выполняется своя часть кода, для клиента своя. Например, для сервера выполнится код из файла missionServer.c а для клиента игры из missionGameplay.c Это я к чему - то что вы правите в скрипте для серверного мода не всегда может работать, так как эта часть кода может быть предусмотрена для клиентского мода, или наоборот. Аналогично и касается отдельных функций в коде сервера. Например, комманда GetGame().Chat("MyMessage", "colorAction"); выполняется только на клиентской стороне, а GetGame().Chat("MyMessage"); только на серверной (за исключением случаев, когда авторы игры могут ломать эти самые комманды с патчами обновлений). Но бывают и комманды, выполняющиеся и на сервере и на клиенте игры. Например, комманда Print("MyLogMessage"); выводящая в 'script.log' нужный нам текст. Вдаваться в особенности взаимодействия между сервером и клиентом игры не буду, скажу лишь то, что работает оно через id (идентификаторы вызова) и процедуру RPC (см. события OnRPC) Для ищущих и любопытных сразу отмечу, что можно делать одну общую функцию, разделяющую в зависимости от клиента и сервера код на нужное выполнение коммандами: GetGame().IsMultiplayer() - будет true(истина) если игра запущена для игры по сети, или false(ложь) во всех иных случаях GetGame().IsClient() - будет true(истина) если игра запущена клиентская часть игры (в том числе и если offline версия тоже), или false(ложь) во всех иных случаях GetGame().IsServer() - будет true(истина) если игра запущена серверная часть игры, или false(ложь) во всех иных случаях Не буду вдаваться и в подробности, но думаю эта информация вам пригодится, если вы всерьез решились заняться данной игрой. Добавлю только то, что игра может запускаться в 3 режимах: 1) Сервер 2) Клиент Мультиплеера 3) Клиент Offline версия, и во всех 3 случаях будут работа игры будет отличаться (к примеру, в Offline не будет PlayerIdentify, т.е. идентификатора игрока). Так вот, вернемся к нашему моду. Игрок с английского у нас Player. Логично предположить, что и название нужных нам событий и функций будут также содержать такой текст. Сразу отмечу, что у данной игры, как и у любой c++ подобной программы. есть подразделение по классам и подклассам. и практически все скрипты и функции игры разделены именно на них. Т.е. Если мы хотим искать Player - ищем его поиском по нахождению в папке (В Notepad++ есть крайне полезная опция, зажимаем CTRL+F и в 3 вкладке будет такой поиск). Среди результатов поиска будет много файлов и текстов. Нас интересует файл со строкой, начинающейся на class. В нашем же случае это будет 'class PlayerBase', который вы и найдете. Это базовый класс, содержащий в себе основные функции и события, связанные с персонажем, например DropItem - скидывает вещь, RemoveAllItems удаляет все вещи с игрока (см перевод текста в переводчике с англ.), а события EEKilled и OnConnect выполняются на сервере игры соответственно при смерти (и убийстве) игрока, и при присоединении к серверу. Отступление: Каждая функция имеет свой синтаксис. void - функция без возврата значения, например void OnConnect(), а бывают функции с возвратом значений, например bool IsBleeding(), возвращающая true(истина) если игрок страдает от кровотека, и false если нет. Также у каждой функции могут быть свои входящие и используемые переменные, например у void OnConnect() их нет, а у void EEKilled( Object killer ) есть. Вернемся к нашим 'интересностям' Как вы поняли уже, нас интересует OnConnect(). Открываем найденный файл PlayerBase.c. Ищем функцию OnConnect() поиском по файлу На патче 1.06 она выглядит вот так: void OnConnect() { Debug.Log("Player connected:"+this.ToString(),"Connect"); // analytics GetGame().GetAnalyticsServer().OnPlayerConnect( this ); m_PlayerOldPos = GetPosition(); if( m_AnalyticsTimer ) m_AnalyticsTimer.Run( 60, this, "UpdatePlayerMeasures", null, true ); //construction action data ResetConstructionActionData(); } Теперь, как вы сами понимаете, нам надо внести нужные нам изменения. Но как же это делать правильно, чтобы не сломать ничего в игре и модах? Объясняю ниже: Так что же нам делать то? Ведь мы не можем перепаковывать 'scripts.pbo' сервера, иначе включенный параметр verifysignatures перестанет пускать на сервер игроков. Отвечаю вам. Создайте свой текстовый файл, заполните его следующего вида данными: modded class PlayerBase extends ManBase { override void OnConnect() { super.OnConnect(); Pring("[MyTestLog] Player connected:"+this.ToString()); } } затем сохраните его в формате .с вместо txt. Как видите, вверху в файле modded class. Modded означает, что мы будем модифицировать базовый класс игры, или проще говоря писать мод на данный класс. Перед функцией OnConnect появилась override, что в переводе с англ. означает переопределение. Т.е. мы в класс PlayerBase будем переопределять функцию OnConnect. Отступление про override: Как некоторые любопытные заметили, в некоторых функциях уже имеются override. Не буду вдаваться в подробности данной структуры, скажу лишь то что в игре если главные базовые классы, есть мелкие наследуемые классы (для понимания можно подкатегориями их назвать). Так вот. один и тот же объект в игре может быть отображен в нескольких переменных под разными классами, но игровым объектом он останется одним и тем же. Делается это для того, чтобы получить доступ к тем или иным функциям. Для примера, в классе EntityAI (общий базовый класс всех объектов в игре) нет функции установки количества вещей SetQuantity (как например количество вещей), а у класса ItemBase такая функция есть. Вот для того чтобы выполнить нужное нам действие используют конверсию из одного класса в другой. хотя сам игровой объект от этого не изменяется никак. Пример такой конверсии в своих init.c миссии сервера можете наблюдать в таком вот виде: itemEnt = itemTop.GetInventory().CreateInInventory("Rag"); if ( Class.CastTo(itemBs, itemEnt ) ) itemBs.SetQuantity(4); Где сначала создается тряпка и записывается в класс EntityAI, а затем для совершения действий выполняется конверсия класса предмета в подкласс ItemBase с другими функциями, почле чего уже вызывается функция и используется параметр 4, означающий задать предмету количество 4 (Set Quantity в переводе установить количество). Также, есть у любого класса в игре, как и в c++, конструкторы и деструкторы класса. Указывать их не обязательно, но они могут иметься в классах. Пример своего класса: class My_MissionServerClassMod { void My_MissionServerClassMod() { Print("Build My_MissionServerClassMod TECT"); } void ~My_MissionServerClassMod() { Write_Log("DeBuild My_MissionServerClassMod"); } } Здесь: void My_MissionServerClassMod() - конструктор класса, выполняется в момент, когда создается объект или переменная этого класса. Т.е. в игре каждый персонаж имеет свой объект в игровом мире. Проще говоря, каждый игровой персонаж (в т.ч. и мертвый это объект класса PlayerBase). переменной такие вещи можно задавать вот так: ref My_MissionServerClassMod MyPeremennaya = new My_MissionServerClassMod; void ~My_MissionServerClassMod() - деструктор класса, выполняется в момент, когда объект или переменная удаляются с памяти, например скриптово удаление объекта с карты GetGame().ObjectDelete(MyPeremennaya); или при закрытии сервера если это переменная. Через override деструкторы и конструкторы переписывать нельзя, их в своем мод-скрипте просто объявляете, например в таком виде: modded class My_MissionServerClassMod { void My_MissionServerClassMod() { Print("Build My_MissionServerClassMod TECT"); } void ~My_MissionServerClassMod() { Write_Log("DeBuild My_MissionServerClassMod"); } } В этом случае они сами допишутся к оригинальным вызовам родного класса игры, если такие вообще были объявлены. Вернемся к объяснению в нашем классе PlayerBase: Теперь посмотрите функцию OnConnect . Как видите, куча кода в ней отсутствует, но появились 2 новые строки. Комманда super.OnConnect(); позволит нам вызвать оригинальную функцию базового класса игры с сохранением как всех ее оригинальных действий, так и зависимостей из других связанных классов в игре (напомню, в игре один и тот же объект может быть в разных классах и разных переменных). Вы сразу спросите: 'А зачем так, можно же взять оригинальный код и переписать его как нам надо' или 'А можно ли взять и переправить базовый оригинальный код?' - отвечаю - делать так тоже можно, но крайне не желательно. У вас, как мы можем догадываться, в игре могут быть разные модификации, и данный класс может с данной функцией встретиться в другом моде. Если вы вместо такого вызова вставите весь оригинальный код функции игры, вы тем самым можете сломать запуск одного из модов, которые у вас стоят. Вторая же строка в данном файле - Print("[MyTestLog] Player connected:"+this.ToString()); - т.е. запись в script.log метки с текстом [MyTestLog] Player connected:{данные о персонаже} (где + this подставит вместо текста текущие данные персонажа из данного класса, а функция-модификатор ToString() преобразует эти данные в формат текстовой строки для вывода(иначе сервер выдаст вам ошибку, так как this в данном случае - это объект текущего класса, т.е. Playerbase)). Сразу же упомяну для всех страждущих, комманда +this.ToString() не выведет данных о нашем персонаже в логе, даже не выведет никнейм или его данные. Для вывода таких сведений надо писать дополнительный код такого вида: modded class PlayerBase extends ManBase { override void OnConnect() { super.OnConnect(); PlayerIdentity identity_player = this.GetIdentity(); string nickname_player = identity_player.GetName(); string steam64id_player = identity_player.GetPlainId(); string bis_id_player = identity_player.GetId()(); Pring("[MyTestLog] Player with name " + nickname_player + "(steam64id=" + steam64id_player + " bisid=" + bis_id_player + ")connected!"); } } Собственно, этот код в готовом и сформированном вами виде вы и кладете в свой серверный мод, он у вас уже в готовом виде. Отступление на тему: В коде своего скрипта можно использовать все оригинальные функции, имеющиеся в базовом классе. который вы меняете. Также можно использовать и любые другие функции из других классов, предварительно конвертируя и используя переменные этих классов в игре. Также можно беспрепятственно использовать все переменные из модифицируемой функции и класса, ссылаясь на них, но не забывайте, что эти же переменные могут меняться и использоваться с других функциях. Куда размещать файл в своем моде, спросите вы? Отвечаю - поглядите в каком расположении находится файлик с оригинальным классом PlayerBase (4_World\Entities\ManBase\PlayerBase.c) и разместите в своем моде его по такому же пути, название файла не сильно важно, но желательно сохранять оригинальные имена для упрощения задач самим же себе. (на самом деле сервер читает скрипты в алфавитном порядке из main-разделов игры типа 5_Mission или 4_World) Любителей скриптить и писать свои моды с большим опытом работы с игрой может заинтересовать вопрос 'можно ли в моде добавлять свои переменные и функции, и вызывать их из базовых оригинальных (нативных) классов игры?' - отвечу, да, можно. Вы просто добавляете эти переменные и функции как обычные классы, например, так: modded class PlayerBase extends ManBase { string myPeremennaya = ""; override void OnConnect() { super.OnConnect(); MyFunctia(); } void MyFunctia() { Pring("[MyTestLog] Player connected:" + myPeremennaya); } } Обращу внимание, что к добавленным таким образом функциям и переменным можно обращаться лишь из своего мода, либо из других модов но только после указания зависимостей ваших других модов с текущим в cpp файле мода. Доп. информация: Отмечу сразу, что указанный в теме способ подходит для дописывания и модификации оригинальных классов скриптов сервера от разработчиков и модификации чужих модов с помощью моддинга. Изменять сам родной код функции без дописывание не рекоммендуется, но если это для вас требуется - используйте следующее: Изменение оригинальных скриптов, для которых не предусмотрена операция 'modded class' в движке игры, а также классов и функций, которые защищены языком и движком игры от такого рода действий через серверные моды не получится. Если вы столкнулись с этим, вам проще распаковать scripts.pbo и поместить папку scripts в корень сервера игры, добавить в параметры запуска сервера параметр -FilePatching и изменять напрямую в папке необходимые вам файлы. Также, подобные описанные выше оранжевым цветом действия будут работать, если вы будете использовать override без использования строки-комманды super в своей функции. Важно: не выполняйте указанную выше доп. информацию на стороне клиента игры, иначе это может стать причиной неработоспособности вашего клиента игры и входа на сервера, поскольку сервера игры поумолчанию защищены от такого рода действий и будут исключать вас с сервера на попытках входа на него! И так, если вы смогли осилить данную тему с кучей текста, вдумчиво и с пониманием всего описанного, вы сможете создать любой свой мод без особых проблем. Если же данная тема при изучении вызывает особые трудности, советую вам заказать готовое решение у кого-либо в специальной ветке форума. P.S. Прошу извинить меня за излишнюю монотонность чтения и оформления темы, а также неточности, я далеко не эксперт ?

Ванхан@ смотри тот файл где меняется количество игроков на сервере, и там есть путкт , прописываи правильно то есть год.месяц.и день затем время ,в конце пишется пример в этом пункте 34 строчька вроди. Вот тебе ссылка на разрабов https://community.bistudio.com/wiki/DayZ:Server_Configuration