Thread Tools Display Modes
04/22/23, 07:34 AM   #1
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
Question pre or post hook the "travel to player" in context menus

I'd be interested in hooking into the default in-game "travel to player" context menu items in guilds, friends and groups to have them perform my code instead. Mainly just to perform the effect etc before doing it so the game feels more seamless. I have 90% of the code already inplace to handle it anyway with some minor tweaks. The benefits would be the teleport effects and queue when/if still in combat etc which are used by my addon keybinds etc for many functions..

Is this something safe to do without breaking other addons? And does anyone happen to know what I would hook for those? I have trouble with zgoo finding these things. All I see are names like "ZO_MenuItem3" etc but I'm not comfortable assuming its always menuitem3 and not 4 if another addon lists above it etc.

Im thinking this will be a prehook if I'm understanding how these work a bit.

Last edited by sinnereso : 04/22/23 at 09:41 AM.
  Reply With Quote
04/22/23, 11:27 AM   #2
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
Been experimenting and have managed to somewhat get the flow im looking for with:

Code:
ZO_PreHook("JumpToFriend", function()
		MyAddon.TravelToPlayer()
		return true
	end)

function MyAddon.TravelToPlayer(displayName)
	if displayName ~= nil then
		--JumpToGroupMember(displayName)
		JumpToFriend(displayName)
		--JumpToGuildMember(displayName)
		return
	end
Its obviously not able to retrieve the friends list rowdata and displayname as im unable to figure out how to access that still but workin on it.

Ideally I'll be able to prehook the jumptogroup/friend/guildmember functions themselves which makes this fairly simple but I have a feeling I wont be able to harness the list data and displaynames that way to make it work. I am open to ideas though of course

Last edited by sinnereso : 04/22/23 at 11:36 AM.
  Reply With Quote
04/23/23, 05:11 AM   #3
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,913
If you do this you most probably make other addon hooks fail to work
Lua Code:
  1. ZO_PreHook("JumpToFriend", function()
  2.         MyAddon.TravelToPlayer()
  3.         return true
  4.     end)

return true makes the original functions top working, never called!
So any other hooks which have been applied after your addon will never be called -> broken
I would not do that. If you want your addon do some early animation then prehook, do your animation stuff and let the original function be called afterwards (no return true!).
  Reply With Quote
04/23/23, 07:25 AM   #4
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
I realize there is a possibility of affecting other addons with something like this so Ive been running it through my head the possible scenarios where an addon might need to perform something after a "jumpto" and the only scenario I can come up with is an "arrival something" because you can't do anything other than output messages or crunch data while teleporting.

So that leaves me with the possibility of affecting other teleport addons. Which is a concern for me but so far I've yet to see any evidence of any of them doing anything after the teleport.

So the way I see it theres 99% chance this is ok since they wont execute my code untill theyres were ready to execute a teleport. And if anything MINE might be affected if they used effects like beammeup which would cuase my code already inplace to detect that and skip right to the teleport anyway. Mine is already designed specifically to deal with just an @NAME to determine if they're group, friend or guildy and execute the appropriate function and skip effects if they've already been used.

mine will be performing 3 things when any player or addon executes a teleport...
1. checks for combat and queues it up untill that ends
2. checks for momento is unlocked and able to be used "this would return not able if beameup fired its linvers trinket for example and skip directly to the jumpto".
3. jumpto

ok now I see where there might be an issue... the jumpto WHO???. Which actually brings me back to the same question. can i harness the original addon or players jumpto(@NAME) that triggered the prehook to pass the @NAME through? Because then I can handle that as well with code already in place todo so.

I think with minimal tweaks to can use that to determine if it was jumptofriend guildy or groupmember and pass it right through and do it.

Can you think of anything that might actually break if done this way? I'm happy to make sure to the best of our ability that it handles just about any scenario from any addon approprately and seamlessly. My intention is just a seamless experience for the end user nomatter how they initiate a jumpto. With this setup beammeup for example would still be able select its teleport target as normal, fire its linvers trinket effect as normal and then hit the jumptotarget which would pass to mine and skip my effects because momento use wouldnt be allowed for sometime and skip right to the jumptotarget. I'd just need to know who the target was from theyre jumptotarget or the users right click "travel to.." from context menus to make it all seamless.

