Altair

Эмм, неправда. Панельки этого аддона никаким образом не мешают ставить стяжки/стенки, они прозрачны для кликов. Только что на всякий случай проверил, думал, может я забыл чего, но нет, все в порядке! Если что-то мешает, то это может быть любой какой-то другой аддон, который в ту же область что-то выводит.

Если нужно только сравнить, то лучше использовать common.CompareWString().

В моем понимании "вырезание Debug'а" - это не столько вопрос производительности, сколько вопрос чистки кода от нежелательных вещей. В этом контексте смириться с разницей во временах выполнения пустой функции и проверки переменной вполне себе можно. А если заморачиваться, то тогда уж надо вплотную смотреть на препроцессор.

Кстати насчет дебага добавлю. Т.к. можно оверрайдить функции любые (в том числе библиотечные, вроде как), то как вариант вместо препроцессинга можно добавлять в проект debug.lua, в котором будет написано что-то типа (в некоторой степени псевдокод):

local _logInfo = _G["LogInfo"]
_G["LogInfo"] = function(...)
    _logInfo("additional_debug_data", ...)
end

Соответственно, если НЕ добавлять, то ничо оверрайдиться не будет. Таким образом можно заранее определить несколько функций как пустые, а потом в debug.lua их переопределить и написать какое-нибудь тело.

Ога.

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

Ну а сборка выглядит примерно вот так:

Фичи:

• Собирается всё одной кнопкой Build. Можно из этого же окна задать Output папку - игровую папку с аддонами. Можно открыть её или папку с сорцами любого аддона, если дабл-кликнуть по нему в списке.
• Debug - это нескомпиленная версия, кладется в Output отдельной папочкой.
• Release - сборка скомпиленного и упакованного в pak аддона. Если ставлю галку Distribution, то складывается туда, откуда был запущен билдер, иначе - в Output.
• Автоматом инкрементируются и могут подставляться версии/ревизии в имя аддона (которое в *.(UIAddon).xdb), в localizedName/Desc, в имя pak-файла или куда-нибудь еще по желанию.
• Есть папка _SharedLibraries, где лежат всякие "общие" lua-скрипты типа LibDnD, всяких хелперов и прочего. Эдакая помойка, откуда можно поиметь код на все случаи жизни. Зареференсить оттуда файл в аддоне можно прописав тэг [shared] перед именем файла в стандартном *.(UIAddon).xdb. Пример из ACP: 

  <Item href="[Shared]Core.lua" />
  

  В таком случае файл Core.lua кладется в аддоне в подпапочку Libraries, а его путь в xdb аддона подменяется на соответствующий.

• Можно скипнуть компиляцию для любого скрипта, добавив аналогично предыдущему пункту тэг [skipCompile]

• Есть система "патчей" (папочка _Patches), которая представляет собой независимые от аддона ресурсы, которые могут складываться в любой аддон. К примеру, есть у меня MessageBox, я могу интегрировать его в несколько аддонов, при этом файлы MessageBox'а лежат в одном месте. В патчах же могут лежать и более мелкие ресурсы. Например, шаренные одинаковые текстуры, чтоб руками не перекладывать туда-сюда.

Я почти доволен этой штукой. Если б еще препроцессор был и можно было прыгать по сорцам как в любой другой IDE через Go to definition, то вообще б лепота.

Можно время посчитать и по факту появления подсветить место же..

Хочу отметить только, что прочитал и намотал на ус. Ушел думать

Думаю, добавить каноны паладинов в список по умолчанию будет не лишним.

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

Пожалуйста подскажите можно ли увеличить размер панелек бафов и как можно сместить панельки ниже буду очень благодарен за подсказку. Адон и правда очень полезен просто класс.

Размер панелек думаю вынести в конфигурационный файл в следующей версии. А сместить ниже можно уже сейчас. В конфиге для каждого бафа своего класса можно задать параметр PosY, который как раз управляет смещением панелек относительно центра экрана.

она ищет квесты доступные на текущий уровень. Квесты ниже уровнем не видит

Враки. Видит.

обновил аддон и он вылетел несколько раз за 1 час.

Если в 5.0.2, то да, логично, потому как фикс был для 6.0. Последняя версия для PTS выложена.

AoUMeter.zip

Fixed for 6.0 PTS.

Changes: 

--//spellPanel.Damage:SetVal("DamageBlock", common.FormatFloat(spellData.ResistPercentage , "%d"))
spellPanel.Damage:SetVal("DamageBlock", common.FormatFloat(spellData.ResistPercentage , "%g"))

function IsFriend(id)
    --//return id and object.IsExist(id) and object.IsUnit(id) and unit.IsFriend(id)
    return id and object.IsExist(id) and object.IsUnit(id) and object.IsFriend(id)
end

Though, I didn't test it thoroughly...

З.Ы. Снимаю с себя всю ответственность. Пофиксил, но особо не тестил, поэтому если что-то все-таки недочинено - мопед не мой ©...

Два реквеста:

1. Регистрация без указания ID вручную, но используя RequestIntegerByInstanceId.

2. Функции для корректной раз-регистрации (нужно, например, когда двигающийся виджет должен быть удален).

Есть!

Там вообще речь про аргументы в пользу добавления Драг-Н-Дропа шла...

