Jump to content
Korean Random

Crus

User
  • Content Count

    77
  • Joined

  • Last visited

Community Reputation

11 Noob

Recent Profile Visitors

2,765 profile views
  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-а. Вопрос в том, какие хуки (или иные методы) применимы теперь.
×
×
  • Create New...