Would something like this grab the @NAME with the "targetName" variable and pass it through to my code?:

Code:
ZO_PreHook("JumpToFriend(targetName)", function()
        MyAddon.TravelToPlayer(targetName)
        return true
    end)
Im still exploring ideas here. The only issue I can think of so far left is combat. Mine is designed to handle being in combat, if lets say beammeup etc isnt then they would fire theyre effect and then get stopped and queud in my code untill combat ends and then likly fire my effect and teleport. If they ARE designed to handle combat then they should have never made it to the jumptotarget anyway and handled that appropriatly beforehand which would be perfectly fine.

so worst case I can see is a EFFECT - COMBATQUEUE - EFFECT - TELEPORT scenario. best case is seamlessness and noone notices anything unusual. It may be an issue others are already hooking the jumpto's which would be unfortunate if I had to bail on the idea as Id like to position mine as more of a neutral enhancement to all them and a seamlessness for end user. I dont want to and never intended to be a mass teleport addon, just an event or questing "get back to local shrine quick" or directly to 1 specific person. But I do have the code inplace to handle and determine who is where.

Last edited by sinnereso : 04/23/23 at 08:12 AM.
  Reply With Quote
04/23/23, 08:06 AM   #5
ExoY
 
ExoY's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2020
Posts: 87
Please read Beatrams comment more carefully.....

the important part is: dont return true!
  Reply With Quote
04/23/23, 08:18 AM   #6
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
OH! yeh i did read that but didnt see the bigger picture with it. OK let me experiment with that and see how it works out.. in the meantime I Could really use some help with the @name from the context menu "travel to.." which was sort of the original question.

Is there a way with that prehook I can get the @NAME from the selected user or am I going to need an additional posthook on mouseup? The timing of these in my head gets sketchy. Id still need to get the @NAME for my code to know wtf is going on and handle it accordingly.

Last edited by sinnereso : 04/23/23 at 08:33 AM.
  Reply With Quote
04/23/23, 09:36 AM   #7
Valve
 
Valve's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2017
Posts: 23
Originally Posted by sinnereso View Post
Is there a way with that prehook I can get the @NAME from the selected user or am I going to need an additional posthook on mouseup? The timing of these in my head gets sketchy. Id still need to get the @NAME for my code to know wtf is going on and handle it accordingly.
Code:
ZO_PreHook("JumpToFriend", function(displayName)
	d(displayName)
end)
You get the variable passed through as part of the hook.

So, if you had the above exactly as I've shown and were to travel to me, you would see in chat "@Valve" and the travel-to-player action would go through.

Do whatever you want with the name and that's it. Don't return true or you'll block the original JumpToFriend function from running.

Last edited by Valve : 04/23/23 at 09:42 AM.
  Reply With Quote
04/23/23, 10:35 AM   #8
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
ok perfect thats exactly what I was looking for thank you
  Reply With Quote
04/23/23, 11:10 AM   #9
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
OK return false might not work. Ill need to halt the execution of the original "jumpto.." code by a delay required by the individual effect which i cant or dont know how todo without using:

Code:
zo_callLater(function() JumpToFriend(friendName) end, effectDelay)
Otherwise im nearly complete the code tweaks to try it.

with return false.. if i execute the effects the original code will fire the teleport after right away and in most cases wont be able to as the momento is likely still in progress.

is it possible to:

Code:
ZO_PreHook("JumpToFriend", function(displayName)
		MyAddon.TravelToPlayerContext(displayName)
		zo_callLater(function() return false end, effectDelay)
	end)
this might make it doable.

*EDIT
Doesnt appear to delay the return. I guess Ill just bail on the idea.. It woulda been cool but without a Lib or something controlling the original function with some delay options fairly between addons I dont think its going to work.

Last edited by sinnereso : 04/23/23 at 11:58 AM.
  Reply With Quote
04/24/23, 07:49 AM   #10
Valve
 
