poget

Значит в 94-й строке файла имеется лишний отступ, т.е. один или несколько пробелов (табов) перед строчкой кода.

Dark_Knight_MiX, если есть такая возможность/желание, можешь сам попробовать запустить клиент с модом через Орион. Даже на сервер заходить не надо. Как вариант мог бы проверить на моде с протектором/без протектора.

Ну получается что разница есть. Я ставлю мод на чистый клиент. Запускаю игру через экзешник, конфиг читается, мод работает ок. Запускаю игру через Орион, конфиг не читается, мод работает некорректно. Может конечно это и косяк в коде мода, но некое взаимодействие мода с wot-transmission имеет место быть. Не то чтобы это было критично, но возможно подобный конфликт может проявиться с другими модами, что затруднит тестирование/отладку с помощью Ориона.

Приветствую, StranikS_Scan. Столкнулся с такой странностью. Использую мод Damage Announcer Если загружать клиент в стандартном режиме, мод работает как надо. Если же запускаю клиент через Орион (wot-transmission), то мод не может считать конфиг файл. Лог стандартный: Лог в Орионе: Мод работает в режиме трансмиссии, но конфиг не подгружается и используются стандартные настройки. Получается wot-transmission каким-то образом мешает моду корректно считать конфиг файл, или я что-то не так понял?

Похоже дело в том, что иконка при 100% масштабе имеет свой оригинальный размер для миникарты самого маленького размера. Если же размер карты задан больше минимального то вместе с картой увеличивается и иконка артприцела. А при ресайзинге, само собой, происходит искажение изображения. Более хорошего качества можно добиться если сделать исходную иконку в несколько раз большего размера (т.е. увеличить разрешение) и уменьшить её во столько же раз задав масштабирование в конфиге xvm. Но полностью избавиться от искажений не получится. Тут уже надо править метод вывода картинки в xvm. (отключать масштабирование вместе с картой, либо делать возможность вывода векторной иконки)

Не совсем, код для Win там имеется. Я пробовал ловить клавиши по отдельности для Win прилетает свой код, для кнопок мыши - свой, а когда используется сочетание, то последовательно прилетают коды по отдельности, а заодно, в общей куче, и нолик. Да и такое происходит только при определенных обстоятельствах, как например в моем случае - задействованые горячие клавиши + мод который я упоминал. Хотя, вполне возможно, конфликт может вылезти и с другими модами использующими отлов клавиш. Но это все так, рассуждения, слишком глубоко копать, проблема того не стоит. Проще поставить костыль как сделал я, с проверкой возврата 0, или как сказал ты, с присвоением KEY_NONE в -1.

Да, тот мод закодирован. Поэтому смог поковыряться только в этом. upd: Ну, вроде разобрался. Весь затык происходит когда в функции "handleKeyEvent" проверяется совпадение нажатых клавиш с сочетаниями в конфиге (для включения/выключения мода, либо отдельных фильтров). По невыясненной причине, указанные мной сочетания (Win+Mouse) присылают код клавиши = "0". При парсинге хоткеев из конфига все "KEY_NONE" превращаются в "0". В итоге 0=0 и все "KEY_NONE" отрабатываются как нажатые хоткеи, а т.к. в дефолт конфиге все фильтры имеют хоткей "KEY_NONE", то по волшебному сочетанию (Win+Mouse) все фильтры включаются/выключаются. Почему данное сочетание приобретает значение "0" и как это связанно с другим, указанным мной, модом, я не знаю, тут надо еще и исходник второго мода смотреть. Короче я сделал самым простым способом - дописал в первый же "IF" функции "handleKeyEvent" условие "and key > 0". Работает как надо. И все сочетания срабатывают корректно.

Уважаемый StranikS_Scan, не понял баг это или фича. Открыт .py-файл в орионе. Редактирую файл во внешнем редакторе, открываю орион - он сообщает что файл изменен и предлагает переоткрыть (спасибо кстати за эту фичу, которую я просил), после чего выполняю <compile script> и орион ПОВТОРНО выдает сообщение что файл изменен и предлагает переоткрытие. PjOrion Версия: 1.2.1 upd: Странное дело, вышеописанное происходит когда редактирую файл с помощью notepad++ или akelpad, если же редактирую файл в PyCharm то Орион, как и положено, выдает только один запрос на переоткрытие, но при этом, после нескольких редактирований/компиляций файла, Орион вообще перестает реагировать на обновление исходного файла и не предлагает переоткрытие. Лечится перезапуском Ориона. Непонятно.

