5.4.8 Changes to CVars While In-Combat

Community Manager
Greetings,

We’re making a change to a number of CVars in the upcoming Patch 5.4.8 (release date: 05-20-2014). UI Add-Ons will be unable to update the following CVars while the player is in combat. Add-On authors, please feel free to use the 5.4.8 PTR testing environment to see if an UI Add-On is compatible with the upcoming patch before it goes live.

alwaysShowActionBars
bloatnameplates
bloatTest
bloatthreat
consolidateBuffs
fullSizeFocusFrame
maxAlgoplates
nameplateMotion
nameplateOverlapH
nameplateOverlapV
nameplateShowEnemies
nameplateShowEnemyGuardians
nameplateShowEnemyPets
nameplateShowEnemyTotems
nameplateShowFriendlyGuardians
nameplateShowFriendlyPets
nameplateShowFriendlyTotems
nameplateShowFriends
repositionfrequency
SetUIVisibility - You can still SetUIVisibility(true) while in combat, but you can no longer toggle it.
showArenaEnemyFrames
showArenaEnemyPets
showPartyPets
showTargetOfTarget
targetOfTargetMode
uiScale
useCompactPartyFrames
useUiScale

Edit: Added info for 'SetUIVisibility'.
Edit2: Added release date info for 5.4.8.
Edited by Rygarius on 5/19/2014 2:53 PM PDT
Reply Quote
MVP - Technical Support
90 Human Warrior
18100
I don't understand, why would you block changing nameplates in combat?

Specifically these ones

if self.Options.FixNameplates then
--Blizz settings either return 1 or nil, we pull users original settings first, then change em if appropriate after.
Totems = GetCVarBool("nameplateShowEnemyTotems")
Guardians = GetCVarBool("nameplateShowEnemyGuardians")
Pets = GetCVarBool("nameplateShowEnemyPets")
--Now change all settings to make the nameplates while in constructs not terrible.
if Totems then
SetCVar("nameplateShowEnemyTotems", 0)
end
if Guardians then
SetCVar("nameplateShowEnemyGuardians", 0)
end
if Pets then
SetCVar("nameplateShowEnemyPets", 0)
end


Which I use in DBM on amber shaper unsok to basically fix bad fight design. You see, when you get turned into an amber construct, the game is bogged down with low performance and a Ui NIGHTMARE tornado of nameplates for players, pets, totems, guardians. DBM handles this grievous bad encounter design by auto hiding nameplates when you are turned into a construct and then reshow them when you become human again.
**DBM did this smart and in a way so that you still had nameplates for amber shaper, oozes, and other constructs. It wasn't a simple matter of just hitting V in combat and turning all plates on or off. or just friendly plates on or off. There will be no substitute to DBM's work around in 5.4.8 with these changes. :\

God knows what this will do to 3rd party nameplate addons too.

I am aware there is a particular UI mod out there that uses showing/hiding of nameplates to detect casts for auto interrupting that can be abused in pvp. However, there has to be a way to fix that problem without breaking other mods.
Reply Quote
MVP - Technical Support
90 Draenei Mage
6490
Interesting.

Are these changes in the current build on the PTR yet ?

Sorry I have to go in for training at work then onto a 7 hour shift.

So I don't really have time atm to write a small addon that attempts to set those in combat then test it on Live THEN on the PTR :P
Reply Quote
90 Dwarf Hunter
18820
Not terribly happy with the nameplate changes from an end-user perspective, myself.

I don't like having nameplates shown out-of-combat, because they add a hell of a lot of clutter -- yet they're invaluably useful in-combat (to the point of practically being mandatory in some encounters). If the dev team is dead-set on this change, can we at least have a built-in toggle for showing in-combat, hiding out-of-combat?

(Yes, I know there are some vague, possible workarounds like mucking with the opacity on each nameplate individually. That still causes problems, since the nameplates, no matter their opacity, still 'exist' for the purposes of mouseover and such. Not to mention the increased overhead of having to do that for each and every nameplate.)
Reply Quote
I would also like to hear why you're adding restrictions to nameplates.

Were there addons using these features considered game breaking?
Reply Quote
90 Blood Elf Paladin
17965
Somebody pointed this out to me just now - this breaks a few mods that 'kill totems' by removing nameplates for everything except totems when one is found.
Reply Quote
MVP - Technical Support
90 Human Warrior
18100
Yes, that's likely an example of what they don't want. A lot of the mods this is to break are no doubt pvp ones.

What they need to do is expand protected functions with more options. For example, maybe add a 5 second grace from start of combat before enforcing. Totem mashing addons or interrupt helpers that exploit showing/hiding nameplates, clearly out of bounds. Setting nameplates the second you enter combat, so you can hide out of combat and show in combat, clearly not game breaking.
Edited by Omegal on 5/13/2014 5:02 PM PDT
Reply Quote
90 Undead Priest
16125
Will SetUIVisibility still hide the psuedo-interface/world elements it does right now - all nameplates and raid target icons?

