pre or post hook the "travel to player" in context menus

[sinnereso]

I think hooking the entire function is a little too much responsibility for me at this time. I'm gonna look at hooking the travel to player in friends list and guild list context menus I think instead so the jumpto functions work as normal and make sense to me. I'm not sure whos doing more loops the code or me here with this previous idea =p

[sinnereso]

I've decided to go the route of pre-hooking the "Travel to Player" context menu item in guild, friend and group lists and executing my code instead if my addon is installed and running. This will leave the original JumpToPlayer() functions intact for other addons to use.

I go crazy with zgoo and mertorch trying to find the objects etc. Its keeps coming up as ZO_MenuItem3 in a toplevel control of ZO_Menus but I cant seem to get a prehook using them in many different ways to even suggest its doing anything at all to the context menu item.. Any suggestions on this?

[Baertram]

ZO_Menu is the context menu TLC and ZO_MenuItemn is 1 item in the context menu.
It's correct that you see those.

But also here applies: This is reused in MANY other vanilla code and addons so do not change ZO_MenuItem etc. !as this is rebuild each time! you right click any control and ShowMenu(control) is called!

You need to find the correct "build of those context menus, before ShowMenu is called, for the guild, friend lists and change the code there. If you change it at ZO_Menu (which you won't be able to do as the context menu was build already and the callback functions that are called as you click on one ZO_MenuItem is already there) you most probably get into similar trouble as before AND will break even more addons

So what you need to do is reverse engineering as described in one of my other posts.
Use ZGOO or merTorchbug to get the control below the mouse before the context menu opens.
This will be a ZO_FriendsListRow1 or whatever then
Search for that control's parent e.g. ZO_FreindsList
Then check where in teh vanilla code the AddMenuItem or ShowMenu functions are used and read the code how the lines for the context menu are build there.
You will find a function that you need to overwritte or change then AND it must bea global function, no local (as you cannot access those).

ZO_KeyboardFriendsListManager:FriendsListRow_OnMouseUp(control, button, upInside)
https://github.com/esoui/esoui/blob/...board.lua#L215
-> ZO_KeyboardFriendsListManager is the class, you need to hook into the global object which get's greated via <object> = <className>:New(...)
-> https://github.com/esoui/esoui/blob/...board.lua#L357
-> Object is FRIENDS_LIST

But ZOs also provides a globally acessible function returning that object'S function for you already, which you can easily PreHook and change the context menu accordingly to your needs:
https://github.com/esoui/esoui/blob/...board.lua#L278
ZO_FriendsListRow_OnMouseUp(control, button, upInside)

BUT AGAIN: If you prehook and return true to hide the original context menu etc. you will maybe destroy other addons or even vanilla code.
You would have to rebuild ALL code from function ZO_KeyboardFriendsListManager:FriendsListRow_OnMouseUp(control, button, upInside) and just replace the context menu entry for "Jump to friend" with yours! So you cannot simply "just replace 1 entry" in there. You need to redefine that function basically....

So do this with care and MUCH testing (this would also be a relief for us who need to check your files and update them every day several times I recommand to change your code and TEST it for a few days before updating the addon each time... Thank you).



Most of the lists like friends list etc. are also suported by LibcustomMenu afaik so instead of altering the original menu entry and trying to overwrite or change it, maybe just try to add a new entry which teleports AND runs your code then? And keep the existing entry where it is?

[sinnereso]

I appreciate all the help and sorry for all the updates. I'm new at this and have been working on it nearly steady for 3months.

My goal with this was to improve the user experience by harnessing the jumpto's so the user's chosen teleport effects etc would be fired everywhere but that proved difficult with the jumpto loops. So I thought maybe the group, friends and guild lists might be safer leaving the jumpto function intact and loopless but this seems risky too.

My issue is for this to work I NEED to completely control the jumpto function and delay it varied amounts. I think you've convinced me this is far more of a big deal than I anticipated and I'll likely just bail on the whole idea. At least for now.

[Baertram]

As I said, you might leave the original jumpto as it is and just add other context menu entries, "custom ones", below the existing ones, which call your code then, making the jump delayed by calling the API function delayed, etc.

This way you would at least be able to test if everything that you had in mind is even possible and works, before hooking into/replacing/manipulating the code of the API functions itsself.

[sinnereso]

Im trying as you suggest registering it EARLY which may suffice. got all three group guild and friends lists working smoothly so far with just a jumpto and no effect/queue yet but thats nearly a copy/past over and that will work too.