Как установить мод на вот. Как установить моды для танков — пошаговая инструкция Как самому сделать установщик модов для вот

Каждый игрок в современных компьютерных играх пользуется модами. Это может быть новая сюжетная линия, дополнительная стратегия, функции игрока или запуск каких-либо возможностей в игре.

World of Tanks не стали исключениями, поэтому узнать, как установить мод в world of tanks, никогда не будет лишним. И даже если вы пока легко обходитесь без дополнительных опций, возможно, в будущем вы захотите себе упростить жизнь, запустить новые возможности своих танков или сделать баталии более реалистичными. А что для этого необходимо сделать – разберемся прямо сейчас.

Какие бывают модификации

Выбор дополнительных мод в Танках впечатляет. Все моды можно поделить на группы. Рассмотрим самые значимые из них:

Звуковые
Графические
Прицелы
Ангары
Оленемер.

Начнем с самого загадочного – последнего, под названием оленемер. Его также называют «оленеметр» и «пользомер». Этим словом обозначается новая функция в world, позволяющая узнать больше об игроках – их статистику, число побед и так далее. Считается одним из самых полезных модов, так как игрок всегда знает, с кем имеет дело.

Модификатор «ангары», как сразу понятно из названия, позволяет полностью изменить внешний вид своего ангара в стратегии.

Дополнение «прицелы» позволяет поменять базовый прицел на новый. Например, на прицел от Джова, который пользуется особой любовью игроков, так как может показывать время перезарядки, zoom, имеющуюся прочность танка, количество снарядов в барабане и многое другое.

Звуковые модификации позволяют поменять озвучку игры, сделав так, чтобы любимые «танчики» звучали по-новому. Они улучшают звуковое оформление, делая взрывы, выстрелы, команды, рев гусениц более реалистичными. Их бывает несколько видов, и каждый из них может создать свою атмосферу боя. Устанавливаются они одинаково.

Графические модификации также делятся на несколько подвидов. К ним относится функция, благодаря которой можно увидеть уязвимые места в броне танков. Функция под названием «белые трупы» помогает увидеть прячущегося после боя противника. Кроме того, можно с помощью установки сделать ЖД-платформы яркими, окрасить в белый цвет сбитые гусеницы, улучшить видимость на расстоянии и многое другое. Все это очень помогает в бою.

Чтобы воспользоваться этими опциями, необходимо сперва установить их в игровой клиент.

Как установить моды на world of tanks

Все дополнительные настройки в wot можно установить по отдельности, но гораздо проще работать сразу с целой упаковкой – так называемыми модпаками. В них собраны различные игровые модификации, призванные упростить стратегию и сделать ее более удобной и комфортной.

Наиболее популярным считается «Модпак от Джова», но есть и масса паков от других разработчиков. Каждый найдет подборку по своему вкусу. Установить их просто — как обычную программу с помощью простейшего инсталлятора.

Выбор дополнительных мод в Танках впечатляет

Пошаговая стратегия, как устанавливать моды на world of tanks

Итак, начинаем:

Заходим в папку с клиентом игры. Найти ее можно чаще всего по следующему адресу:
D: /World of Tanks/.
Ищем /res_mods. Данная папка создается автоматически, нужна она для того, чтобы игроки могли самостоятельно устанавливать желаемые модификации.
Создаем папку с названием используемого патча игры, то есть ее текущей версии. К примеру — /0. 9.13.

Таким образом, для инсталляции понадобится пройти следующий путь: D /World of Tanks/res_mods/0. 9. 13.

Новые моды улучшают качество игры

Как установить моды на wot: улучшаем прицел

Но не все бывает так просто, как в описанном выше случае. Некоторые улучшения, например, многие прицелы, будут требовать создания дополнительных папок. В результате перед тем, как устанавливать моды на wot будет, будет создана папка в документе /0. 9. 13, а в нем еще несколько.

Выглядеть весь путь будет так:

