Jump to content
Korean Random

Crus

User
  • Content Count

    77
  • Joined

  • Last visited

Everything posted by Crus

  1. В предложении речь идет исключительно об обмене данными между союзниками. Поясню. Алекс и Боб - союзники. Расстояние между Алексом и Бобом - 600 метров, что превышает радиус отрисовки. Из-за этого Алекс и Боб не видят HP друг друга. В паре метров от Алекса находится противник, Чак. Алекс видит его HP, но его союзник, Боб - не видит (ведь Чак тоже находится за границей отрисовки Боба). Разумеется, союзники могу общаться между собой, посредством встроенного чата - это не запрещено. А следовательно, Алекс может передать Бобу информацию о том, сколько у него в настоящий момент осталось HP, и сколько у Чака. Моё предложение - это именно автоматизация данных "переговоров" между Бобом и Алексом.
  2. Как известно, клиент не получает информации об изменении HP техники за пределами круга отрисовки. Из-за этого ограничения "Индикатор общего hp команд" (total_hp) нередко показывает значения, весьма далекие от реальных. Это расхождение, само по себе, ставит под сомнение полезность данного индикатора. Более того, к сожалению, этот индикатор вводит часть игроков в заблуждение, "подталкивая" к неверной оценки ситуации. Однако нет никаких сомнений, что "общее hp команд" - это очень полезный индикатор, если бы он отражал корректные, актуальные данные. Мне видится, что механизм XMQP просто идеально подходит для актуализации данных о HP техники за пределами отрисовки. С его помощью станет возможным получить актуальные hp техники в ушах и, разумеется, подсчитывать фактическое общее hp команд. Также отмечу очевидный, но немаловажный момент: для получения данных о HP техники на фланге/направлении, будет достаточно присутствия всего лишь одного игрока с активированным сервисом XMQP. P.S. Идея из категории "сама напрашивается", так что скорее всего уже поднималась, но мне найти не удалось.
  3. Стандартно, при наведении курсора на живую технику в "ушах", она "подсвечивается" на миникарте. Однако после уничтожения, эта функция перестает работать. Если имеется возможность простой реализации аналогичной подсветки для уничтоженной техники - было бы здорово.
  4. Полагаю, что да - звуки от чемоданов арты чрезвычайно громкие, на фоне остальных звуков эффектов. В итоге, у меня вдобавок к внутриигровому оглушению добавляется вполне реальное оглушение :| Ясно, т.е. действовать по стандартной процедуре, описанной в первом посте. UPDATE: а как провести сопоставление "название ивента" - "извлеченный тулзой файл"?
  5. Подскажите, есть ли "упрощенный" способ изменения громкости определенных стандартных звуков? Или нужно действовать по инструкции "Создание звукового банка (контейнера), *.bnk" из первого поста + извлечь стандартные звуки с помощью RavioliGameTools?
  6. В процитированной мной реплике недвусмысленно пояснялось, что данный функционал в этот мод добавляться не будет. Вопрос об отдельном моде.
  7. Почти год назад в этой теме зашла речь о моде с позициями для света: Нет, это отдельный мод. Пока что нигде его не скачаете. Он войдет в модпак Цезаря. Хотел поинтересоваться, проект заморозился или я что-то упустил?
  8. Понятно, что чем меньшая доля времени приходилась на загрузку XFW.Native (до оптимизации) от общего времени загрузки клиента, тем меньше заметно влияние оптимизации на общее время загрузки. Речь же шла исключительно о самом XFW.Native - 4 поста начиная с этого. По моим замерам, оптимизация дала существенное улучшение производительности, вне зависимости от системы.
  9. Ради интереса измерил время загрузки XFW.Native 1.1.1 (точнее python27.dll) на двух системах: 1) 23.3 секунды на: CPU: Core2 Quad Q6600 @ 3200 MHz RAM: 8Gb (4x2Gb) DDR2-800 Windows 10 Pro (1709) 2) 17.8 секунд на: CPU: Core i7-5930K (Haswell-E) RAM: 32Gb (4x8Gb) DDR4-2133 Windows 10 Pro (1803) Хм. На вышеприведенных конфигах, время загрузки клиента (от запуска и до экрана логина) с оптимизированным XFW.Native сократилось почти в 2 раза. И один из них тоже на Haswell. Интересно, в каких случаях улучшение производительности (загрузки XFW.Native) несущественное.
  10. Теперь понятно откуда обсуждение вариантов unique. На текущий момент ResMgr.openSection().keys() уже не возвращает отсортированный список.
  11. unique и OrderedSet - это конечно хорошо, но как помогло бы в данном случае? Ведь в сохранении исходного порядка элементов нет необходимости, требуется получить отсортированный по алфавиту список.
  12. Так текущее фактическое поведение, отличное от выделенного утверждения - это баг? Или просто данная часть документации устарела?
  13. Они и для прежней Scaleform реализации были "всем"; использовался хук Python DataProvider-а. Вопрос в том, какие хуки (или иные методы) применимы теперь.
  14. В обновлении 0.9.20 весь интерфейс укрепрайонов на "традиционном" Scaleform был упразднен. Новая реализация создана на базе Web-стандартов (HTML/JS/CSS) и встроена в клиент с помощью Chromium Embedded Framework (CEF). Каким образом можно модифицировать новое UI на CEF, кроме костыльных хаков? Опишу конкретную задачу, из-за которой и возник вышепоставленный вопрос. Требуется добавить доп. информацию в окно подбора отряда "Укрепрайон: сражения", со списком отрядов. Ранее, в UI на Scaleform, это не представляло проблемы и решалось через Python DataProvider (sorties_dps.py). Теперь же UI создается с помощью объекта WebBrowser, являющимся wrapper-ом вокруг нативного BigWorld.WebBrowserProvider. В классе WebBrowser присутствует метод с многообещающим именем executeJavascript. Казалось бы, вот оно! Можно воспользоваться техникой, уже более декады применяющейся для внесения изменений в веб страницы - UserJS. По факту же оказалось, что в нативном объекте executeJavascript отсутствует. Других приемлемых возможностей получения доступа к DOM внутри WebBrowserProvider разглядеть не удалось.
  15. @ktulho, хотелось бы уточнить, с какой целью было решено (пере)создать hitLog средствами py_macro? Для реализации возможностей, которые отсутствуют в hitLog-е XVM? Или в перспективе планируется перевести стандартный XVM hitLog с AS на данное py_macro (аналогично часам в ангаре, которые, как и hitLog, изначально создавались еще до появления экстра полей)?
  16. @Kornet_WA, речь об отдельном моде, который можно скачать с их сайта. Он не имеет привязки к модпаку и не использует GUI-настройки в ангаре.
  17. Почему нет? Чем от протанки (отдельный от модпака) не устраивает?
  18. Простую и быструю процедуру тестирования с подробными инструкциями именно для этого и сделал.
  19. Посмотрел касательно автоматизации тестирования - всё выглядит неплохо. Не знал, что можно воспроизводить несколько реплеев без перезапуска клиента, причем это стандартная возможность. Этот момент существенно ускоряет процесс. В прикрепленном архиве: py_macro\xvm\damageLog.py - тестовая версия damageLog с поддержкой BattleEvents (на основе damageLog из релиза XVM 6.7.4.1) py_macro\damageLog_test.py - скрипт для автоматизации тестирования gen_wotlist.cmd - батник для упрощения создания файла со списком реплеев - .wotreplaylist Как тестировать: 1) Скопировать файл damageLog_test.py в res_mods\configs\xvm\py_macro 2) Закинуть реплеи в любую папку (без пробелов в пути) и "перетащить" её на gen_wotlist.cmd. Будет сгенерирован файл damageLog_test.wotreplaylist 3) "Перетащить" созданный файл на WorldOfTanks.exe или открыть с его помощью. Дождаться окончания проигрывания реплеев. 5) Повторить пункт 3, предварительно заменив damageLog.py в res_mods\configs\xvm\py_macro\xvm тестовой версией из архива. Необходимые для проверки ошибок данные будут сохранены в подкаталогах damageLog_debug и damageLog_debug-test каталога с реплеями. DamageLog_BattleEvents.zip
  20. @ktulho, Все оказалось несколько запущеннее, чем я предполагал. Вот что удалось выяснить о событиях, используемых в логе повреждений от WG, т.н. "BattleEvents": Для некоторых воздействий на игрока, регистрируемых в логе damageLog, отсутствуют BattleEvents. Порядок возникновения BattleEvents в "последовательности событий" от различных "источников информации" недетерминирован. Например, простейший случай - урон от выстрела без нанесения критов. Сейчас в damageLog ему соответствует последовательность (USH): updateVehicleHealth -> showDamageFromShot -> HealthChanged. BattleEvents же может возникнуть в любой момент данной последовательности: в самом начале (еще до updateVehicleHealth), в самом конце (после HealthChanged) или где-то в середине. В рамках одного BattleEvents может приходить информация как об одном, так и о нескольких событиях сразу. Например, может поступить список событий, одно из которых относится к "завершенной" последовательности (USH), а другое - к еще не начавшейся. Событие BattleEvents к "завершенной" последовательности (USH) может возникнуть уже после того, как начнется новая (в случае получения/блокирования нескольких выстрелов за короткий период времени) и различные комбинации вышеперечисленного В общем-то, текущая "альфа" с поддержкой BattleEvents на моей небольшой тестовой выборке работает. Число раз, когда мне казалось что "теперь то уже все", а позже находилась очередная "неучтённая" ситуация, далеко от нуля. Поэтому считаю, что добавлять BattleEvents в damageLog без проведения регрессионного тестирования на большом числе реплеев - не лучшая идея. Кто-нибудь готов за это взяться? Возможно имеет смысл тестировать на реплеях с wotreplays с большими цифрами заблокированного урона? P.S. Составил полный список танков с орудиями, для которых нет возможности определить голдовые снаряды текущим методом, т.е. без использования BattleEvents: Имхо, действительно интересны только ЛТ-9 (особенно 13 90) и шведы.
  21. Удалось посмотреть? Если "да", то к чему пришли? Если "нет", то у меня есть возможность в ближайшие дни попытаться с этим повозиться.
  22. @ktulho, Если эта информация доступна, то из-за чего отсутствует возможность её использования в данном моде? После того как вы прояснили причину невозможности определения голды (если "эффекты снарядов" одинаковые), стало ясно, что она затрагивает и другие танки, у которых основной и премум снаряд однотипные. Например, шведские ПТ начиная с 8 уровня. Часто недоумевал, что даже выйдя на сверхбронированном танке, эти пт никогда не стреляют голдой :) Второй же просмотренный реплей подтвердил догадку, что было наивно так думать.
  23. Именно про него, ясно. Если не затруднит, можете прояснить, технически эта информация недоступна для модов на питоне вообще, т.е. сам лог повреждений от WG получает данные по-другому?
×
×
  • Create New...