SLA

And it is already accurately prepared, to be exactly like Locale_ENGLISH.zip Thank you! It will be included in the next DarkDPSMeter update

Всё верно, у нас нет совершенно НИКАКОЙ официальной документации по GUI, пришлось разбираться самим... Эх, и всё таки он нужен, этот мой давным-давно обещанный учебник по созданию аддонов Ну что ж, напишу по-быстрому каркас одной из его частей, пока кратко, и пока без иллюстраций: (очень) Краткое введение в создание графических интерфейсов (GUI) для аддонов АО Вообще, на самом деле, GUI нужен НЕ каждому аддону. Есть такие аддоны, которые вообще ничего на экране не пишут и не рисуют, например AutoResurrect и AutoSellGreyAddon - им никакой GUI не нужен, они и без него прекрасно работают. Но для большинства аддонов, нужно что-то рисовать и/или писать на экране игры, поэтому GUI нужен, причём нужен сразу, на стадии начала разработки аддона. Именно поэтому, разработку аддона приходится начинать именно с разработки GUI, а уже потом, наполнять его функционалом на LUA. Структура GUI аддонов Элементы GUI в аддонах АО, называются виджетами. Каждый виджет - это отдельный XDB-файл. Все шаблоны виджетов (шаблоны XDB-файлов) находятся в архиве ModdingDocuments.zip, в папке ResourceSystem. А также, имеется несколько примеров их использования в SampleAddons. Виджеты (XDB-файлы) в аддонах образуют иерархию. Иерархия GUI каждого аддона начинается с "особого" виджета WidgetForm. Его рекомендую вообще не трогать, оставить всё как есть, просто вписать в него дочерние виджеты. Лирическое отступление о WidgetForm: Хотите знать, что особенного в этом виджете? Как раз то, что если вы послушаетесь моего совета, и НЕ станете в нём ковыряться, то, скорее всего, сэкономите несколько часов собственной жизни, которые сможете потратить на что-нибудь полезное Иерархическая связка MainForm -> MainPanel, которую можно наблюдать не только во всех аддонах, но даже в ниваловских примерах (см. SampleAddons), очень смахивает на "масло масляное". Такое ощущение, что один из этих двух виджетов лишний... Но сколько я ни пытался использовать WidgetForm вместо "главной панели" MainPanel.(WidgetPanel).xdb, что-то получалось, а что-то нет. Например, drag&drop (перетаскивание) работает для WidgetPanel, но НЕ для WidgetForm. Казалось бы, в чём тогда логика WidgetForm, зачем он нужен, если его нельзя использовать как главный контейнер аддона? А вот не знаю, но даже сами разработчики используют её ТУПО как контейнер для MainPanel.(WidgetPanel).xdb (посмотрите их примеры в SampleAddons). Возможно, программисты Нивала что-то не доделали в WidgetForm, раз уж даже дизайнеры Нивала используют её "через задницу". Ну, приходится и нам делать то же самое. В общем, забудьте копаться в WidgetForm, делайте как все, "через задницу" - вписал в MainForm дочернюю MainPanel, и всё, дальше играйтесь с MainPanel. UPD: Эх, век живи, век учись Кажется, знаю, зачем нужен MainForm - чтобы можно было показывать/скрывать ВСЕ панели аддона одновременно (например, по Alt+Z), гениально простым способом - просто показывая/скрывая MainForm. Типы виджетов Всё гораздо проще, чем кажется ПОЧТИ ВСЕ аддоны построены, в основном, из всего ТРЁХ типов виджетов: 1) WidgetPanel - Самые основные виждеты, из которых можно слепить почти все детали графического оформления аддона (окна, всякие графические элементы, и даже прогрессбары). Он представляет из себя прямоугольный контейнер, с указанным размером и координатами (которые можно менять программно из LUA). У WidgetPanel всего два практических применения - ему можно назначить фоновую текстуру, И/ИЛИ внутри него может находиться дочерняя иерархия других виджетов. Обычно, иерархия аддона начинается именно с такой панели, её часто называют MainPanel.(WidgetPanel).xdb. Короче говоря, WidgetPanel очень смахивает по смыслу на элемент <div> в HTML'е. 2) WidgetTextView - Пустой контейнер для текста, он необходим для того, чтобы написать в GUI какой-нибудь статический или динамический текст. Кстати, сами тексты хранятся отдельно от этих контейнеров, в TXT-файлах, и обязательно в кодировке UTF16-LE. 3) WidgetButton - Полноценная кнопка, имеющая 3 текстуры - для нормального, подсвеченного, и нажатого состояния. Ах да, есть ещё пара НЕвизуальных виджетов - UIRelatedTexts и UIRelatedTextures - это "коллекции" текстов и текстур соответственно, которыми можно пользоваться в LUA, программно применяя их к WidgetTextView и WidgetPanel соответственно. Конечно, в ResourceSystem лежит ещё куча типов виджетов, из которых освоены только несколько. Но ничто никому не мешает освоить их, методом проб и ошибок. Кстати, каждый раз, меняя что-то в LUA-файлах, достаточно только перезагрузить сам аддон (с помощью специального аддона AddonManager), а все ошибки LUA, в реальном времени, пишутся в файл Mods.txt. А меняя что-то в XDB-файлах, приходится каждый раз ПОЛНОСТЬЮ ПЕРЕЗАГРУЖАТЬ ИГРУ (!), и накаких ошибок никуда не пишется! В связи с этим, подозреваю, у разработчиков есть какой-то специальный IDE для разработки GUI аддонов, но с нами они им не поделились. Теги XDB-файлов У всех виджетов, структура XDB-файла очень похожая, и различается только несколькими "специфическими" для разных типов виджетов тегами. Подавляющее же большинство xml-тегов присутствуют в каждом типе виджета, их я опишу ниже. Кстати, половина из этих тегов НЕ ВАЖНЫ, потому что описывают какие-то второстепенные свойства, или "значения по умолчанию". Я, например, сторонник того, чтобы "минимизировать" кол-во тегов, выкинув все лишние. (Правда, выкидывая некоторые теги из виджетов, я столкнулся с тем, что нельзя выкидывать всё подряд, т.к. если, например, выкинуть <Placement>/<X>/<Align>, то вместо него становится НЕ "значение по умолчанию", а ОН НАСЛЕДУЕТСЯ от материнского виджета!) В качестве хорошего примера, где XDB-файлы здорово упрощены для лучшего понимания устройства GUI, советую посмотреть мой аддон TargetOfTarget - аддон СПЕЦИАЛЬНО написанный как пример по созданию GUI (правда, этот аддон написан очень давно, и сейчас я бы написал этот аддон совсем иначе). А вот значения основных тегов: <Name> - Имя виджета. Нужно указать, чтобы иметь из LUA доступ к виджету, и/или его дочерним виджетам. <Priority> - Число от нуля до ... . Приоритет виджета, как слоя. Это, как бы, Z-order виджета в материнском контейнере. То есть если в каком-то материнском контейнере существует несколько дочерних виджетов (все на одном уровне логической иерархии), то визуально они будут располагаться в соответствии с их <Placement> - чем число больше, тем выше. ВАЖНО: Приоритет главной панели аддона - это особый случай. Выше неё в иерархии нет никаких материнских виджетов, поэтому, в качестве её материнского виджета выступает сам экран игры, на котором разные встроенные элементы интерфейса имеют разный <Priority> в диапазоне наверное от 1 до 2000. Но вы не промахнётесь, если будете в своих аддонах указывать приоритет главной панели = 4000. (UPD: До версии АО 1.1.04, нужно было указывать 1000). <Children> - Список дочерних виджетов, если они есть. <BackLayer> - Ссылка на фоновую текстуру виджета, если она нужна. (Именно так делается почти всё графическое оформление аддона - ставится панель, и указывается её фоновый рисунок.) <Placement> - Расположение и размеры виджета. Очень интересная часть, напишу про неё отдельно, ниже. Далее идут менее важные теги: <Visible> - true/false - Видимый виджет или не видимый. Включать/отключать видимость виждета можно также и из LUA. <TransparentInput> - Если true, то виджет будет "прозрачен" для нажатий мыши. Настоятельно рекомендую выставлять true для всех текстовых контейнеров (WidgetTextView)! <reactionOnPointing> - название реакции, которая срабатывает при наведении мыши на виджет, и при уводе мыши с него. На все эти т.н. реакции можно реагировать в LUA. <Variants> / <Item> / <Reaction> - Только у кнопки (WidgetButton). Название реакции, срабатывающее при нажатии на кнопку. Далее идёт ещё куча редко употребляемых тегов, смысл большинства из них мне известен, но лень их сейчас описывать Если интересно, спрашивай. Виртуальная система координат экрана Перед тем, как рассказывать про <Placement>, придётся рассказать про "виртуальную" систему координат экрана, которая используется в игре. В зависимости от выставленной пользователем резолюции экрана (или окна игры, в оконном режиме), ВСЕ элементы встроенных и пользовательских аддонов, вся графика, все шрифты, все расстояния АВТОМАТИЧЕСКИ увеличиваются/уменьшаются пропорционально высоте экрана. Базовая резолюция, под которую "заточены" все GUI, и вся графика в игре, запомните - 1280x1024. В двух словах: КАКАЯ БЫ РЕЗОЛЮЦИЯ ЭКРАНА У ВАС НИ БЫЛА, выставляете в игре резолюцию 1280x1024, делаете скриншот, и дальше, уже в Фотошопе, отмеряете все расстояния, и делаете всю графику аддона именно по этому скриншоту, под резолюцию 1280x1024. Такая графика будет как раз КАК НАДО выглядеть в игре, при любой резолюции экрана, какую бы пользователь ни выставил. Придумано всё это как раз для того, чтобы нам НЕ приходилось ломать головы с тем, как располагать элементы GUI, и как измерять расстояния... Просто делаете всё под резолюцию 1280x1024, и всё Если интересно, расскажу подробнее, что такое "виртуальная" система координат, хотя, это не так уж важно: В этой системе, всегда предполагается, что высота экрана - 1024 пикселя, а ширина зависит от пропорций экрана. Если реальная резолюция экрана 1280x1024, то она полностью совпадает с "виртуальной" - 1280x1024. А если, например, у пользователя, резолюция экрана 1920x1200, то "виртуальная" система координат будет такая: 1638x1024. Как так? Просто пропорции экрана в этой резолюции не 4:3, а 16:10. Поэтому, "виртуальная" ВЫСОТА всегда остаётся 1024, а "виртуальная" ШИРИНА вычисляется, если кому интересно, по такой формуле: РеальнаяШиринаЭкрана / РеальнаяВысотаЭкрана * 1024. Расположение и размеры виджета (<Placement>) И теперь, самое загадочное место - <Placement>. Оно описывает координаты И/ИЛИ размеры виджета, как по X, так и по Y, ОТНОСИТЕЛЬНО МАТЕРИНСКОГО ВИДЖЕТА. Можно придумать множество разных комбинаций тегов <Size>, <Align>, <Pos>, <HighPos> (Не обязательно указывать все эти теги, можно выборочно. Но имейте ввиду, если вы убрали тег <Aligh>, то он наследуется от родительского виджета), и каждая комбинация будет иметь разный эффект. Примеры использования будут ниже. <Size> - Размер виджета в "виртуальных" пикселях. (Ширина для <X> или высота для <Y>). <Align> - Привязка координат (описанных в <Pos> или <HighPos>) к какому-нибудь краю материнского виджета (или экрана, если этот виждет - главная панель). Значения: WIDGET_ALIGN_LOW - отсчёт координат от ЛЕВОГО (для <X>) или ВЕРХНЕГО (для <Y>) края материнского виджета. WIDGET_ALIGN_HIGH - отсчёт координат от ПРАВОГО (для <X>) или НИЖНЕГО (для <Y>) края материнского виджета. WIDGET_ALIGN_BOTH - привязка одновременно к ЛЕВОМУ и к ПРАВОМУ (для <X>) или одновременно к ВЕРХНЕМУ и к НИЖНЕМУ (для <Y>) краям материнского виджета. Т. о., такой виджет будет менять свой размер пропорционально с материнским - это ОЧЕНЬ удобно. WIDGET_ALIGN_CENTER - позиционирование виджета просто в центре материнского виджета (по выбранной оси - <X> или <Y>). <Pos> или <HighPos> - позиция в "виртуальных" пикселях, от того края, что указан в <Align>. Если <Align> = WIDGET_ALIGN_LOW, то нужно указать только координату <Pos>, а если <Align> = WIDGET_ALIGN_HIGH, то нужно указать только координату <HighPos>. Приведу несколько примеров, какие сочетания этих параметров могут быть на практике. Кстати, <X> и <Y> совершенно НЕзависимы друг от друга, и могут иметь совершенно разные сочетания параметров. Поэтому, в примерах будем считать, что я пишу про координату <X>: <Align>WIDGET_ALIGN_LOW</Align> <Pos>30</Pos> <Size>100</Size> Виджет шириной 100 пикселей, с отступом 30 пикселей от левого края материнского виджета. <Align>WIDGET_ALIGN_HIGH</Align> <HighPos>30</HighPos> <Size>100</Size> Аналогично, только отступ от правого края материнского виджета. <Align>WIDGET_ALIGN_BOTH</Align> <Pos>30</Pos> <HighPos>50</HighPos> Размер виджета НЕ указан, но он относительный, так как привязан к размеру материнского виджета (т.е. зависит от размера материнского виджета). Отступ слева - 30 пикселей, отступ справа - 50 пикселей. <Align>WIDGET_ALIGN_CENTER</Align> <Size>150</Size> Виджет шириной 150 пикселей, по цен