В файле /0. 9. 13. создаем файл gui
В gui создаем документ scaleform
Проверяем путь. Он выглядит так: D /World of Tanks/res_mods/0. 9. 13.0/gui/scaleform

По сути – ничего сложного в создании дополнительных папок в wot нет, поэтому проблем с установкой различных дополнений к стратегии обычно не бывает.

Улучшаем качество обзора

Улучшаем звучание

Инсталляция звуковых дополнительных настроек является довольно простой. Необходимо скачать их на сайте, обычно файл носит название /audio. В файле с клиентом игры будет такой же файл, и все надо скопировать в папку игры. Копируем с заменой текущих документов, чтоб мод пошел.

Перед установкой обязательно закрываем игровой клиент.

Рассказ о создании модификации XVM (eXtended Visualization Mod) для игры World of Tanks. Во второй части вас ждет описание истории развития серверной части мода.

Древнее царство

Как я уже говорил в первой части, самый первый бэкэнд мода работал на VPS, написан был на PHP и хранил базу игроков в виде файлов в файловой системе. Чтобы избежать лимита inode-ов 64K (лимит файлов в одном каталоге обычно настраивается, но на той VPS, похоже, настройка была залочена), применялась трехуровневая структура.

Первые две буквы ника игрока становились именем первой директории от корня БД. Следующие две буквы - именем вложенной в нее директории. И уже в ней-то и лежали plain-файлы с данными игроков и именами, равными никам.

Запросы выглядели так: http://domain.com/users/ .

На каждого игрока отправлялся свой запрос. То есть, из одного боя могло прийти до 30 запросов. Правда, на клиентской части применялось кеширование уже увиденных игроков, что слегка снижало нагрузку. Затем от этого кеширования отказались из-за крайне низкого процента попаданий в рандоме.

Несмотря на примитивность, у этой реализации было весомое преимущество - она работала даже на VPS и «тянула» сотню-другую запросов в секунду.

Надежда

После переезда на полноценный сервер была не менее оперативно запилена еще одна реализация, на сей раз на PHP + MySQL. Нам тогда вообще казалось, что для нашей задачи (запрос по одной записи по индексу), да еще запущенной на таком «мощном» железе (EQ4: Intel Core i7-920, 8 GB DDR3, 2x 750 GB SATA II HDD), можно использовать все антипаттерны проектирования - и оно все равно заработает. Реальность, как обычно, не подвела.

Итак, что же мы там «наколхозили»:

Шаблон запроса, естественно, оставили как есть.
Запрос проверялся регуляркой на похожесть на ник.
Искали в БД этот ник.
Если находили и он был обновлен не слишком давно, то отдавали его в ответе.
Если не находили, либо запись была слишком старая, то начиналось самое интересное.

Надо было как-то получить данные игрока. На тот момент никаких публичных API не существовало, поэтому первое, что приходило в голову - парсить страницу вида worldoftanks.ru/community/accounts/27030462-Alex . Но есть одна проблема: в URL страницы, помимо ника, есть еще и ID, который мы из запроса получить не можем. Из-за этого, следующим пунктом колхоза у нас идет страница worldoftanks.ru/community/accounts , а точнее - форма поиска на этой странице. Отправляем из нашего приложения как бы AJAX–запрос, ушедший со страницы поиска игроков. В ответе получаем:

Request_data: { echo: 0 filtered_count: 210846 items: [ abbreviation: "", account_url: "/community/accounts/27030462-Alex/", battles: 3737, clan_url: "", exp: 636853, id: 27030462, name: "Alex", wins: 1686 ], …. }
Видим, что у нас теперь есть не только id, но и готовая ссылка. Все, можно парсить.

К счастью, примерно тогда же появилось мобильное приложение World of Tanks Assistant , от Wargaming. Приложение вполне себе отображало статистику любого игрока. Добрые люди провели исследование и выяснили протокол обмена.

