John_Nash

Внезапно, оно пока не взлетает. Похоже, проблема совместимости: XFW стало независимым уже после перехода на версию общего теста 0.9.17.1, а тестировал я на текущем клиенте, который 0.9.17.0.3. Городить костыли для актуальной ныне версии клиента особого смысла нет. Особенно для hello_world проекта, который должен быть рабочей заготовкой. Попробую с клиентом общего теста. Тяжёлое наследие :)

ОК ясно.

Спасибо. ОК. Спасибо. Пулл реквест для xfw.hello_world делать?

Спасибо. Надо изучать. Спасибо. Ну, хоть что-то.

Посмотрел -- вообще всё идеально. Нативные либы XFW стали субрепо XFW. Фикс для WinXP стал частью XFW. Нативная часть XVM пакетов откочевала в XVM. В результате XFW вообще не знает о существовании XVM, как и быть должно. Более того, нативные либы ничего не знают о вотфиксе и об остальном XFW. Но компилятся вместе, что важно. Потенциальный источник багов -- что нативная часть XVM-a компилится отдельно от нативной части XFW, так что, теоретически, если конфиги билда будут разными, возможны накладки. Но это я перестраховываюсь. Ну и сразу чешутся руки применить наступившее счастье на практике. Например, взять xfw.hello_world и сделать его самодостаточным. То есть, добавить в него XFW как субрепо и написать элементарный скриптик, который будет давать на выходе самодостаточный мод. Фактически, это дистрибутив XFW плюс ровно один файл мода xfw.hello_world. Такая самодостаточная заготовка, не нужно будет бегать с файлами XFW вручную. Мечта начинающего мододела. Кроме того, xfw.hello_world станет более аккуратным -- т.к. либы swc, на которые он опираются, будут не падать с неба, а браться из результатов билда XFW. Красиво же. Если дадите добро -- сделаю пулл реквест для xfw.hello_world. Оффтопик. В билд скрипте верхнего уровня есть функция build_native(). Казалось бы, она должна запускать скрипт билда уровнем ниже. Но она только копирует. Это нормально? Оффтопик. В верхней папке XFW появились два новых скрипта. Что делает xfw / _build_package.sh понятно -- раскладывает файлы согласно мануалу. Скрипт xfw / _build_wotmod.sh тоже как-то раскладывает скомпилированное, но иначе. А зачем? Иной способ внедрения мода в клиент?

Спасибо. Выглядит круто. Сорри, не успел склонить и потрогать руками новую структуру каталогов. Надеюсь, нынче вечером, и напишу по результатам.

Сорри, совсем я запутался. wot.libpython -- это то же самое, что и субрепо xvm-native в Меркуриале, которое скачивается при клонировании репо XVM ?

Спасибо. Если разработчики не возражают, я бы осторожно попробовал немножко навести порядок. Но строго после одобрения старших товарищей, потому как дело важное и деликатное. Насколько понял, в xvm-native компилятся библиотеки, часть и которых нужна для XFW, а часть -- для отдельных модов в составе XVM. Как раз фикс для XP логично отнести к XFW, так как он делается раз и навсегда для всего колхоза. Вообще в XFW из xvm-native копируются всего 3 файла: python27.dll, lib\_ctypes.pyd и упомянутый фикс XVMNativeWOTFix.pyd. Было бы логично вынести их создание в отдельный проект XFW-native. Тут могут быть подводные камни, потому что нативные части остальных модов должны компилироваться единообразно с нативными частями XFW. Наверное. Упс, пока строчил простыню :)

