Dragon-tis: Я плохо разбираюсь в модостроении, поэтому могут быть некоторые не точности в переводе с технического языка. Не судите строго. )))

Привет, я приветствую вас, чтобы еще раз поговорить в это воскресное утро.
Тема: «Mod Conversion from FS15 to FS17».
Я хотел бы отметить, что разговор снова будет достаточно технический, с большим количеством XML и некоторым Lua.
Я приведу больше подробностей и, я буду использовать конкретный пример, чтобы проиллюстрировать изменения от версии FS15 к версии FS17.
Я хотел бы также отметить, что игра все еще находится в стадии разработки, поэтому ничего из этого еще не доработано и подлежит изменению.
Тем не менее, в целом, эта презентация должна обеспечить хороший обзор о возможностях, которые там существуют.
Итак, из каких компонентов состоит мод ?
Возможо, вы все знаете это.
Во-первых, есть «modDeck» XML файл, «vehicle» xml, который содержит конкретные данные для транспортного средства или оборудования.
Затем, есть Shader файл, который не так широко используется, потому что это довольно сложная область, но тем не менее, является составной частью процесса преобразования.
И затем, конечно, существуют i3D модели, в этом случае Amazone Pantera, которые я использую в качестве примера для доступной опции к моду для FS15, а также игрового мира / карты.
Здесь также включено размытие (или рассеивание) и нормальные текстуры, знаки и другое.
И, в конце, здесь есть Lua скрипты, если это применимо.
Давайте начнем с просмотра modDesk.
Самое главное повысить deskVersion до 30.
Это позволит двигаться с модом, например, когда нужно установить определенный патч.
Начнем с того, что значение 30 для FS17.
Теперь, если транспортное средство определяет свой тип, для этого элемента оборудования, необходимы несколько изменений.
Для примера, были созданы новые фары и навесное оборудование.
Было удалено «mouseControlVehicle», потому что это было интегрировано непосредственно в «cylindered».
Итак, если мы посмотрим на Amazone Pantera, и что было здесь добавлено или отменено. К примеру: «aiTractor» стало «aiVehicle».
Полный список изменений будет доступен в SDK позднее.
Мы продолжаем в modDeck с «storeltem».
Он был перемещен в полном объеме из modDesk в «vehicle» XML.
Преимущество этогог в том, что все данные находятся непосредственно в vehicle XML. Ранее они были разделены между modDesk и vehicle XMLs.
Теперь есть четкое разделение: modDesk содержит только общую информацию и фактические детали storeltems, т.е. XML-файлы, на которые будут ссылаться, в то время как все другие данные находятся в vehicle XML.
В нашем примере, мы выбираем индивидуальный storeltem и перемещаем его в vehicle XML под названием «storeData» («магазин данных»).
Это также возможно для некоторых значений, таких как «capacity», который вы можете увидеть здесь, чтобы загрузить непосредственно из транспортного средства в FS17.
Это позволяет избавиться от избыточных данных и быть менее подверженым ошибкам.
Стоит также отметить, что тег «image» больше не содержит атрибутов «brand» и «actice».
Вместо этого, значок теперь расположен непосредственно внутри тега изображения.
Другой вопрос — функциональность «brand».
Здесь довольно жесткая модель, которой нужно следовать, чтобы избежать дублирования брендов в магазине. Например, появление двух экземпляров «Fendt», потому что один человек зарегистрировал его с заглавными буквами, а другой со строчными.
Так что мы положили этому конец, предписав, что имя тега должо быть полностью в верхнем регистре, без каких-либо дефисов и тому подобное.
Это гарантирует, что каждый бренд встретится в магазине только один раз.
В этом случае, название, которое будет отображаться в магазине, будет с идентичным именем, но также может быть и разным.
Важно, что идентификация имени бренда должна быть полностью в верхнем регистре и без каких-либо дефисов или пробелов.
Это для modDesk, то есть, deskVersion 30, миграция StoreData vehicleTypes также должны быть изменены, если это необходимо, и есть новое определение брендов, для общей согласованности и, чтобы не было ошибок.
Мы продолжаем с vehicle XML.
Например, шины также хранятся в виде файлов XML, которые уже содержат множество деталей, таких, как радиус, ширина, масса и другие физические данные.
Таким образом, вы меняете шины просто путем присвоения другого файла XML, а радиус и все остальное уже совпадает согласно сохраннению в файле.
Это очень просто.
Параметр «node» определяет, будет ли это левый или правый руль.
Это теперь установлено «isLeft» или «configIndex», как вы можете увидеть здесь.
Таким образом, у вас есть простой вариант замены колес без необходимости много раз заходить в XML.
Фары («lights») также изменены.
В FS15 вы могли установить один «lightType» («тип света»), в единственном числе, тогда как в FS17 есть потенциально несколько, хотя и не в этом случае.
«states» в основном определяют то, что произойдет, если вы переключаетесь с помощью F-клавиш.
Теперь вы получаете гораздо большее количество опций.
Например, Вы можете играть с новыми источниками света, включая возможность добавлять источники света, если это необходимо, так что это намного более динамично.
Как я уже говорил, теперь также есть источники света для заднего хода, тормоза и поворотники.
Индекс был переименован в «decoration» (декорация).
Раньше это было только коронным разрядом, а сейчас это просто декорация, потому что есть дополнительный подлинный источник света.
Это должно быть интегрировано в i3D первым, для чего не индекса в этом пункте, поэтому я ставлю «todo» на данный момент.
Это должно быть интегрировано вручную в i3D и связано должным образом.
Именно так.