Данные грузились по адресу:
http://worldoftanks.ru/uc/accounts//api//?source_token=Intellect_Soft-WoT_Mobile-unofficial_stats
ApiVersion за время его использования нами и до появления официального API успел вырасти с 1.3 до 1.7. Каких-либо отличий для нас в них не было. Правда, проблема получения playerID прежде, чем делать запрос к API, никуда не делась.

И да, если кто еще не понял: запрос данных игрока происходил прямо во время обработки клиентского запроса.

Данный шедевр инженерной мысли стабильно работал под нагрузкой 200-300 запросов/секунду, что было лишь немногим больше, чем самый первый вариант, работавший на статических файлах. При повышении нагрузки мы упирались в CPU.

Эпоха возрождения

Поначалу моменты, когда сервер не справлялся, случались только по вечерам пятницы и субботы. Со временем эти «моменты» все увеличивались и увеличивались. Стало очевидно: что-то тут не так. Нагрузка у нас не рекордная, сервер не самый слабый. Проблема усугублялась тем, что опытных PHP-шников у нас не было. Как и не было опытных *nix специалистов.

Сели думать. Надумали следующее:

Самое главное - мы занялись улучшением клиентской части, и нашли способ получать не только ники игроков, но и ID.
Оптимизировать клиентские запросы, чтобы запрашивать игроков не по одному, а сразу всех из одного боя.
Попробовать модную связку NodeJS + Mongo.

Был запилен первый вариант node-сервера. В нем не использовались никакие фреймворки. Только стандартные модули, типа http и mongo. Сервер представлял собой хардкорный процедурный код.

Запросы стали выглядеть так:

Http://domain.com/users/,......

Первый же вариант показал обнадеживающие результаты - он тянул до 100-150 запросов/секунду. Новых запросов, на 30 игроков, т.е. это эквивалентно ~4000 старых запросов по одному игроку. Прирост более чем в 10 раз на смене технологии нас очень впечатлил, и, поскольку на тот момент запас прочности был очень солидным, - мы стали развивать «статистические» возможности XVM.

В очередной раз сели думать и надумали сделать что-то типа REST-сервиса со следующими методами:

Вариант разработки серверной части под такое ТЗ в процедурном стиле вызывал нехорошие мысли, поэтому решили попробовать еще одну модную штуку: express .

Надо сказать, до этого у меня не было опыта работы с каким-либо MVC-фреймворком, но, несмотря на это, разобрался очень быстро, и буквально за два вечера сделал первый работающий вариант. В общем, в адрес разработчиков express говорю самые теплые слова за возможность быстрого старта.

Получившийся сервер, во-первых, неплохо работал, а во-вторых, его код радовал глаз в отличие от старого варианта.

На этой волне воодушевления я решил «гулять так гулять!» и добавил в проект ODM mongoose . Код стал еще красивее, пока гонял тесты на локальной машине, буквально нарадоваться не мог, что все красиво лежит на своем месте и как все просто и логично работает.

Пришла пора деплоить эту красоту на сервер. Задеплоил. Проверил - работает! Отошел минут на 20. Прихожу, проверяю - не работает. Смотрю в консоли - процесс node запущен. Перезапускаю. Несколько секунд работает, потом - глухо.

Не буду долго тянуть: проблема была в CPU. Под обычной на тот момент вечерней нагрузкой вариант кода без mongoose шутя эту нагрузку переваривал, а вариант с mongoose (несмотря на всю свою красоту) - нет. Пришлось с грустью откатывать почти все изменения нескольких дней.

Тучи сгущаются

В конце 2012 года случился очередной всплеск активности пользователей XVM, и наш замечательный сервер перестал справляться с нагрузкой. Если честно, проблемы были и раньше, но не такие серьезные. Теперь же вечерами мод скорее не работал, чем работал. В качестве крайней меры мы даже прикрутили к серверу модуль toobusy , который позволял обрабатывать столько запросов, сколько тянуло железо, и пропускать остальное. Мониторинг показывал острую нехватку памяти для процесса mongo. Решили переезжать на другой сервер: EX-4S (i7-2600, 32 GB DDR3, 2x3 TB SATA III HDD).

