Trying my 1st addon - a few basic questions

[vsrs_au]

Hi, I hope this is the right subforum for my thread, if not can the mods please move it?

I just started playing around with Baertram's FooAddon (from the "New to AddOn creation? - Usefull links and information" thread) to start learning about ESOUI addons, and have a few questions:

- I specified the ESOUI API version as 101039 in the addon, because https://wiki.esoui.com/APIVersion says that's what it should be, but in the addons menu in the game it's flagged as out of date, why is that?

- FooAddonIndicator:ClearAnchors() gives exception 'attempt to index a nil value'. Any ideas on what I've done wrong here? I wrote the addon as specified in that tutorial page, and it worked up to the point where I added the saved variables code and the code to move the indicator icon, but now gives the exception every time the addon is [re]initialised.

[vsrs_au]

Already answered my 1st question!

The ESOUI API page is incorrect: the live API version is actually 101040, not 101039, I verified this by running the script command in the chat window for retrieving this version.

[vsrs_au]

The 2 lines where this addon is generating the "attempt to index a nil value" error are:

FooAddonIndicator:SetHidden(not inCombat)
(in function FooAddon.OnPlayerCombatState(event, inCombat))

FooAddonIndicator:ClearAnchors()
(in function FooAddon.RestorePosition())

so it's almost like the indicator UI component hasn't yet been initialised at that point, but I don't know what could cause that.

[vsrs_au]

I think my hypothesis from previous post was correct: the UI component wasn't being loaded. For some reason, when I removed the hidden="true" attribute from the component, the addon started working properly with no errors, so it was (somehow) causing the problem.

[Baertram]

Originally Posted by vsrs_au Already answered my 1st question! The ESOUI API page is incorrect: the live API version is actually 101040, not 101039, I verified this by running the script command in the chat window for retrieving this version.

Yeah, sorry, i'm updating the versions on the Wiki and forgot it last time
You always get the most up2date live or PTS API version by logging in to the server and using /script d(GetAPIVersion())

[Baertram]

Originally Posted by vsrs_au I think my hypothesis from previous post was correct: the UI component wasn't being loaded. For some reason, when I removed the hidden="true" attribute from the component, the addon started working properly with no errors, so it was (somehow) causing the problem.

I have not checked that Foo addon for long time, maybe it's also wrong somewhere.
if an "attempt to index a nil value" error happens it means that you are working with a table and the table is nil but you try to access it at an index.
In your case that means that the table FooAddonIndicator was nil as the code tried to call it's function :<WhateverNameHere>
So this can happen if it's called too early, before the table FooAddonIndicator was created.
Often happens if you forget to load an XML file before the lua file actually was run, where the XML code was used (if in the XML that table or control FooAddonIndicator was craeted e.g.).

Or you try to access the FooAddonIndicator before the EVENT_ADD_ON_LOADED for YOUR addon has fired and thus created the control/table in there.
Happens if you put a function or lua code in your lua file e.g. at the beginning, outside of the EVENT_ADD_ON_LOADED callback function, so it will be processed directly as the file is processed!

lua files are parsed from top to bottom at the time they are read. Each addon will be loaded from the ingame addon manager via it's txt file (manifest) in the order "ZOs code first, then all addons in live/AddOns A to Z but respecting the ## DependsOn and ## OptionalDependsOn in all txt files -> builds a load order of depending addons).
In the manifest txt file there the linked xml and lua files are loaded in the order of the txt file lines afterwards -> per addon.

After that ALL addons pass through EVENT_ADD_ON_LOADED once so that is the reason why one is checking in there for the own addon name and ONLY runs code initialization IF the own addon name was found. And afterwards one unregisteres the own EVENT_ADD_ON_LOADED again as the own code was initilized and there is no need to do the "is my addon currently processed?" check again and again for each other addon

If one would init the own code without checking that it will provide you many nl errors as your files of the addon have not been loaded properly maybe, but you already try to access code from them!!!

-> I bet this or similar was an issue here, and not the hidden="true" as this only shows/hides a control on the UI, but does not create or no create it.


At least the notation : used in there is kind of hard to understand, or might raise issues too:
If FooAddonIndicator is a control, like a movable UI thing where you want to show something visually: Forget the below! Controls and such always use the : notation as they are created objects.

Only if FooAddonIndicator is e.g. a self-created table for your addon, -> In this example addon it is "FooAddon", then the below would apply!!!


If FooAddonIndicator is a table (not an object, see below)

: and . are different ways to call a function of that table.
But . is "just" referencing the member (function, variable, another subtable, ... ) of the table and if the member is a function it will "just" call it (if you close the string with ()
Example FooAddonIndicator.testFunction() calls the function testFunction of table FooAddonIndicator.


Where as : will always call a function, and not reference a member of that table.
AND it will automatically pass in as 1st parameter the "object" of FooAddonIndicator so you can reference that object internally in the function via the pointer "self".
This normally applies to an object riented approach of coding where you create a "class" e.g. "myCar" and then define different objects from that class like "familyCar" and "raceCar". The class "myCar" then provides basic functions like "accelllerate" and "break" and the objects created can have different functions like family car got "openTrunk" and raceCar got "changeTiresFast".
Both car types use the base class FooAddonIndicator in this case but create different objects which are referenced internally in the functions of class FooAddonIndicator via the "self" variable.

So for beginners the : notation should not matter and not be used, simply stick to . notation!
You can baiscally exchange all : definitions and calls to a . definition and call then.

e.g.
function FooAddonIndicator:testFunc()
end

Change to
function FooAddonIndicator.testFunc()
end

And calls like
FooAddonIndicator:testFunc(param1, param2)
to
FooAddonIndicator.testFunc(param1, param2)

Should be easier to read, to understand and to be used in simple example addons then.

[vsrs_au]

@Baertram, thanks so much for the detailed reply! Also, sorry for my late reply, I'm in timezone GMT+11 (Melbourne, Australia).

My code was as follows (and as I said, taken from your tutorial):

FooAddon = {}

FooAddon.name = "FooAddon"

{{ various function definitions of the form FooAddon.functioname(...) }}

EVENT_MANAGER:RegisterForEvent(
    FooAddon.name, EVENT_ADD_ON_LOADED, FooAddon.OnAddOnLoaded)

In those functions, the references to FooAddonIndicator (defined as a top-level control in the XML file) are all of the form:

FooAddonIndicator::functioncall(...)

I'm still not sure exactly what I did to fix the sample addon, but it works OK now. I guess I'll find out one day, when I know more about ESO UI and/or LUA.

[Baertram]

Either the FooAddon.xml was not loaded due to an error in th XML code and thus the control was nil,
or the xml line was missing in the txt file of the addon causing it to fully miss that control (= nil)