Crus

Исправил, теперь не пересекаются. На XVM 6.1.0 stable наблюдаю аналогичное поведение. На дефолтном конфиге символы в ушах (лампочка засвета) и хитлоге не отображались, пока из системы (Win 8.1 x64) не был удален установленный ранее шрифт XVM от Andrey_Hard для замены букв от {{vehicle-class}} макроса. Немаловажно, что ссылка него присутствует в дефолтном конфиге.

Касательно моих соображений, кто-нибудь прокомментировать может? Есть ли настройки, позволяющие избежать вышеописанного поведения Zoom-а и тем самым раскрыть потенциал данной возможности?

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

Не совсем понял вопрос. Цвет рамки/прозрачность у подсветки можно задать любые. Оформление подсказки тоже произвольное (цвет, шрифт и т.п.), может как двигаться за курсором, так и статично привязываться к элементу. Всех возможных вариантов просто не счесть. Для продолжения работы нужны карты с описаниями. HTML-часть готов взять на себя, но описания - это из другой оперы. Имел ввиду сабж топика. Если позиция принципиальная, и совместная разработка с разделением обязанностей (HTML / подготовка контента) не приемлема, то кроме представленного выше кода помочь не смогу.

Mikk36, ironically, I made a similar page based on jquery.maphilight yesterday. You may notice additional highlighting on hover compared to your implementation. Набросал, по-видимому, одновременно с Mikk36 похожий (на основе одного плагина) базовый код. Использовал карту из поста Alastanka. В моем варианте реализована подсветка областей при наведении мыши: http://trialzone.github.io/wot-xvm-docs/ingame.htm (исходник https://github.com/trialzone/wot-xvm-docs/tree/gh-pages) Фактически, знание HTML более не требуется. Теперь все упирается в создание карт (image map) с областями, и составление понятных описаний к ним для каждого из "экранов". Возможно имеет смысл подкорректировать требования. Для карт можно использовать визуальный редактор, например в GIMP присутствует данный функционал. Есть и онлайн инструменты.

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

Сделать можно через xvm-stat. Но соотношение "польза от фичи/трудозатраты на реализацию" весьма сомнительно, учитывая систему обнаружения/маскировки игры.

Для меня это основная причина, почему флеш-конфигуратор не смог заменить блокнот. Выходной конфиг получается трудночитаемым и дальнейшая допилка в текстовом редакторе затрудняется. Сложно не согласиться, что возможность сохранения исходного форматирования - фактически невозможна. Но при этом, сделать генерируемый конфиг более удобоваримым для дальнейшей доработки, полагаю, вполне реально: - добавлять комментарии (генерировать в соотв. с элементом и/или секцией); - упорядочить секции как в образцовом конфиге. Т.е. постараться приблизить его на выходе к samples/FULL Config.

Картинка смотрится отлично, точно также как и "текстовый" отлетающий урон. За диск волноваться не стоит, системный кеш в памяти никто не отменял. Скорее всего такое поведение связано с приведением цвета из формата записи в JS (0xFFFFFF, в конфиге) в HTML/CSS (#FFFFFF, макрозамена).

Почему же сразу все? Несколькими постами выше задавался подобным вопросом. Тоже не понимаю, как можно используя только цвета, наглядно представить и тип, и источник урона. Получается нечто далекое от интуитивного восприятия. Персональных макросов ждать не нужно, оказывается уже сейчас есть такая возможность. В сочетании с макросом {{c:dmg-kind}} позволяет добиться искомого эффекта.

К вопросу о "поддержке". Есть ли возможность ввести макрос числа игроков, которым был нанесен урон? Т.е. значение_макроса = число_поврежденных_противников + число_фрагов. На данный момент узнать количество поврежденных противников зачастую не представляется возможным при небольшом значении lines.

Конфиг стандартный из поставки, Full config RU. Скрин приложил.

В секции damageText координата x = 0 (к примеру, в конфиге по-умолчанию). Для остальных секций блока markers это означает выравнивание элемента по центру, однако отлетающий урон немного смещен вправо. Это глюк или фича?

Ну хотя бы оставить отписку в блоке colors/damage конфига, аля "цвет урона от падения определяется значением, заданным в colors/dmg_kind/world_collision".

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

Не совсем понимаю последовательность наследования цветов в маркере отлетающего урона. Почему к урону при падении союзника применился цвет world_collision из секции dmg_kind на стандартном конфиге? Ведь в нем не используется макрос {{c:dmg-kind}} в блоке markers. Update: похоже нашел ответ. В таком случае это имхо совершенно не очевидно, и нигде в документации и комментах конфига данной информации не обнаружил. Может стоит добавить в доки/конфиг описание этого момента?

Касательно наслоения, перенес несколько цитат из закрытой темы "Отлетающий урон в маркере" для воссоздания контекста: См. выше, собственно это изначально и предложил.

Как видно из постов, абсолютное большинство считает, что урон должен быть из красных - красный, из зеленых - зеленый и никак иначе. Потому что это уже на уровне стереотипа. И с этим нельзя не согласиться, поддерживаю что так и нужно оставить. В тоже время соглашусь, что данная схема анти интуитивна. Для меня зеленый - это союзники, положительный цвет. Красный - враги, цвет опасности. Соответственно и зеленые цифры урона воспринимаются как союзный урон, положительный. А красный - потери, внимание (!). Ну а в контексте раскраски урона по источнику, так и вовсе все становится логично.

Всмысле сделать так, что если одно и то же свойство определено и в "старой" dead\alive ally\enemy и в новой damageTextMajor секции, то приоритет отдается свойству из старой секции? Тоже навскидку ничего не придумать, что требовало бы обратного приоритета.

Да, вот это и хотелось увидеть, а то реплика "Возможно, подкручу матрицу выбора размера шрифта, курсива, жирности." немного насторожила. Но возник вопрос. Сейчас во многих конфигах используется возможность маркировки последнего (смертельного) урона, путем настройки damageText (шрифта и damageMessage) внутри секции dead. Например "damageMessage": "{{vehicle}} уничтожен!\n{{dmg}}". Получается, что определив damageMessage внутри damageTextMajor (как это сделано в прототипе для маркировки типа урона), маркировка последнего урона пропадет. Я верно понял, что reverseInheritance как раз для обхода этого и будет служить?

В таком случае ждем разделения тем, перед продолжением обсуждения. Лично мне, еще бы очень хотелось иметь возможность изменения damageMessage для маркировки типа урона спец. символами. А кому-то другому, несомненно, захочется переопределить другую настройку damageText. Поэтому, может быть, все же не стоит плодить матриц, а сразу реализовать универсальное решение? Какой именно будет формат конфига в этом случае, уже другой вопрос, мне кажется все же важно определиться с самим подходом. Моя позиция по нему озвучена в постах выше. Как вариант - та же матрица, значения которой не цвета, а объекты damageText, наследующие настройки от родительского, с возможностью переопределения только нужных свойств. Т.е. вариант из теста 3 выглядел бы примерно так: [ [ {"color": "0xFF00FF", "shadow": {"color": "0x000000"} }, ... ], ... ]

А я не совсем об этом. А о том, что палитру, дающую возможность без затруднений одновременно определить источник и тип урона, наколдовать не получится. Соответственно на мой взгляд, не резонно вводить только цветовую матрицу, т.к. все равно полноценно её не будет возможности использовать. Поэтому концептуально все же или ограничиться массивом цветов по источнику урона. Т.е. планов все же нет, жаль. Но ведь отображение циферок пожара (по которым несомненно можно судить о динамике) и его суммы ни в коей мере не взаимоисключают друг друга. Можно ведь, к примеру, показывать суммарный урон от пожара (с ВГ-ой иконкой например) и "залетающими" в него циферками урона за тик, вариантов масса. Почему, можно поинтересоваться? Складывание не особо хороший вариант по очевидным причинам - теряется информация о источнике/числе попаданий/фокусе. Но ведь наслоение (у меня с настройками "speed": 2, "maxRange": 50) встречается с завидной регулярностью, и тоже приводит к потере информации. Причем если урон прилетает практически одновременно, то потери еще выше, чем в случае с суммированием. Но почему не ввести задержку, чтобы текущий урон вылетал только после того, как перестанет перекрывать предыдущий? Присоединяюсь. Это хоть и симпатичная рюшечка, но затрудняет восприятие с учетом новых возможностей раскраски.

Не совсем представляю, как подобрать цвета так, чтобы без затруднений можно было одновременно определять и источник урона, и его тип. Например, предложенная demon2597 палитра (альфа идет с ней), наглядно позволяет определить источник урона, но едва ли (особенно в пылу сражения) его тип, т.к. он представлен оттенками одного цвета. Вариант же типа "новогодняя гирлянда", хоть и позволит однозначно определить пару источник-тип, но вряд ли сможет похвастаться интуитивностью восприятия и органичностью. С другой стороны, если не ограничиваться только цветами, то открывается простор для создания представления, лишенного перечисленных выше проблем. Например, использовать цветовую схему для источника урона, а тип маркировать спец. символами и/или начертаним шрифта. Пара вопросов: 1) Теперь, когда суммирование урона от пожара реализовать возможно без костылей, есть ли фича в планах? 2) Если цель практически одновременно получает урон от нескольких источников, то отлетающие значения наслаиваются друг на друга, в результате чего виден только последний полученный урон (предыдущие им перекрываются), или мне кажется?

Имел ввиду банальную передачу данных клиенту через другой файл. Т.е. клиент после запроса производит попытки прочитать ответ из файла (который создаст/обновит wot-proxy при получении данных), вплоть до успеха/неудачи по таймауту. Сверху вниз: 1) градиент посредством lcolor (color: 0xFF0000; lcolor: 00FF00) - плавный переход 2) динамические цвета (color: {c:hp-ratio} + hp_ratio для 101; 50; 1) - ступенчатый переход 3) 1 + 2, т.е. динамические цвета с градиентом. В XVM так не сделать или не нашел такой настройки, собственно об этом и был вопрос. Впрочем наверное не актуально, поигрался с большим числом промежуточных значений динамических цветов, результат вполне устраивает.

С этим никто не спорит. Но сам вариант все же жизнеспособен, двунаправленный обмен то возможен. А вообще, привел его только в качестве примера, что без dokan-а обойтись таки можно, но утилита Junction тут не поможет :) Вопрос относительно health bar. Какова судьба давней идеи о добавлении промежуточного цвета(ов)? Есть ли в обозримых планах или отложена на неопределенный срок? Хотелось бы создать переход, как в стандартном маркере клиента версии ниже 0.7.2 (до ввода настраиваемых маркеров), т.е. такой же, как в полоске не модифицированной DamagePanel.