Переехали. Полегчало. Правда, ненадолго.

Как только случились зимние каникулы, проблема опять возникла. Ценой всякого шаманства над кодом удалось довести скорость запросов со 150 до 180-200 в секунду, но этого все равно было мало. В какой-то из вечеров, когда все почти лежало, я ради проверки закомментировал блок кода, отвечавший за обновление “просроченных” игроков с WG API и… оно заработало. И неплохо: получили стабильные 240 с пиками до 260 запросов/сек. Через несколько дней родился код, в котором апдейтер игроков был выделен в отдельный независимый процесс, а непосредственно код, взаимодействующий с клиентами, только складывал ID игроков, требующих обновления, в отдельную коллекцию.

Этого апгрейда нам хватило где-то на месяц. И в очередной раз увидели все те же проблемы: вечерами начинались пропуски клиентских запросов. На сей раз уперлись в IOPS. Не очень долго думая, в марте 2013-го заказали для нашего сервера дополнительное оборудование: SSD-диск на 240Гб. Линейки серверов с предустановленными SSD-дисками тогда еще не было.

Помогло! Сервер стал тянуть до 380-400 запросов/сек. Примерно полгода все работало довольно ровно и не вызывало особых нареканий у пользователей. В августе 2013-го мы переехали на свежепоявившийся EX40-SSD, поскольку для наших целей он подходил лучше, а стоил дешевле, чем EX-4S с дополнительным SSD.

А в конце 2013….. как вы уже догадались, нас постигла та же самая проблема. Причем на сей раз очевидных и простых путей решения было не видно. Последние колдунства над кодом сделаны. Сервер весьма неплох. q4x2, который *nix специалист, в свою очередь, “подкрутил” сервер "по самое немогу".

Содержимое /etc/sysctl.conf для интересующихся

# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

# Controls the default maxmimum size of a mesage queue
kernel.msgmnb = 65536

# Controls the maximum size of a message, in bytes
kernel.msgmax = 65536

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
net.core.somaxconn = 262144
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.core.netdev_max_backlog = 10000
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_max_tw_buckets = 720000
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_probes = 7
net.ipv4.tcp_keepalive_intvl = 30
net.core.wmem_max = 33554432
net.core.rmem_max = 33554432
net.core.rmem_default = 8388608
net.core.wmem_default = 4194394
net.ipv4.tcp_rmem = 4096 8388608 16777216
net.ipv4.tcp_wmem = 4096 4194394 16777216
net.ipv4.tcp_fin_timeout = 15
fs.epoll.max_user_watches = 1000000

Fs.file-max = 5000000
net.core.netdev_max_backlog = 100000
net.core.optmem_max = 10000000
net.core.rmem_default = 10000000
net.core.rmem_max = 10000000
net.core.somaxconn = 1000000
net.core.wmem_default = 10000000
net.core.wmem_max = 10000000
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 12000
net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_mem = 30000000 30000000 30000000
net.ipv4.tcp_rmem = 30000000 30000000 30000000
net.ipv4.tcp_wmem = 30000000 30000000 30000000
net.netfilter.nf_conntrack_max=1048576

В общем, все, что можно было сделать малой кровью, сделано. Уже начали подумывать о приобретении второго-третьего сервера и настраивать балансировку.
Но как-то вечером в разговоре с q4x2 у нас вышел спор о том, что не все платформы одинаково полезны. А если проще, то он меня убеждал, что все наши беды из-за NodeJS, и что он готов сделать свой вариант сервера на Java, который “порвет” Node на британский флаг. Я в этом сильно сомневался, но согласился поучаствовать в эксперименте, и, раз уж такое дело, решил попробовать чего-нибудь нативного.

