[Addon] ArcheAge Assistant

[STilllive]

ну а собсно, что я хотел бы убрать, так это все Мин и Макс
и проверку if offsetX<TargetHighlight.MinX or offsetX>TargetHighlight.MaxX or offsetY<TargetHighlight.MinY or offsetY>TargetHighlight.MaxY then ...

собсно решение нашлось. оч.простое и элегантное :)

ты рисуешь указатель на цель тогда, когда она находится на 1/8 от края экрана и дальше, т.е. за пределами прямоугольника.
минус заключался в том, что у прямоугольника есть углы :) при прохождении через которые указатель то гас, то снова появлялся.

предлагаю сделать следующее:
1. совсем убрать блок:
42 TargetHighlight.Inset = SCREEN_H/8
43 TargetHighlight.MinX = TargetHighlight.Inset
44 TargetHighlight.MaxX = SCREEN_W - TargetHighlight.Inset
45 TargetHighlight.MinY = TargetHighlight.Inset
46 TargetHighlight.MaxY = SCREEN_H - TargetHighlight.Inset
2. убрать строку:
102 if offsetX<TargetHighlight.MinX or offsetX>TargetHighlight.MaxX or offsetY<TargetHighlight.MinY or offsetY>TargetHighlight.MaxY then
3. добавить строку сразу после вычисления "g":
106 if g > TargetHighlight.Radius then
4. оценить профит :)

[Kreider]

Какие настройки приводить при наличии багов? Скрины графических?

Графические настройки тут вряд ли помогут, какие могут помочь - неясно.
Вообще же, если есть какая-то ошибка в аддоне и она выводится в чат - желателен скрин ошибки.

1. offsetX, offsetY = X2Unit:GetUnitScreenPosition("target")
судя по тому, что ты следил за этими показаниями... то может разгадал почему такой ипанистический диапазон значений (максимум, которое видел это 5+е7, т.е. от 1 до 50кк при том, что стоишь в трёх шагах и просто вращаешь камерой)?

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

2. я правильно понимаю шо это одно и тоже?
local CenterX, CenterY = X2Unit:GetUnitScreenPosition("player")
и
local CenterX = SCREEN_W/2
local CenterY = SCREEN_H/2

Почти. Первое - положение над головой игрока, второе - центр экрана. Они не совпадают, но близки.

ну а собсно, что я хотел бы убрать, так это все Мин и Макс

Да, можно заменить кругом, в чем-то будет лучше.

- если таргет находится за спиной примерно на 4 или на 8 часов, то в эти моменты указатель на цель начинает скакать по экрану

Да, есть вообще глюки с указателем, когда цель за спиной, поправлю.

- если выбрана цель в таргете и при этом заюзать какойньть интерактивный объект (буковкой F), то и маркер над таргетом и указатель на таргет фризятся на экране до выбора новой цели.

Ага, поправлю.

[STilllive]

1. Такие неадекватные значения у меня возникали, когда цель была рядом с положением камеры. Видимо они при расчете этих значений где-то делят на расстояние от камеры до объекта и результат в бесконечность уходит

2. Почти. Первое - положение над головой игрока, второе - центр экрана. Они не совпадают, но близки.

3. Да, можно заменить кругом, в чем-то будет лучше.

1. если стоять далеко, то результат тот же.
2. угу. разобрался уже. если отдалить камеру по максимуму, то разница метров 18 выходит :)
3. хоть и не совсем скромно, но лучше всем. а главное в клиенте всё очень гармонично получается.