Could it be fixed/expanded to hide the nameplates/icons of wild battle pets while tracking is active?

Could we see a non-CVar approach to hiding combat text? Setting the CVar only disables the generation of new combat text strings, and does not immediately hide text that is already present.

In other words, while retaining the functionality changes intended here, can we have access to the controls necessary to instantly and completely hide all elements that are not strictly a part of the game world, even while in combat?
Edited by Corveroth on 5/13/2014 5:20 PM PDT
Reply Quote
Community Manager
05/13/2014 04:17 PMPosted by Bor
I don't like having nameplates shown out-of-combat, because they add a hell of a lot of clutter -- yet they're invaluably useful in-combat (to the point of practically being mandatory in some encounters). If the dev team is dead-set on this change, can we at least have a built-in toggle for showing in-combat, hiding out-of-combat?

This change only prevents Add-Ons from automatically toggling nameplates on or off during combat. Players will continue to be able to toggle nameplates regardless of combat state (bound to the "v" key by default).
Reply Quote
90 Gnome Warrior
12005
Are these changes in the current build on the PTR yet ?

They are. Or at least the couple I spot checked. Attempting to SetCVar("nameplateShowEnemies",1) in combat will give the yellow "Interface action failed because of an AddOn" message in chat. Not the popup if any wondering.

I don't like having nameplates shown out-of-combat, because they add a hell of a lot of clutter -- yet they're invaluably useful in-combat (to the point of practically being mandatory in some encounters).

This is still doable. Right now on the PTR (build 18224):
local f=CreateFrame("Frame")
f:SetScript("OnEvent",function(self,event)
SetCVar("nameplateShowEnemies",event=="PLAYER_REGEN_DISABLED" and 1 or 0)
end)
f:RegisterEvent("PLAYER_REGEN_ENABLED")
f:RegisterEvent("PLAYER_REGEN_DISABLED")

will hide nameplates out of combat and show nameplates in combat.

When stuff is protected in combat, addons can typically choose to do stuff at the moment you enter combat (as long as it requires no server interaction).

The DBM example Omegal gave was when you want them to be switched off mid-fight. Like when you get turned into a golem the screen is a huge mass of nameplates that's really difficult to see through. That part will definitely be breaking.
Edited by Ro on 5/13/2014 5:50 PM PDT
Reply Quote
90 Dwarf Paladin
13525
Can there be some sort of grace period, like 4 or 5 seconds when combat starts so we can still have our nameplates automatically hidden and shown?
Reply Quote
MVP - Technical Support
90 Human Warrior
18100
05/13/2014 05:47 PMPosted by Pastafarian
Can there be some sort of grace period, like 4 or 5 seconds when combat starts so we can still have our nameplates automatically hidden and shown?

This is what I want. Most of my nameplate changes in DBM are at combat start and end.

I only actually change ONE option mid combat and it's a tidyplates/threatplates option which I may still be able to do anyways, unless the changes break tidyplates from doing so.

if i can still hide totems, guardians and pets on combat start though and restore on combat end, then at least unsok won't be totally fubared.
Reply Quote
MVP - Technical Support
90 Human Warrior
18100
05/13/2014 05:43 PMPosted by Rygarius
This change only prevents Add-Ons from automatically toggling nameplates on or off during combat. Players will continue to be able to toggle nameplates regardless of combat state (bound to the "v" key by default).

it's not always that simple to end user. that's simply toggling them all on or all off. Toggling something very specific like totems isn't so straight forward, unless the intent is to have someone open up their interface settings mid combat to do this from now on? (I remember trying to do this on amber shaper and realizing how stupid it was. That's when i coded DBM to do it for me.

Far as I know you can't bind the sub nameplate options. just the root Enemy nameplate and friend nameplate options. Each has 3 sub options though, which is where addons come in.
Edited by Omegal on 5/13/2014 6:06 PM PDT
Reply Quote
90 Gnome Warrior
12005
This is what I want. Most of my nameplate changes in DBM are at combat start and end.

Maybe I'm misreading, but this will be doable. All of those cvars can be changed at PLAYER_REGEN_DISABLED. That is our grace period when you enter combat. You can set up a flurry of attributes and protected stuff during PLAYER_REGEN_DISABLED.
Reply Quote
90 Dwarf Hunter
18820
05/13/2014 05:43 PMPosted by Rygarius
This change only prevents Add-Ons from automatically toggling nameplates on or off during combat. Players will continue to be able to toggle nameplates regardless of combat state (bound to the "v" key by default).