Quote: (and I can also divide my French files with the developers if they wish it) OK, give it to me, I will add it into the next DarkDPSMeter release (You can attach it as an attachment here, or give a download link, if it is already posted somewhere else.)

Неправда, всё работает.

Результаты нашего активного ремонта аддонов после выхода патча 1.1.02: Все аддоны исправлены, кроме: AucCenter LootInfo

Ну, как бы, кнопки я подвинул. Да да, я помню, что просили сделать этот аддон компактнее, и сделать его передвигаемым. Это означает, что нужно сделать полный ре-дизайн аддона. Я это сделаю, но чуть позже. А пока, просто подвинул кнопки, чтобы аддоном можно было пользоваться... Кстати, кнопки "Шепот" и "*" придётся убрать, т.к. они не работают, насколько я понимаю. После ре-дизайна, аддон будет выглядеть как конфетка.

+1 ...отремонтировав последние 2 глюка, и переименовав в AddonManager ?

Nikon wrote: Если хочется знать загрузку всех аддонов, может просто по открытию списка обновлять состояние? Естественно! Только так, и никак иначе! Между прочим, причина, по которой AddonDevReloader, при старте игры, всегда показывает кнопку ВКЛЮЧЕНИЯ аддона (хотя, в коде написано, что если аддон включен, то нужно показать кнопку ВЫключения) в том, что игра загружает аддоны в алфавитном порядке. Т.о. "AddonDevReloader" загружается самым первым, и всегда видит, что целевой аддон не загружен (он загрузится через несколько секунд)... Поэтому, при старте игры, вообще нужно дать время игре загрузить аддоны, секунд 20-30, тогда список будет адекватным. Но ещё правильнее, конечно, обновлять при каждом открытии списка.