значит смотри, что я ещё натестил сегодня:
1. математическое понятие "спереди" (т.е. когда косинус положителен) НЕ совпадает с игровым понятием "спереди" (т.е. offsetZ положителен)!!!
т.е. становишься боком (любым) к цели, косинус равен нулю, Z положителен > неспешно начинаешь поворачиваться к цели спиной, косинус становится отрицательным, НО! Z всё ещё положителен > продолжаешь поворачиваться дальше и только примерно при cos = -0,11 становится отрицательным Z, т.е. для игры я только сейчас повернулся спиной :)
2. именно в этот момент значение offsetX (и уж тем более g) подскакивает до епанутых значений больше 8кк и возможно приводящих к переполнению переменной, меняя знак. с какой переменной косяк... пока не допёр.

в общем, какой то из этих двух пунктов и приводит к тому, что указатель начинает перескакивать из стороны в сторону...

З.Ы. приятно было узнать, что перед у игрока занимает 220 градусов, а спина только 140, т.е. даже боком (визуально) можно вполне танковать тех же лучников, так же успешно, как стоя строго лицом :D

[Kreider]

ArcheAge Assistant v0.13b

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

ArcheAge Assistant v0.13b

PS: Z - это положение относительно камеры, а не игрока. Да и вообще все эти числа связаны с графикой, а не с боевой системой, так что не факт, что перед и зад у персонажа при расчете блоков расчитывается так же.

[STilllive]

PS: Z - это положение относительно камеры, а не игрока. Да и вообще все эти числа связаны с графикой, а не с боевой системой, так что не факт, что перед и зад у персонажа при расчете блоков расчитывается так же.

согласен, что отсчёт от камеры идёт, но если привязать её к игроку, то можно допустить, что речь идёт об игроке сразу. ну и как я уже предположил - возможно, что механика игры на эту систему и завязана... типа если работает, то зачем изобретать ещё 1 велосипед... хотя от этих загадочных корейцев, в одиночку пилящих коды для поддержки другой страны, можно чего угодно ожидать :D

P.S.
затестил - полёт нормальный :)

вот это вообще бомба:
100 if g>TargetHighlight.VisibleRadius or offsetZ<0 then
главное, что так доставало, когда указатель на моём затылке пропадал... а решение оказалось таким простым :D

теперь хочу обсудить пару косметических правок, исходя из практического опыта:
1. всё же хотелось бы эти величины поменьше, типа /6 и /4 соответственно (с сохранением твоих пропорций)
41 TargetHighlight.Radius = math.floor(SCREEN_H/4)
42 TargetHighlight.VisibleRadius = SCREEN_H/3
объясню почему (напомню, что я сужу со своей колокольни... с точки зрения хила): представь, что у меня в центре экрана, вокруг перса сосредоточены - слева рейд, сверху мои полоски ХП/МП, справа аддончик с дебаффами, а потому хочется, чтобы указатель летал чуть поближе к персу, не наезжая на остальные панельки.
2. ну и второе
98 local CenterY = SCREEN_H/2+SCREEN_H/20
мне заметно комфортнее, когда за центр отсчёта берётся не лысина перса, а хотя бы плечи, и поигравшись с этим значением, думаю, что нашёл оптимал.

З.З.Ы

2. именно в этот момент значение offsetX (и уж тем более g) подскакивает до епанутых значений больше 8кк и возможно приводящих к переполнению переменной, меняя знак. с какой переменной косяк... пока не допёр.

в общем, какой то из этих двух пунктов и приводит к тому, что указатель начинает перескакивать из стороны в сторону...

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

[zAndro]

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

там же обе переменные меняют знак и offsetX и offsetY. И растут они в одинаковых пропорциях, то есть нам то и не надо для точного указания стрелки на обьект знать значение offsetX и offsetY, главное знать значение offsetX/offsetY - покрайней мере в моих тестах было именно так.

[STilllive]

1. там же обе переменные меняют знак и offsetX и offsetY.
2. И растут они в одинаковых пропорциях
3. то есть нам то и не надо для точного указания стрелки на обьект знать значение offsetX и offsetY
4. главное знать значение offsetX/offsetY

