Маркеры - отлетающий урон. Обсуждение

[st.Archer 18]

...хотя не совсем я тут прав наверно, думаю многие люди ничего не меняют, используют по умолчанию. Так, что к какому-то консенсусу прийти надо. Я сторонник того, что из красных летит красный, из зеленых- зеленый, это основное

Поддерживаю: враги красные - из красных вылетает красный урон, союзники зеленые - из них зеленый урон.

Да, да, взводному так и оставить как сейчас системный, а вот свой я бы лучше не ярко оранжевым, а темно-желтым сделал

Ну, темно-желтый\оранжевый - что-то где-то рядом:)

[sirmax 5,499]

> В чем смысл отлетания от зеленого красным, а от красного зеленым? Только путаницу внесли.

Как с этим дерьмом можно согласиться? Это только вносит путаницу.

Сейчас у красных урон вылетает красный, у зеленых - зеленый. Так и надо оставить.

 

Как? В updateHealth(*) не передается ник тимкилера.

И реплея с нанесением хотя бы одного дамага от тимкилера у нас, к сожалению, нет.

Да, не получится. Я забыл, что нельзя вычислить того, кто нанес урон. Не вопрос, пока без этого.

 

Спасибо. Самый полезный комент за две страницы.

Вот это важно: http://www.koreanrandom.com/forum/topic/1653-%D0%BE%D1%82%D0%BB%D0%B5%D1%82%D0%B0%D1%8E%D1%89%D0%B8%D0%B9-%D1%83%D1%80%D0%BE%D0%BD-%D0%B2-%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%80%D0%B5/page__st__200#entry16125

[Crus 11]

) Хо-хо! Союзник нанес урон! Давайте его дамаг отрисуем зеленым! Союзник же зеленый! ... ой нет, тут шаблон ломается в отношении того как было предложено выше. Только путаницу внесли.

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

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

[demon2597 5,468]

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

Ну тут как расценить, можно и так: зеленые бьют красных, поэтому наносимый ими урон- тоже красный:)

[VicKing 650]

Ну тут как расценить, можно и так: зеленые бьют красных, поэтому наносимый ими урон- тоже красный:)

Этот спор, вернее, отношение к происходящему на экране, сравнимо с игрой на инверте мыши и без :)

Это личное восприятие происходящего.

[demon2597 5,468]

Этот спор, вернее, отношение к происходящему на экране, сравнимо с игрой на инверте мыши и без :)

Это личное восприятие происходящего.

Ну да, в принципе тоже верно

[█XlebniDizele4ku 344]

Кто-нибудь удостоверился в том, что unknown тип урона идет от невидимого?

[stilett 2]

Могу вечером проверить. Напишите какой урон ещё нужен сделаем с друзьями.

и желательно если можно то ваш кон фиг. у меня дефол сейчас стоит от sirmax.

 

Нашёл ваш кон фиг вечером сделаем..

Edited October 8, 2012 by stilett

[7serafim7 49]

Сейчас реплеи тренировок пишутся так что проверить любой урон не сложно,ну окромя тимкилла)

[kashbessm 19]

Нашёл ваш кон фиг вечером сделаем..

на всякий случай, стоит иметь в виду, что unknown урон может быть присвоен

"еще не обнаруженному противнику на ГК".

 

формально говоря, если в обычном бою я получаю чемодан рядом с собой, то мне пишут от кого криты, хотя я и не вижу арту. то есть это определенно урон от enemy.

 

если предположение верно, то проверить его будет сложно. ГК выключено.

[VicKing 650]

Кто-нибудь удостоверился в том, что unknown тип урона идет от невидимого?

Да, так и есть, покрасил весь "unknown" в один цвет - замечал в основном от арты чемоданы с цветом "unknown", пару раз кусты стреляли "unknown" цветом :)

[█XlebniDizele4ku 344]

Еще раз для ноющих. Вопрос стоит как дать авторам конфигов возможность попользовать новую фичу, а не как поломать калькуляторщиков. Зараза, до сих пор противит этот вася. Если кто-то в теме не в теме и конфига основательно не редактировал, то читается это все сложно. Конкретно определитесь что вы хотите и получается ли это при текущем положении.

 

Поехали.

 

Таким образом, учитывая ваши пожелания что из кого должно лететь, похоже, надо вернуть общий переключатель приоритетов.

Заодно обрисую сложность ситуации.

 

Вот что сейчас получается без него в отношении подхода зеленый урон из зеленого союза.

 

1) Приоритет как сейчас:

 

damage by receiver "" -> damage by source

 