Ого! Я как раз подумывал о необходимости такого менеджера аддонов. Причём, с возможностью включать/выключать как пользовательские, так и встроенные аддоны. Примерно, как на скриншоте. У меня есть ещё пара хороших идей, чем такой менеджер аддонов должен заниматься. Потом напишу подробнее. Ушёл тестировать... UPD: Протестировал. Ошибки: Галочки снимаются только со второго нажатия. Не раскрываются и не сворачиваются списки аддонов. Т.е. список встроенных аддонов так и не удалось посмотреть. Посмотрел исходники. Порадовало обилие свежих решений! Например: 1) Прототипы компонентов интерфейса. (Это есть в примерах нивала, но в аддонах, насколько знаю, ещё никто не использовал.) 2) Реагирование на команду, вводимую в консоли. (Вроде, элементарно, но никто до сих пор, почему-то, не догадывался этого сделать. Ни у кого голова даже не пыталась думать в этом направлении, наверное потому, что разработчики отобрали у нас почти все функции для работы с чатом, и все это знают.) 3) Вроде, первый аддон, в котором использован скроллируемый контейнер. (На форуме уже какое-то время лежит пример того, как это делается. Но до сих пор никто этого не использовал на практике.) 4) Локализуемые строки хранятся прямо в LUA, а не в кипе внешних TXT-файлов. (Это стало возможным с появлением userMods.ToWString(), которую мы СПЕЦИАЛЬНО выпросили у разработчиков, но до сих пор никто ещё не использовал эту функцию в аддонах. У этого способа есть только один большой минус - он пока НЕ работает в иностранных версиях АО.) Для всего, что реализовано, довольно КОМПАКТНЫЙ исходник, кстати.