Есть и другое интересное изменение.
В FS15, потребление удобрений исчислялось в литрах в секунду, как показано в верхней части.
Это был тот недостаток, при котором оборудования с большей шириной должны потреблять больше удобрений, и это нужно было рассчитать для достижения пропорционального покрытия с тем же самым количеством навоза.
Вот почему мы упростили это.
Теперь вы просто устанавливаете «workingWidth» («Рабочая ширина») и значение масштаба, приводящее к переменному потреблению в соответствии с индивидуальной шириной.
Так что в конечном итоге, все транспортные средства используют одинаковое количество для той же самой области.
Это изменение, в том, что теперь единицы заполнения могут быть определены для каждого транспортного средства.
Это особенно относится к сеялкам с функцией подкормки.
Вместо того, чтобы «fillTypes» и «capacity», теперь вы можете указать «fillUnits».
В случае, если он только один, это будет распылитель с одним уровнем заполнения.
Но, например, для сеялок вы можете задать две единицы здесь в нижней части: одну — «sprayer», а другую — «sowing machine», с их соответствующими возможностями.
Категории, позволяют использовать стандартный механизм с модом типа заполнения без скрипта, при условии, что мод типа заполнения указан в соответствующей категории.
Мы также убрали тот факт, что «mouseControls» был дан свой собственный элемент, который на самом деле не имел особого смысла, так как он содержит лишь информацию об оси и нужен для того, чтобы связать много вещей оси в «movingTool «.
Это теперь интегрировано непосредственно в «movingTool», а это означает, что ось обозначена с элементом «control».
В настоящее время там только одна ось и уже вторая (ось) для мыши, которая вызвала много проблем, если мод транспортного средства имеет ось мыши неправильное положение на стреле фронтального погрузчика.
Теперь это было упрощено.
Теперь только одна ось для мыши, клавиатуры и контроллера. Убедитесь, что для всех транспортных средств ось ведет себя правильно при перемещении мыши вверх или вниз.
Мы также переместили другие пункты в свои под-элементы, например все различные манипуляции, такие как «rotation» («поворот») и «translation» («перевод»).
Это делает его опрятнее и уменьшает длину строки, так у вас все аккуратненько друг под другом.

Ещё одно важое изменение для обеспечения дальнейшего использования функциональных возможностей.
В данном случае, это означает, что рукоятка распылителя становится регулируемой, или появляется дополнительная функция для перемещения колеса.
В прошлом видео мы уже касались темы «characterNode».
Это означает, много избыточных данных, которые первоначально относятся к i3d плееру, теперь сохранены непосредственно в «player» XML.
Это делает всё намного проще.
Все, что осталось — это набор узлов, которые связаны с рулевым колесом, например.
Это делает его гораздо короче и можно не бояться, скажем, в попытке что-то вроде этого.
Вы можете видеть, это стало довольно просто, что могли бы побудить людей использовать больше это и не бояться.
Этого достаточно для vehicle XML (транспортного средства).