Ах да, забыл про это, но просто потому, что конфиг - дефолтный из архива, а лог - чистый (не отличается от лога чистого клиента + сообщения о загрузке собственно модов). Но все же прикладываю лог. python.log Тем временем обнаружил, что указанный глюк происходит в связке с этим модом: http://forum.worldoftanks.ru/index.php?/topic/1464199-095-%D0%BC%D0%BE%D0%B4-%D0%B8%D0%BD%D0%B4%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D1%80-202-21112014-%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F-%D0%B8%D0%BD%D0%B4%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F-%D0%B0%D0%B2%D1%82%D0%BE/ Приложенный лог как раз от клиента только с двумя упомянутыми модами.

Приветствую. У меня одна проблемка с модом. У меня в системе используется программа с управлением горячими клавишами и при использовании некоторых сочетаний клавиш мод циклично включается/выключается. А именно при использовании сочетаний в которых используется клавиша Win (windows) и любая кнопка мыши (или даже прокрутка колеса). Например такие: Win+LMouse или Win+MouseWheelUp При нажатии, маркеры орудий на карте полностью исчезают, как при отключении мода (при этом информ.сообщение о вкл/выкл мода не появляется и родным сочетанием клавиш мод обратно не включается), после повторного нажатия сочетания клавиш маркеры снова появляются. Замечена проблема только при использовании именно такого сочетания (Win + Мышь), другие сочетания (только клавиатурные или без использования Win) похоже не срабатывают. При этом, какое именно действие завязано на сочетании клавиш, не имеет значения, даже если действие отсутствует. Важно только наличие хука на данное сочетание клавиш в сторонней программе. Используемая программа также не важна (проверялось на нескольких программах использующих управление горячими клавишами и поддерживающими использование сочетаний Win+Мышь).

Мне казалось логичным обсуждать ("рассуждать") карусель танков в теме с названием "Карусели танков". Какой смысл создавать еще одну такую же тему? Про обсуждение в теме ночников не знал, редко туда заглядываю, ибо обсуждение там очень объемно и не структурировано. Но ладно буду копать её. На вкус и цвет... Я лично очень часто переключаю фильтры (иногда после каждого боя). И лишние нажатия для выбора списка отнимают больше времени. Так вроде же существует конфиг для этого, нет? ну вопрос был всего один и он не отпал после беглого осмотра темы. но перечитаю внимательней. все-таки пол-сотни страниц обсуждения с указанного момента.

"раньше" - это отдельный мод. Сейчас же это реализуется непосредственно в XVM. Причем даже на текущей стадии функционал в XVM-версии гораздо богаче, лишь группировка всех фильтров в сворачиваемые списки не очень удобна при частом использовании фильтров (видимо сделано в угоду компактности). И вот как-раз идеальный был бы вариант через конфиг выбирать между группировкой фильтров в списки и отдельным отображением нужных фильтров.

я только ночниками и пользуюсь. я же говорю, что сейчас доп.фильтры реализованы под спойлером (в раскрывающемся списке), а хотелось бы возможность размещения их открытом списком. сейчас вот так: а хотелось бы вот так:

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

Спасибо. А еще вопросик. В версии 1.0.10 Alpha при попытки запустить реплей чезер wot-transmission вываливается ошибка: Error: invalid syntax (, line 23) В версии 1.0.9 все отлично.

Уф, разобрался. Куча методов получить координаты точки прицела и у каждого свои особенности/недостатки, один работает только в снайперском, другой в аркадном и т.д. Но вроде нашел универсальный способ. Получаю точку проекции через cameras.getWorldRayAndPoint(x, y). Работает в бою и в реплеях (в любом режиме камеры). Надо еще потестить значения, но похоже дает верные данные.

Уважаемый StranikS_Scan, приветствую, есть такая хотелочка: Можно ли сделать в программе перезагрузку текущего открытого ".py" файла? Например по горячей клавише/пункту меню, а в идеале - автоматическая перезагрузка файла если он изменился. А то я использую сторонний редактор, и при каждом изменении приходится заново перетаскивать файл в Орион, довольно неудобно.

Точку до маркера орудия я уже знаю как находить. А мне надо именно точку наведения центрального маркера, то есть, грубо говоря, точку в центре экрана. Куда указывает центральный маркер, до той точки мне и нужно посчитать расстояние. Я нахожу точку методом getDesiredShotPoint() экземпляра AvatarInputHandler. Он работает как надо если реплей в режиме "свободной камеры" - куда поворачиваю камеру туда он и считает расстояние, но если включаю режим "сохраненной камеры", то камера закрепляется и управляется реплеем, но я вращаю мышкой и расстояние постоянно меняется, как будто камера не закреплена (хотя визуально она на месте). В общем муторно как-то описал. Пожалуй продолжу копать РеплейКонтроллер. Просто довольно большой объем кода и куча обращений к камере. Пока не получается найти где зацепить нужные координаты. Вопрос времени, я думаю.

