2.7 Update
 

Hello,


2.7 Update (Homestead) is on PTS.




More info : http://www.elderscrollsonline.com/en...cing-homestead


I would like first to thanks sirinsidiator for his 2.5 update post and the awesome ambiance on Gitter.


Now, back to business, so some placeholders :

• Last 2.6 thread : http://www.esoui.com/forums/showthread.php?t=6483
• Last 2.5 thread : http://www.esoui.com/forums/showthread.php?t=6384
• Last 2.4 thread : http://www.esoui.com/forums/showthread.php?t=6250
• Last 2.3 thread : http://www.esoui.com/forums/showthread.php?t=6052
• Last 2.2 thread : http://www.esoui.com/forums/showthread.php?t=5196
• Last 2.1 thread : http://www.esoui.com/forums/showthread.php?t=4892
• Last 1.6 thread : http://www.esoui.com/forums/showthread.php?t=4235

• Main Axis for Addons
  
  
  • HOUSING
  • New styles as always.
  • Other things still unknown.
  
  
  
• Code itself - Done
  
  There's extracts, tools and methods to use reverse engineering and understand the ESOUI original code. When devs who starts to build something "big", you should all know this website or get an extract on your computer, to understand, find and see "how it works" :
  https://github.com/esoui/esoui
  http://esodata.uesp.net/current/index.html
  
  The "ESOUI" source code (Core Lua Base Game made by Zenimax) is here : http://www.esoui.com/downloads/info1...ourcecode.html
  
  
  
• Patchnotes - Done
  
  https://forums.elderscrollsonline.co...change-log-pts
  
  
  
• Patch Notes TXT - Done
  
  https://us.v-cdn.net/5020507/uploads...f6e0477e19.txt
  
  
  
• Wiki pages
  
  How-to update Wiki Pages
  
  http://wiki.esoui.com/Globals : Done
  http://wiki.esoui.com/Texture_List : TODO
  http://wiki.esoui.com/Constant_Values : Done
  http://wiki.esoui.com/API : Done
  http://wiki.esoui.com/Events : Done
  http://wiki.esoui.com/Maps : Done
  http://wiki.esoui.com/Zones : Done
  http://wiki.esoui.com/Keeps : Done
  http://wiki.esoui.com/Sounds : Done
  http://wiki.esoui.com/Controls : Done - no changes
  http://wiki.esoui.com/Virtuals : TODO
  http://wiki.esoui.com/UI_XML : Done - no changes
  
  
  
• Devs guild on PTS
  
  First here, let's go. @ESOUI as you want. Give Guild invites permissions to members
  
  PLEASE ANNOUNCE IT ON GITTER : https://gitter.im/esoui/esoui
  
  Want to join ? @Ayantir on PTS or use Gitter
  
  

PTS should pop the 5 jan. for info
I'll try to update all the stuff, you can talk about improvments we could do..

If you plan to stop, leave a comment,
If you plan to start coding, CONSIDER TAKING OVER AN ADDON FIRST even by rewriting it entirely.

Probably a good place to ask: if an addon is no longer being worked on by the author but is otherwise completely functional and just needs the API version updated, how should I go about getting that handled?

It's MY answer, not the *official* one, there is no really official answer in fact.

@Cairenn / Dolby : feel free to edit my post.

bit earlier than planned

Attached is the updated documentation for PTS. You can ask any questions you have about the changes here. The summary notes have not been written yet. Are those useful to you guys or would you rather we address the changes in a Q+A format on this thread?

Thanks Chip!
Differences after first comparison are stored here: https://www.diffchecker.com/v4WyyUws

=================
Events - Added
=================


=================
Events - Removed
=================

=================
Events - Changed
=================


====================
functions - Added
====================



====================
functions - Removed (Including possible replacement functions)
====================



====================
functions - Changed
====================



=======
[Added]
=======



=======
REMOVED
=======

Thanks a lot for the early post. Really appreciate it :)
I usually read the summary notes once and then forget about them. Most info comes from the difference in the ESOUIDocumentation for me, so I am fine with discussing them here instead.