Valve's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2017
Posts: 23
Originally Posted by sinnereso View Post
OK return false might not work. Ill need to halt the execution of the original "jumpto.." code by a delay required by the individual effect which i cant or dont know how todo without using:

Code:
zo_callLater(function() JumpToFriend(friendName) end, effectDelay)
*EDIT
Doesnt appear to delay the return. I guess Ill just bail on the idea.. It woulda been cool but without a Lib or something controlling the original function with some delay options fairly between addons I dont think its going to work.
You should still be able to do this if you're willing to halt the initial execution by returning true. You can then use a variable to keep track of whether you want to halt the subsequent "JumpToFriend" execution.

First time it executes, you can return true, trigger the memento and use your `zo_callLater` to execute it again after the memento has finished.

Code:
local shouldHaltExecution = true;

local function DoStuff(name)
	d("DoStuff")
	shouldHaltExecution = false
	JumpToFriend(name)
end

ZO_PreHook("JumpToFriend", function(name)
	d(name)
	if shouldHaltExecution then
		zo_callLater(function() DoStuff(name) end, 5000)
		return true
	else
		shouldHaltExecution = true
	end
end)
Calling "JumpToFriend" yourself will trigger the prehook again so be careful with recursion if you're doing this. You'd also be blocking the initial JumpToFriend which seems to be requried for your memento logic.

Last edited by Valve : 04/24/23 at 07:55 AM.
  Reply With Quote
04/24/23, 08:22 AM   #11
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,913
Also keep in mind that JumpToFriend could be used by ANY addon without the context menus or UI elements you know!
It also trigges if you just do /script JumpToFriend(@TestAccount) in your chat!

So if you want to do something delayed etc. based on entries at the vanilla UI context menus, hook into the context menus and not the final API function that some other addons might use too.

I'm still not sure WHAT EXACTLY you try to achieve here and why, and when? You mentioned a "visual" thing? Is something shown visually too early or too late? And what?


Lua Code:
  1. ZO_PreHook("JumpToFriend", function(displayName)
  2.         MyAddon.TravelToPlayerContext(displayName)
  3.         zo_callLater(function() return false end, effectDelay)
  4.     end)

This will call JumpToFriend and execute the code normal,
call your function MyAddon.TravelToPlayerContext(displayName) (whatever it does. If this calls JumpToFriend you got an endless loop now! :-) ).
including the jump start to your friend at the end of that function call to JumpToFriend.

After that it will return a false which never is passed to the prehook of JumpToFriend as you have called it with zo_callLater in that "closure" of zo_callLater(function() ... end. So the return false will be passed to the PreHook of JumpToFriend but not from that back to the calling code where it would be needed.
But as a return false or nil is not needed at all in a ZO_PreHook it will just do the same as a normal JumpToFriend would do: Jmp to the displayname! Without delay! Normal!

What you thought off was this maybe:

Lua Code:
  1. local preventEndlessLoop = false
  2. ZO_PreHook("JumpToFriend", function(displayName)
  3.     if preventEndlessLoop then return true end --check for endless loop protection as this is called from JumpToFriend ZO_PreHook, and abort here with true -> Abort JumpToFriend
  4.     MyAddon.TravelToPlayerContext(displayName) --call your visual stuff here
  5.     zo_callLater(function()
  6.         preventEndlessLoop = true   --prevent an endless loop as we call JumpToFriend from JumpToFriend ...
  7.         jumpToFriend(displayName)
  8.         preventEndlessLoop = false  -end prevent an endless loop as we call JumpToFriend from JumpToFriend ...
  9.     end, effectDelay) --delay the call to JumpToFriend a bit
  10.     return true --prevent original JumpToFriend
  11.  end)

Still, you got the problemw ith return true here, maybe breaking other addons, maybe not.
I'd rather check if you could skip and PreHook here and achieve whatever you want by other means.

Last edited by Baertram : 04/24/23 at 08:32 AM.
  Reply With Quote
04/24/23, 01:15 PM   #12
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
thank you both for the examples. I halted production on this plan for the moment until i understand it better but will stare at this off and on until I do.

Beartram.. I was simply hoping to hook into every possible way to jumpto to perform the desired effects the user has chosen and is already using in my addon. Which is simply executing a momento and halting the jumpto varying delays based on the momento used. with a return true it worked perfectly but Id also be left responsible for handling any and all jumpto's for any addon as well. In theory that might actually be doable if done right, so they pass right through to the jumpto while only my addon does the extra stuff. This is a primary feature of mine and isnt designed to be turned off so I bailed on it for now but will continue researching.

I halted on it because its really not a critical feature, its more cosmetic doing the effects on jumpto's from guild, group and friends lists mainly and of course the combat queue as well if stuck in combat and executing it when combat ends..

I'm still very new at this so positioning myself into a major library handling other addons teleports etc is not where I want to be. I think I'd rather stay in my corner for now

Last edited by sinnereso : 04/24/23 at 01:25 PM.
  Reply With Quote
04/24/23, 01:47 PM   #13
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,913
As long as you do the JumpTo in the end somehow, with your addon active, it's a choice of the player.
If he activates your memento feature, and obviously your addon :-), it should be okay.
Just tell them in teh description you do that and it might cause problems.
And effectively do the JumpTo then as normal addons would do (just delayed as you said).

