Ciuine

unit.GetTarget fetches the SecondaryTarget, unit.GetPrimaryTarget fetches the PrimaryTarget.

SecondaryTargets change from a large number of things, whereas PrimaryTargets only changes under specific circumstances. It's the reason that EVENT_AVATAR_SECONDARY_TARGET_CHANGED is used over EVENT_AVATAR_PRIMARY_TARGET_CHANGED in my targeting interfaces and why the developers specifically state that PrimaryTargets should only be used for simple tracking. I made the mistake in one of the versions of PlayerHUD a while ago and used PrimaryTarget changes rather than SecondaryTargets and found this out.

Additionally this is one of the reasons that avatar.SelectTarget (rather than avatar.SelectSecondaryTarget) was essentially a function "break" in particular codes.

Edit: Changed "is" to "was" in last statement, as Setras informed me that the code was changed to have both be the same function.

Art Up Your Allods!

These are going to be quite old for your interface. My newest version "Arisen" which is unreleased is slightly updated and more inclusive but doesn't have the action bar modification required for 3.0.5+.

RaidPlates

Does everything that Setras says is doable, and doesn't do everything he says can't be done.

Conceptual idea to remove the need for pre-coded definitions. (Keep having to deal with changes to non-RU/EU/NA localizations. BR is now Terra Santa using the old localization and I couldn't get info about the CHN one.)

This code assumes that the developers use the language naming conventions to figure out localizations.

Spatially shortened form:

I made a simple add-on for this a while back. But everyone uses ShipControl.

Type /cw to bring up the color changing menu, there are also a few different types of crosshairs to choose from.

GT:

Я просто надстройка для этого некоторое время назад. Но каждый использует ShipControl.

Тип /cw, чтобы вызвать изменение цвета меню, есть также несколько различных типов перекрестье на выбор.

CrosshairChange

These functions are protected despite what the API says.

I didn't look your code/paneling over too much, but from what I can see North, you're using a Prototype button. Add alignx='left' to the ButtonFormatNormal.txt's <button> and it will align the Prototype to the left. Your text reference in the ListButton.(WidgetButton).xdb is unused.

Curse - TargSelection

Simple add-on that super highlights your target; also included is my /tar selection code which is probably not as useful in other localizations.

This add-on is a .pak file. Just put the .pak file in your Addons folder and it'll work like other add-ons.

Fixed (with Setras test approval) and uploaded, enjoy.

There's an issue with the RU version; the container is self-sizing but from what I can tell from the picture (as I told nordfox) is that the left to right containers are being ignored when it comes to sizing the container. (This does not occur in my version of the game.) As a result only the TextViews are setting the container's size.

I'll have to either set the size static or figure out why the container isn't self-sizing in the RU version.

Sent you a message with a test version of the localized add-on.

I was going to use that for the translation of the words; but I still need the exact string that is used for the text at the top of the Unexplored Astral.

Scratch that, found it on a picture; Неисследованный астрал is correct?

All I need to know is what it says at the top of the RU Unexplored Astral map.

Another issue will arise is that we're not as far as y'all in astral. So the buttons won't totally be in the right place, and I don't have 29-35 in full; despite trying to sift through the RU Astral threads to get that information.

Google Translate:

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

Еще одна проблема возникает в том, что мы не так далеко, как вы все в астрале. Таким образом, кнопки не будут полностью находиться в нужном месте, и я не имею 29-35 в полном объеме; несмотря на попытки, чтобы просеять через RU Астральная темы, чтобы получить эту информацию.

Ah. The .pak file didn't need to be opened though. The boss buff/debuff portion of the code works no matter what boss it is or what localization. Just the other bits that have to be entered do not; like Spawns, Attacks, Health/Mana percentage based phase changes.

It works as is. Just needs to be slapped into the Addons folder. Thanks for the pro-tip about Nav though; I haven't been to Nav yet.

Oh, and thanks for explaining what's going on. There was lots of mistranslated stuff here and there.

I don't understand what's going on in this thread.

Were there issues with the .pak file?

Not really localized and not fully functional for Nav, but it'll work for your needs;

http://www.curse.com/addons/allods/bosstracker

The current version is remodeled to use only Valued_Object, Setras.

I was trying to ask for Loss to add back in backwards compatibility so that clients with 3.0 and 3.0.2 don't have issues.

Whatever method of implementation works best, it doesn't matter to me; just that the compatibility is restored.

Please add;

IsFocused() is used for EditLine/CommandLines. It's use is to check whether the EditLine is usable or not.

SetFocus() demands that the EditLine be selected.

They're not pre-generated. All IDs in this game are dynamic to a single client generation at an instance of time. So an ID at one point could be a completely different ID if you walk away and come back again.

So knowing the ID at one instance of time for an item doesn't mean you'll know it at another, and definitely does not mean that someone else that sees that exact item at that exact time will see the same ID.

Picture the ID system as if you've given birth to identical twins at a single instance. (Sounds painful.) They look similar, but as time goes on they become more and more unique from each other and are never truly the same.

Not applicable to built-in add-ons.

Off-topic answer: Go into LuaCompiledIngame.pak, you'll find all the .luac files.

Nope, only the ResourceSystem stuff.

There are some add-ons around with good Container design though, as you already know.

Yeh, it is frustrating, especially when most of it isn't really revealed.

You can make "static" widgets or widgetDesc's via adding them to the MainForm of your add-on similar to how I did in my example. This is kind of how certain things are done in the real tooltip, where instead of running a bunch of code to create a commonly used widget they just call on a CreateWidgetByDesc() for that widget. Then you just call on them and change parts and slap 'em in when needed, that's how the devs do it.

Take a look at the 1.0.03 ContextTooltip scripts.

It's all dynamic. My sample is direct copy of the real tooltip that you show pictures of.

Edit: To better explain; everything you see in the in-game tooltip is slapped into a Container. Nothing is static but the items in the Container themselves.

Maybe a picture will explain it better.

This is using the exact same resources I just gave you except for the fact that I removed all the excess from ContInternal except for the one TextView and doubled the TextView to allow for multiple locations at the same line.

What you see is done with six of the exact same widgets created then dynamically changed via simple "fontsize='#'" code.

To create the objects that you consider "Static", they are simply stored versions of the same idea that are dynamically added when necessary via the same Container:PushBack(*clickIconWidget*)

Pretty sure you're misunderstanding me.

Example: