|
   |
| Модератор форума: Dimitro |
| Форум TrinityCore [TrinityCore] Help Вопрос от новичка =) (Вопрос по изменению сервера)) |
| Вопрос от новичка =) |
Привет всем форумчанам!
По ходу работы назрел вопрос!) Как вообще эффективнее по трудозатратам изменить сервер на свой рисованный?) Скажу что есть сборочка, на которой хотел бы добавить немножко своего  Предполагается добавить вендоров штучек 6-7 Вроде бы определился с айди скином.... и тому подобное...Но тут я немного растерялся! На просторах инета есть масса статей как редактировать .dbc и швырять в сервер или через Navicat или SQLyog, или опять же что то там конвертировать в MPQ и последующая накатка патчей... Я так понимаю удобнее делать через накатку патча?! Клиент будет удобнее установить.... Так вот, кто сталкивался поделитесь мнением!)
Сообщение # 1 написано 05.05.2017 в 00:14
|
Судя по всему, у Вас возникла некоторая путаница в понимании алгоритма работы сервера. Возможно мне удастся прояснить некоторые моменты.
Вся специфика подобных проектов заключается в распределении вычислений между серверной и клиентской стороной (стороной игрока). Так все вычисления, связанные с игровым процессом, изменение которых может нарушить изначальные условия существования этого самого процесса, по традиции назначаются серверу. Он, например, симулирует AI НИПов, обрабатывает бой, генерацию добычи, поведение способностей и прч. Клиентам же предоставляется некоторый интерфейс для создания запросов на взаимодействие с миром, поддерживаемым сервером, и графическая оболочка, призванная отображать результат такового взаимодействия. Все системно значимые действия, которые может запросить клиент, подвергаются некоторой классификации с обеих сторон: так формируется система опкодов - детерминирующих заголовков, определяющих положение запрашиваемого клиентом действия или полученного серверного ответа в классификации возможных взаимодействий. Одних опкодов (представленных, по сути, обычными числовыми идентификаторами) безусловно недостаточно, чтобы настроить достаточно информативный канал связи между клиентом и сервером. Потому к пакетам, заголовками которых являются опкоды, добавляется т.н. полезная нагрузка (payload), предоставляющая дополнительную информацию по специфике совершаемого взаимодействия. Пара грубых примеров "на пальцах" для упрощения понимания процесса такового обмена: если клиент хочет переместиться - то куда (клиент отправляет координаты), если клиент хочет использовать способность - то какую (клиент отправляет ID), если клиенту способность использовать нельзя - то почему (сервер отправляет код причины отказа), если клиент пострадал в бою - то как (сервер отправляет данные по полученным игроком повреждениям) и т.д. Используя систему обмена такими пакетами, клиент(ы) и сервер синхронизируются, оставляя при этом все критически важные для соблюдения правил игрового процесса вычисления в безопасности (на стороне сервера), но не нагружая при этом сам сервер незначительной ерундой, вроде правил визуализации того или иного явления (именно поэтому существуют патчи, предоставляющие возможность изменить облик персонажа или предметов, визуализацию способностей и даже уровень игрового мира в тайне от серверной стороны). С технической же точки зрения, впрочем, процесс обмена пакетами ничем не примечателен и протекает так же, как и в десятках тысяч других программ: процесс клиента и сервера резервируют на своих машинах по порту, создавая сокеты, между которыми и происходит обмен пакетами; обычно по сети (за исключением той ситуации, когда клиент и сервер находятся на одной физической машине). Теперь, когда было предоставлено некоторое представление об организации клиент-серверной архитектуры, следует перейти к конкретному устройству элементов этой архитектуры. Чаще всего под именем сервер понимают всю систему серверной стороны, а не только ее исполняемые файлы (хотя правильным будет и обратный вариант). Одной из технических особенностей подобных систем является то, что они призваны работать с огромными массивами данных (зачастую еще и разного формата и семантических свойств), которые часто подвергаются изменениям, а потому "зашивать" их в эти самые исполняемые файлы было бы большой ошибкой сразу по многим причинам. Этим целям служат специальные инфраструктурные единицы, называемые Базами Данных (БД). Они могут быть самопальными (DataBaseClient.dbc - пример от Blizzard) или обслуживаться более конвенционными средствами (эмулятор, например, работает с Системой Управления Базой Данных (СУБД) под названием MySQL), при этом каждая служит своей цели. Например, данные, содержащиеся в .dbc файлах, так или иначе требуются для работы и клиенту, и серверу, а потому они дублируются на обеих сторонах, в то время как базы auth, characters и world (названия могут быть другими) используются только сервером. СУБД, с которой работает сервер, является самостоятельным программным комплексом, требующим отдельной установки, по успешному завершению которой обслуживающий процесс может быть запущен, а взаимодействие с ним - начато. В процессе разработки с этой программой зачастую взаимодействует множество других (в т.ч. упомянутые Вами Navicat и SQLyog), изменяя содержимое соответствующих БД. Исполняемые файлы сервера тоже читают и модифицируют данные этих БД в процессе своей работы (загружая конфигурацию мира при старте, отвечая на команды администратора, выполняя сохранение прогресса персонажей, статуса мира и т.д.). Файлы .dbc же серверу нужны только для чтения (по сути эти БД являются конфигурационными), информацию в них он никогда не пишет. Помимо баз данных, сервер работает и с другими типами структурных единиц: с библиотеками динамической компоновки, с конфигурационными файлами и журналами работы, с файлами т.н. серверных карт. Взаимодействие с библиотеками рассматриваться не будет, т.к. это узкоспециализированная околопрограммистская тема, которая едва ли будет полезна новичку; упомяну только, что серверу требуется криптографический сервис, предоставляемый библиотекой OpenSSL. Конфигурационные же файлы представлены в обычном открытом (текстовом) формате со стандартным расширением .conf и содержат информацию уникального типа о правилах работы соответствующего исполняемого файла. Исполняемых файлов, кстати, два: сервер авторизации (сервер - в прямом смысле слова в данном случае) authserver и сервер игрового мира worldserver. Из названия нетрудно догадаться, какой цели служит каждый (в данном случае названия тоже могут отличаться). Каждый из них может создавать журналы своей работы (или даже несколько, в зависимости от настроек), используемые для отладки или мониторирования их деятельности. Остаются файлы карт. Карты делятся на три типа: обычные (.map), векторные (.vmap), движения (.mmap). Все они используются для валидации и проверки необходимости дополнительной обработки перемещений игрока и существ: нужно ли обрабатывать игрока, как если бы он находился в жидкости, нужно ли на него набросить ауру от конкретной зоны, не изменил ли он файлы карт так, что рельеф теперь отличается от официально утвержденного, не нужно ли сбросить его с ездового животного, как лучше спровоцированным существам до него добраться и т.д. Последним обсуждаемым серверным компонентом станет само ядро. По сути это и есть сами сервера или их изначальное представление в виде файлов исходного кода, процесс превращения которых в исполняемые файлы здесь, опять же, обсуждаться не будет. Отмечу лишь, что обратное преобразование - исключительно трудозатратное предприятие сумасшедших масштабов, излишнее в подавляющем большинстве случаев. Перейдем к клиентской стороне архитектуры (12340 билд). Она традиционно представлена исполняемым файлом, включающим графический, сетевой и интерфейсный движки, а также их взаимодействия. За исключением некоторых клиентских интерфейсных модификаций (т.н. аддонов), все его данные пакуются в архивоподобные агрегаты с расширением .mpq. Традиционно они содержатся в двух директориях: основные - в Data, содержащие локализацию - в папке соответствующей локализации. Они загружаются клиентом в алфавитном порядке, начиная с общих из Data, заканчивая принадлежащим локализованной части, с перезаписью дублирующихся ресурсов (для поддержки дополнительных архивов, впрочем, требуется патченный исполняемый файл, который можно найти на просторах интернета). Так разработчики добиваются актуализации своих изменений/нововведений. Клиентские данные представлены большим множеством форматов, включая уже упомянутые .dbc, предназначение каждого из которых будет коротко описано далее. Уровни (карты) представляются тремя форматами: ADT, WDT, WDL. Любая карта подвержена иерархической гранулярности, предполагающей следующие структурные единицы: - Tile, каждый из которых представлен собственным .adt-файлом. Карта ограничена сеткой в 64х64 (4096) таких единиц (минус 127 начальных, которые выбраковываются багом движка), каждая из которых является квадратом со стороной 533.(3). - Chunk, заполняющий каждый Tile сеткой 16х16 (256) со стороной единицы 33.(3). - Minichunk, являющийся абстрактной структурной единицей. Каждый чанк можно разделить на 8x8 (64) миничанка со стороной в UNIT карты (расстояние между точками основания треугольников, формирующих плоскость террейна), приблизительно равной 4. Каждый .adt файл, помимо самой информации о террейне, предоставляемой почанково (145 вершин, 256 треугольников на каждый), содержит также великое множество другой информации: установленные объекты (WMO и M2, о которых речь пойдет позже), жидкости, данные наложения текстур, вертексный шейдинг и т.д. Все .adt файлы, принадлежащие конкретной карте, конфигурируются в общем .wdt, где, в числе прочего, указывается их относительное географическое расположение в глобальной Tile-сетке. Кроме того, для карт генерируется .wdl, содержащий малодетализированное представление рельефа, чтобы клиент мог, например, отрисовать горную гряду вдалеке. Помимо файлов уровней, за конфигурирование трехмерной графики в клиенте отвечает еще два формата: .m2/.mdx и .wmo. Первый может использоваться для большого спектра задач, т.к. поддерживает анимации, системы частиц, риббоны и прч. Модели персонажей, предметов, многих ассетов для уровней, скайбоксы, визуальные эффекты способностей и зачарования - все это представлено с использованием именно этого формата. Формат .wmo (World Map/Model Object) служит более узкоспециализированным целям: для создания объектов уровней большого размера, либо имеющих интерьеры. Например Штормград является одним большим (и весьма уродливым в плане исполнения, с сотней багов) WMO. WMO делятся на группы, каждая из которых хранит информацию о геометрии, текстурах, шейдинге, т.н. batch'ах (используемых клиентом для построения VBO и последующей оптимизации рендера) и т.д. Помимо своей геометрии, WMO может иметь т.н. Doodad-set'ы: наборы размещенных .m2, зачастую однотипных. Эта система используется для детализации интерьеров и легкого добавления вариативности. Вы наверняка видели в игре, скажем, повторяющегося внешнего вида дома с различающимися интерьерами. Все текстуры и прочая 2D-графика представляются в клиенте в BLP-формате, часто с компрессией. Формат поддерживает LOD-систему (Level Of Detail), используемую для снижения нагрузки на клиент: разрешение текстуры поэтапно снижается при удалении от источника, на который она наложена. Наконец, интерфейс представлен XML/LUA связкой, при этом с помощью первого осуществляется верстка, а встроенный интерпретатор второго позволяет функционировать клиентским сценариям. Подавляющее большинство стандартного интерфейса, а также все аддоны, написаны с использованием именно этой системы. Помимо этого, клиент поддерживает звуковые файлы в формате .wav. На этом, полагаю, можно закончить данный краткий экскурс. За более подробной информацией о работе серверной стороны можно обратиться сюда. Клиентская документация находится здесь. Руководства разной степени добротности, а также подавляющее большинство ресурсов для модостроения можно найти тут и тут. Стоит отметить, что все ресурсы зарубежные (англоязычные). Исходники официального TrinityCore содержатся в открытом репозитории на GitHub.
Сообщение # 2 написано 05.05.2017 в 16:53
|
Цитата p620 (  ) На этом, полагаю, можно закончить данный краткий экскурс.  Огромное спасибо за такой оперативный и детальный ответ, да ещё и с ссылками!!! Не перевелись на wowjp.net гуру разработки! Признаться о многом я впервые слышу, такого детального разбора я ещё не читал) Сейчас вот докачиваю программки на model-changing, которых у меня небыло. И буду вникать по полной в Ваш пост)И всё же по моддингу можно послушать в двух словах?! Наврятле я ещё встречу русскоязычного гуру . Когда то давно баловался со сборкой 3.3.5a. В Navicate добавлял топорик с моими характеристиками и чтобы его получить заливал в БД с перезагрузкой сервера. Потом прописывал его себе и profit. Так вот =) К примеру, я хотел бы Трала переместить к себе гмом и сохранить изменения! Вроде бы гм может изменять бд на сервере... ну а после перезагрузки npc появляется на прежнем месте  Получается мне нужно делать всё по феншую?! Мол поставил npc, записал координаты, выключил сервер, поменял координаты в sql файле и вот только потом profit? Или есть другой способ который бы сохранял изменения от гейм мастера?!) Направьте на истинный путь)
Сообщение # 3 написано 05.05.2017 в 18:50
|
.npc move, насколько я помню (со всеми командами можно ознакомиться в таблице `command` базы `world`). Да, многие команды администратора действительно приводят к изменениям в базе.
В первую очередь следует понять, что первоочередную роль играют те данные, которые находятся в памяти процесса. В целях экономии ресурсов обратная (пишущая) синхронизация этих данных выполняется раз в некоторое время или при завершении работы сервера. Чтение же осуществляется на загрузке сервера, либо при ручном вызове перезагрузки некоторых таблиц во время его работы. П.С: если модмейкинг для забавы осуществляется - команды подойдут идеально в качестве средства разработки. |
| |||
| |||