Да вот копал-перекапывал. Судя по всему в модули aim и replayctrl данные попадают из уровней ниже. Копая дерево классов уровнями ниже постоянно утыкаюсь в исходный модуль BigWorld, который ковырять тяжело. Вот и пытался отловить нужные координаты уровнями выше. Пока безрезультатно. Слишком много пересекающихся методов с подобными координатами. Ладно буду дальше ковырять, понятно что по другому никак. Просто думал, что может уже кто-то сталкивался с этим.

Приветствую! Помогите, пожалуйста, разобраться в вопросе. Я пытаюсь определить дальность от игрока до точки наведения центрального маркера. Точку наведения получаю через player().inputHandler.getDesiredShotPoint() В принципе это работает, но появляется проблема при просмотре реплея. Если активирована свободная камера - то все ок, но если активирована сохраненная камера, то точка не привязывается к центральному маркеру, а "гуляет" при движении мышкой. Может кто знает каким методом получить нужную точку?

Здравствуйте, возникла такая проблемка, пытаюсь отредактировать внешний вид камуфляжей (те которые покупаются на танк). Редактирую соответствующие DDS для каждого камуфляжа, но возникает проблема - у каждого камуфляжа имеется предопределенный набор цветов (каждый цвет приписан к одному из цветовых каналов), из-за чего получается поменять сам рисунок камуфляжа, но не его расцветку. Видимо для каждого камуфляжа где-то заданы параметры наложения, но вот где они находятся, так и не понял. Может кто-то в курсе куда копать?

Шкурки + насечки - все ок. На т43 одна насечка (звезда на стволе)

Ок. Спасибо за уделенное время. Прояснил, все что хотел )

1) Может я жестко туплю, но что-то мне кажется через paths.xml проблему с лампой не решить. К примеру я добавляю в файл запись <Path>./res_mods/my-xvm</Path> И закладываю в папку "my-xvm/SixthSense.png", или даже, по аналогии с дефолтом - "my-xvm/res/SixthSense.png". Но она не грузится, оно и логично, иначе бы можно было кинуть файл SixthSense.png в любую папку прописанную в paths.xml, например в "res_mods/0.8.8/". Я так понимаю лампа как и другие файлы грузятся по пути вида: "../../../xvm/", тогда единственная возможность изменить путь к файлу, это правка кода и добавление возможности изменять этот путь через конфиг. Но важность и приоритет такой задачи, конечно, крайне низки. 2) ну а по поводу файлов из папки mods, покопался по исходникам, вроде нашел почему так происходит. Видимо xvm.swf грузится строкой "../../../xvm/mods/xvm.swf" (нашел такое в application.patch). То есть путь вычисляется относительно какой-то исходной папки и, в зависимости от исходной точки, сюда попадают как "WOT/res_mods/xvm/mods/", так и "WOT/xvm/mods/". (таким же образом, видимо, грузятся и почти все остальные файлы для XVM) А вот все остальные файлы дополнительных модов, в числе которых - "xvm-hangar.swf" и "xvm-autologin.swf", грузятся похоже в (XvmStat.py) кодом: mods_dir = "res_mods/xvm/mods" if not os.path.isdir(mods_dir): return None mods = [] for m in glob.iglob(mods_dir + "/*.swf"): m = m.replace('\\', '/') if not m.lower().endswith("/xvm.swf"): mods.append(m) return json.dumps(mods) if mods else None И тут уже путь задан более жестко, относительно корневой папки WOT - "res_mods/xvm/mods". Отсюда и те нестыковки, которые меня заинтересовали. Так вот хотелось бы спросить: то, что папка XVM грузится не только по дефотному пути - "wot/res_mods/xvm/", но и из корня - "wot/xvm/", это так было задумано, или просто это погрешность, возникшая вследтвие использования путей вида - "../../../xvm/", на которую, ввиду малой значимости, было решено закрыть глаза? Просто в первом случае желательно исправлять метод вызова файлов доп. модов, а во втором случае ничего исправлять не нужно, и все ок ))

Кстати неплохая идея. Попробовал, все работает. Но этот вариант я оставлю прозапас, все-таки это костыль, а не полноценное решение. 1. Ну я везде так и делал, но как указать путь к лампочке (SixthSense.png), я не нашел 2. Если не ошибаюсь, paths.xml указывает пути, по которым игра проходится в поисках нужных файлов. Но чем мне это поможет? Ведь файлы (xvm-hangar.swf) и (xvm-autologin.swf) вызываются из кода xvm (как я понял) и ищутся они имено в папке "/res_mods/xvm/mods/" и нигде больше (с помощью файл-монитора мне удалось обнаружить запросы на эти два файла только по данному адресу), в то время как файл "xvm.swf", из той же папки, прекрасно берется и из корня игры - "world_of_tanks/xvm/mods/". Странно что все файлы для XVM прекрасно работают из одноименной папки в корне игры, кроме этих двух файлов.