Jump to content
Korean Random

Crus

User
  • Content Count

    79
  • Joined

  • Last visited

Everything posted by Crus

  1. @T2000 Nice try to pretend you don't know This decade-old guide is impossible to read without laughter and tears in 2022. So I almost wrote "Dude, did you lose your calendar? Today is not April 1st". But checked the date December 28 at the last moment and bingo!
  2. @T2000 paragraphs about IS-7 and Maus look especially actual. Are you from Spain or Hispanic America? ;-)
  3. В предложении речь идет исключительно об обмене данными между союзниками. Поясню. Алекс и Боб - союзники. Расстояние между Алексом и Бобом - 600 метров, что превышает радиус отрисовки. Из-за этого Алекс и Боб не видят HP друг друга. В паре метров от Алекса находится противник, Чак. Алекс видит его HP, но его союзник, Боб - не видит (ведь Чак тоже находится за границей отрисовки Боба). Разумеется, союзники могу общаться между собой, посредством встроенного чата - это не запрещено. А следовательно, Алекс может передать Бобу информацию о том, сколько у него в настоящий момент осталось HP, и сколько у Чака. Моё предложение - это именно автоматизация данных "переговоров" между Бобом и Алексом.
  4. Как известно, клиент не получает информации об изменении HP техники за пределами круга отрисовки. Из-за этого ограничения "Индикатор общего hp команд" (total_hp) нередко показывает значения, весьма далекие от реальных. Это расхождение, само по себе, ставит под сомнение полезность данного индикатора. Более того, к сожалению, этот индикатор вводит часть игроков в заблуждение, "подталкивая" к неверной оценки ситуации. Однако нет никаких сомнений, что "общее hp команд" - это очень полезный индикатор, если бы он отражал корректные, актуальные данные. Мне видится, что механизм XMQP просто идеально подходит для актуализации данных о HP техники за пределами отрисовки. С его помощью станет возможным получить актуальные hp техники в ушах и, разумеется, подсчитывать фактическое общее hp команд. Также отмечу очевидный, но немаловажный момент: для получения данных о HP техники на фланге/направлении, будет достаточно присутствия всего лишь одного игрока с активированным сервисом XMQP. P.S. Идея из категории "сама напрашивается", так что скорее всего уже поднималась, но мне найти не удалось.
  5. Стандартно, при наведении курсора на живую технику в "ушах", она "подсвечивается" на миникарте. Однако после уничтожения, эта функция перестает работать. Если имеется возможность простой реализации аналогичной подсветки для уничтоженной техники - было бы здорово.
  6. Полагаю, что да - звуки от чемоданов арты чрезвычайно громкие, на фоне остальных звуков эффектов. В итоге, у меня вдобавок к внутриигровому оглушению добавляется вполне реальное оглушение :| Ясно, т.е. действовать по стандартной процедуре, описанной в первом посте. UPDATE: а как провести сопоставление "название ивента" - "извлеченный тулзой файл"?
  7. Подскажите, есть ли "упрощенный" способ изменения громкости определенных стандартных звуков? Или нужно действовать по инструкции "Создание звукового банка (контейнера), *.bnk" из первого поста + извлечь стандартные звуки с помощью RavioliGameTools?
  8. В процитированной мной реплике недвусмысленно пояснялось, что данный функционал в этот мод добавляться не будет. Вопрос об отдельном моде.
  9. Почти год назад в этой теме зашла речь о моде с позициями для света: Нет, это отдельный мод. Пока что нигде его не скачаете. Он войдет в модпак Цезаря. Хотел поинтересоваться, проект заморозился или я что-то упустил?
  10. Понятно, что чем меньшая доля времени приходилась на загрузку XFW.Native (до оптимизации) от общего времени загрузки клиента, тем меньше заметно влияние оптимизации на общее время загрузки. Речь же шла исключительно о самом XFW.Native - 4 поста начиная с этого. По моим замерам, оптимизация дала существенное улучшение производительности, вне зависимости от системы.
  11. Ради интереса измерил время загрузки 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) несущественное.
  12. Теперь понятно откуда обсуждение вариантов unique. На текущий момент ResMgr.openSection().keys() уже не возвращает отсортированный список.
  13. unique и OrderedSet - это конечно хорошо, но как помогло бы в данном случае? Ведь в сохранении исходного порядка элементов нет необходимости, требуется получить отсортированный по алфавиту список.
  14. Так текущее фактическое поведение, отличное от выделенного утверждения - это баг? Или просто данная часть документации устарела?
  15. Они и для прежней Scaleform реализации были "всем"; использовался хук Python DataProvider-а. Вопрос в том, какие хуки (или иные методы) применимы теперь.
  16. В обновлении 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 разглядеть не удалось.
  17. @ktulho, хотелось бы уточнить, с какой целью было решено (пере)создать hitLog средствами py_macro? Для реализации возможностей, которые отсутствуют в hitLog-е XVM? Или в перспективе планируется перевести стандартный XVM hitLog с AS на данное py_macro (аналогично часам в ангаре, которые, как и hitLog, изначально создавались еще до появления экстра полей)?
  18. @Kornet_WA, речь об отдельном моде, который можно скачать с их сайта. Он не имеет привязки к модпаку и не использует GUI-настройки в ангаре.
  19. Почему нет? Чем от протанки (отдельный от модпака) не устраивает?
  20. Простую и быструю процедуру тестирования с подробными инструкциями именно для этого и сделал.
  21. Посмотрел касательно автоматизации тестирования - всё выглядит неплохо. Не знал, что можно воспроизводить несколько реплеев без перезапуска клиента, причем это стандартная возможность. Этот момент существенно ускоряет процесс. В прикрепленном архиве: 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
  22. @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) и шведы.
  23. Удалось посмотреть? Если "да", то к чему пришли? Если "нет", то у меня есть возможность в ближайшие дни попытаться с этим повозиться.
×
×
  • Create New...