I expected the keybind would still work. However, there's a big difference between a keybind and automation as far as being user-friendly goes -- this is particularly true if, like me, you're running with roughly forty key/mouse binds as it is ('v' is my Serpent Sting, for instance -- I think my nameplate toggle is something arcane like Ctrl+Alt+Shift+v).

That said, it sounds as though these are still changeable during PLAYER_REGEN_DISABLED. So long as that doesn't change later in the PTR cycle, I retract my complaint. That's the only time I really care about being able to toggle them automatically, and it should cover the vast majority of all the legitimate "in-combat" uses of these cvars.

...It is intended that they still are modifiable during PLAYER_REGEN_DISABLED, right? Please say yes -- I cannot see any sort of harm that could possibly cause, ever.
Reply Quote
MVP - Technical Support
90 Human Warrior
18100
05/13/2014 06:14 PMPosted by Ro
This is what I want. Most of my nameplate changes in DBM are at combat start and end.

Maybe I'm misreading, but this will be doable. All of those cvars can be changed at PLAYER_REGEN_DISABLED. That is our grace period when you enter combat. You can set up a flurry of attributes and protected stuff during PLAYER_REGEN_DISABLED.

that's hit or miss based on computer speed & latency as far as I know. I did do some testing on ptr and this issue won't affect dbm with some minor edits. DBM actually hides nameplates before PLAYER_REGEN_DISABLED on amber shaper. It restores them before PLAYER_REGEN_ENABLED though but I fix this easily with a delay.

This is the benefits of starting combat with an event that always fires 1 second before PLAYER_REGEN_DISABLED. ENCOUNTER_START or INSTANCE_ENCOUNTER_ENGAGE_UNIT. :)

As for the methods I use IN COMBAT, since they aren't cvars, it seems non issue (DBM interacts with tidyplates threat plates mid combat only if user has it installed because it allows hiding nameplates for the oozes (non elites) so only unsok's, monstrosity, and out of control construct nameplates are left).

The only issue I cannot fix is if a user pulls the boss while IN COMBAT (which pretty much means it probably won't work for level 100 soloers that pull the boss with trash)

So it looks like these changes may mainly just break the intended pvp mods after all. We'll see how they treat changing on regen in next PTR patch (cause we know there will be new builds, the ilvl stuff isn't in yet)
Edited by Omegal on 5/13/2014 7:23 PM PDT
Reply Quote
90 Gnome Warrior
12005
that's hit or miss based on computer speed & latency as far as I know.

The UI is single-threaded. On a TI-99/4A with a 300 baud modem, client lockdown won't happen until all of the dispatched PLAYER_REGEN_DISABLEDs are complete.

http://blue.cardplace.com/newcache/us/15401595.htm
Poster: Slouken at 2006-10-07 13:55:33
Subject: Re: 2.0.0 Changes - Concise List

The event PLAYER_REGEN_DISABLED is sent before protected frames are locked down, and the event PLAYER_REGEN_ENABLED is sent after protected frames are unlocked.

You can tell whether or not a particular frame can currently be moved/resized/shown, etc. by calling Frame:CanChangeProtectedState()

http://forums.worldofwarcraft.com/thread.html?topicId=15401595&pageNo=20&sid=1#396

It's unfortunate that we no longer have Slouken or another UI dev on this forums nowadays. It'd be interesting to hear if the server tracks our lockdown too and if there's ever a case where the server can think we're in lockdown and our client doesn't.
Reply Quote
90 Troll Druid
21850
05/13/2014 04:44 PMPosted by Simca
Somebody pointed this out to me just now - this breaks a few mods that 'kill totems' by removing nameplates for everything except totems when one is found.


/tar spirit link totem
/tar healing stream
/tar healing tide

fixed lol, most people use this anyway, faster than clicking the totem.
Reply Quote
90 Undead Priest
10965
05/13/2014 10:05 PMPosted by Dolson
05/13/2014 04:44 PMPosted by Simca
Somebody pointed this out to me just now - this breaks a few mods that 'kill totems' by removing nameplates for everything except totems when one is found.


/tar spirit link totem
/tar healing stream
/tar healing tide

fixed lol, most people use this anyway, faster than clicking the totem.


You can't use macros to target enemy totems, as far as I'm aware.
Reply Quote
UGG I rarely complain on forums. But man.. this is a headache.
Reply Quote

Please report any Code of Conduct violations, including:

Threats of violence. We take these seriously and will alert the proper authorities.

Posts containing personal information about other players. This includes physical addresses, e-mail addresses, phone numbers, and inappropriate photos and/or videos.

Harassing or discriminatory language. This will not be tolerated.

Forums Code of Conduct

Report Post # written by

Reason
Explain (256 characters max)
Submit Cancel

Reported!

[Close]