bah i need something thatd work on my vista machine
Vim works fine under Windows. (Whether you enjoy working with a vi clone is up to you. Personally I wouldn't use anything *other* than vi/vim, but it's not very friendly the first time you use it.)
Vim works fine under Windows. (Whether you enjoy working with a vi clone is up to you. Personally I wouldn't use anything *other* than vi/vim, but it's not very friendly the first time you use it.)
vi is horrible. We have mice, arrow keys, and Alt keys in the 21st century!
In my latest round of updates, I have isolated and fixed the following bugs, most of which are reported in the last 5 pages. Note that these are Omen fixes and not Threat-2.0 fixes.
- Fix not seeing the threat of some people in your raid when the rest of your raid sees them. This is a result of not setting .isTitle to false when releasing a title bar that is no longer in use, and when the same bar is reused for displaying a player's threat later, the code specifically skipped displaying these title bars.
- Fix border/background colors not updating until reloadUI when changing them in the configuration. This is a result of not resetting memoizations for the optionStubs.
- Omen will now save window width and height into the profiles instead of relying on layout-cache.txt. Omen will now also respect Omen's scaling when saving its position, width and height.
- Fix text labels in the display bars extending out of the Omen window sometimes.
- Fix game client hanging, mouse unresponsiveness, or Omen being stickied to your mouse cursor forever when attempting to resize Omen if you have "Auto collapse also hides bar list" or "Auto collapse also hides Omen Frame" option on.
- Make the profile copying, resetting, creation and deleting actually work.
Excellent addon, we simply couldn't raid without it. One small (although I'm sure it's more complicated than it sounds) request, any chance we can pull out threat bars like the original so they can be dragged and monitored. I used to love pulling the MT bar out and being able to put it somewhere independent of all the others.
no, nightbane still fails to reset. do an /omen clear for the time being.
Yeah, I saw this last night. I double-checked the strings for what he yells at each phase transition and they look correct, so my guess is that either Omen is using the wrong combat log ID for Nightbane or something is wrong in the code which handles the detection of those yells.
Unfortunately, I didn't think to record a combatlog.
Yeah, I saw this last night. I double-checked the strings for what he yells at each phase transition and they look correct, so my guess is that either Omen is using the wrong combat log ID for Nightbane or something is wrong in the code which handles the detection of those yells.
Unfortunately, I didn't think to record a combatlog.
I actually went to a pug NightBane to find out what's wrong.... only to find that the code wasn't even specified to be loaded in the TOC/XML files.
Omen:VersionCheck() does not include the player in its output when in a party (instead of a raid). This is very annoying, since the user only sees everybody else's revisions without seeing his own for comparison.
Initially, it's because the "partyN" unitid does not include the player (at the top of VersionCheck()). Checking for GetNumRaidMembers() equal to zero and manually inserting the player's name into the the partySort table (just before the sort() on line 355) only kind of works; the player is included in the version check output correctly, but the revision numbers are unknown.
That, in turn, is because the local Threat.partyMemberAgents table doesn't include the player's own data unless in a raid.
And that, in turn, seems to be because of ThreatLib:UpdateParty(). Around line 325 of Threat-2.0.lua, that function calls PublishVersion, which registers the player's own revisions -- but only if it thinks the party is growing in size. Or something. I haven't worked through enough of the event code to figure it out.
I was hoping to include a patch to fix this, but I'm sort of stuck now.
Also:
Quote from HunterZ »
vi is horrible. We have mice, arrow keys, and Alt keys in the 21st century!
Farmbuyer, is it really that much of an issue? You can see your own Threat-2.0's version right in Omen's title frame itself (unless you hid it). Or by using "/dump Omen.version" which will dump a string containing both Omen's and Threat-2.0's version.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Vim works fine under Windows. (Whether you enjoy working with a vi clone is up to you. Personally I wouldn't use anything *other* than vi/vim, but it's not very friendly the first time you use it.)
Any plain text editor like Notepad, Textpad, UltraEdit, even WordPad, will work.
vi is horrible. We have mice, arrow keys, and Alt keys in the 21st century!
- Fix not seeing the threat of some people in your raid when the rest of your raid sees them. This is a result of not setting .isTitle to false when releasing a title bar that is no longer in use, and when the same bar is reused for displaying a player's threat later, the code specifically skipped displaying these title bars.
- Fix border/background colors not updating until reloadUI when changing them in the configuration. This is a result of not resetting memoizations for the optionStubs.
- Omen will now save window width and height into the profiles instead of relying on layout-cache.txt. Omen will now also respect Omen's scaling when saving its position, width and height.
- Fix text labels in the display bars extending out of the Omen window sometimes.
- Fix game client hanging, mouse unresponsiveness, or Omen being stickied to your mouse cursor forever when attempting to resize Omen if you have "Auto collapse also hides bar list" or "Auto collapse also hides Omen Frame" option on.
- Make the profile copying, resetting, creation and deleting actually work.
Yeah, I saw this last night. I double-checked the strings for what he yells at each phase transition and they look correct, so my guess is that either Omen is using the wrong combat log ID for Nightbane or something is wrong in the code which handles the detection of those yells.
Unfortunately, I didn't think to record a combatlog.
I actually went to a pug NightBane to find out what's wrong.... only to find that the code wasn't even specified to be loaded in the TOC/XML files.
T_T
Initially, it's because the "partyN" unitid does not include the player (at the top of VersionCheck()). Checking for GetNumRaidMembers() equal to zero and manually inserting the player's name into the the partySort table (just before the sort() on line 355) only kind of works; the player is included in the version check output correctly, but the revision numbers are unknown.
That, in turn, is because the local Threat.partyMemberAgents table doesn't include the player's own data unless in a raid.
And that, in turn, seems to be because of ThreatLib:UpdateParty(). Around line 325 of Threat-2.0.lua, that function calls PublishVersion, which registers the player's own revisions -- but only if it thinks the party is growing in size. Or something. I haven't worked through enough of the event code to figure it out.
I was hoping to include a patch to fix this, but I'm sort of stuck now.
Also:
Any modern vi clone supports all of those.