Торговля

Материал из MODFAQ.RU — моддинг игр серии S.T.A.L.K.E.R., The Elder Scrolls и Fallout
Перейти к: навигация, поиск

Торговля

Автор Карлан
Тип статьи справка
Актуальность ТЧ, ЧН, ЗП

Что из себя представляет торговля в игре?[1]

Это банально, самый обычный трансфер итема с использованием денег. Что такое деньги спросите вы? Простая числовая (u32) переменная, которая хранится в пакете (при сильном желании их можно выдать и монстрам). Итак, собственно у нас есть два экономических агента, каждый со своим багажом, в идеальной модели совокупная стоимость товаров равна количеству предметов в персонаже, у каждого из которых есть какая-то сумма денег исходя из базовых настроек конфига.

Это как все выглядит, а работает все тоже достаточно просто, в файлах вида trade.xml статическими данными указываются настройки для интерфейса, при инициализации начинает заполнятся визуальная часть окошка, то есть всякие иконки персонажей, листы с итемами (есть четыре основных листа) и прочие заготовки типа как для статиков о причине отказа торговать. Заполнение листа в два этапа, есть итемы которые вообще не должны попадать, есть которые попасть должны, но не должны быть доступными для торговли (красным закрашивается как правило), условия для попадания в лист достаточно просты, итем должен быть прописан в конфиге на продажу, у него должен стоять флаг can_trade и он не должен быть квестовым, если все условия выполнены – итем в листе. Далее второй акт, проверка на то, блочить ли его в интерфейсе, тут настройки такие, в конфиге оппонент должен смочь его купить (вспомните, если купить не может, то он появляется, но закрашивается красным) и еще идут проверки на переносимый вес (насколько критичен перевес для обычного сталкера честно говоря я уже не помню). Итак, если у нас итем торгуется, и везде в конфиге прописан со всеми френдли и энеми коэффициентами, то мы можем его торговать.

Вот это, скажем так, я описал подкапотную работу торговли, а самый балет начинается на поверхности, в так называемом менеджере торговли, а также замечательном методе buy_supplies, который, чтобы вы думали, совершает каждый раз полный цикл своей работы, даже когда это совершенно не нужно, т.е. представьте, что у вас тот же Бармен торгует 500 эскимо всю дорогу после определенного события (тут не рассматриваем динамичные листы для торговли), и время от времени (ага, при каждом выходе в онлайн), эти 500 эскимо благополучно перезагружаются! Это колоссальная нагрузка в любом случае, а особенно в случае, если у вас динамичная торговля, это очень сильно наказывает, поэтому нужно переделывать функцию в движке, либо писать какой-то аналог. Далее идет совершенно кривая работа самого менеджера, который каждый раз по новой создает всю торговлю на выходе персонажа в онлайн. Отсюда баг, который не в силах сохранить текущий ассортимент (точнее сохраняет, но неизвестно зачем (я предположу, что тестеры разрабов за день успевали раскупить весь ассортимент, а до перезагрузки ассортимента ждать было долго)), и в результате мы имеем читерство, когда при перезагрузке игры (а точнее при пробросе on->off->on) у торговца возобновляется ассортимент. Сюда же отнесем мгновенное обновление листа по условию, так как при срабатывании условия перехода условия обновления всегда выполняются. Веду к чему, в отличии от движка, скриптовое оформление очень дырявое. В движке явных недочета я заметил только два, это вышеуказанная работа с purchase_list, а также баг с тегом infinitive_money, который если его выставить, то все равно черта с два продашь товаров больше чем на 1000000 рублей. В движке хватает и недоделок, но в недочеты их записывать некрасиво, поэтому в файлах, где на мой взгляд я заметил недоделки оставил соответствующие комментарии. Есть функции пустышки, есть просто ненужный код, который ни к чему не приводит, я даже узрел намек на создание какого-то хранилища, возможно накопленная благосклонность, если много торгуете? Кто же теперь знает.

Пишу, пишу, и понимаю, что очень много можно рассказывать. Есть еще такая тема, что сам движок парсит из секции торговлю напрямую, как раз через CTradeParameters, но там совершенно другой подход, нежели как это сделано в оригинале. Ищите buy_price_factor_hostile по коду, увидите, как это было когда-то, тут конечно разрабы продвинулись достаточно мощно и хорошо. В соседних классах кстати и находится формирование листа по конфигу, который мы передаем из менеджера, а в него из логики, система проста как грабли.

Можно упомянуть и схемы для поддержки торговца, это mob_trade и mob_trader. Функционал тут заманчив, но тем, кто не на исходниках сразу подскажу, что на него как сядешь, так и слезешь, он вообще неприменим для масс.

Итак, действительно, получилось как-то сумбурно, возможно местами не понятно, но я старался не вдаваться в код, а объяснить сам механизм работы, а также указать на недочеты, которые долгое время считались чем-то нормальным.

Источники