1.1) Данные о цвете сначала ищутся в секции маркеров с учетом ally/enemy. Там стоит null на цвет во всех маркерах. Теперь я понимаю, что это сильно аффектит на людей с дефолтовым конфигом и такой null надо воспринимать как системный цвет.

 

Поскольку там цвет null во всех секция ally/enemy, с новым алгоритмом значение ищется во вторичной секции - корневой секции damage. Это та новая секция в которой атрибуты относительно источника.

Таким образом данные о цвете получены с учетом типа урона и источника.

 

Что же случается с цветом при таком алгоритме с вашей схемой?

Вы поставили в новой корневой секции damage урон от врагов в зеленый. Так из зеленых союзников вылетает зеленый урон. Таким способом вы хотите сохранить это отношение зеленый из зеленого.

Какие это превносит минусы?

Урон от тимкилера красится по цвету из unknown строки. Голубой лупанул по союзу. Из зеленого союза вылетает какой-то другой цвет, а не зеленый.

Урон союзной арты по нашим зеленым союзам. Из зелёного союза вылетает красный, если нашу стреляющую арту было видно.

Урон от любой арты вне зоны видимости, похоже считается unknown. Красится другим цветом и какой туда цвет не поставь это нарушает вашу схему зеленый из зеленого.

Недочеты.

 

Как с текущим алгоритмом поживает финишный урон?

1.2) Данные о damageText сначала ищутся в секции маркеров с учетом ally/enemy dead/alive.

Предположим, что по всем секциям markers - alive у вас берется damageText просто как "-{{dmg}}", а по всем dead берется "{{vehicle}} готов!". Для dead своя плюшка работает.