Подводим итог:
Когда мы говорили о modDesk, «storeltems» должны быть интегрированы.
Этого не было на слайде, но элемент «name» больше не требуется, так как это теперь часть storeData.
Колеса определяются как (или в) XML, что приносит много преимуществ и делает его проще.
Есть новая установка фар.
fillUnits весьма интересны, особенно в сочетании с другими функциями.
MouseControls, characterNode…
Различные пути к старым звуковым файлам также должны быть адаптированы, поскольку многие моды используют ресурсы игры. Таким образом, Вы должны удостовериться, что они все еще присутствуют и, адаптировать или изменить их, при необходимости.
Это для modDesk и vehicle XML.

Давайте перейдём к i3D.
Как обычно, новая версия выходит с новым форматом.
В этом случае, все, что вам нужно сделать, это сохранить его в новом редакторе, и он будет там в новом формате.
Источники света, там, где нет такой функции в FS15, нужно будет интегрировать отдельно.
Мы предоставим шаблоны для этого в SDK, в виде заданных источников света, которые могут быть импортированы, уже с правильными параметрами, чтобы гарантировать, что работа останется на правильном уровне.
На карте, у нас есть уровни внесения удобрений. Внесение удобрений — три раза, а излишки достигаются за счет вспашки, что также должно быть интегрировано.
Кроме того, различные данные, которые раньше были в Lua переносятся в XML, что упрощает интеграцию дополнительных мест или точек доступа.
XML делает его легче, чем lua для неопытных пользователей, чтобы просто скопировать и вставить строки, в случае, если есть ошибки и Вы не знаете, где они находятся.
Кроме того, карта ещё не окончена, мы все еще работаем над игрой, поэтому руководство будет издано, мы надеемся, до выхода, или, самое позднее, вместе с SDK, что позволит мгновенно конвертировать вашу карту и использовать её в FS17.

Как я уже упоминал ранее, кроме modDesk и vehicle XMLs , есть также шейдер (затенение).
Это также требует адаптации к новой DirectX 11.
Так что, опять же, шейдер (затенение) должны быть конвертированы или скопированы из базовой игры.
Обратите внимание, что шейдер (затенение) также привязывается к файлам текстур.
Вы иногда задаетесь вопросом, почему файл отсутствует, поскольку на него не ссылаются ни в каком i3d или XML.
В этом случае это будет непосредственно связано в рамках шейдера.
Вот выдержка из шейдера.
Вы можете видеть, что в стандартной игре, путь для грязи нормальной карты хранится выше уровня «shared», в то время как в моде, следующий верхий уровень — это мод индекс.
Поэтому путь нуждается в адаптации, оставаясь в моде и подачи грязи нормальной карты непосредственно в папке «shared».
Затем, есть особый случай с coronas, где простого копирования и вставки шейдера будет не достаточно, потому что в coronas есть изменения в FS17.
Это означает, либо изменения текстуры, а также новые шейдеры для работы, или использование специального шейдера, который был оптимизирован для FS15 coronas и будет продолжаться в FS17.

Переходим к DDS файлам, так как текстуры, иконки и тому подобное, не требуют каких-либо изменений, и могут быть использованы такие, какие они есть.
Наконец, скрипты Lua, также затронутые в прошлом видео, но я сделаю это более подробно.
Функция «load» теперь требует «savegame» в качестве параметра.
Это дает вам больше возможностей, теперь вы можете использовать определенные атрибуты из «savegame» без того, чтобы специально делать это в отдельной функции.
Вместо этого, теперь вы можете получить доступ к параметрам непосредственно через «savegame.resetVehicles» или другие.
Это означает, что «xmlFile» должен быть заменен на «selfie.xmlFile» внутри функции.
Но, конечно, во многих случаях этого будет не достаточно, многое изменилось в скриптах и нет общего списка изменений, поэтому вам необходимо проконсультироваться, или в документации Christian Ammann, или запросить ее в форуме в случае, если есть дальнейшие проблемы с code-related.

Многие из вас, будут думать, «Ничего себе, это очень много работы, котрая делается вручную, я не уверен, что справлюсь.»
Именно поэтому мы создали этот сервис ‘Cloud Mod Conversion’.
Он берет на себя огромную часть задач, о которых мы только что говорили.
Это доступно для XML-файлов, т.е. modDesk, vehicle и shader, а также для Lua файлов, управление обменом параметров для функций загрузки или «xmlFile».
Это также напрямую интегрировано в GIANTS-Editor.
Я дам Вам пример для этого.
Он также генерирует отчет о состоянии для каждого преобразованного файла, сообщающая, были ли какие-либо проблемы, или все работало.

