Can no longer receive runspeed data in combat

[gythwulf]

It looks like Blizzard decided in their infinite wisdom that runspeed should not be something the players can see while in combat... So now it just throws numerous errors while in combat.

[gythwulf]

I added this to the top of UpdateRunSpeed, though perhaps it should go somewhere else (I basically am ignoring classic since I don't play it):

if UnitAffectingCombat("player") then
	brsRunSpeed.value = "n/a"
	brsRunSpeed.text = "n/a"
	return
end

[KyrosKrane]

Thanks for the heads up. I'll try to get this in the next day or so. I assume this just started with today's patch?

[gythwulf]

Yeah, it started with today's patch.

[gythwulf]

My "fix" didn't seem to fix it entirely, as I still sometimes get errors about the UnitSpeed being a secret value. Not sure why my check isn't always working.

[aa-chrismcfadyen]

To calculate run speed as a % you can use CurveUtil like so:

local speedCurve = C_CurveUtil.CreateCurve();
speedCurve:SetType(Enum.LuaCurveType.Linear);
speedCurve:AddPoint(0.0, 0);
speedCurve:AddPoint(105.0, 1500);
speedCurve:Evaluate(UnitSpeed)

However, that still doesn't work in the current iteration because you end up with bad argument #2 to '?' (Usage: local y = self:Evaluate(x). Secret values are only allowed during untainted execution for this argument.)

[KyrosKrane]

This is fixed in v3.1.0. I strongly urge folks to use the feedback function in WoW to let Blizzard know that secrecy of movement speed is a bad idea.

[KyrosKrane]

To calculate run speed as a % you can use CurveUtil like so:

local speedCurve = C_CurveUtil.CreateCurve();
speedCurve:SetType(Enum.LuaCurveType.Linear);
speedCurve:AddPoint(0.0, 0);
speedCurve:AddPoint(105.0, 1500);
speedCurve:Evaluate(UnitSpeed)

However, that still doesn't work in the current iteration because you end up with bad argument #2 to '?' (Usage: local y = self:Evaluate(x). Secret values are only allowed during untainted execution for this argument.)

Thanks for this! The problem here is that execution will always be tainted in this context. But I might be able to put the calculation in the curve itself to get around this. I'll look into it.

[KyrosKrane]

So it seems like even if I get around the secret limitations as @aa-chrismcfadyen noted, I still run into the tainted code issue. I have some ideas about that, but even then it won't work because LDB itself doesn't support storing or displaying secret values. I'm going to leave this issue open for now and revisit it after a while, to see what changes happen on the Blizz and LDB sides.

[KyrosKrane]

Note to self, this is tracked in the SecretWorkaround branch.