При создании AS3 части мода начинающему мододелу (относительно) понятно, как подключиться подключиться к картошкиной экосистеме. Засовываем тестовый мод xfw.hello_world в FlashDevelop и видим ссылки на внешние библиотеки в *.swc файлах. Спасибо создателям XVM, они собрали картошкины методы в этот полуфабрикат, который в большой степени закрывает нужды мододелов. Потому что из *.swc файлов торчат сигнатуры методов и свойств объектов, это очень много инфы. Как работает каждый метод нужно разбираться отдельно, но вопрос с зависимостями в целом закрыт. Ура. Однако при попытке создать чисто питоновский hello world оно как-то не идёт. Непонятно, что импортировать в IDE. И где смотреть хотя бы сигнатуры методов. С импортом объектов из XFW относительно понятно: скопировать то, что выдаёт компиляция XFW в xfw\~output\python\mods\xfw\python. Однако даже относительно небольшие моды в своей питоновской части импортируют и другие зависимости. Например, в моде xvm_ping в заглавном файле __init__.py импорт такой: import traceback import BigWorld import game from ConnectionManager import connectionManager from gui.shared import g_eventBus from predefined_hosts import g_preDefinedHosts from gui.Scaleform.daapi.view.meta.LobbyHeaderMeta import LobbyHeaderMeta from xfw import * traceback понятен, это встроенный питоновский модуль. xfw тоже понятен. А где брать BigWorld ? ConnectionManager? gui? Хоть какую-нибудь болванку, stub с названиями доступных объектов и методов. Видимо, это картошкины родные модули, но как с ними работать? Я чего-то очень простого не понимаю. Может, гайд какой, где расписано, как и что. Или декомпилить что-то общедуступное нужно? Как разберусь, обязуюсь написать тестовый мод по образцу xfw.hello_world :)

Пара внешних модулей есть в каждом проекте - это wotres и wotswf, и они импортированы как зависимости. Это исходники клиента python и as3 из lobby/battle. Каждый под управлением git, любое обновление клиента отражается коммитами с номером версии, иначе сложно отслеживать ошибки, к сожалению, WG часто меняет базовый код. wotres содержит scripts из res и res_bw (последний содержит common/Lib, где можно посмотреть доступные пакеты python), я получаю исходники через uncompyle2 wotswf содержит as3 из battle.swf, lobby.swf, common_i18n.swf, а так же библиотеки org.idmedia.as3commons, com.adobe.serialization.json и fl.*, которые можно скачать отдельно. Для декомпиляции я использую jpexs-decompiler, далее пробую собрать swc-библиотеки из lobby и battle, исправляя ошибки декомпиляции. Этот процесс долгий, но требуется один раз - в итоге получаются lobby.swc и battle.swc, готовые для подключения как внешние библиотеки. Таким образом, в правильно настроенной IDE появляется code hinting, автоимпорт и обнаружение ошибок, а так же можно легко гулять по коду клиента и исследовать его. ******* BigWorld - это built-in модуль движка (как и GUI, Math, ResMgr, _Scaleform и может что-то еще), по сути это API для связи Python <---> Движок В контексе флеша - BigWorld'а нет, флэш работает исключительно внутри Scaleform, который раскрыт в питоне модулем _Scaleform (смотрим scripts/client/gui/Scaleform/Flash.py) Если непонятно, то Scaleform это аналог Adobe Flash Player, имеет свой движок и набор базовый AS3-классов для построения интерфейса (как у Flash есть Flex). Кроме того, Wargaming создал свой набор классов для построения интерфейса игры - окна, кнопки и т.д. (это как Spark у Flex). Вот эти два набора нам и нужны для успешного собирания своих флешек, неймспейсы scaleform.click, scaleform.net (это классы Scaleform) и net.wg.* (это классы Wargaming). lobby.swf содержит наиболее полный набор классов для лобби, поэтому берем его, и battle.swf для боя. [Про питоновские скрипты] В 9.10 добавили модлоадер, Чтобы моды запустились, достаточно поместить мод в папку scripts/client/gui/mods и название файла должно начинаться с mod_. Если поставить в constants флаг IS_DEVELOPMENT на True, то будут грузится некомпилированные моды (*.py) с той-же маской имени. Появилось некоторые методы, которые клиент вызывает у мода, например: init, fini, onAccountShowGUI... И в таком духе, найти их можно поиском в исходниках слова guiModsSendEvent или sendEvent. Чтобы они вызывались достаточно создать метод с соответствующим названием в моде. https://koreanrandom.com/forum/topic/25955-http-запрос-json/#entry285225