Отлично! ) Красивое, продуманное решение. Я проверил, всё работает. Залил на главную Только я ещё удалил из аддона форму (она ему не нужна), и теперь остались только 2 файла - сильно сокращённый AddonDesc.(UIAddon).xdb, и твой LUA-файл. Кстати, это не просто один из самых нужных аддонов, ЭТО САМЫЙ ПЕРВЫЙ В МИРЕ ПОЛЬЗОВАТЕЛЬСКИЙ АДДОН ДЛЯ АО ! Было бы жаль его потерять

EsAlexey починил его, он работает! Проверено!

Нет. К сожалению. Если бы мы нашли способ заставить работать русификатор в 1.0.07+, то это бы автоматически означало, что снова начали работать вообще все старые Моды (в числе которых куча отличных текстурных модов, например, RedAlert).

Я сегодня как раз собираюсь починить этот аддон.

OK, поправлю сегодня.

Valltron сказал, сам исправит LootInfo.

Трудно отказать девушке... Особенно потому, что девушки у нас на UI9 - на вес золота, у нас девушек считанные единицы ) DDView отремонтирован.

Очень грамотно составленный запрос о помощи. Странно, что никто до сих пор не отозвался, аж стыдно за коллег Лично я ещё не сделал ни одного аддона, в котором бы активно использовались классы. Поэтому я ещё не разбирался, как классы работают в LUA, и конкретно в Аллодах. И не стесняюсь признаться в этом То есть, мне, по существу, посоветовать нечего Я только подозреваю, что в вышеприведённом коде, ты создаёшь НЕ новые объекты, а просто линкуешь один и тот же объект в нескольких местах. Поэтому, когда он изменяется, он изменяется везде. Конечно, я могу ошибаться, т.к. нихрена не смыслю в этом. Но я могу посоветовать посмотреть, как устроена библиотека классов AOClassLibrary.lua, которую можно найти в аддоне DarkDPSMeter. Там всё отлично работает, думаю, ты найдёшь подходящее решение там