Поскольку, по своему обыкновению, захотелось чего-то нового, то выбор пал на D и фреймворк vibed . Удивительно, но даже мне, последние года три занимавшемуся почти исключительно JS, удалось относительно быстро состряпать работающий вариант. Разрабатывал я его под Windows. А вот при разворачивании под Centos 6.5 у нас возникли очень большие сложности с удовлетворением зависимостей. Линкеру приходилось вручную прописывать очевидные вещи.

Сложности до конца побороть не удалось, поэтому эксперимент с D был досрочно свернут. Сам язык нам очень понравился, но пока что у него, увы, проблемы с инструментарием.

Пока мы все-это писали, сервер вечерами не справлялся: не хватало CPU. И мы решились на еще один переезд, на сей раз на PX90-SSD (Xeon E5-1650 v2, 64 GB ECC DDR3, 2 x 240 GB SSD).

Рассвет новой эры

Не успел Node-сервер обрадоваться двум новым ядрам, как q4x2 выкатил свой Java-сервер. Код мне напомнил самый первый вариант Node-сервера: все в одном файле в процедурном стиле. Код мы постепенно привели к божескому виду, но все равно было видно (после избавления от детских болячек), насколько этот вариант быстрее Node. В цифрах загрузки CPU - примерно в четыре раза. В часы пик, при ~500 запросах/сек основным java-процессом используется одно ядро. Для Node-версии на четырехядернике такая нагрузка была недостижимой, а на шестиядернике она была очень близка к предельной.

Как раз в это время мы решили вводить активацию статистики на нашем сайте. Это означало, что полученные клиентами токены доступа будут ходить по сети при каждом запросе. Чтобы немного их обезопасить, сервер был размещен за HTTPS. И тут нас ждал очередной сюрприз.

Чуть выше я упомянул про детские болячки java-кода. А пока мы их пару недель лечили, java-код работал не намного лучше старого, и было очень похоже на то, что шестиголовый сервер не потянет проксю + https.

Чтобы не ждать чуда, был немедленно приобретен еще один сервер: EX40 (i7-4770, 32 GB DDR3, 2 x 2 TB HDD) с целью быть фронтендом и тянуть https. Немцы сервер сделали, но с одной маленькой, как потом выяснилось, проблемкой: ему присвоили IP в диапазоне 5.x.x.x. Фронтенд мы на нем сделали, и все замечательно работало, но на форуме начали копиться жалобы от людей, у которых ничего не работало.

Немного исследовав этот вопрос, мы выяснили, что проблема с 5.x.x.x - известная штука, связана она с приложением под названием Hamachi. Причем новые версии Hamachi переехали на 25.x.x.x (интересно, эти ребята принципиально не хотят использовать приватные сети для своих целей?), но нам от этого было не легче. Пришлось переезжать обратно на основной сервер, благо к тому моменту он уже мог тянуть все наше хозяйство единолично, да еще с солидным запасом.

Итого на данный момент у нас весь бэкэнд: наш код + БД работает на одном сервере. Load averages редко превышают единицу. Но сейчас мы задумали еще одну реорганизацию серверного хозяйства с переносом БД на отдельный сервер. Одна из причин: у Mongo очень тяжело с холодным стартом - после перезагрузки она не тянет и половины той нагрузки, которую тянет после прогрева (из-за этого, кстати, были проблемы 3-4 августа). Перенос на отдельный сервер позволит не трогать его. Другая причина - у нас появились некоторые идеи по развитию мода, которые потребуют значительного увеличения размера БД. Текущих 2*240Гб может не хватить. В целом, можно сказать, что проблема бэкэнда на нашей стороне решена. Осталась другая.

Борьба с Wargaming API

Второй по остроте проблемой после работоспособности самого сервера у нас всегда были обновления статистики игроков. По понятной причине, все наши пользователи так или иначе обращают внимание на игровую статистику, и большинство из них хотят видеть обновления этой статистики настолько часто, насколько это вообще возможно (в идеале - в реальном времени). А на пути к решению этой задачи у нас всегда стоял WG API. Точнее - его ограничения.

