[sinnereso]

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?:

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.