SLA

Отремонтировано

Отремонтировано

Патч 2.0.07 - автоматическое сокрытие аддонов по ALT+Z

Цитата из патч-ноута АО 2.0.07:

Вот так! Начиная с версии АО 2.0.07, нам больше не нужны никакие хитрые методы для сокрытия аддонов по Alt+Z. Теперь, это достигается одним простым действием:

В файле MainForm.(WidgetForm).xdb, в теге <Name> (где обычно написано MainForm) нужно написать имя аддона. Например:

И аддон будет автоматически скрываться/показываться при нажатии ALT+Z, и при показе главного меню =)

Пора начинать переименовывать MainForm'ы!..

English:

Patch 2.0.07 - automatic addons hiding on ALT+Z

Quote from AO 2.0.07 patchnote:

That's it! Starting from version AO 2.0.07, we don't need any sneaky tricks to hide our addons on pressing ALT+Z anymore. Now, this is achieved in one simple step:

In the MainForm.(WidgetForm).xdb file, in <Name> tag (there is usually written MainForm) we have to write the name of the addon. For example:

And the addon will automatically hide/show when you press ALT+Z, and when displaying the main menu =)

It's time to start renaming MainForm's!..

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

+1.

Конечно же, это не будет чем-то вроде биржы я ля форекс. Это будет нечто вроде "пункта обмена валют", где меняешь доллары на рубли, рубли на доллары, и обратно, но на каждой сделке теряешь какой-то процент. То есть, всё время чуть-чуть в минус. Просто, если бы это было не так, то... все "делали" бы себе кристаллы, сидя на этой бирже.

P.S. Спам удалил

Я мог что-то пропустить, но насколько знаю, не все простейшие способы годятся для EU/US версий АО. Поэтому, и появилась LibTiogan.

Ура!!! Наконец-то!
Действительно, в аддонах, у которых в MainForm, в <Name>, написано имя аддона, скрываются с экрана, как по Alt+Z, так и при показе меню


Не 3, а всего лишь полтора года =)))


На самом деле, до сих пор, это было, мягко говоря, неудобно - нам приходилось прятать аддоны либо AddonManager'ом, либо огромной функцией, которая потенциально ненадёжна, и могла периодически ломаться (LibTiogan однажды поломался).


ОМГ!!! Я после предыдущего патча ещё не все аддоны обновил, и тут, внезапно, 2.0.07!
Буквально завтра-послезавтра, залью все аддоны, в которых до сих пор не исправлен Drag&Drop, а также, аддоны, работающие с бафами (они тоже поломались в 2.0.06). Естественно, везде переименую MainForm'ы. Но СНАЧАЛА, протестирую, как всё это работает в 2.0.07...

1) You fail to upload the addon, because your AddonDesc.(UIAddon).xdb is NOT valid XML.

(You can check it here: http://www.w3schools.com/xml/xml_validator.asp )

To make it XML-valid, you have to replace the '&' sign to either '&' or word 'and':

Replace:

<comment>Contributors: Barut & Aspex from ISA EU SERVER - Contributor SLA from ui9.ru</comment>

to:

<comment>Contributors: Barut and Aspex from ISA EU SERVER - Contributor SLA from ui9.ru</comment>

2) Also, you fail to upload the addon, if your ZIP file contains "Addons" folder. I must be excluded.

Read this instruction - Publication of new Addons (Instruction) (it is in English).

But I have already fixed XML, also updated LibDnD.lua to the latest version (2011-05-28), and uploaded it to UI9 starting page.

Next time you upload it yourself, OK?

ВАЖНО:

Вчерашнее исправление библиотеки LibDnD, исправившее перетаскивание аддонов в АО 2.0.06, НЕ работало в EU/US версиях.

Сегодня я обновил её до версии 2011-05-28, теперь работает везде.

Тем, кто уже обновил свои ддоны на вчерашнюю библиотеку (iCreator, например, уже обновила), нужно ещё раз обновить LibDnD, чтобы аддоны работали и в EU/US версиях АО.

Исправленная LibDnD.lua - в аттачменте SampleLibDnD_2011-05-28.zip, в теме "HOW-TO: LibDnD.lua - Библиотека Drag&Drop"

Все аддоны, в которых ВТЕЧЕНИЕ НЕДЕЛИ не будет исправлен Drag&Drop самими авторами аддонов, будут исправлены лично мною. Через неделю.

Thank you, it was really broken.

RU:

Библиотека обновлена до версии 2011-05-28.

-- Вчерашнее обновление библиотеки (2011-05-27) НЕ работало в EU/US версиях. Отремонтировано!

EN:

Library updated to version 2011-05-28.

-- Yesterday's library update (2011-05-27) did NOT work in EU/US versions. Repaired!

Также, добавилось новое событие:

EVENT_RAID_MEMBER_STATUS_CHANGED

-- параметры