А так, карта картой, но аддоном явно быстрее можно сориентироваться, куда бежать к конкретному человеку. Вот сказал тебе кто-то из патьки "иди ко мне", ты как поступишь? Откроешь карту и будешь искать на карте, где этот человек? Там же метки не подписаны, надо мышку наводить, искать среди них нужную, потом надеяться, что человек не сойдет с места. А с помощью этого аддона выделил просто сопартийца и всё, идешь по указанному направлению и никаких проблем с поисками. Ну а уж если ты в рейде, а не в группе - состаришься, пока по карте сориентируешься.

Я категорически против глупых дурацких стрелок "как в AcAddon'е". Мой маркер тоже не идеален, но он хотя бы не так уныл, как просто стрелка. Соответственно я против выкладывания твоей модификации в качестве отдельного самостоятельного аддона в общем списке всех аддонов аллодера.

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

А вообще можно было просто внести аргументированные предложения, чтобы я подумал и, возможно, сам что-то поправил.

Я долго думал, прикручивать или нет. Последняя мысль была, что он скорее мешать будет, чем помогать. За всё время использования (а я и мои согильдийцы им пользуются уже больше года) ни разу ни одного реквеста о необходимости перемещения по экрану не пришло. Ну и он-таки полупрозрачный, по идее не мешает обзору.

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

Тонко. Нет. :Р

Единственный доступный способ на данный момент - это mission.SetChatInputData

Только она требует в качестве аргумента виджет строки ввода.

Видимо, просто копирует текст из виджета, принадлежащего аддону (в который уже проще впихнуть что угодно), в строку чата.

 

PS: функцию не проверял, могу и обманывать

Боюсь показаться глупым, но как в EditLine вставить ссылку на объект? ) У него есть только SetText и InsertTextAtCursorPos, которые оба на вход принимают только WString.

Всем привет.

Задача стоит показать на экране иконку вещи и позволить юзеру линкануть эту вещь в чат кликнув по иконке. Это возможно?

Я в мануале не нашел информации о том, как впихнуть ValuedObject или ValuedText в строчку ввода сообщений

В оригинальных скриптах видно какую-то функцию InsertGameItem, но в public API ее чота не видать.

А, ну окей. Андерграунд не по мне, так что я с удовольствием покину этот сайт вместе со своим мнением.

> На разрешения Нивала лично я кладу свысока.

До тех пор, пока это так, твое творчество - это андерграунд с ограниченной аудиторией. Если хозяин сайта придерживается той же позиции, будет обидно.

О великий! Тебе все уже известно! Прости меня, я был не прав %(

А теперь серьезно. Нивал _не может не сделать_ ничего для текстов. Если будет API, то по-любому будут и свои тексты. Если ВДРУГ это будет не так, можно будет пойти спрыгнуть с крыши разуверившись в общечеловеческой (и нивальской в частности) разумности.

Но и в таком случае, даже если Нивал-таки вынудит кого-либо на самоубийство не дав никаких инструментов по загрузке собственного текста в интерфейс, то сильновероятно он же (нивал в смысле) и запретит перегружать файл pack.loc. Я общался с разработчиками напрямую, мне было сказано, что часть возможностей Нивал однозначно будет закрывать. Так вот, внутренние неизменяемые ресурсы - это первые же претенденты на "защиту" от шальных рук.

Его вообще как-либо модифицировать нет смысла. Если ты туда что-то и добавишь, оно все равно будет неиспользуемо в массовом варианте. Клиент цепляет только один loc-файл и только целиком.

А что будет, если человек захочет поставить два мода, каждый из которых добавляет какие-то тексты? Если у каждого в архиве будет свой pack.loc, то игра загрузит только один, а второй мод останется без добавленных текстов. Если же в архиве будут только сырые тексты, а пользователь при установке будет "запаковывать" эти тексты в pack.loc, то это блин какой-то очень крутой пользователь, который вполне способен сам и мод наваять. Даже если все это будет автоматом, выглядеть это все будет очень ненадежно и ошибкоопасно. Далеко мы все так не уедем.

Нивал скорее всего даст возможность тексты каким-то дополнительным образом "добавлять" к пользовательским аддонам. Если не даст, значит ПРИДЕТСЯ обходиться только тем, что есть в составе оригинального pack.loc.

И еще немаловажный момент. Согласно моим текущим изысканиям (они конечно не факт, что 100% истина, чисто догадки), каждому интерфейсному аддону соответствует некоторый набор текстовых файлов из виртуального каталога pack.loc. Соответствие это задается как раз в pack.bin и определяется жестко. Если соответствия у конкретного текстового файла с аддоном нет, то загрузить этот текст функцией GetAddonRelatedText() или аналогами не получится. И мне думается, что уж pack.bin Нивал точно не даст "править" и "подменять".

А смысл? В будущем это все равно будет не нужно.

Нивал не позволит менять ресурсы клиента. Подменять другими, к примеру, скрипты - это да. Для собственных скриптов текст скорее всего откуда-то из спец-места грузиться будет, иначе могут возникнуть проблемы совместимости разных аддонов. Аддон должен быть самостоятельным и не должен менять при этом оригинальных ресурсов игры.

Именно исходя из этой логики, я не стал делать "компилятор". Он просто бесполезен. Единственное место его приложения я вижу только если у себя _локально_ хочется поправить текст какой-то, к примеру. Тогда да, он может пригодиться. Но ради этого стоит ли городить огород?

Ко всему прочему, у вас там че-то уж очень много "неизвестностей" в ваших описаниях. В loc-файле нет никаких "ненужных" полей.

И если уж хотите действительно полезное дело сделать, расковыряйте лучше файл AO\data\packs\bin.pak\bin\pack.bin. Там очень _похожая_ на pack.loc структура, но, к сожалению, не _такая же_.