We are seeing a few reports that some people experience the issue with the vehicle pods on the Antoran High Command once more. The weird part is that the ElvUI team is unable to reproduce the issue.

One user provided info that disabling all addons except ElvUI worked for him, but after he re-enabled all his addons again it was still working correctly. To me this sounds like that it may not be an addon issue, but rather something that might get fixed with a /reload or a relog.

Do you guys have any thoughts about whether the currently implemented workaround in oUF might fail to register correctly upon entering the raid instance? That's the only thing I can think of that might be the cause, and would also explain why a /reload would fix it.

Edit: The ElvUI ticket for reference: https://git.tukui.org/elvui/elvui/issues/279

It is possible that you get "UI action blocked". It can turn the related addon unusable until /reload.
If that it true a taintlog can give you some hints.

We haven't had any reports where people mentioned errors or messages like that of any kind. ElvUI itself continues to function correctly as well, except that the vehicle workaround for that raid instance doesn't seem to take effect.

I have no time to look into this issue now, I'm a bit busy w/ my own addon and it's already late T_T But I want to rewrite my old hack since Blizz implemented proper API.

Do you guys have any thoughts about whether the currently implemented workaround in oUF might fail to register correctly upon entering the raid instance?

It should work fine, well, it used to work fine, it's handled by this block. One possible explanation might be that your user was stuck in combat for quite some time, so proper attribute values weren't set, but that's just my speculation. I wonder if we could use PEW w/o InCombatLockdown checks to avoid such scenarios, but it's hard to test because it's hard to get stuck in combat on purpose 😁🔫

-- edit

I'll look into it tomorrow, it's almost night here, so good night 😴:zzz:

Appreciate the insight and your work @ls-

Thank you.

@ls- Thx for your "improved" hack :P I'll port it into ElvUI. We will need to test it from our users who have this issue.

Thanks @ls- , much appreciated.

Haven't tested proper fixing yet, but I found a bug in our current implementation: it can actually "unhack" itself because we don't check map ID in that case T_T

PEW w/o combat checks works as well, I'll post a patch diff in this discussion a bit later, after I test it a bit more. Won't PR anything just yet because I want to see if it's possible to remove this hack entirely and use proper API...

diff --git a/ouf.lua b/ouf.lua
index 0856010..4aaa223 100644
--- a/ouf.lua
+++ b/ouf.lua
@@ -665,19 +665,11 @@ do
 	end
 
 	local eventHandler = CreateFrame('Frame')
-	eventHandler:RegisterEvent('PLAYER_LOGIN')
 	eventHandler:RegisterEvent('ZONE_CHANGED_NEW_AREA')
+	eventHandler:RegisterEvent('PLAYER_ENTERING_WORLD')
 	eventHandler:RegisterEvent('PLAYER_REGEN_ENABLED')
 	eventHandler:SetScript('OnEvent', function(_, event)
-		if(event == 'PLAYER_LOGIN') then
-			local _, _, _, _, _, _, _, id = GetInstanceInfo()
-			if(id == 1712) then
-				initialConfigFunction = initialConfigFunctionTemp:format(0)
-
-				-- This is here for layouts that don't use oUF:Factory
-				toggleHeaders(false)
-			end
-		elseif(event == 'ZONE_CHANGED_NEW_AREA') then
+		if(event == 'ZONE_CHANGED_NEW_AREA') then
 			local _, _, _, _, _, _, _, id = GetInstanceInfo()
 			if(id == 1712 and not isHacked) then
 				initialConfigFunction = initialConfigFunctionTemp:format(0)
@@ -687,7 +679,7 @@ do
 				else
 					shouldHack = true
 				end
-			elseif(isHacked) then
+			elseif(id ~= 1712 and isHacked) then
 				initialConfigFunction = initialConfigFunctionTemp:format(1)
 
 				if(not InCombatLockdown()) then
@@ -696,6 +688,17 @@ do
 					shouldHack = false
 				end
 			end
+		elseif(event == 'PLAYER_ENTERING_WORLD') then
+			local _, _, _, _, _, _, _, id = GetInstanceInfo()
+			if(id == 1712 and not isHacked) then
+				initialConfigFunction = initialConfigFunctionTemp:format(0)
+
+				toggleHeaders(false)
+			elseif(id ~= 1712 and isHacked) then
+				initialConfigFunction = initialConfigFunctionTemp:format(1)
+
+				toggleHeaders(true)
+			end
 		elseif(event == 'PLAYER_REGEN_ENABLED') then
 			if(isHacked and shouldHack == false) then
 				toggleHeaders(true)

@Blazeflack, @Merathilis here's my improved hack, feel free to test :p Removed PL because now it uses PEW instead, added instance map ID checks to avoid "unhacking"...

So far it looks like that we're stuck w/ this hack.

Although Blizz added UnitTargetsVehicleInRaidUI to secenv, they still need to tweak their SecureButton_GetModifiedUnit func because it's the one that determines what unit is used for secure actions, for instance, clicks, atm it only takes UnitHasVehicleUI into account.

I'll talk to our fav Blizz dev about it tomorrow when he's at work T_T

@ls- We pushed a release containing your improved workaround, and so far the responses show that this fixed the issue.

Cool, but let's wait until after the reset, this way more people will do the encounter w/ the fix.

Welp, according to our fav Blizz dev, SecureButton_GetModifiedUnit will be fixed in 8.x, hopefully 🎉

That's pretty much what I expected.

Well luckily we got the workaround from you until then.