Congratulations, you are probably the FIRST non-russian guy in the World, who is trying to mess with AO addons development Right now, official addon development documentation by game developers is very incomplete and inaccurate. It is written in russian only, and you can find here: Allods Online\data\Mods\Docs\ModdingDocuments.zip That's why I'm planning to write a complete tutorial about AO addons development, and translate it into english, so it will be readable for everyone. -------------- I guess, you are cheating, you do not want to write "TargetOfTarget", you want to write something else on the DarkDPSMeter titlebar ) But since you are the first in the world foreigner with such request, I will help you: To add a text field here, you will have to: 1. Add a link to a new child into the MainPanel widget. 2. Create this child - an empty text container (a.k.a. "WidgetTextView"). 3. Create a child of this text container - the text itself (TXT file with some HTML-like formatting). Do the following: 1. Edit DarkDPSMeter\MainPanel\MainPanel.(WidgetPanel).xdb, add a new child link into the MainPanel widget. Simply insert a new string <Item href="MyTitle.(WidgetTextView).xdb#xpointer(/WidgetTextView)" /> into the <Chindren>: Code: <Children> <Item href="Buttons/ResetButton/ResetBtn.(WidgetButton).xdb#xpointer(/WidgetButton)" /> <Item href="PlayerInfoPanel/PlayerInfoPanel.(WidgetPanel).xdb#xpointer(/WidgetPanel)" /> <Item href="DropDownPanel/DropDownPanel.(WidgetPanel).xdb#xpointer(/WidgetPanel)" /> <Item href="MyTitle.(WidgetTextView).xdb#xpointer(/WidgetTextView)" /> </Children> 2. Then create the text container, which we linked above. Create a new file DarkDPSMeter\MainPanel\MyTitle.(WidgetTextView).xdb file, with the following contents: Code: <?xml version="1.0" encoding="UTF-8" ?><WidgetTextView> <Name>MyTitle</Name> <Placement> <X> <Pos>150</Pos> <Size>75</Size> </X> <Y> <Pos>15</Pos> <Size>22</Size> </Y> </Placement> <TransparentInput>true</TransparentInput> <FormatFileRef href="MyTitle.txt" /> </WidgetTextView> This is just a text container. You can experiment here with different x/y positions and sizes, by changing the <Pos> and <Size> values. Each time you change something in any XDB file, you HAVE to fully restart the game, to see the change. Unfortunately, there is no simplier ways to see the changes in the game. 3. Now lets create the text itself. Create a new file DarkDPSMeter\MainPanel\MyTitle.txt file, with the following contents: Code: <body color="0xFFFF0000" alignx="center" fontsize="10" outline="1">YOUR TEXT</body> Here you can experiment with fontsize and color. Btw, color value format is 0xAARRGGBB. "RRGGBB" is RGB , and "AA" is an alpha channel (transparency). "0xFFFF0000" here means "fully opaque red color". Done I haven't tested this solution, but it should work. -------------- BTW, the last DarkDPSMeter version contains english translation (see file Locale_ENGLISH). And you localized DarkDPSMeter in ...French?