If you eperience problems with other addons you could try apply your hook after other addons hooked the same function by using the
## OptionalDependsOn: <otherAddonName>
tag in your txt file.
That will make the oher addons EVENT_ADD_ON_LOADED event fire before yours, and if they did their hooks in there apply them before yours.

It's a bit problematic as you need to know the other addon names, and you need to see where they apply their hooks. They could do it at EVENT_PLAYER_ACTIVATED too, or somewhere else.
But at least it would make their hooks register and fire before your code then, in theory. So if JumpToPlayer is called their code is called first, afterwards yours (as I said: In theory!).

Last edited by Baertram : 04/24/23 at 03:20 PM.
  Reply With Quote
04/24/23, 02:38 PM   #14
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
oh yeh the jumpto is the last function... it checks for combat and waits.. then executes momento if one is enabled or doesn't if not and then jumpto after varied delay based on momento chosen or instantly if effects disabled.

I guess my concern is other addons jumping to specified targets.. the guild/friends lists is no problem but I have to manage to make sure the jump is to they're intended target. Id basically be a middleman for the jumpto for anything attempting to and applying effects if enabled and ABLE to provided the original addon(beammeup fore example) didnt do one alrdy which is fine as i check fi one can be cast and if not just skips to jumpto.

Ill explore the possibilities more and see what I can come up with.

What I want ideally happening is completely not interfering with beammeup, teleport etc and allowing them to perform as normal with theyre effects etc for theyre functions while adding my own spice to my functions and guild/friend/group menu's or any addon just using plain old fashioned jumpto.

Hooking the jumpto i realize is a powerful risky maneuver affecting ANY jumpto's but its also the simplest to deal with as they only accept specific input which I'm already prepared to deal with so it sort of makes sense to me. But maybe I should be looking at hooking the context menu's instead of the jumpto functions which would avoid all this. Its more complicated though having to actually close the friends list 1st etc because u cant use a momento with them open. stuff like that.

Last edited by sinnereso : 04/24/23 at 03:12 PM.
  Reply With Quote
04/25/23, 08:46 AM   #15
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
ok ive got a nearly working setup here but hitting a snag on the loop.. because of the delay i need to delay the stoploop as well.

Ideally something like this that works would be perfect:

Code:
if MyAddon.travelLoop == false then zo_callLater(function() JumpToGuildMember(displayName), MyAddon.travelLoop = true end, effectDelay) end

I need to get the "MyAddon.travelLoop = true" to fight like instantly after the jumpto like it would in code. Not before and not long after. I supposed I could do another ZO_CallLater for it but would rather not if possible.

**EDIT
Nevermind I see how you did it in your example without the comma.
I think now only issue is passing through the "displayName" through this event"

Code:
EVENT_MANAGER:RegisterForEvent("MyAddon", EVENT_PLAYER_COMBAT_STATE, MyAddon.TeleportPassthroughQueue)
So that when the event fires it passes the original "displayName" used throughout the rest of the function. Then shes ready for serious testing.