1. ты не понял про знак. я имел ввиду, что именно переполнение переменной вызывает изменение знака, а не какие то игровые действия.
2. нет не в одинаковых. они вообще НЕ взаимосвязаны, т.е. изменение значений одной никаким образом не влияет на величину другой. или ты хочешь сказать, что изменяются они в одинаковых диапазонах? это тоже не так.
3. чтобы поделить х на у нужно знать значения х и у.
4. для чего? как именно ты хочешь это использовать использовать? пока не понимаю

[SunDay]

[Kreider]

SunDay, когда происходит ошибка?

[SunDay]

SunDay, когда происходит ошибка?

Сразу после входа в игру аддон даже не создает свои кнопки.

Если в игре выбрать это:

то появляется ошибка.

- - - Добавлено - - -

Откатился на 0.12

[zAndro]

1. ты не понял про знак. я имел ввиду, что именно переполнение переменной вызывает изменение знака, а не какие то игровые действия.
2. нет не в одинаковых. они вообще НЕ взаимосвязаны, т.е. изменение значений одной никаким образом не влияет на величину другой. или ты хочешь сказать, что изменяются они в одинаковых диапазонах? это тоже не так.
3. чтобы поделить х на у нужно знать значения х и у.
4. для чего? как именно ты хочешь это использовать использовать? пока не понимаю

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

[Kreider]

SunDay, попробуй эту версию, должно помочь.

[SunDay]

Да, спасибо, заработало.

[SunDay]

Не хватает функционала:
1) Метки над всем рейдом (т.е. любая самая простая метка над всем остальными членами рейда, кроме кп).
А также - метки над всей патей, даже рандом. Это было бы особенно полезно на БГ, т.е. по сути в рандом пати. Пати легко превращается в рейд, поэтому эта функция полезна как для пати, так и для рейда.

заглянул в код

В цикле идет перебор членов консты, а не рейда. Так что простой правкой в условии не отделаться... :( Что делать?

[свернуть]

2) Отсутствие красной метки цели на себе. На себе метка - либо как для члена консты, зеленая, либо вообще отсутствующая была бы к месту, имхо, но никак не красная. Хотя, это уже сложный скрипт получается. Там можно подумать еще о типе метки на члене рейда, клана, союзного клана, кос клана, но это уже другая история. Однако яркая метка на себе, имхо, смысла точно не имеет и мозолит глаз при селфбафе.

[STilllive]

1) Метки над всем рейдом (т.е. любая самая простая метка над всем остальными членами рейда, кроме кп).

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

да, на БГ или в рандом пачках был бы профит... но основной упор делается всё же на КП игру... под неё же надо и затачивать аддон в первую очередь.
хотя если будет галочка: отмечать мемберов только своей КП / отмечать всех мемберов рейда (пати)... то такой вариант устроит всех.

З.Ы. про КОС лист понравилось :) а то у меня память не очень... приходится записывать

[Kreider]

Про метку на себе - согласен.
По поводу меток на всем рейде - польза тут только для БГ. Добавлю в список.
Сейчас в работе оповещение о наложении дебафов.

[SunDay]

По поводу меток на всем рейде - польза тут только для БГ. Добавлю в список.

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


Эх, интересно, будет ли работать на рузбт?.........................................

[Jinhae]

З.Ы. про КОС лист понравилось

dobavte kos v sled versii)))) esli eto realno

[h0st]

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

[Kreider]

Сомневаюсь, что будет на РуЗБТ. Хоть кнопка настройки аддонов для экрана выбора персонажей и переведена. Если уж на корейском лайве не запустили - то на ру ни к чему им лишний источник дыр и багов. Так что пока надеемся, ждем и понемногу пишем аддон.

По поводу КОС листа - символ о принадлежности к нему можно рисовать только у текущей цели. Если этого хватит - можно добавить в список хотелок, но в следующей версии его точно не будет - приоритет сейчас на дебафах.

По поводу МА - метку на цель МА можно показывать только когда МА у тебя в таргете.