Самая главная для нас проблема - лимит на число запросов с одного IP. Во времена, когда публичного API еще не было, лимит с одного IP составлял около 10 запросов/сек. Нам этого было, мягко говоря, маловато. Поэтому выкручивались как могли: у нас было несколько прокси-серверов, через которые слались запросы к API.

С появлением API стало немного легче в плане доступного лимита. Нашему приложению присвоили премиум-статус, что в теории дает нам право делать по 50 запросов/сек. А дальше начинаются НО:

В старой версии (не публичный API, данные для мобильного приложения) все нужные нам данные по каждому игроку были собраны в одном методе. А с появлением публичного API данные были перераспределены по разным методам, и нам пришлось делать на каждого игрока по два запроса (/account/info/ , /account/tanks/).
Эти методы поддерживают запрос сразу по нескольким игрокам (до 100). То есть, в теории мы бы могли запрашивать до 5000 игроков/сек. Но в реальности запрос к /account/tanks/ на 100 игроков занимал ~45 секунд, а если их отправлять слишком часто, то они начинают массово отваливаться.
Методом проб и ошибок был найден рецепт относительно стабильной работы: запрос на 20 игроков раз в 2 секунды. Да, это нас отбросило обратно на 10 игроков/сек. В связи с недостаточностью этой величины периоды обновления были дифференцированы для пользователей нашего мода и для всех остальных.
Пользователей обновляем в 3-4 раза чаще. Например, сейчас пользователи попадают в очередь на обновление через 3, а остальные - через 11 суток после предыдущего обновления.
Через некоторое время WG выкатил новый метод - /tanks/stats/ . Метод выдавал гораздо более детальную статистику по танкам игрока по сравнению с /account/tanks/, и нам, естественно, захотелось ее получить. Но! Этот метод не поддерживает запрос по списку игроков. Только по одному. И это было еще не самое плохое: хуже, что этот метод для некоторых игроков выдавал несуществующие у него танки.
Вот пример , отправленный в техподдержку WG, в котором видно расхождение в показаниях двух методов почти в два раза. Немного поисследовав, выяснили, что показания по реально существующим у игрока танкам - правильные. Неправильны только показания по танкам, которых нет. Для нас это означает, что теперь приходится делать по три запроса на каждый аккаунт: /account/info/, /account/tanks/, /tanks/stats/. Причем /account/tanks/ нужен только для того, чтобы получить актуальный список танков, и откинуть из результатов /tanks/stats/ лишние.
Все это привело к тому, что сейчас скорость обновления снизилась до 8 аккаунтов/сек. Надеемся, что когда-нибудь мы сможем делать по сотне/сек, и сбудется мечта многих пользователей если не о реальном времени, то хотя бы о ежедневных обновлениях.
Были и еще мелкие косячки: к примеру, после разделения немецкого танка PzIV на модификации Pz_IV_AusfD, Pz_IV_AusfH и Pz_IV_AusfA естественно изменились ID этих танков. Но еще долго API выдавал для некоторых аккаунтов старый ID=17, соответствующий неразделенному PzIV. А метод /encyclopedia/tanks/ , из которого мы узнаем уровень и тип танка, этот ID уже не содержал, что иногда приводило к забавным результатам при подсчете рейтингов.

К счастью, сейчас появилась возможность отправлять багрепорты на такие чудеса. Раньше единственным ответом было: вам запрещено пользоваться чужим идентификатором приложения (?source_token=Intellect_Soft-WoT_Mobile-unofficial_stats). То есть, медленно, но верно начались изменения к лучшему. Нас стали воспринимать серьезно. Так что ждем, надеемся и верим!

На этом вторая часть повествования завершается. Впереди будет еще одна часть, которая расскажет о самом интересном - развитии клиентской части модификации.

Теги:

Wargaming
wargaming.net
XVM
оленемер
gamedev
game development
программирование
wargaming_inside

Добавить метки сайт Версия: - Обновлено: 24 января 2018

