Jump to content
Korean Random

Crus

User
  • Content Count

    79
  • Joined

  • Last visited

Posts posted by Crus


  1. В предложении речь идет исключительно об обмене данными между союзниками. Поясню. Алекс и Боб - союзники. Расстояние между Алексом и Бобом - 600 метров, что превышает радиус отрисовки. Из-за этого Алекс и Боб не видят HP друг друга. В паре метров от Алекса находится противник, Чак. Алекс видит его HP, но его союзник, Боб - не видит (ведь Чак тоже находится за границей отрисовки Боба). Разумеется, союзники могу общаться между собой, посредством встроенного чата - это не запрещено. А следовательно, Алекс может передать Бобу информацию о том, сколько у него в настоящий момент осталось HP, и сколько у Чака. Моё предложение - это именно автоматизация данных "переговоров" между Бобом и Алексом.

    • Upvote 2

  2. Как известно, клиент не получает информации об изменении HP техники за пределами круга отрисовки. Из-за этого ограничения "Индикатор общего hp команд" (total_hp) нередко показывает значения, весьма далекие от реальных. Это расхождение, само по себе, ставит под сомнение полезность данного индикатора. Более того, к сожалению, этот индикатор вводит часть игроков в заблуждение, "подталкивая" к неверной оценки ситуации.

    Однако нет никаких сомнений, что "общее hp команд" - это очень полезный индикатор, если бы он отражал корректные, актуальные данные. Мне видится, что механизм XMQP просто идеально подходит для актуализации данных о HP техники за пределами отрисовки. С его помощью станет возможным получить актуальные hp техники в ушах и, разумеется, подсчитывать фактическое общее hp команд.

    Также отмечу очевидный, но немаловажный момент: для получения данных о HP техники на фланге/направлении, будет достаточно присутствия всего лишь одного игрока с активированным сервисом XMQP.

     

    P.S. Идея из категории "сама напрашивается", так что скорее всего уже поднималась, но мне найти не удалось.

    • Upvote 2

  3. Стандартно, при наведении курсора на живую технику в "ушах", она "подсвечивается" на миникарте. Однако после уничтожения, эта функция перестает работать. Если имеется возможность простой реализации аналогичной подсветки для уничтоженной техники - было бы здорово.


  4. 2 часа назад, Polyacov_Yury сказал:

    Ну, если тебе нужен прям определённый ивент

    Полагаю, что да - звуки от чемоданов арты чрезвычайно громкие, на фоне остальных звуков эффектов. В итоге, у меня вдобавок к внутриигровому оглушению добавляется вполне реальное оглушение :|

    2 часа назад, Polyacov_Yury сказал:

    ты можешь создать банк, который содержит его слегка переименованную версию и прикреплённые к ней вытащенные при помощи тулзы звуки, и подключить свой ивент вместо стандартного при помощи audio_mods.xml.

    Ясно, т.е. действовать по стандартной процедуре, описанной в первом посте.

    UPDATE: а как провести сопоставление "название ивента" -  "извлеченный тулзой файл"?


  5. Подскажите, есть ли "упрощенный" способ изменения громкости определенных стандартных звуков? Или нужно действовать по инструкции "Создание звукового банка (контейнера), *.bnk" из первого поста + извлечь стандартные звуки с помощью RavioliGameTools?


  6. 14 минут назад, Pivoved сказал:

    Я бы тоже был бы рад, если бы в этот мод включили позиции для за света

    В процитированной мной реплике недвусмысленно пояснялось, что данный функционал в этот мод добавляться не будет. Вопрос об отдельном моде.


  7. Почти год назад в этой теме зашла речь о моде с позициями для света:

     

    В 28.07.2017 в 20:29, Pavel3333 сказал:
    В 28.07.2017 в 20:24, D_MAN_1987 сказал:

    А позиции для света тоже в этом моде будут?

    Нет, это отдельный мод.

     

    В 29.07.2017 в 13:35, Pavel3333 сказал:
    В 29.07.2017 в 12:23, Gerhard сказал:

    А где можно скачать это мод ? 

    Пока что нигде его не скачаете. Он войдет в модпак Цезаря.

     

    Хотел поинтересоваться, проект заморозился или я что-то упустил?


  8. 21 час назад, StranikS_Scan сказал:

    Возможно на компутерах с очень медленной дисковой подсистемой.

     

    2 часа назад, Slava7572 сказал:

    Тоже думаю дело в ХДД

    Понятно, что чем меньшая доля времени приходилась на загрузку 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)

     

    В 18.05.2018 в 10:27, Mixaill сказал:

    У меня разница вообще незаметна на ноутбучном i7 Haswell.

    Хм. На вышеприведенных конфигах, время загрузки клиента (от запуска и до экрана логина) с оптимизированным XFW.Native сократилось почти в 2 раза. И один из них тоже на Haswell.

     

    В 18.05.2018 в 10:56, GPCracker сказал:

    Но факт остается фактом - на некоторых конфигурациях железа оптимизация дает существенное улучшение производительности.

    Интересно, в каких случаях улучшение производительности (загрузки XFW.Native) несущественное.


  10. 52 минуты назад, GPCracker сказал:

    А что именно возвращает? Пример есть?



    pprint.pprint(ResMgr.openSection('scripts\client\gui\mods').keys())
    ['mod_pmod.pyc',
     'mod_battlehits.pyc',
     'mod_.py',
     'mod_.pyc',
     'mod_xfw_native.pyc',
     'mod_pro_lasthits.pyc',
     'mod_pro_reduced_armor.pyc',
     'mod_safeshot.pyc',
     'mod_pro_spotted.pyc',
     'mod_wotxp.pyc',
     '__init__.pyc']


  11. 11 минут назад, Polyacov_Yury сказал:

    Суть в том, что ResMgr.openSection().keys() возвращает уже отсортированный список.

    Теперь понятно откуда обсуждение вариантов unique. На текущий момент ResMgr.openSection().keys() уже не возвращает отсортированный список.


  12. unique и OrderedSet - это конечно хорошо, но как помогло бы в данном случае? Ведь в сохранении исходного порядка элементов нет необходимости, требуется получить отсортированный по алфавиту список.


  13. Цитата

    6.4 Исполнение Python-кода

    После монтирования всех пакетов и разрешения конфликтов, происходит исполнение всех .pyc - файлов из каталога /scripts/client/gui/mods/ в алфавитном порядке, имя которых начинается с mod_ .

    Так текущее фактическое поведение, отличное от выделенного утверждения - это баг? Или просто данная часть документации устарела?


  14. 12 часов назад, StranikS_Scan сказал:

    Потому хуки - это ваше всё.

     

    Они и для прежней Scaleform реализации были "всем"; использовался хук Python DataProvider-а. Вопрос в том, какие хуки (или иные методы) применимы теперь.


  15. В обновлении 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 разглядеть не удалось.

    • Upvote 1

  16. @ktulho, хотелось бы уточнить, с какой целью было решено (пере)создать hitLog средствами py_macro? Для реализации возможностей, которые отсутствуют в hitLog-е XVM? Или в перспективе планируется перевести стандартный XVM hitLog с AS на данное py_macro (аналогично часам в ангаре, которые, как и hitLog, изначально создавались еще до появления экстра полей)?


  17. Посмотрел касательно автоматизации тестирования - всё выглядит неплохо. Не знал, что можно воспроизводить несколько реплеев без перезапуска клиента, причем это стандартная возможность. Этот момент существенно ускоряет процесс.

     

    В прикрепленном архиве:

    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

    • Upvote 2

  18. @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:

    Орудия ниже 5-го уровня:

     

    [czech] Kolohousenka (Cz06_Kolohousenka)
    [germany] 43 M. Toldi III (G117_Toldi_III)
    [japan] Renault Otsu (J01_NC27)
    [japan] Type 97 Te-Ke (J02_Te_Ke)
    [japan] Type 95 Ha-Go (J03_Ha_Go)
    [japan] Type 98 Ke-Ni (J04_Ke_Ni)
    [japan] Type 98 Ke-Ni Otsu (J05_Ke_Ni_B)
    [japan] Type 5 Ke-Ho (J06_Ke_Ho)
    [japan] Type 97 Chi-Ha (J07_Chi_Ha)
    [japan] Type 1 Chi-He (J09_Chi_He)
    [japan] Chi-Ni (J15_Chi_Ni)
    [japan] Type 91 Heavy (J21_Type_91)
    [sweden] Lago (S04_Lago_I)
    [sweden] Strv fm/21 (S05_Strv_M21_29)
    [sweden] Strv m/40L (S12_Strv_M40)
    [sweden] L-60 (S15_L_60)
    [sweden] Sav m/43 (S19_Sav_M43)
    [sweden] Ikv 72 (S20_Ikv_72)
    [uk] Vickers Medium Mk. I (GB01_Medium_Mark_I)
    [uk] Vickers Medium Mk. II (GB05_Vickers_Medium_Mk_II)
    [uk] Vickers Medium Mk. III (GB06_Vickers_Medium_Mk_III)
    [uk] Grant (GB17_Grant_I)
    [uk] Universal Carrier 2-pdr (GB39_Universal_CarrierQF2)
    [ussr] А-32 (R68_A-32)

     

    Орудия 5-го уровня и выше:

    [france] AMX 13 90 (F17_AMX_13_90)
    [japan] Type 3 Chi-Nu (J08_Chi_Nu)
    [japan] Type 4 Chi-To (J10_Chi_To)
    [japan] Type 5 Chi-Ri (J11_Chi_Ri)
    [japan] Type 3 Chi-Nu Kai (J12_Chi_Nu_Kai)
    [japan] Type 5 Heavy (J20_Type_2605)
    [japan] O-I Experimental (J23_Mi_To)
    [japan] O-I (J24_Mi_To_130_tons)
    [japan] Type 4 Heavy (J25_Type_4)
    [japan] O-Ho (J27_O_I_120)
    [japan] O-Ni (J28_O_I_100)
    [sweden] Strv m/42 (S02_Strv_M42)
    [sweden] Strv 74 (S07_Strv_74)
    [sweden] Strv 103-0 (S10_Strv_103_0_Series)
    [sweden] Strv 103B (S11_Strv_103B)
    [sweden] Leo (S13_Leo)
    [sweden] Ikv 103 (S14_Ikv_103)
    [sweden] Emil II (S17_EMIL_1952_E2)
    [sweden] Emil I (S18_EMIL_1951_E1)
    [sweden] UDES 03 (S21_UDES_03)
    [sweden] Strv S1 (S22_Strv_S1)
    [sweden] Strv 81 (S23_Strv_81)
    [uk] Sherman Firefly (GB19_Sherman_Firefly)
    [uk] Centurion Mk. 7/1 (GB24_Centurion_Mk3)
    [uk] Challenger (GB41_Challenger)
    [uk] Archer (GB44_Archer)
    [uk] Achilles (GB45_Achilles_IIC)
    [uk] FV215b (183) (GB48_FV215b_183)
    [uk] Sherman III (GB50_Sherman_III)
    [uk] Alecto (GB57_Alecto)
    [uk] Charioteer (GB80_Charioteer)
    [uk] FV4005 Stage II (GB83_FV4005)
    [uk] Chieftain Mk. 6 (GB84_Chieftain_Mk6)
    [uk] T95/Chieftain (GB88_T95_Chieftain_turret)
    [usa] T49 (A100_T49)
    [usa] XM551 Sheridan (A116_XM551)
    [usa] T26E5 Patriot (A117_T26E5_Patriot)
    [usa] T26E5 (A117_T26E5)
    [ussr] Т-54 облегчённый (R109_T54S)
    [ussr] ИСУ-130 (R111_ISU130)
    [ussr] СУ-100Y (R49_SU100Y)
    [ussr] КВ-2 (R77_KV2)

     

    Арта:

    [france] Lorraine 155 mle. 50 (F24_Lorraine155_50)
    [france] Lorraine 155 mle. 51 (F25_Lorraine155_51)
    [france] Bat.-Châtillon 155 58 (F38_Bat_Chatillon155_58)
    [france] Bat.-Châtillon 155 55 (F67_Bat_Chatillon155_55)
    [germany] G.W. Tiger (G45_G_Tiger)
    [germany] G.W. Panther (G49_G_Panther)
    [germany] G.W. E 100 (G61_G_E)
    [germany] G.W. Tiger (P) (G94_GW_Tiger_P)
    [uk] Crusader 5.5-in. SP (GB29_Crusader_5inch)
    [uk] FV3805 (GB30_FV3805)
    [uk] Conqueror Gun Carriage (GB31_Conqueror_Gun)
    [uk] Sexton I (GB78_Sexton_I)
    [uk] FV207 (GB79_FV206)
    [usa] M12 (A32_M12)
    [usa] M40/M43 (A37_M40M43)
    [usa] T92 HMC (A38_T92)
    [usa] M53/M55 (A88_M53_55)
    [ussr] С-51 (R15_S-51)
    [ussr] СУ-14-2 (R27_SU-14)
    [ussr] 212А (R51_Object_212)
    [ussr] Объект 261 (R52_Object_261)
    [ussr] СУ-14-1 (R91_SU14_1)

    Имхо, действительно интересны только ЛТ-9 (особенно 13 90) и шведы.

    • Upvote 2

  19.  

     

    проблема, скажем так, в "синхронизации" полученной информации.

    Я еще посмотрю, может что и придумаю.

    Удалось посмотреть? Если "да", то к чему пришли? Если "нет", то у меня есть возможность в ближайшие дни попытаться с этим повозиться.

    • Upvote 1
×
×
  • Create New...