name: WString - имя аватара, чьё состояние изменилось

Присылается в случае изменения состояния члена рейда (описываемого через RAID_MEMBER_STATE_...) :

RAID_MEMBER_STATE_OFFLINE - игрок не находится в игре

RAID_MEMBER_STATE_NEAR - по игроку доступна вся информация

RAID_MEMBER_STATE_FAR - игрок в игре, но информация по нему недоступна либо доступна только частично

Раньше, до версии 2.0.06, при изменении этих статусов, приходило событие EVENT_RAID_CHANGED. Так вот, теперь, оно приходит только при фактическом изменении состава рейда (добавился или удалился персонаж, кого-то переместили в другую группу рейда, и др.), но оно больше НЕ приходит в случае изменения статусов членов рейда (близко/далеко/оффлайн). Для этого, теперь есть отдельлное событие EVENT_RAID_MEMBER_STATUS_CHANGED.

Однако, при изменении статусов в группе (НЕ рейде!), по прежнему приходит EVENT_GROUP_CHANGED.

В DarkDPSMeter я уже поддержал это новое событие. MinimapSla тоже следит за этими статусами, обновлю завтра или послезавтра (UPD: Уже обновил!). НАПОМИНАЮ ВСЕМ РАЗРАБОТЧИКАМ АДДОНОВ, что это событие нужно поддержать во всех аддонах, которые следят за статусами членов рейда.

RU:

Библиотека обновлена до версии 2011-05-27.

-- Отремонтировано для АО 2.0.06. Естественно, сохранена и обратная совместимость с EU/US версиями.

Кстати, отремонтировать удалось добавлением вызова mission.DNDConfirmPickAttempt() в DnD.OnPickAttempt()

EN:

Library updated to version 2011-05-27.

-- Repaired for AO 2.0.06. Of course, backward compatibility with EU/US versions preserved.

Btw, I have repaired it by adding mission.DNDConfirmPickAttempt() call to DnD.OnPickAttempt()

Нажмите здесь, чтобы скачать файл

Discussion

Достоверно никак не определишь, и это правильно, так и должно быть. Именно для этого, люди и меняют ники.
Впрочем, Setras дал несколько хороших способов попытаться идентифицировать игрока


И да, и нет. Дело в том, что Все ID в "Аллодах Онлайн" существуют локально и временно, только на время использования. Например, персонаж ПыщьПыщь вошёл в "зону видимости" аватара (аватару пришли события EVENT_OBJECT_DETECT_STARTED и EVENT_OBJECT_DETECTOR_LIST_CHANGED, а ещё, ПыщьПыщь попал в список avatar.GetUnitList()). Именно в ЭТОТ момент, для ПыщьПыщь сгенерировался новый ID. Если ПыщьПыщь вышел из этой "зоны видимости", и вошёл снова, то у него уже новый ID.

Как только ПыщьПыщь вышел из "зоны видимости" аватара, то для аватара, юнит ПыщьПыщь больше НЕ СУЩЕСТВУЕТ! А раз он НЕ существует, то естественно, у него нет ID

Детектирование членов группы/рейда, супруги(а), хорунжих - это "особый" случай, когда юниты постоянно находятся в списке avatar.GetUnitList(). Что там с unitId членов гильдии (сейчас можно их получить функцией guild.GetMemberInfo()), я не знаю, не смотрел ещё.

Исходя из всего этого, как вы уже догадались, функцию определения ID мы можем написать сами:

1) Никак не конфликтуют. Даже при том, что круглая миникарта убирает компас, квадратную миникарту можно по-прежнему вызвать, нажав Shift+M.

2) Нет. Пока нет

http://www.lua.ru/doc/5.1.html#pdf-next

http://pgl.yoyo.org/luai/i/lua_next

Она использует table.remove() в параметрах for, вместо ipairs().

Нет, тут дело самой Lua. В Lua, существуют два вида таблиц:

1) "Быстрые" таблицы, наподобие массивов в Си, только индексируются числами, с 1 (а не с 0, как в Си). Именно для обслуживания таких таблиц, существуют table.insert() и table.remove(). Чтобы таблица оставалась массивом (а не была "на лету" сконвертирована в "навороченную" таблицу), добавлять и убирать элементы в неё нужно ТОЛЬКО этими двумя функциями.

2) "Навороченные" таблицы (как в PHP), в которых индексом может служить что угодно (числа, строки, и др.). В них, элементы добавляются так: Таблица[ Индекс ] = Что-то, а убираются так: Таблица[ Индекс ] = nil.

table.insert() и table.remove() предназначены для работы с массиво-подобными таблицами. И не будь у Lua податливый женский характер, или будь она стервозна, она могла бы напрочь отказаться обрабатывать этими функциями "навороченные" таблицы. Однако, то, что эти две функции работают с такими таблицами - это, как бы, бонус. Например, в Lua, никто не мешает нам сделать вот такую таблицу:

local a = { [-1] = 10, [0] = 20, [1] = 30, [1.5] = 40, [2] = 50, [3] = 60 }

Чудо, но table.remove() будет с ней работать, и удалит индексы 3, 2, 1, однако, индексы -1, 0, 1.5 не тронет... А вот с такой таблицей, table.remove() работать откажется сразу:

local a = { [-1] = 10, [0] = 20, [1] = 30, [1.5] = 40, [3] = 60 }

Так как я удалил индекс 2, и Lua видит, что в цепочке целочисленных индексов (1 - 3) появилась дыра, и уже совершенно очевидно, что это не массиво-подобная таблица.

Таблицы, индексируемые с нуля, это "изобретение" разработчиков АО, не знаю, зачем они так сделали. По стандартам Lua, таблицы должны индексироваться с 1. Однако, любую таблицу, получаемую из API, индексированную с нуля, можно "вылечить" такой простой командой:

Посмотерел. Насколько успел разобраться, где-то в последних (пропущенных мною) патчах, изменились некоторые функции API, для работы с почтой. Если я правильно понял, ничего не урезали, просто что-то поменяли. То есть, имхо, аддон починить МОЖНО. Кто бы починил?

No no, you can't make those textures transparent, because the original textures are opaque. Since DXT1 exists in two flavors - without alpha-channel, and with 1-bit alpha channel, I guess, game developers have marked many of those DXT1 textures as "no alpha channel", so you can't do anything, game engine simply ignores the alpha-channel in some used-created textures. If you make something transparent and you see it is totally black in the game, then give up, you can't change it.

Kosh detected!

ОБНОВЛЕНИЕ R3 / UPDATE R3:

RU:

-- Исправлен единственный серьёзный баг, о котором никто кроме меня не знал -- попадая в инстанс, вы НЕ должны были "залипать" на одном месте карты - это был баг, и теперь, он исправлен. Карта ДОЛЖНА "дёргаться" по мере вашего продвижения по осям координат инстанса (особенно, в самом начале - вы даже будете выходить за пределы карты, но каждую секунду, карта будет само-корректироваться - выглядит так, как будто она "дёргается"), ТАК ДОЛЖНО БЫТЬ, потому, что именно так миникарта "знакомится" с инстансом.

-- Цвета тултипов супруги/супруга теперь розовые, а членов рейда из соседних групп - оранжевые. Всё как в игре.

-- Добавлены геоданные (пока НЕ карты) нескольких инстансов, и координаты нескольких кладов.

-- Исправлен ещё один микроскопический баг.

EN:

- Fixed the only serious bug, nobody knew it is a bug, except me -- in instance, you were not supposed to "stick" in one place of the map - it was a bug, and now it is fixed. Map should be "jerky" as you move along the coordinate axes of the instance (especially at the beginning - you'll even go beyond the map, but every second it will be self-corrected - looks as if it "jerks"), THIS IS NORMAL, because that's the way the minimap "learns" the instance.

- Tooltip colors altered. Spouse is now pink, and Raid members of neighboring groups - orange.

- Added geodata (NO maps yet) for a few instances, and the coordinates of several Treasures.

- Fixed another microscopic bug.

Duvodas сейчас в отъезде, но мы с ним уже договорились, что синтаксис событий AddonManager чуть-чуть поменяется:

Во-первых, у SCRIPT_TOGGLE_VISIBILITY, параметр isVisible будет ПЕРЕИМЕНОВАН в state, чтобы синтаксис SCRIPT_TOGGLE_VISIBILITY был аналогичен синтаксису SCRIPT_TOGGLE_DND.

Во-вторых, снова появятся события запроса и отправки памяти (правда, память теперь будет показана НЕ в отдельной колонке, а во всплывающих подсказках аддонов). Эти два события, теперь, будут называться так:

SCRIPT_ADDON_MEM_REQUEST

SCRIPT_ADDON_MEM_RESPONSE

У SCRIPT_ADDON_MEM_REQUEST теперь будет параметр target,

а у SCRIPT_ADDON_MEM_RESPONSE будет параметр sender.

Реагировать на SCRIPT_ADDON_MEM_REQUEST нужно будет примерно вот так:

Я уже реализовал поддержку всего этого в нескольких аддонах, которые сейчас залью на сайт. Например, аддоны DarkDPSMeter, GuildGui1b и AnatomySelfDefence теперь поддерживают ВСЕ события нового AddonManager, причём, именно в таком синтаксисе, как я здесь сейчас написал. Вот, на них можно будет и тестировать.

ВАЖНО: Эти изменения синтаксиса ещё НЕ реализованы (!) в том AddinManager, который прицеплен к первому сообщению этой темы. Так что, ждём когда вернётся Duvodas.

НУ НАКОНЕЦ-ТО, у нас есть Примерочная в игре! Огромное спасибо!