Установка модов в игры, бывает сложной задачей. Но в World of Tanks разработчики изначально добавили поддержку пользовательских модификаций, по этому в папке с игрой, есть специальная папка для модов с названием res_mods , которая и отвечает за модификации.

Теория работы модов

Давайте рассмотрим как вообще все это работать в Wot. Сначала игра загружает все ресурсы из папки res , в ней лежат файлы игры, такие как звук, текстуры, модели, скрипты и многое другое. Именно в World of Tanks все это запаковано в архивы, для того что бы игра чуть быстрее грузилась. По сути мы может взять от туда нужный нам файл (например шкурку танка) и изменить его. Затем поместим его обратно, заменив существующий файл. И все будет работать. Вот только такой метод неудобен, во первых нам бы пришлось сохранять оригинальные файлы на случай если ничего не будет работать, во вторых когда будет много модов, мы не сможем все это удалить, ведь надо запоминать что и куда закидывали.

Вот для этого и существует папка res_mods , после того как игра загрузила файлы из папки res , она загружает файлы из res_mods , и если там есть файл который уже был загружен из папки res , то игра возьмет последний вариант, то есть наш модифицированный из папки res_mods . Вот таким удобным способом все и сделано в World of Tanks.

Как устанавливать моды в World of Tanks?

На данный момент, в World of Tanks существует две папки для модификаций. Первая это mods , она появилась недавно и нужна для модов которые запакованы и имею формат .wotmods . Вторая папка была практически с самого начала, это res_mods , она нужна для не запакованных модов.

Обе эти папки, внутри себя содержат еще папки, с номером текущей версии игры, сейчас это 1.6.1.0 , а папки более старых версий, можно просто удалить что бы они не мешались.

На нашем сайте, в каждом моде, мы пишем как его устанавливать. Но часто мы выкладываем модификации уже вместе с нужными папками и по этому, все что необходимо, это открыть скачанный архив и скопировать (или распаковать или перенести мышкой содержимое, это одно и тоже) в папку где у вас установлена World of Tanks .

Примечание: Если во время установки игры вы ничего не меняли, то танки установились в C:\\Games\World_of_Tanks . Собственно это и есть папка с игрой.

Всегда читайте описание к моду, мы ВСЕГДА пишем как именно устанавливать тот или иной мод. Ниже мы приведем список возможных установок.

Варианты установки модификаций

Распаковать архив в папку World of Tanks — Тут все просто, открываем скачанный архив, выделяем мышкой все что там есть и переносим в папку с установленной игрой.
Скопировать папку mods (или res_mods) в папку World of Tanks — Все тоже самое что и в прошлом варианте, но когда написано именно так, то возможно в архиве есть еще папки, например с шрифтами или дополнительными вариантами мода, по этому если сразу все скопировать, то ничего не заработает.
Распаковать архив в папку World of Tanks\mods\1.6.1.0 (или World of Tanks\res_mods\1.6.1.0) — Практически тоже самое что и раньше, но теперь зайдя в папку с игрой, нужно дальше зайти в mods (или res_mods), а потом в 1.6.1.0 и уже туда копировать содержимое скачанного архива.
Установить шрифты — Все просто, в архиве есть папка с названием «шрифт», заходим в нее, затем на каждом файле кликаем 2 раза, а после того как шрифт открылся, жмем «установить». Все. Копировать ничего никуда не надо.
Запустить установщик (или Запустить программу) — В этом случае это обычно либо программы, либо модпаки с установщиками. Тут не надо ничего копировать, просто запускаем двойным кликом и все.

Удаление модов World of Tanks

Что бы удалить конкретный мод, нужно знать какие файлы были установлены, и просто удалить их. А что бы удалить ВСЕ моды из танков, то надо просто очистить папки mods/1.6.1.0 и res_mods/1.6.1.0 . Но ни в коем случае не удаляйте сами папки 1.6.1.0 , иначе игра просто не запустится.