Last edited by sinnereso : 04/25/23 at 09:13 AM.
  Reply With Quote
04/25/23, 09:15 AM   #16
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,913
Lua Code:
  1. if MyAddon.travelLoop == false then
  2.    MyAddon.travelLoop = true
  3.    zo_callLater(function()
  4.       MyAddon.travelLoop = true
  5.       JumpToGuildMember(displayName)
  6.       MyAddon.travelLoop = false
  7.    end, effectDelay)
  8. end

Like this?
Will call the zo_callLater only if travelLoop is false.
As the 1st call set's it true BEFORE the zo_callLater AND within before the jump,
and then does the zo_calllater where travelLoop gets reset to false again after the JumpToGuildMember is executed again, you should not have any double attempts that way?
You'd have to test this.

Your call to JumpToGuildMember would start the same code again, where it checks if MyAddon.travelLoop == false -> MyAddon.travelLoop = true
directly before the jump again so it should be always true there if the check is done,
until after the call of JumpToGuildMember where it getsr eset to false
  Reply With Quote
04/25/23, 09:31 AM   #17
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
Yeh I think i got that part working ok now...

Where im hitting the snag is the event combat state for the incombat queue for the teleport...

once combat ends its going bonkers and the only issue I can see is the possibility of the displayName variable not being held and passed again to the event_combat_state function once it fires.

and it really doesnt like this:

Code:
EVENT_MANAGER:RegisterForEvent("MyAddon", EVENT_PLAYER_COMBAT_STATE, MyAddon.TeleportPassthroughQueue(displayName))
i realize thats probably not enough context for you... Im trying a few more things here and if they dont work ill go into more detail.

**EDIT
It seems to be running the code as expected except its not delaying the actual jumpto if i return false on the prehook. and if i return true it doesn't jumpto at all, just does the effect and stops.

its the delay i need applied to the actual jumpto not the effects.. Seems no matter which way I do this I cant delay the jumpto with the hook.

Last edited by sinnereso : 04/25/23 at 12:23 PM.
  Reply With Quote
04/25/23, 12:28 PM   #18
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,913
I answered that already in one of your past question post:
Code:
EVENT_MANAGER:RegisterForEvent("MyAddon", EVENT_PLAYER_COMBAT_STATE, MyAddon.TeleportPassthroughQueue(displayName))
Wrong function call to MyAddon.TeleportPassthroughQueue(displayName) as this is executed directly as the code is parsed and not as the event fires!
You need to create an anonymous function around it!

Code:
EVENT_MANAGER:RegisterForEvent("MyAddon", EVENT_PLAYER_COMBAT_STATE, function(eventId, param1OfEventPlayerCombatState)
   MyAddon.TeleportPassthroughQueue(displayName)
end)


And btw:Where should the event know the displayName from? You need to pass in the correct displayName as the event itsself does not have any displayname, and if it would not be the account name of someone to jump to.

Last edited by Baertram : 04/25/23 at 12:30 PM.
  Reply With Quote
04/25/23, 01:37 PM   #19
sinnereso
AddOn Author - Click to view addons
Join Date: Oct 2022
Posts: 244
I agree and think thats where my issue is with the displayName not passing through the event. Well that AND the jumpto firing instantly premature from the original code.

im still messing with it
  Reply With Quote
04/25/23, 02:08 PM   #20
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,913
AND the jumpto firing instantly premature from the original code.
Did you read my last post's 1st part about the anonymous function needed around your function call? This should remove your premature called code issue then, if there isn't another somewhere.

Always hard to guess things, would be easier (as said sometime before) if you post your whole code, all files (1 zip) here. You can attach that to your posts afaik, if you scroll down there should be an attachment button/section. That way we can see what your code atm looks like and what could be wrong.

Add comments in the code to show where the problem occurs, e.g error message or where you know the code runs through, or not.
  Reply With Quote

ESOUI » Developer Discussions » Lua/XML Help » pre or post hook the "travel to player" in context menus

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off