Всё, что оказалось полезным на пути новичка. С краткими аннотациями. Буду расширять по мере знакомства с материалом. Буду благодарен, если подбросите пропущенное или просто полезное. А. Официальные доки Документация XVM Framework 3.1.0 Абсолютно must read, но, к сожалению, крайне кратко и, возможно, давно не обновлялось. Для сборки под Windows необходим пакет MSYS2, который не работает под Win XP. xfw.hello_world Пример мода на основе XFW. Полностью на ActionScript. B. Питоновская сторона силы. Доки к BigWorld -- часть питоновских библиотек, за которые моды цепляются в клиенте игры (via ktulho). Это документация от "чистого" BigWorld 2.1.0. Там нет методов, которые добавлены разработчиками танков. Еще часть может отсутствовать.(thx 2 Monstrofil) Декомпилированные питоновские исходники из клиента игры (via ktulho). Там же инструмент (PjOrion от StranikS_Scan) и инструкции по декомпиляции. Как я забыл скомпилировать питоновские файлы. Заодно там ссылка на проект hello world для ангара. Чтобы моды запустились, достаточно поместить .pyc файл в папку scripts/client/gui/mods и название файла должно начинаться с mod_ C. Разное Создание Flash объектов и управление ими. Основы DAAPI. Про интероп между Питоном и AS. Требует минимального знакомства с обеими языками. Немного про среду для разработки модов Обсуждение IntelliJ IDEA, PyCharm, более легкие альтернативы. Рекомендации по настройке режима отладки. Как создать форму(Окно) в ангаре. Питоновский файл складывать в res_mods\<wot_ver>\scripts/client/gui/mod, swf файл складывать в res_mods\<wot_ver>\gui\flash\ Интеграция своего sfw файла в battle.sfw в патче 9.15.1 D. Всякое В FlashDevelop файл с точкой входа для компилятора должен быть документом (ПКМ). При редактировании питоновских проектов удобно скачать декомпилированные питоновские исходники (Питоновская сторона силы. - 2) и сделать их external lib. Это даст подсказку и исправление опечаток в IDE. E. Чисто конкретно Название танка Как создать сообщение с кнопками в центре уведомлений?

Хороший вопрос. Подозреваю, что задаваемые мной вопросы и встанут в полный рост. А картошка подбавит и новых. Потому что ВГ предлагают страшно сырую штуку, по крайней мере, в заглавной записи про пакеты проблема зависимостей вообще не упоминается. А она ключевая.Тот же XVM -- огромная система, зависимостей масса, причём как по коду, так и по компилированию и копированию файлов. Первое, и второе, и третье -- разные вещи. Вообще, почему я все эти вопросы задаю? Захотелось написать мод 1. используя XFW 2. чтобы его можно было устанавливать без установки всего XVM, а с минимальным набором -- видимо, этот минимальный набор и есть XFW (не факт) 3. чтобы при обновлении набора из пункта 2 обновлять отдельно стоящий мод было по возможности легче и проще. Наверное, для всего этого XFW и создавался. Но пока как-то сложновато. Даже для тестового мода xfw.hello_world выделить XFW не так-то просто. Прямо сейчас я поудалял руками ненужные файлы в дистрибутиве. Но это очень-очень плохой костыль.

