Update 2.5

[sirinsidiator]

Now that Ayantir won't make these threads anymore, you will have to put up with some low-effort ones by me

New API Version: 100016

PTS Dev Guild
We always create a guild for all addon developers on the PTS, so we can test guild related things and more, ask for help with testing or just chat.
If you need an invite, ask here or over on our Gitter channel.

Links

• Update 11 Launch Details
• Patch Notes
• API Patch Notes
• ESOUIDocumentationP11.3.txt
• ESOUI PTS source code
• Harven's 2.4 to 2.5 diff
• Thread for Update 2.4 (links to older threads are found in there)

Undocumented Changes

• GetCraftingSkillName was renamed to ZO_GetCraftingSkillName

I'll edit the OP with more useful information as you post it.

[Ayantir]

http://wiki.esoui.com/Globals updated
+ textures in progress.
http://wiki.esoui.com/Constant_Values too.

[haggen]

I think it'd be worthy of a honorable mention:

3D Textures An early API for placing GUI textures in 3D space has been added. The form of this API is likely to change a lot before it is officially launched in the following update. The textures still render in the GUI layer, but it allows for 3D visual effects to be created.

More on the docs https://15254b2dcaab7f5478ab-24461f3...55ffb93863.txt

And also an important and pertinent comment about name changes:

I didn't see anything specific here, but is there a method to detect a name change for a character such that it could be used to migrate add-on settings? I attempted a name change and when I logged in I noticed a number of my add-ons reverted to default settings. It would be nice to be able to migrate the settings of the add-ons affected without popping open all of the saved variable files and editing them manually.

[sirinsidiator]

Originally Posted by haggen And also an important and pertinent comment about name changes

I already created a thread about this problem on the wishlist.

[haggen]

Originally Posted by sirinsidiator I already created a thread about this problem on the wishlist.

I don't know why I even try. :P Thanks sid.

[haggen]

Just updated the repo with PTS files:
https://github.com/esoui/esoui/tree/pts

[Haho]

GetUnitName("player") caps the name in german or/and french and doubles the data of chars with no cap in the name. (when testing multilang it's a problem)

didn't check if English let it as typed or uncap it.


GetCraftingSkillName(...) replaced by ZO_GetCraftingSkillName(...) *just saw the nb in op post ^^ sry

Is it the same for a number of functions? (it's the first one i check and nothing is documented on ESO official post about the API changes)

Edit : is it possible to post a fix for these renamed functions in medic or something?

[QuadroTony]

Originally Posted by haggen I think it'd be worthy of a honorable mention:

wait, what its meant?
really

[haggen]

Originally Posted by QuadroTony wait, what its meant? really

What did I meant with it or what does the whole 3d texture is about?

[QuadroTony]

Originally Posted by haggen what does the whole 3d texture is about?

this one! indeed

[Ayantir]

3d object in ui is here for housing editor.

[sirinsidiator]

Originally Posted by Haho GetUnitName("player") caps the name in german or/and french and doubles the data of chars with no cap in the name. (when testing multilang it's a problem) didn't check if English let it as typed or uncap it. GetCraftingSkillName(...) replaced by ZO_GetCraftingSkillName(...) *just saw the nb in op post ^^ sry Is it the same for a number of functions? (it's the first one i check and nothing is documented on ESO official post about the API changes) Edit : is it possible to post a fix for these renamed functions in medic or something?

I am not sure what problem you have with GetUnitName. Can you give an example?

GetCraftingSkillName is the only renamed method that I am aware of. I think it would be better if ZOS added an alias to addoncompatibilityaliases.lua, but if they don't do it before it goes live, I will add it to medic.

[Haho]

sure :
I created a char with no cap first letter on PTS...

In English, savedvars were saved correctly but when i switched to german, something wasn't working because it didnt use the data that were saved on some event while i was testing in English, and the name appeared twice in the saved vars with 2 different orthographs :

["craftlevels"] = 
                {
                    ["Randomion"] = 
                    {
                    },
                    ["Fgyhftgh"] = 
                    {
                    },  --- this one was saved from german or french or both. 
                    ["fgyhftgh"] = 
                    {
                        [1] = 10,
                        [2] = 10,
                        [6] = 10,
                    },   --- this one was saved from english
                },

But as i switched to german and french before opening the savedvars, I can't tell which one(s) is faulty.

Not sure if it has always been like this cause i dont remember if i already used an uncapped name.

If it has always been like this, then it's not really an issue since "thatname" and "Thatname" count as the same upon creation, thus we cant create 2 name alike in the same savedvars,
BUT if it wasn't, prepare to hear people reporting missing data. (especially on addons that save data on the long run, it would suck badly)

[Ayantir]

there is no bug with GetUnitName().
And you can't create a char when the string.lower(name) already exists.

Please review your code first.

[Haho]

whaw... I dont need to fix this for myself you know. But i'll refrain to point at a potential issue from now.


and since you didn't test it for yourself before bashing me, i did : with circonian's click4info (it must be badly coded too, seing the results) :

d(GetUnitName("player")) of an uncapped name does cap the first letter in German, and only in german.

[Ayantir]

Now I understood your bug. So indeed, yes.

It only affect users switching languages with a name without capitalization switching to german.
Just /bug ? They'll maybe fix, or not. It's maybe not a bug

[votan]

Originally Posted by Haho whaw... I dont need to fix this for myself you know. But i'll refrain to point at a potential issue from now. and since you didn't test it for yourself before bashing me, i did : with circonian's click4info (it must be badly coded too, seing the results) : d(GetUnitName("player")) of an uncapped name does cap the first letter in German, and only in german.

I think you want to use GetRawUnitName("player")

Names were never a good data-layer identifier. And with the upcoming name change, we know why.

Besides that, all names, I mean really everything which as "name" or "caption" in it, should be processed by zo_strformat for presentation-layer. Including return values.
That has to do with the "^..." most english native speakers just strip away.

local caption = zo_strformat(SI_TOOLTIP_UNIT_CAPTION, GetUnitCaption(unitTag))

Normally SI_TOOLTIP_UNIT_CAPTION looks like this "<<1>>", but in german it is "<<C:1>>".
That would explain why the first letter is capitalized in german only.

[Haho]

that would be worse. The character tables of the savedvars are saved the same way. Got two table for most addons in my saved vars on pts.

And I don't need to repair anything, I just noticed and pointed it out in case someone is having troubles too while testing their multilang addons and in case it's a new "feature" introduced with the name change thing. (I cant test on live, all chars are already created)

[sirinsidiator]

It will be a problem for German players if it stays like this. The live version does not have this bug, so any character save data will disappear for names that start with a lowercase letter, unless it gets fixed.

[Haho]

that and potentially any addon that would communicate player/teammates data through the chat (or idk how you do/intend to do this) with clients of different languages.

Is the "target" tag even affected by the same overzealous translation too? (i'd test, but pts is a freaking desert. idk where people are)