Crus
-
Content Count
79 -
Joined
-
Last visited
Posts posted by Crus
-
-
Касательно моих соображений, кто-нибудь прокомментировать может? Есть ли настройки, позволяющие избежать вышеописанного поведения Zoom-а и тем самым раскрыть потенциал данной возможности?
-
Недопонял профита от Zoom-а миникарты, или недокрутил настроек. Думал, появится возможность определить "кто есть кто" в местах скопления маркеров-надписей. Однако при увеличении, маркеры и надписи масштабируются вместе с миникартой, в итоге "каша" остается.
-
1
-
1
-
-
-се варианты подсветки и подсказки где посмотреть?
Не совсем понял вопрос. Цвет рамки/прозрачность у подсветки можно задать любые. Оформление подсказки тоже произвольное (цвет, шрифт и т.п.), может как двигаться за курсором, так и статично привязываться к элементу. Всех возможных вариантов просто не счесть.
А встройте теперь это в страничку офф. сайта.
Для продолжения работы нужны карты с описаниями. HTML-часть готов взять на себя, но описания - это из другой оперы.
Вроде ТЗ никто и не давал.
Имел ввиду сабж топика.
Кто 100% берется сделать работу?
Если позиция принципиальная, и совместная разработка с разделением обязанностей (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 присутствует данный функционал. Есть и онлайн инструменты.
-
По-прежнему хотелось бы получить комментарий по данному вопросу (макрос для определения возможности получения медали "Поддержка").
Kill log над миникартой работает пока я живой, как только меня убивают, сообщения исчезают! Может кто сталкивался с такой ситуацией или знает где это можно исправить подскажите пожалуйста!!!
К XVM это отношения не имеет никакого, тем более в теме по hit-log. Скорее всего скрипты, например control_modes.pyc.
-
В общем будет наглядно видно по динамическому кругу во время боя на сколько увеличивается или уменьшается ДОНет. Такое не сделать, во всяком случае пока динамические ТТХ не реализованы непосредственно в клиенте WOT, да и то...
Сделать можно через xvm-stat. Но соотношение "польза от фичи/трудозатраты на реализацию" весьма сомнительно, учитывая систему обнаружения/маскировки игры.
-
Невозможно.
Для меня это основная причина, почему флеш-конфигуратор не смог заменить блокнот. Выходной конфиг получается трудночитаемым и дальнейшая допилка в текстовом редакторе затрудняется. Сложно не согласиться, что возможность сохранения исходного форматирования - фактически невозможна. Но при этом, сделать генерируемый конфиг более удобоваримым для дальнейшей доработки, полагаю, вполне реально:
- добавлять комментарии (генерировать в соотв. с элементом и/или секцией);
- упорядочить секции как в образцовом конфиге.
Т.е. постараться приблизить его на выходе к samples/FULL Config.
-
Картинки я как-то опасаюсь вставлять. Мало того, что будет каждый раз происходить чтение с диска (как мне кажется), так ещё и картинка, несущаяся с приличной скоростью вверх, будет смотреться хреновенько)Картинка смотрится отлично, точно также как и "текстовый" отлетающий урон. За диск волноваться не стоит, системный кеш в памяти никто не отменял.
Может стоит изменить поведение модуля? Не нужно проверять корректность цветов...Скорее всего такое поведение связано с приведением цвета из формата записи в JS (0xFFFFFF, в конфиге) в HTML/CSS (#FFFFFF, макрозамена).
-
Возможно я что-то не понимаю, но почему все зациклились на цветах? Я бы предпочёл иконки, типа как в логе нанесённого урона.Почему же сразу все? Несколькими постами выше задавался подобным вопросом. Тоже не понимаю, как можно используя только цвета, наглядно представить и тип, и источник урона. Получается нечто далекое от интуитивного восприятия.
Или "персональные макросы" позволят мне оформить тип урона дополнительной иконкой?Персональных макросов ждать не нужно, оказывается уже сейчас есть такая возможность. В сочетании с макросом {{c:dmg-kind}} позволяет добиться искомого эффекта.
-
К вопросу о "поддержке". Есть ли возможность ввести макрос числа игроков, которым был нанесен урон? Т.е. значение_макроса = число_поврежденных_противников + число_фрагов. На данный момент узнать количество поврежденных противников зачастую не представляется возможным при небольшом значении lines.
-
-
В секции damageText координата x = 0 (к примеру, в конфиге по-умолчанию). Для остальных секций блока markers это означает выравнивание элемента по центру, однако отлетающий урон немного смещен вправо. Это глюк или фича?
-
Можно добавить в доку, но я не знаю как сформулировать...
Ну хотя бы оставить отписку в блоке colors/damage конфига, аля "цвет урона от падения определяется значением, заданным в colors/dmg_kind/world_collision".
-
Не совсем понимаю, как на текущий момент создать конфиг, который даст возможность без затруднений одновременно определить источник и тип урона.Update: разобрался, пост можно удалить
-
Не совсем понимаю последовательность наследования цветов в маркере отлетающего урона. Почему к урону при падении союзника применился цвет world_collision из секции dmg_kind на стандартном конфиге? Ведь в нем не используется макрос {{c:dmg-kind}} в блоке markers.
Update: похоже нашел ответ. В таком случае это имхо совершенно не очевидно, и нигде в документации и комментах конфига данной информации не обнаружил. Может стоит добавить в доки/конфиг описание этого момента?
-
Касательно наслоения, перенес несколько цитат из закрытой темы "Отлетающий урон в маркере" для воссоздания контекста:
Складывание не особо хороший вариант по очевидным причинам - теряется информация о источнике/числе попаданий/фокусе. Но ведь наслоение (у меня с настройками "speed": 2, "maxRange": 50) встречается с завидной регулярностью, и тоже приводит к потере информации. Причем если урон прилетает практически одновременно, то потери еще выше, чем в случае с суммированием. Но почему не ввести задержку, чтобы текущий урон вылетал только после того, как перестанет перекрывать предыдущий?
Можно обсудить заново, я не настаиваю. Просто раньше мы довольно долго это обсуждали и не нашли варианта лучше. Может сейчас придумаем, давайте обсуждать.
Давайте анимацию вынесем в отдельную тему
О! Нужно сделать эту задержку похитрее- отсчет времени не от попадания, а от начала предыдущей анимации
См. выше, собственно это изначально и предложил.
-
) Хо-хо! Союзник нанес урон! Давайте его дамаг отрисуем зеленым! Союзник же зеленый! ... ой нет, тут шаблон ломается в отношении того как было предложено выше. Только путаницу внесли.
Как видно из постов, абсолютное большинство считает, что урон должен быть из красных - красный, из зеленых - зеленый и никак иначе. Потому что это уже на уровне стереотипа. И с этим нельзя не согласиться, поддерживаю что так и нужно оставить.
В тоже время соглашусь, что данная схема анти интуитивна. Для меня зеленый - это союзники, положительный цвет. Красный - враги, цвет опасности. Соответственно и зеленые цифры урона воспринимаются как союзный урон, положительный. А красный - потери, внимание (!). Ну а в контексте раскраски урона по источнику, так и вовсе все становится логично.
-
По поводу реверса приоритета. Похоже, он не нужен.
Кто-нибудь может себе представить случай, когда нужно сначала искать данные в новой секции и если там нет то по старым dead\alive ally\enemy?
Мне в голову лезут только случаи когда сначала надо брать данные по старым dead\alive ally\enemy.
Всмысле сделать так, что если одно и то же свойство определено и в "старой" dead\alive ally\enemy и в новой damageTextMajor секции, то приоритет отдается свойству из старой секции? Тоже навскидку ничего не придумать, что требовало бы обратного приоритета.
-
Весь прототип конфига разработки индикатора на текущий момент: [skip]
Да, вот это и хотелось увидеть, а то реплика "Возможно, подкручу матрицу выбора размера шрифта, курсива, жирности." немного насторожила. Но возник вопрос. Сейчас во многих конфигах используется возможность маркировки последнего (смертельного) урона, путем настройки damageText (шрифта и damageMessage) внутри секции dead. Например "damageMessage": "{{vehicle}} уничтожен!\n{{dmg}}". Получается, что определив damageMessage внутри damageTextMajor (как это сделано в прототипе для маркировки типа урона), маркировка последнего урона пропадет. Я верно понял, что reverseInheritance как раз для обхода этого и будет служить?
-
Можно обсудить заново, я не настаиваю. Просто раньше мы довольно долго это обсуждали и не нашли варианта лучше. Может сейчас придумаем, давайте обсуждать.
Давайте анимацию вынесем в отдельную тему, а тут оставим обсуждение цветов урона.
В таком случае ждем разделения тем, перед продолжением обсуждения.
Возможно, подкручу матрицу выбора размера шрифта, курсива, жирности.
Лично мне, еще бы очень хотелось иметь возможность изменения damageMessage для маркировки типа урона спец. символами. А кому-то другому, несомненно, захочется переопределить другую настройку damageText. Поэтому, может быть, все же не стоит плодить матриц, а сразу реализовать универсальное решение? Какой именно будет формат конфига в этом случае, уже другой вопрос, мне кажется все же важно определиться с самим подходом. Моя позиция по нему озвучена в постах выше.
Как вариант - та же матрица, значения которой не цвета, а объекты damageText, наследующие настройки от родительского, с возможностью переопределения только нужных свойств. Т.е. вариант из теста 3 выглядел бы примерно так:
[ [ {"color": "0xFF00FF", "shadow": {"color": "0x000000"} }, ... ], ... ] -
Вот и я про что толкую, сделать для всех типов цвета одинаковые- как для источника. И пусть кто желает сам колдует над палитрой.
А я не совсем об этом. А о том, что палитру, дающую возможность без затруднений одновременно определить источник и тип урона, наколдовать не получится. Соответственно на мой взгляд, не резонно вводить только цветовую матрицу, т.к. все равно полноценно её не будет возможности использовать. Поэтому концептуально все же
стоит закладываться на полностью независимые настройки damageText для разных видов урона
или ограничиться массивом цветов по источнику урона.
(планы по суммированию пожара) Конечно есть. Не за пять минут делает, конечно, но да. Еще иконку пожара хочу ВГ-шную подкрутить. Красота.
Кстати, пожар складывать тоже нельзя, так как текущий отлетающий урон за то и ценят, что по уменьшению цифр можно догадаться догорит танк или нет.
Т.е. планов все же нет, жаль. Но ведь отображение циферок пожара (по которым несомненно можно судить о динамике) и его суммы ни в коей мере не взаимоисключают друг друга. Можно ведь, к примеру, показывать суммарный урон от пожара (с ВГ-ой иконкой например) и "залетающими" в него циферками урона за тик, вариантов масса.
(касательно наслоения урона) Тут не надо ничего трогать. Мы это год назад уже обсуждали, лучше вариантов нет. Были предложения и складывать, и лесенкой отображать, фигня все это.
Почему, можно поинтересоваться? Складывание не особо хороший вариант по очевидным причинам - теряется информация о источнике/числе попаданий/фокусе. Но ведь наслоение (у меня с настройками "speed": 2, "maxRange": 50) встречается с завидной регулярностью, и тоже приводит к потере информации. Причем если урон прилетает практически одновременно, то потери еще выше, чем в случае с суммированием. Но почему не ввести задержку, чтобы текущий урон вылетал только после того, как перестанет перекрывать предыдущий?
А можно сделать вспышку и разгон настраиваемыми или отключаемыми, а то как-то не очень хорошо поначалу видно от кого урон.
Присоединяюсь. Это хоть и симпатичная рюшечка, но затрудняет восприятие с учетом новых возможностей раскраски.
-
Концептуальный вопрос ко всем, кто уже попробовал альфу - обойдемся только цветами, или все-таки стоит закладываться на полностью независимые настройки damageText для разных видов урона?
Не совсем представляю, как подобрать цвета так, чтобы без затруднений можно было одновременно определять и источник урона, и его тип. Например, предложенная 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.
Конфиг: Замена символов из Wingdings на универсальные
in XVM Development
Posted