You must login to post a comment. Don't have an account? Register to get one!

• 

  • Reply
  • #17

  Morgalm Dec 30, 2011 at 00:01 UTC - 0 likes

  Not sure what has changed but tank behavior seems to be broken atm. It isnt (always) detecting when I add/remove tanks using the blizz tanks (ie promote them to tank) Also I had 2 tanks up then one just disappeared. I checked and under custom tanks it had tank1 and tank2 both checked but only tank1 was showing. If I unchecked tank2 tank1 disappeared. Could never get tank2 to appear. Seems to be new behavior in last month or so.

• 

  • Reply
  • #16

  Sonora Apr 27, 2011 at 21:57 UTC - 0 likes

  @Morgalm: Go

  Just caught that - fixed in 1.4.1.

  Last edited Apr 27, 2011 by Sonora
• 

  • Reply
  • #15

  Morgalm Apr 27, 2011 at 00:38 UTC - 0 likes

  Your comm name is too long can only be 16 chars now.

• 

  • Reply
  • #14

  Sonora Dec 06, 2010 at 03:01 UTC - 0 likes

  More great suggestions!

  (a) patch included in 1.2 (b) patch included in 1.2 (thanks, I hadn't stumbled on these API calls before) (c) Most flickering and blinking should be fixed in 1.2. Your suggestions for replacing the previous kludge with a cleaner implementation inspired me to take a larger pass over the drawing/updating functions.

• 

  • Reply
  • #13

  Dridzt Nov 30, 2010 at 12:36 UTC - 0 likes

  You shouldn't encourage me... but you just did so.. :-P

  A couple last things if I may.

  a. One more convenience key-bind for "Clear All"
  Use case: Works nicely as a quick refresh when you have "automatically add tanks".
  Setting a tank through oRA or Blizzard interface adds it to targetAssist targets.
  Removing it (because next encounter doesn't need 2 or 3 or because it was a ranged tank for particular encounter etc) doesn't also remove it from targetAssist.
  A quick "clear all" refreshes the list since current tanks are automatically re-added.
  

  BINDING_NAME_TACLEARTARGETS = "Clear all targets"
  

  <Binding name = "TACLEARTARGETS">
      targetAssist:clearAll()
  </Binding>
  

  There's also a little typo in the print for combat lockdown in add target binding ('durring' instead of 'during')

  b. In gui.lua a small typo in broadcasts menu item:
  'Recieved broadcasts' instead of 'Received broadcasts'.
  In the same section the functions for broadcasting to raid/party/guild need some checks in place so you don't get the dreaded "player x / you are not in a raid/party/guild" system message spam.
  

  -- 'RAID'
  if GetRealNumRaidMembers()>0 then
      self:SendCommMessage() 
  end
  -- 'PARTY'
  if GetRealNumPartyMembers()>0 then
      self:SendCommMessage()
  end
  -- 'GUILD'
  if IsInGuild() then
      self:SendCommMessage()
  end
  

  Using the GetRealNum* function variants as the plain GetNumParty|RaidMembers() versions will return true in BGs but trying to sendcomm in 'RAID' or 'PARTY' distribution will fail and produce the usual system error messages.
  The GetRealNum* functions only return true party/raid members.

  c. Finally.
  Tested the disable functionality.
  It is working better than before i.e no stuck assistbuttons but they do occasionally 'flicker' in existence briefly and immediately hide again.
  I'm thinking this flickering will be more noticeable the slower frequency updates the user has selected (barely noticeable at 0.1 the default, more visible at 0.2 that I have it set, quite visible at 0.5)
  It would help down the road if you made use of AceAddon-3.0 :OnEnable() and :OnDisable() api to split your initialization to SV stuff in OnInit and event registration/callbacks etc in OnEnable so OnDisable can shut the addon down cleanly.
  Same if you decide to make 'disable' a persistent value instead of a session variable.
  (although I think it makes perfect sense as you have it not persisting a reload)

  Anyway getting carried away :)
  That would require some refactoring.
  The next best thing and quite simple is with these minimal changes:
  1. In core.lua in OnInitialize() function storing the timer handle when it's created
  

  self.timerhandle = self:ScheduleRepeatingTimer('onUpdate', self.config.updateInterval)
  

  2. In core.lua again a new function added

  function targetAssist:disable(disabled)
      if disabled then
          self:UnregisterEvent('PARTY_MEMBERS_CHANGED')
          self:UnregisterEvent('RAID_ROSTER_UPDATE')
          self:UnregisterEvent('PLAYER_ROLES_ASSIGNED')
          self:CancelTimer(self.timerhandle)
          self:UnregisterComm('targetAssist.broadcastTargets')
          if self.headerFrame then
              self.headerFrame:Hide()
              for targetName, buttonFrame in pairs(self.targetButtons or {}) do
                  buttonFrame:Hide()
              end
          end
      else
          self:RegisterComm('targetAssist.broadcastTargets', 'targetReceiver')
          self.timerhandle = self:ScheduleRepeatingTimer('onUpdate', self.config.updateInterval)
          self:RegisterEvent('PARTY_MEMBERS_CHANGED')
          self:RegisterEvent('RAID_ROSTER_UPDATE')
          self:RegisterEvent('PLAYER_ROLES_ASSIGNED')
          -- onUpdate will take care of showing header/buttons
      end
  end
  

  I put it just under OnInitialize() block.
  3. A little further down core.lua remove that workaround from onUpdate() as it's no longer needed and just leave the original hide check.

  if self.hide and self.headerFrame then
      self.headerFrame:Hide()
      -- etc
  

  4. In gui.lua updating the 'Disable' gui option and the '/ta hide' '/ta show' respectively to:
  gui options

  set = function(info, value) self.disabled = value; self:disable(self.disabled) end,
  

  /ta hide

  self.disabled = true
  self:disable(self.disabled)
  

  /ta show

  self.disabled = false
  self:disable(self.disabled)
  -- etc
  

  Sorry for the humongous wall of text.
  Went to the source to find the reason for the flickering so I don't keep bothering you for the same thing with no new info and kinda bumped into these :)

• 

  • Reply
  • #12

  Sonora Nov 30, 2010 at 02:03 UTC - 0 likes

  @Dridzt - another great suggestion! Fixed in 1.1.2.

  Feature suggestions, accompanied by clean & simple implementations? Feel free to bug me all you want!

• 

  • Reply
  • #11

  Dridzt Nov 29, 2010 at 05:00 UTC - 0 likes

  Great, I'll get back to you after I've tested :)

  I have another little suggestion.
  It's never been an issue on my tank but noticed it on the healer.
  

  I'm using Clique for click-casting.
  There's a small non-breaking problem in that targetAssist doesn't check for modifiers
  so you can only use modified-leftclick and middle or modified-middle click to click cast.
  

  Doing a shift-right click or ctrl-right click will do the cast but will also popup the targetAssist menu.

  Maybe checking IsModifierKeyDown() in OnMouseUp handler to avoid popping up the menu and only do it on plain right click.

  Sorry to keep bugging you :P

  Last edited Nov 29, 2010 by Dridzt
