Go to non-primary residence?
 

Hey there,
I've wondered whether there's a way to travel to a player's non-primary residence.
My use case, as always:
My husband and I have two couples in RP, one house is on his account, one on mine. However, due to the fact that I'm GM, I'm also hosting our guild residence, which is for that reason the primary residence.
This is resulting in my husband not being able to get to the house his character shares with mine unless I am there first for him to travel on me.

Is there a way, or if not, could you implement one, Chip? I'd love to have either a secondary residence, or just

Thanks! awesome work!

So I don't know if this is a bug or just a bad decision on how to categorize data, but..

I am the author of SmarterAutoLoot which allows you to auto loot with defined filters, so you only get items you want rather than filling your bag with everything. For Homestead I am trying to update my AddOn to allow filtering furniture crafting materials.

At first I assumed that either 1) They would simply fall under the existing ITEMTYPE filters for the appropriate craft skills such as Blacksmith or Woodworker, or 2) There would be a new ITEMTYPE for them.

Truth is neither, they are actually marked as ITEMTYPE_INGREDIENT which is the same ITEMTYPE used for cooking ingredients and spices. I found this very annoying as one of the main reasons I even wrote SmarterAutoLoot in the first place was to let me filter out ingredients!

So I kept digging trying to find a way to differentiate these from cooking ingredients. I stumbled across a function GetItemLinkRecipeCraftingSkillType(link) which sounded like my savior. If I can check that and it returns that the ingredient is actually used for say Woodworking then I can probably safely assume it is for furniture crafting.

But in my tests so far, these all return CRAFTING_TYPE_INVALID!

EDIT: Hmm... I think the bug might be on my side. Even normal ingredients for cooking are showing as CRAFTING_TYPE_INVALID.

I am getting it this way:

Here's why they are all prov ingredients:
As for why your code isn't working: not sure. Based on the API (and me not being home to test it): it looks like it should be straightforward.

Yeah I can't find any bug in my code. Every item just returns as CRAFTING_TYPE_INVALID. The only option I can see is maybe it doesn't actually take a link string despite it saying it does? I printed out my link in debug just to verify it, and it is correct.

Wait a minute...I bet that only works on recipes, not ingredients? Unless someone else proposes something clever: There aren't (currently) many things in this special non-category so I would filter them by ID. Check if ingredient, then check if it matches the handful of furnishing ingredient IDs.

Yeah there is a facepalm moment. Did I see one that worked for ingredients and just get my wires crossed? Have to look again.

Are their not tiers for these furniture materials? If they are all the same then yeah that might be easy.

So far, there's just one for each skill. Mundane rune is the only enchanting one I'm aware of, for example.

A low level pretended to be tank to get into a dungeon (after he got into the dungeon, he removed the role). This is nonsense so I left the group. I had the customary penalty time and once it expired (a little extra time passed before I actually checked), I had this message:

.

That is absurd and excessive punishment.

Another queue issue: complete a dungeon, "activity complete." Good. Now queue again, it'll find people, form group and...nope, no one gets teled to dungeon. You have to do it manually.

Another queue issue: after getting in (while standing in an overland area), it decided we weren't in the correct instance, kicked us from the dungeon and then did not move us into a new one.

To assist with the need for a secure PostHook function and the continued lack of an official one, I figured out a bit of a hack to pull it off.

This uses the existing ZO_PreHook function and injects a zo_callLater to call the code you want to be executed after the hooked function 10 ms later. From my testing, just about any function you'd want to hook into would be done by that point and its still short enough of a time that the user won't notice. I've tested it fairly extensively with a personal add-on of mine that hooks into the inventory lists with it and haven't run into any problems with it thus far.

You don't have to worry about calling it too soon with zo_callLater.
Lua is singlethreaded and there are no interrups, which means the function you call later will always run after the current call stack finished executing.
The only problem I see compared to a real post hook is that you cannot guarantee that no other functions run in the meantime.

Another queue issue: After completing the dungeon, I left the group, was removed from the dungeon. Then I everyone in the group was pulled back into the group and instantly thrown into a new instance of the dungeon. When we left, we received the customary 15 minute penalty for leaving.

I've added http://wiki.esoui.com/Houses to the wiki and on its main page.

This is doable. We'd like to have some way to expose this as part of the stock UI, but at the very least we can add a new function that takes the player name and the house id.

I love you.

I suppose that giving another player co-ownership is something that's more difficult? For shared houses and stuff. :)

Edit: While I am at it - I am finding ON_ACTION_LAYER_PUSHED a little aggressive. I cancel a trade when I switch cursor mode. Any chance of taking care of that, too, while you are at it? :)

Thanks for all you do.

Yes, that would be a substantial system change.

Another queue issue: stuck in "forming group" stage. I can't leave the queue.

Would it be possible to let a decorator retrieve and place items that are not bound? It would make everyone's life easier. :)

Another queue issue: after getting into a group, it told me the group wasn't viable. It did not remove me from the group and we completed the dungeon without an issue. Instead, it merely kept asking me if I was ready to join the group...the entire dungeon. I had to logoff to resolve it.

Or even another level of decorator permissions. That way, there's still a 'safer' option for people to choose.