ОК, новые грабли :) Для начала покопался в билд-скриптах в части копирования файлов, относящихся к XFW -- что, куда и почему. "Файлы, относящиеся к XFW" -- это 1. Точки входа -- всё, что копируется в папку %WOT_CLIENT_DIR%/res_mods/%WOT_VERSION%/ 2. Всё, что копируется в папку %WOT_CLIENT_DIR%/res_mods/mods/xfw/ В релизе в этой директории 4 папки: actionscript native python resources (пустая -- сбивает с толку, можно её выкинуть?) Естественно ожидать что все эти файлы компилятся в проекте XFW, а XVM сам вытягивает из проекта XFW что надо и кладёт куда надо. В большой степени оно так и есть. В скрипте XVMBUILD_ROOT_PATH\build.sh , в функции build_xfw() Точка входа для AS3 скриптов: cp -rf src/xfw/~output/swf_wg/*.swf ~output/~ver/gui/flash/ Содержимое res_mods/mods/xfw/python/ : cp -rf src/xfw/~output/python/mods/* ~output/mods/ Точка входа для питон-скриптов: cp -rf src/xfw/~output/python/scripts/* ~output/~ver/scripts/ Содержимое res_mods/mods/xfw/actionscript/ : cp -rf src/xfw/~output/swf/*.swf ~output/mods/xfw/actionscript/ Всё это очень логично и прекрасно, однако остаётся загадкой происхождение папки res_mods/mods/xfw/native. Она собирается явно не в проекте XFW. Однако лежит в (пусть условном) дистрибе XFW. Что несколько смущает. Откуда берётся папка native найти нетрудно: в суб-репо xvm\src\xvm-native в скрипте build.sh есть замечательная функция copy() copy() { mkdir -p "$currentdir/../../~output/mods/packages/" cp -rf "$currentdir/release/packages/" "$currentdir/../../~output/mods/" mkdir -p "$currentdir/../../~output/mods/xfw/" cp -rf "$currentdir/release/xfw/" "$currentdir/../../~output/mods/" cp -rf "$currentdir/libpython/release/libpython/bin/python27.dll" "$currentdir/../../~output/mods/xfw/native/python27.dll" mkdir -p "$currentdir/../../~output/mods/xfw/native/lib" cp -rf "$currentdir/libpython/release/modules/bin/_ctypes.pyd" "$currentdir/../../~output/mods/xfw/native/lib/_ctypes.pyd" } То есть этот скрипт, на минуточку, из проекта xvm-native, лезет в корень проекта XVM и кладёт свои файлы в условный дистрибутив XFW -- третьего проекта. Тут возникают вопросы и формальные и содержательные. Формальные попроще: чтобы скрипты из суб-проекта (XVM-native) не лазили в проекты верхнего уровня (XVM). Это сделать нетрудно, перетащить копирование в скрипты XVM и всё. Но не будем спешить. Вопрос содержательный поинтереснее: как так вышло, что часть файлов XFW компилится в отдельном проекте и подкладывается в дистрибутив руками. И, главное, что с этим можно сделать. Да и нужно ли? Поймите меня правильно: всё это писалось постепенно, проделана огромная работа, на всё были резоны. Не дошли руки разобраться. Работает -- и норм. Но свежему человеку... сложновато. Пока что понятно, что у XFW есть native часть, которая вставляется в него извне. ОК. За что эта часть отвечает? Насколько от неё зависят другие части XFW? Первое впечатление -- это вообще основа основ. Как тогда без неё компилятся остальные части XFW? В общем, плиз хелп. Объясните нубу.

Эээээ, ну да. Наверное. Вопрос второстепенный не в смысле кто автор, а что я по сути ничего не менял -- так, гарнир освежил и меню поподробнее. Исходники-то модов ровно те же.

Пытаясь запустить тестовый мод https://bitbucket.org/XVM/xfw.hello_world, обнаружил, что в природе не существует отдельного дистрибутива XFW, то есть, чтобы его можно было копировать в папку клиента res_mods. Репо XFW прекрасно компилится, но файлы на выходе не расфасовываются по нужным директориям согласно структуре каталогов XVM Framework. Оно и не беда, потому как в сборке XVM, для которого XFW является суб-репо, билд-скрипты настроены копировать что надо куда надо. Однако для писания XFW - based модов, отвязанных от XVM, неудобно. Потому что как деплоить такие моды? Ставить весь XVM можно, конечно, но как-то неопрятно. То есть нужно копаться в билд-скриптах. Непроизвольно хочется навести порядок в развёртывании XFW. Хотелость бы, чтобы по результатам билда XFW -- без всякого XVM-а -- файлы бы уже раскладывались по правильным подпапкам директории res_mods. Чтобы можно было сразу копировать в клиент и сверху добавлять пакеты собственно модов. А билд-скрипты XVM тупо копировали бы что надо из уже разложенных файлов. Да там ровно одного копирования будет достаточно, директорием. С точки зрения собственно XVM это лишняя ступень копирования. Однако она прояснила бы логику деплоймента XFW и полностью отвязало бы развёртывание XVM от развёртывания XFW. Потому что сейчас они смешаны в одну кучу, что не есть гут. Оно бы облегчило создание модов на основе XFW, а также тестирование собственно XFW. Да и ясность в деплойменте XVM-а добавит. Если отцы-командиры дадут добро (и подскажут иные подводные камни), занялся бы доработкой XFW (и неизбежно XVM ) в этом направлении. Всё равно ведь буду разбираться.

@Mixaill, спасибо за инфу. Несколько оффтопик, но любопытно. Ну как же об этом узнать было. :) Да и вопрос, в общем, второстепенный.

Спасибо. Кажется, боьших глупостей не написал. Навстречу следующим граблям :)

Спасибо. Странно, что питоновский пинг требует прав админа, ну, тут уж ничего не сделать. Хотя если так легко обойти, через нативные внешние модули -- странно. А запускать игру с правами админа не вариант? Небезопасно? Сделал форк репо xfw.hello_world на битбакете, обновил файлы библиотек, добавил инфу в ридми. Заслал пулл реквест. Автор xfw.hello_world вроде бы Олег Савченко, но в списке мемберов XVM-а его не нашёл.

Да, с реплеями я протупил. Всё же раз xfw.hello_world заработал, попробую обновить для него доки. Может быть, стоит проверить, работает ли он со старыми версиями swc библиотек. Хотя ну его. Напишу в доках и норм. Кстати, пока возился, обратил внимание, что функция для пинга серверов написана на C. Почему? Разве в питоне нет подходящей библиотеки? Или оно тормозит?

Ура! в бою рисует! СПАСИБО. Щас гляну логи и начну все остальные моды выкидывать. А в логи не пишет ничего, хотя в акшионскриптах в конструкторах есть строчки типа DebugUtils.LOG_DEBUG("XFW: Hello, world!"); Кстати, что работает по заходу в бой, это очень неудобно для тестирования. Вот заодно попробую и изменить :)

Сделал. Всё равно не работает. Файлы для swc папки в проекте xfw.hello_world взял из скомпилированных сорцев последней официальной версии xvm 6.5.4, которую удалось скомпилить и которая работает с клиентом игры. Мод должен же рисовать лого прилогине -- не рисует. Ещё он должен писать всякое в лог -- в xvm.log ничего не пишет. Хотя xvm этот мод немножко видит, и пишет в этот файл вот что: 2017-02-06 18:42:42: xvm_integrity results: incorrect! extra file res_mods/mods/packages/xfw_hello_world/as_battle/xfw_hello_world.swf extra file res_mods/mods/packages/xfw_hello_world/python/__init__.py

В смысе -- в проекте? Не-а. Брать их из последнего релиза xfw ?

Спасибо. Уже попробовал скопировать по этому пути. Не взлетело. Как я понимаю, xfw.hello_world после залогинивания должен рисовать лого xvm ну и хелло пишет. Или нет? По смыслу xfw.hello_world предполагает уже развернутый xfw. А xfw отдельно от xvm-а не разворачивается. То есть файлы компилятся, но как их расфасовывать в папке res_mods не так очевидно. Оно, конечно, можно эти пуи извлечь из xvm-овских скриптов. Решил всё же срезать путь и поставить xvm, а потом подбавить файлик xfw.hello_world в нужную папку. Не взлетело. Подозреваю, что зависимости xfw.hello_world от xfw собраны в файлах репо. Но опять же, по каким директориям их раскладывать в res_mods непонятно. Попробую найти те же файлы в дистрибутиве xfw и перетащить as3-проект xfw.hello_world в сорцы xvm и там искать нужные зависимости. Потом выкинуть все остальные моды. Да, изврат, но как же иначе развернуть этот тестовый мод.

ОК, как только разберусь, то есть, когда у меня мод пойдёт на клиенте. Без этого как-то неудобно :-) Кстати, про xfw.hello_world. Он идёт без билд-скрипта. То есть там АС3 компилируется в swf и всё. А куда потом этот swf кидать? Непонятно. Почему, собственно, и взялся за xvm -- думал посмотреть, разобраться. Отчасти и разобрался, из билд-скриптов, вот куда xfw складывать.

Спасибо за инфу. К сожалению, в доках по xfw.hello_world про это ничего, вот я и. Я бы взялся, там не так и много. Раз уж я всё это ковыряю.