• 

  • Reply
  • #10

  Sonora Nov 29, 2010 at 02:59 UTC - 0 likes

  Thanks - this bug should be fixed in 1.1.1!

• 

  • Reply
  • #9

  Dridzt Nov 29, 2010 at 01:04 UTC - 0 likes

  version 1.1 works pretty well but I still have the problem with disable.
  Some more info.

  I have the embedded libs version installed on enGB client.

  I definitely wasn't in-combat when I tested it this time.

  Steps to reproduce from my end:
  1. Open targetAssist options tick "Disable"
  Header and any assists bars hide as you'd expect.
  2. Cross a loading screen (like a raid portal for example)
  A "ghost" bar re-appears.
  Open options and check/uncheck "Disable" again.
  Header and assist bars hide again.
  3. Have the RL or yourself if you have permission do a promote, set tanks, basically anything that would fire a RAID_ROSTER_UPDATE.
  Ghost bar re-appears.
  This is how it looks in-game
  
  Attaching the saved variables for the character affected just in case there's some corruption there.

  Still zero lua errors (have them enabled and using BugGrabber/BugSack) but I can move this to a ticket if you prefer it there.

  Last edited Nov 29, 2010 by Dridzt
• 

  • Reply
  • #8

  Sonora Nov 28, 2010 at 03:39 UTC - 0 likes

  @Dridzt Thank you for all of your thoughtful feedback!

  Hide bug: I still haven't been able to recreate the bug. My guild isn't raiding these days so my only test environment for raid groups is battlegrounds; my failure to recreate the bug might be due to some odd difference between the two. If you see the problem again, try this (and let me know what happens): Use the chat command "/ta hide".

  Including self as MA: I'm sold! In 1.1rc1 (or the actual release if I don't end up syndicating the release candidate), you'll find a new option on the configuration panel to include yourself on the add-on's roster of possible main assist targets.

  I hope the EU servers are up and working for you despite the holiday here in the US!