Самое замечательное, это его cloud-based, что означает, что мы можем загружать еженедельные исправления в случае возникновения каких-либо проблем, без необходимости выпускать новую версию редактора.
Это делает его более удобным, вам не придется ждать выхода нового редактора, если есть какие-либо проблемы.
Это пример того, как это выглядит.
Вы можете открыть мод в редакторе через меню файла, либо в виде архива, как показано на рисунке, или распакованый, выбрав файл deskMod.
Это затем загружается в редакторе, показав список доступных storeltems.
Вы выбираете один, который затем открывается автоматически после конвертации.
Если это мод FS15, у вас откроется диалоговое окно, с вопросом, хотите ли вы конвертировать это.
Затем, все файлы XML и Lua загружаются в Cloud (облако), преобразуются там, и снабжаются комментариями с замечаниями в случае, если требуется дальнейшее действие.
После завершения, он возвращается, и вы получите обзор всех измененных файлов, включая состояние по любым вопросам, а также подробное описание, например, если требуется ручная настройки, или если все работает.

Подводим итог и уточняем:
Служба конвертации может обработать большинство действий, о которых мы говорили.
Можно перенести storeltems, можно обновить vehicleTypes, автоматически удалить устаревшие специализации (профили) и добавить новые недостающие.
Автоматически генерирует бренды, если их нет в базовой игре.
Он преобразует capacities и fillTypes в fillUnites.
Это объединяет mouseControls (управления мышью), и может поменять путь к файлу и все остальное, что я уже упоминал ранее.
Что не может сделать, объединить i3d источники света, поскольку это требует человеческого воздействия и интеллекта.
Если бы существовала программа, которая справиться с этим, нам больше не нужны были бы программисты.
Кроме того, Lua скрипты являются сложным вопросом, потому что очень много кода изменилось, так что просто невозможно написать программу, чтобы заменить абсолютно все.
Много логики изменилось, и простой замены переменных недостаточно.
Так что, он делает столько, сколько он может, он заменяет функцию загрузки, а также файл XML внутри функции, помимо прочего, однако, нет никакой гарантии для Lua скриптов, что они будут полностью преобразованы (конвертированы).
В случае Amazone Pantera, скрипт довольно прост, так что все это работает без дальнейшего взаимодействия с пользователем.
Если какие-либо проблемы сохраняются после конвертации, дальнейшая помощь под рукой, например, SDK перечисляет изменения для всех новых vehicleTypes, а также то, что требуется для них.
В нем также перечислены typeDescs, отображаемые в магазине.
И есть также инструменты для преобразования карты и других подобных файлов.
Записи журнала также очень важны.
Каждый раз, когда параметр игры изменяется, мы включаем печать, заявляя, что параметр больше не доступен, и какой использовать вместо этого.
Но, надеюсь, этого не произойдет, так как конвертер позаботиться об этом.
LUADOC от Криса (by Chris), который был расширен, а также GDN, оба являются прекрасной возможностью, особенно для конвертации скриптов.
И, конечно же, это всегда очень помогает в рассматрении стандартных транспортных средств.
Вы получите целый спектр функциональных возможностей и несколько единиц заполнения, и вы можете проверить, как это работает в игре, а затем перенести это на собственное оборудование.
Кроме того, вы всегда можете задать вопросы на форуме.
Там много активных участников с большим количеством знаний, которые будут рады помочь Вам.
Это скриншот, показывающий LUADOC, обеспечивет полный обзор скриптов.
Вы можете увидеть, как функции изменились, какие параметры отсутствуют и что нужно изменить, чтобы заставить его работать снова.
Это значительно расширено по сравнению с тем, с чем Вы знакомы, и это идеальная возможности, чтобы заставить скрипт FS17 работать быстро и легко.
Этого достаточно с моей стороны.
Было весело.
Не стесняйтесь задавать любые вопросы, которые у вас возникли, или поделиться какой-либо просьбой о том, что вы хотели бы видеть в SDK.