Думаю, стоит посмотреть код аддона DarkDPSMeter. Там, в файле DarkDPSMeterData.lua как раз все мозги, связанные с заклинаниями. Кстати, после обновления 1.1.02, в таблице, возвращаемой avatar.GetSpellInfo() больше нет переменной debugName, которую можно было использовать как точное ID заклинания. Поэтому, EsAlexey, когда чинил аддон, добавил там такой код, "подменив" debugName на name: Code: if not SpellInfo.debugName then SpellInfo.debugName = userMods.FromWString(SpellInfo.name) end

Проблемы после патча 1.1.02 в этом аддоне были не только с *ConfigSection(), он также перестал различать заклинания. EsAlexey всё починил, отремонтированная версия теперь доступна на главной.

Вот здесь: Русификатор АО клиента EU/US 1.0.06.x Но он будет работать только до версии 1.0.07, т.к. в 1.0.07 разработчики сделали так, чтобы все наши моды "старого типа" не работали. А русификатор - это один из таких модов.

Ещё один небольшой hotfix: -- Починил совместимость с иностранными версиями АО. -- Немного отшлифовал пользовательский интерфейс (починил обрезанные надписи, убрал мелкие графические глюки). -- Добавил английскую локализацию (Locale_ENGLISH.zip внутри аддона). -- Протестировал в русской и английской версии - всё работает Works in RUS and EU/US game versions. English locale inside (see file Locale_ENGLISH.zip, just do "Extract Here" & "Replace All")

У меня версия от EsAlexey работает абсолютно нормально. Заклинание в списке не одно, а несколько. Все заклинания, которые использовал, все попадают в список.

Спасибо, EsAlexey! Залил аддон на сайт Только, я чуть дополнил исправление *ConfigSection(), для совместимости с иностранными АО, в смысле, вот так.

ВАЖНО: Создателям аддонов. Чтобы не нарушать совместимость с иностранными версиями аддонов (есть такой способ пользоваться современными аддонами в иностранных версиях), при ремонте функций *ConfigSestion() лучше НЕ ПРОСТО заменять "common" на "userMods", а вписывать такой код: Code: if not common.GetGlobalConfigSection then -- AO 1.1.02+ -- здесь используем userMods.GetGlobalConfigSection() else -- здесь используем common.GetGlobalConfigSection() end Code: if not common.SetGlobalConfigSection then -- AO 1.1.02+ -- здесь используем userMods.SetGlobalConfigSection() else -- здесь используем common.SetGlobalConfigSection() end upd: Вставил "userMods and" в первый if. Без этого в иностранных версиях не работало. upd 2010-07-17: давно заметил, но всё забывал написать, что проверка "if userMods ... then" в иностранных АО 1.1.00 генерирует ошибку в лог-файл, говорит, нет такой глобальной переменной userMods. Поэтому, заменил проверку на "if not common.GetGlobalConfigSection then". В таком виде никаких ошибок не возникает.