Thank you Chip!

A nice guy has scripted your whole doc and we're able to do some nice output now. So it should be okay. If the API Natch potes is delayed of 1 week and only in english, it won't be a drama.

:banana: Nice Guy! :banana:

Gonna guess these won't do much yet since there's no mention of adding the ability to convert to other styles besides Imperial in the patch notes. :(

That is correct.

The scroll control stack overflow is a known issue that will be fixed in the next PTS patch.

What about the API version? I noticed its still giving 100017 as the version number and none of my add-ons were marked as out of date.

This will also be updated in the next version.

Amazing changes, I love it.
I am looking forward to trying out
GetItemLinkRecipeCraftingSkillType()
PreviewCraftItem()

Odd how GetCraftingSkillName(craftingType) has come back
Which is more future proof, ZO_GetCraftingSkillName(craftingType) or GetCraftingSkillName(craftingType) ?

You can use either of them equally I'd say. I think we exposed it to unify the client and lua code for getting a tradeskill name.

Hi Chip,

IsSecureRenderModeEnabled() is not available (in opposite to the doc file) and IsInPreviewMode() is private.

Is this intended?

IsSecureRenderModeEnabled() is a function of the WINDOW_MANAGER. Someone just pointed my nose on it :D


@Chip About the preview functions:
It would be really great if you could remove them from "private".
Or is there a better way to check if someone is previewing his house etc.?

IsInPreviewMode
IsCurrentlyPreviewing
IsCurrentlyPreviewingCollectibleAsFurniture
IsCurrentlyPreviewingInventoryItemAsFurniture
IsCurrentlyPreviewingPlacedFurniture
CanSpinPreviewCharacter

We'll be removing private from these among others.

Ahjo, was late :D

@Chip: Ah, ok. Thanks.

BTW: Your addon compatibility aliases have a typo.
The others, too. It is GetPOIType. But on the other side, that way one realizes that a function is obsolete. It may a good idea to wait with releasing aliases and/or posting an obsolete warning at PTS.

Or maybe add a set of logging function that write directly to the interface log without impacting the game's performance too much.
LogError, LogWarning, LogInfo, LogDebug + SetLogLevel which defaults to LOG_LEVEL_WARNING on live and LOG_LEVEL_DEBUG on pts.

The log functions could also write which addon called them, at which time, and from which line e.g:
Maybe also add a function SetLogStack(level, boolean[, addonName]) which allows for requesting the stacktrace to be printed after every message and an optional boolean on the log methods themselves for triggering it for individual messages.

The alias functions could then all include a LogInfo("deprecated method, consider replacing it").

This could help a lot with debugging addons and also during development where putting a d() call into a loop can cause a client crash.

I just played around with the new housing APIs and so far I found that the placed furniture only returns a furnitureDataId to allow identifying items of the same type.
Maybe you could also return the itemLink from GetPlacedHousingFurnitureInfo or provide a method GetItemLinkFromFurnitureDataId? That way it would be easier possible to show which items are missing when trying to deserialize a serialized house, because the itemName won't work cross-language and searching all existing items for the right furnitureDataId is a bit of an overkill.

I also noticed that there is still no function to restore a stringified id64 into a proper id64. It shouldn't be necessary for this case, but it would still be nice to have in some other cases.

EDIT: after some more tinkering I found that furnitureDataId is not what I thought it was and multiple itemIds can have the same furnitureDataId. It also looks like there is more than one furniture item with the same name, which means there is currently no way to map furniture to an item based on the data returned from the housing API.

I managed to make it work somewhat.
But there are a few major drawbacks.

• I currently rely on SHARED_FURNITURE:GetPlaceableFurnitureCategoryTreeData():GetNumEntriesRecursive() and filter items by name in order to find what I need, but that means that it does not work across languages and it also requires that there is no search text placed in the housing editor (although I probably can clear that from code).
• It looks like some items do not return an itemName from GetPlacedHousingFurnitureInfo which makes it impossible to restore them with this method. (Haven't checked which items are affected yet)
• In order to find out which method I should use to place an item (HousingEditorRequestItemPlacement or HousingEditorRequestCollectiblePlacement) I use GetCollectibleInfo and check if the name is an empty string, but I am not confident that it is always correct. I believe if I get an itemLink it would be easy to determine by comparing the itemType.
• This method is slow and sends a lot of individual requests to the server. Maybe you could add a HousingEditorBeginItemPlacement, HousingEditorCommitItemPlacement and HousingEditorRollbackItemPlacement and in the same fashion a HousingEditorBeginItemRemoval, HousingEditorCommitItemRemoval and HousingEditorRollbackItemRemoval to collect these calls locally and then do a bulk update. For removal you could also just add a HousingEditorClearHouse method which removes everything.

I just tried to get the new trading house filters to work and found that some things just don't work (yet?).
First I tried to list some furniture and recipes in a guild store and use the vanilla interface. When searching for All items, the 3 furniture items and 6 recipes show up as expected, but when I select the new furnishings category and search for all furnishings / items and recipes I only see 2 recipes instead of the expected 9 items.
I then looked through other categories and noticed that the crafting category also has a new subcategory for furnishing formula which show the remaining 4 recipes, but the furniture items never showed besides in the main all items category.

Next I tried to add the filter to AwesomeGuildStore and found that there is a typo in the definition of ZO_TRADING_HOUSE_FILTER_FURNITURE_ITEM_TYPE_DATA in line 385 in tradinghouse_filter_shared.lua. The constant for SPECIALIZED_ITEMTYPE_RECIPE_BLACKSMITHING_FURNISHING_DIAGRAM should be SPECIALIZED_ITEMTYPE_RECIPE_BLACKSMITHING_DIAGRAM_FURNISHING instead.
When I use the ITEMTYPE_FURNISHING I can find all furnishing items as expected and the recipes also show in the category for recipes, but I cannot get the TRADING_HOUSE_FILTER_TYPE_SPECIALIZED_ITEM to work in order to split them up further.

From my standpoint it looks as if the trading house changes are not yet finished. :(

I also tried to figure out what I can do with the increased filter parameter limit and while 16 is already a good improvement, it is still too low. I need at least 20 parameters to be able to add an all category for all crafting materials. The issue where I cannot show shields in the all category for armor would also need a specialized item type for shields that is not linked with weapons and can be combined with the armor category.

Hey guys,

Does anyone have the style item index for all the new styles? I was looking here but I think people are still working on getting everything updated -> http://wiki.esoui.com/StyleItemIndex

Thanks!

I was playing around with the new Master Writs to see what local filters I can do for them in the guildstore and noticed that there is a crash bug. I won't post the details here (already sent a bug report ingame), but please fix that before it goes live.

I also thought a bit more about the housing export addon I am making and I think with the possibility to save furniture arrangements it is important that you tie GetNextPlacedHousingFurnitureId() into the housing permission system, otherwise some random visitor could copy my hard work and claim it as their own (exactly what I am doing right now with Solinur's work :D).
For example you could always return nil when the player does not have decorator permissions or is not the owner himself, that way the homeowner can decide who may copy his work. I think this is especially important when/if the housing leaderboard becomes available.

Look again. I just updated it.

The typos are now fixed. The other problems you are seeing are likely because many items haven't had their specialized item type set yet. Those should be complete shortly.

I'll increase the search term limits to 24 and we'll see how that plays. The shield problem will takes adding some new specialized item types which won't happen until the next major release.

Please provide an example of an item without a name when you find one.

As for the placement functions, those trigger an inventory operation and also broadcast a new piece of furniture to everyone when they are used. We have to be careful so that if an addon was made that moved or placed the full contents of the house very frequently it would not grind the servers to a halt. The current mechanism for this is using the message rate limits, but we could potentially build a more robust system for queuing these things in the future.

Are you aware that the Ebony motif items are showing as motif number 36 but that's also the same motif number as Dark brotherhood already uses?
Do you know what motif number Ebony is planned to be?

I've noticed that furnishings bought from the crown store have an item value of 0 while they're non-crown store counterparts have their full item value. It makes sense and all but the problem is that when you try to get the item's value via its item link, it returns the full item value regardless. This not only causes some issues with add-ons that view inventory via item links but it also causes the gamepad interface to list the wrong item value in the tooltips.

Looking forward to these changes! Thank you very much. :)

I went back to the same house on Sunday, but the items all showed their name then. Either it was just a display bug in my addon or it depended on some other condition besides the item itself. I'll keep an eye on it either way.

I don't know how your server handles these calls, but in other server based systems a bulk update usually has a performance advantage because of the reduced overhead. I'd think this holds especially true in a case where I would send 1000 individual requests to place all furniture or remove it. I don't expect that it will be added with this update, but I'd love to see an improved way to do this in the future.

p.s. please add a return value for itemLink to GetPlacedHousingFurnitureInfo, or add a method GetPlacedHousingFurnitureItemLink

This happens with every patch. We have to wait and see waht the new numbers are.

hey Chip! will you adress this guild sales history bug in this update?

http://www.esoui.com/forums/showthread.php?t=6695

Yes, it has been fixed.

I just finished the first version of SaveHouse. Unfortunately I could only test it partially, because in the current PTS version HousingEditorRequestItemPlacement produces a crash to desktop whenever I call it for any item in my inventory in any house. I really hope that you can fix that before Homestead goes live. :)

Skin Changer Motif Chapter Books broken
 

@Chip:
The IsItemLinkBookKnown function returns false on the skin changer motif chapter books. The PTS template knowns all styles. The full books are ok.
Two of them have typos in the german description.

item ids
[73855]
[73856]
[73857]
[73858]<-typo
[73859]
[73860]
[73861]
[73862]
[73863]
[73864]
[73865]<-typo
[73866]
[73867]
[73868]

And GetItemLinkItemType does not return 61=SPECIALIZED_ITEMTYPE_RACIAL_STYLE_MOTIF_CHAPTER for any chapter book (the second return value).
Is this correct?

While getting AGS ready for Homestead I noticed that the TRADING_HOUSE_FILTER_TYPE_FURNITURE_CATEGORY shows entries for mounts, pets and assistants in the vanilla interface. Seems a bit pointless, or do you plan to make them tradeable? :D

It also looks like the filter limit is still set to 8. Will the change make it in with the patch tomorrow?

And last but not least there is a typo in addoncompatibilityaliases.lua: GetItemLinkRankRequirement should actually be GetItemLinkRecipeRankRequirement. ;)

I also noticed IsItemLinkBookKnown() was broken on PTS for skin changer motif.

I tried GetItemLinkItemType() but never got it to return anything about motif chapters :(

I should add that I checked on PTS today (16th Jan) and now my live characters have been copied over the skin changer motif is behaving correctly.

This will be fixed on the fourth PTS update.

I just noticed that GetNumChampionXPInChampionPoint(champLevel) can only be called by players that are past level 50. Could this be changed?

What would be the usage ?.... I don't see any reason for this ?

All it does is grab the XP for a specific champion level so it should be a pretty lightweight function to allow. Due to the way champion levels rescale every update, there isn't a permanent XP amount from one CP to another. I was using it for calculating remaining XP until X CP, but it can only function for people that have already reached CP. So on my main, it works perfectly. On an alt at lv 44, it won't work at all.

but for people who ddn't reached level 50.. there's no need to know this, only xp required for next level.

The intent was for someone at level X (below 50) to be able to check how much XP until Y (the normal goal being CP160). I can still achieve this by having to build a table of 600+ CP levels, but it isn't ideal.

We can do this. I can't see any reason why an informational function should be restricted based on the level of the current character.

Thanks! I only figured it out once I was basically done with it, so now I don't have to do a tedious rewrite and manually update a table every update.

On a different note, maybe you could also take a look at GetCollectibleInfo and GetCollectibleName. For some reason they won't work with crownstore collectibles which have not been purchased yet. The only way to show their name to a player is to use a collectible link.

@Chip

will ZOS lock on gear prevent items from being picked for completing a master writ?

(case : i have to craft the same gear i'm using sometimes, i craft a C150 for the writ, is there a check on which one will be picked? the 150 or my functional 160?)

if yes, can we have this "writ lock check" as an API feature please? (for all writs and item types if possible)

if no, could you please look into it? I know the odds of it happening are very low, but not null.

I know writs won't take upgraded items and I'm pretty sure they don't take crafted set items. I'm not sure if they take traited items. You might want to try making a CP150 for a writ with a trait and see if it takes it. If it doesn't: I don't think there's an issue. If it does: there is a small one, but then I'd recommend immediately upgrading the quality (for your use) before turning writs in.

He's talking about master writs. In case you have to make something for a master writ that is identical to a piece of equipment that you have in your backbag and do actively use (just not right now), how will the game decide which one to pick? For example you have to make a golden cp160 twice born star helmet with divines trait. For the writ the style doesn't matter, but the one you use has yokudan style. Which one will be used for the master writ? Does locking the item work in that case?

Ah, my bad, he did say master writ.

I tested by myself, made a c150 and a c160 valid for the quest. Locked both with ESO Lock.

the c160 item had a slotIndex > than the c150 one.
and bye bye locked c160 gold eternal hunting well fitted gear


So all of the points have been overlooked for now.
i think i'm gonna avoid the gear master writs.


Also getting writs craftable only in DLC territories when not having the DLC is really not acceptable. And on live we got surveys like that too. but i wont mind trashing them if they are not tradable.

@sir : the style is requested by the writ. with makes the odds really lower, but still. It's overlooked. like the tripots.

They could at least make it so that bound equipment won't get taken for the master writs. Should at least solve the problem for equipment. As for potions, there was an addon a while ago which managed to swap them out before they got taken when you handed the quest in. Maybe that same technique could be used for the master writs too?

it would be hard to target the item because on the difference with the potions, when the deed is complete, there is no text in the general description of the writ anymore to know which item to save.

but you can make an addon that reallocate slotIndexes from the higher level gear to the lower level gear unconditionnally to protect your items though.

the idea is that the ****tiest item needs the higher slotIndex.
but that would be easier for everybody to have an API lock for writs with bagId,slotIndex usable on stacks of pots or anything... I'm thinking of itemsaver or FCO itemsaver too.

I'd prefer the game just to give us a seleciton popup for the master writs where you can choose which item will be taken.
Adding some protective functions via addons could be possible but you'd need to check so much stuff which could be avoided by the game "from the scratch"! So better build it right instead of having to rely on addons which have to be adapted after each patch again :(

@Chip
Please have a look at those master writs and try to come up with something that prevents destroying of the higher level equipment due to master writes (even if the item is unbound and a set part -> maybe one crafted a set part for a guild mate, improved it and then suddenly the next writ just will destroy it...).
Maybe a simple "ask dialog" will be enough?

Agreed for having the choice. Probably too complex to implement before Homestead release though.

btw I didnt equip the c160 item before talking to the npc when i tested, but anyway, I would want to be able to get rid of an old piece of armor i don't use anymore if it happens i have one that fits a writ.

but in the end, i expected the Build-in lock to actually lock stuff.
That would be intuitive, easy to use, to understand, non-intrusive, easy to implement and most of all expected by anyone.
Though you can't lock potions with it.
So while we're at it... if the check done for item Validity was to include the lock, it couldn't hurt to have the corresponding API for other things than gear.

just a thought.

Does this only refer to furniture related items or all types? I just ran a script to show me which SPECIALIZED_ITEMTYPES are actually in use and it looks like right now only SPECIALIZED_ITEMTYPE_RECIPE and SPECIALIZED_ITEMTYPE_TROPHY are ready. I planned to add new filters for drinks, food, provisioning ingredients, alchemy ingredients and siege items, but I guess they'll have to wait for now if you only plan to update them for furniture.

Just found a bug that is in the vein of locked issues: if you have two of the same item, one locked and one unlocked, they will both show up in the improvement tab.

I'll raise this concern today.