В markers - alive поставим damageText в пустое значение - marker{ enemy{ alive{ normal{ damageText: "". И для ally тоже, конечно.

Теперь damageText для alive выбирается по типу и источнику. Можно для пожара "x{{dmg}}x" поставить и все что угодно для других типов\источников.

Работает.

 

Как починить цвет? Цвет чинится переключением приоритета.

 

2) Альтернативный приоритет.

 

damage by source"" -> damage by receiver

 

С таким переключением сначала данные цвета ищутся в новой корневой секции damage, если в ней аттрибут "color": "" или "color": null для текущего типа и источника урона, то данные ищутся в секции markers по соответствующим ally\enemy dead\alive normal\extended.

 

Что же получается при таком алгоритме с вашей желаемой схемой сохранения отношения зеленый из зеленого?

Какой из источников\типов урона вы проигнорите в этой секции, что бы он брался из markers?

Предположим вы поставили все "color": по всем типам и источникам в пустое значение "" и таким образом color всегда берется из секции markers с учетом ally/enemy dead/alive.

Из markers с учетом ally/enemy dead/alive берется цвет относительно получателя урона - зеленый из союза, красный из врага, голубой из голубого, золотой из сквадного, если системные цвета работают как я предполагаю.

 

Про секцию markers. В ней, кстати, по дефолтовому конфигу в "color": null и никто ничего не менял, чтобы использовались системные цвета. Какой цвет в таком случае берется я не вникал. Сирмакс может подскажет. Наверняка, из зеленого вылетает зеленый независимо ни от чего. Из красного красный. Из голубого и сквадного тоже соответственно свои.

 

Но с такой настройкой нет подкраски даже урона от сквадного!

Ок. В корневой секции damage подкрасим весь урон от сквадного в золотой и общий урон от падений в серый посредством заполнения пустых color: "" на что-то желаемое. Сработает как запланировано. Минусов не вижу. Всех так устраивает кому это вообще надо. Кому не надо править, останется как было.

Работает.

 

Теперь думаю проверяю не сломался ли финишный урон для dead.

В корневой секции damage для обычного "attack" типа урона из всех источников damageText ставим "-{{dmg}}". Для пожара "x{{dmg}}x" или как первый. Неважно.

Поскольку приоритет переключен в альтернативную сторону, данные сначала берутся из корневой секции damage, если их там нет, то из markers.

 

Какие это превносит минусы?

Поскольку все damageText по источнику и типу заполнены, то из markers - dead ничего браться не будет. Большой минус для кого-то. Финишный урон не работает.

В качестве хоть какого-то выхода все damageText по источнику и типу в пустое значение "" или null и alive ставить "-{{dmg}}", а dead "{{vehicle}} готов!", но ни о какой модификации относительно типа и источника урона нет.

Недочеты.

 

Немного схематики для наглядности.

damage by receiver "" -> damage by source

damage by source"" -> damage by receiver

{ marker { ally { alive { normal { color: null, damageText: "-{{dmg}}" }

{ marker { enemy { alive { normal { color: null, damageText: "-{{dmg}}" }

{ marker { ally { dead { normal { color: null, damageText: "Done!" }

{ marker { enemy { dead { normal { color: null, damageText: "Done!" }

{ damage -> attack -> from ally { color: "0x123456", damageText: "-{{dmg}}" }

{ damage -> fire -> from enemy { color: null, damageText: "xx{{dmg}}xx" }

{ damage -> ramming -> from squad { ...

 

Решение следующее, как его вижу я:

Общий переключатель приоритетов надо не просто добавить, а переделать в индивидуальный.

Уже не сложно накодить переменную в которой были бы записаны имена атрибутов, для которых приоритет нужно брать альтернативный.

Это выход! Всё сработает как захочет автор конфига, но получается сложнее. И, конечно, такое поле к заполнению необязательно, чтобы не путать авторов, кому не надо заморочек, и с дефолтовым значением ведет себя без поломок поведения старых конфигов.

 

Калькуляторщики блин. Тьфу!

 

Да я то не нервничаю,

 

Да я все еще под аффектом от того черта. Ничего личного ни к кому из этого треда, кроме него.

[demon2597 5,468]

Едрит- ти, вот это гайд! Вечером затестю так да сяк, а то все никак со временем, только почитать успеваю. Плюсик:)

Edited October 8, 2012 by demon2597

[█XlebniDizele4ku 344]

Едрит- ти, вот это гайд! Вечером затестю, а то все никак со временем, только почитать успеваю. Плюсик:)

 

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

[demon2597 5,468]

Да на работе особо некогда толком вникнуть то, вечером буду разгребать, спасибо

[kashbessm 19]

Еще раз для ноющих...

damage by receiver "" -> damage by source...

damage by source"" -> damage by receiver...

(много букв)

 

реально не могу понять (может, я слоупок?).

 

что-то есть принципиально сложное или невозможное в том,

чтобы оставить текущую схему приоритетов,

но при этом поменять формат параметра дамаг-мессиджа в старой секции damagetext на новый, продвинутый?

 

пример приводил в сообщении 188.

 

насколько мне кажется, этот подход решает ВСЕ возможные проблемы и варианты.

[█XlebniDizele4ku 344]

пример приводил в сообщении 188.

 

Сообщение 188 в этой теме от меня и очень короткое. У нас разная нумерация?

 

пример приводил в сообщении 188.

 

Вот это?

 

повторю затерявшееся мнение.

если секцию damage, как основную, сделать на верхнем уровне,

но добавить возможность затачивать нужные цвета/размеры/параметры в секции damagetext, (по аналогии с тем как сейчас подавляются системные цвета),

то не нужно будет вычислять союзника по имени.

достаточно будет в сеции damagetext/ally/ изменить параметр цвета урона от союзника.

и иметь возможность вносить туда что-то поменьше размером, не всю матрицу.

типа

"markers": {

"ally": {

"alive": {

"normal": {

"damageText": {

"damageMessage": {

"attack": {

"ally": { "<font color='0x0x00EEFF' size='22'>!{{dmg}} {{i:hit}}</font>" },

...

}

 

реально не могу понять (может, я слоупок?).

 

Да. Согласен, что сложно.

 

Что бы это понять надо поставить себе задачу-хотелку и подумать как это могло бы быть описано в конфиге:

 

Я хочу что бы для трупов текст урона был "{{Готов!}}", для живых "-{{dmg}}", для горящих "xx{{dmg}}xx".

Я хочу что бы цвет урона был красный, если попали по врагу, но золотой, если стрелял сквадной.

 

> если секцию damage, как основную, сделать на верхнем уровне,

 

Она и так на самому верхнем уровне иерархии. Вот основная ли она или нет мог бы решать переключатель приоритета.

 

> но добавить возможность затачивать нужные цвета/размеры/параметры в секции damagetext, (по аналогии с тем как сейчас подавляются системные цвета),

 

Именно это секция и делает. Опять же где находится заточка-уточнение мог бы решать переключатель приоритета.

Кто кого уточняет-затачивает?

Куча секций из markers уточняет корневую секцию damage? - приоритет в одну сторону.

Корневая секция damage со своими случаями типа и источника урона уточняет-затачивает секцию маркеров со всеми её ally\enemy dead\alive? - приоритет в другую сторону.

 

Можешь представить себе это как наследование с override, если разбираешься в программировании. Я посчитал, что слово приоритет всем будет понятней, нежели наследование.

 

Если значение рассматриваемого атрибута пустое "" или null, то смотреть что там в другом отношении.

Отношения два:

по приемнику - markers ally\enemy dead\alive

по источнику - какой тип урона? От кого? fire from squad

Какое из них первично мог бы задавать переключатель или список индивидуальных приоритетов.

 

> то не нужно будет вычислять союзника по имени.

 

Не понял. Опустим.

 

Не думаю, что ответил на всё и всё понятно. "Задавайте ваши ответы."

Edited October 8, 2012 by █XlebniDizele4ku

[kashbessm 19]

видимо, разная, но да, именно это сообщение.

 

а вот эту часть ответа я не смог понять, сорри:

Да. Согласен, что сложно.

Что бы это понять надо поставить себе задачу-хотелку и подумать как это могло бы быть описано в конфиге:

 

Я хочу что бы для трупов текст урона был "{{Готов!}}", для живых "-{{dmg}}", для горящих "xx{{dmg}}xx".

Я хочу что бы цвет урона был красный, если попали по врагу, но золотой, если стрелял сквадной.

 

это значит что сделать такой принцип конфига нельзя?

почему? в чем сложность?

схема-то оптимальная.

в damagetext у нас уже 4 ресивера (свой/чужой, живой/дохлый).

и если по этим ресиверам можно отдельно выставить (а можно и не выставлять, брать из корня) параметры урона, в зависимости от источника,

то эта комбинаторика накрывает все варианты.

 

и все что для этого нужно - ввести доп поля параметру "damageMessage" и включить html.

 

поделитесь, в чем сложность?

 

 

п.с.

прочитал дополненный ответ в сообщении выше, но все равно не нашел там ни подтверждений, что я понятно изложил свою мысль,

ни объяснений, чем она - не решение проблемы.

может, будет полезно, если я наглядную схемку нарисую, чтобы в словах не путаться?

Edited October 8, 2012 by kashbessm

[█XlebniDizele4ku 344]

в damagetext у нас уже 4 ресивера (свой/чужой, живой/дохлый).

и если по этим ресиверам можно отдельно выставить (а можно и не выставлять, брать из корня) параметры урона, в зависимости от источника,

то эта комбинаторика накрывает все варианты.

 

и все что для этого нужно - ввести доп поля параметру "damageMessage" и включить html.

 

поделитесь, в чем сложность?

 

> в damagetext у нас уже 4 ресивера (свой/чужой, живой/дохлый).

 

8! Еще normal\extended.

 

Понял позицию. Да. На мой взгляд хорошее решение. Согласен, это покроет все случаи. Все случаи получаются частные.

Это исключает необходимость приоритетов для решения задачи. Класс.

 

Получается моя груда матриц, копируется во все 8 маркеров.

 

Я побаиваюсь принимать такое только потому, что это раздует размер конфига и его сложность. Да, кому не надо раздуто не будет. Да, по дефолту раздуто не будет. Раздуто будет только у большого фантазёра. Когда еще только вывалилась первая альфа от меня с матрицами типа урона и источника в корневом уровне конфига, то Сирмакс дал понять, что это бегемот большого размера, давай поменьше покомпактей что-ли. Ну я это так понял.

 

Короче, я за. Мне нужно только обобрение Сирмакса на такое упрощение конфига и покрытия всех случаев, но в огромный ущерб избыточности.

Избыточностью конфига в целом, кстати, я планирую заняться позже. Есть тикет http://code.google.com/p/wot-xvm/issues/detail?id=145

 

Здесь важно еще то, что не все будут редактировать конфиг руками и воспользуются XVM editor-ом.

 

И важно еще, что все эти фантазии в самом XVM editor-e надо еще тоже накодить. Кому? Sirmax editor-ом и занимается. Может и сам возьмусь, но это совершенно новая поляна для меня окажется и растянется это всё на недели и недели.

[kashbessm 19]

8! Еще normal\extended.

 

Получается моя груда матриц, копируется во все 8 маркеров.

 

это раздует размер конфига и его сложность.

 

я об этом тоже писал.

все будет гораздо компактнее, если в эти 8 мест

(я, кстати, экстендед не использую, так как настроил уже имеющимся инструметом ВСЮ нужную в бою инфу на normal экран)

копировать не все матрицы.

 

это возможно, если сами матрицы раздробить на строки параметров.

 

например:

attack_ally

fire_squad

 

и так далее.

 

это даст возможность копировать в подсекции markers только то, что нужно поменять, по сравнению с настройками корневой секции.