• 0

    posted a message on RatingBuster
    In my continuing love/hate relationship with RB, I've decided that I only want to see the item level if it's a useful number. Modifying the tooltips of spell reagents and quest items is just clutter ("ooooh, ilvl 1, awesome!"), but seeing the ilvl of armor can be a very useful thing.

    So I added a slider/range option for item level display. The user can set a threshold for a minimum item level. If they have item level display toggled on, and the ilvl is higher than the threshold, then the number is displayed as before. If it's too low, then not. The default cutoff is 1, so there is no change from current behavior unless a user actively fiddles with the option.

    The only thing missing from this patch is localization for the option description strings. I don't know exactly how to do that. The rest of the patch works; I've found that a threshold of about 100 is good at keeping the noise out of tooltips for a level 70 player just starting to raid (like most of my alts).

    Thoughts, opinions, feedback?

    --- RatingBuster.lua.orig	2008-05-30 06:20:24.000000000 -0400
    +++ RatingBuster.lua	2008-05-30 06:40:38.000000000 -0400
    @@ -96,6 +96,7 @@
     	showItemID = false,
     	useRequiredLevel = true,
     	customLevel = 0,
    +	customItemLevel = 1,
     	textColor = {r = 1.0, g = 0.996, b = 0.545, hex = "|cfffffe8b"},
     	enableTextColor = true,
     	enableStatMods = true,
    @@ -340,6 +341,17 @@
     			get = getProfileOption,
     			set = setProfileOptionAndClearCache,
     		},
    +		itemlevelcutoff = {
    +			type = 'range',
    +			name = "Set item level threshold",
    +			desc = "Set the minimum item level to display (1 = always add item level)",
    +			passValue = "customItemLevel",
    +			get = getProfileOption,
    +			set = setProfileOptionAndClearCache,
    +			min = 1,
    +			max = 175, -- as of 2.4.2, the zone-locked TK/Kael legandaries
    +			step = 1,
    +		},
     		usereqlv = {
     			type = 'toggle',
     			name = L["Use required level"],
    @@ -1819,7 +1831,7 @@
     			if link then
     				local _, _, id = strfind(link, "item:(%d+)")
     				local newLine = ""
    -				if level and profileDB.showItemLevel then
    +				if level and level >= profileDB.customItemLevel and profileDB.showItemLevel then
     					newLine = newLine..L["ItemLevel: "]..level
     				end
     				if id and profileDB.showItemID then

    Posted in: General AddOns
  • 0

    posted a message on WowAceUpdater 1.9.44+ Official Thread
    Reporting back that .746 works well:

    - No crashes after 10 seconds
    - No infinite loops
    - No exception traces
    - I won the lottery

    I may be lying about one of those items, it's up to you to figure out which one.

    Some caveats for other people trying to update:

    - The link in the Updaters sticky thread to "the last good WAU build" at codeplex.com points to .738, which is the one which mysteriously start asploding the other day.

    - The "outdated" WAU wiki page referred to at codeplex has two links. The zip file is .718, and the install-via-IE link is to the updated and working .746.

    Finally, two questions, just out of curiosity (feel free to ignore them). I'm a programmer, and while I don't use .NET myself, I've plenty of other experience with similar technologies. What on earth happened to make .738 self-destruct even though nothing on the user's end had changed? And what happened to .739-ish to cause the corrupted-zip-infinite-loop thing?
    Posted in: Updaters
  • 0

    posted a message on WowAceUpdater 1.9.44+ Official Thread
    Quote from Seerah »

    Everyone, please read this post!
    http://www.wowace.com/forums/index.php?topic=13733.msg220538#msg220538


    Believe he's referring to the instant-crash bug, not the infinite loop bug. Going back to the WAU page and installing by hand, as instructed in that post, just gets us the same infinite loop again.

    Posted in: Updaters
  • 0

    posted a message on "error during update (will retry automatically)" infinite loop
    Managed to remove the .739 build (by hand, since going through the control panel gets as far as clicking change/remove for WAU, and then.... does nothing). Installed the .738 standalone build, which exhibits the exact same behavior of infinite looping errors.

    I found the debug output file, which has this to say:

    [5/28/2008 10:51:43 PM] 09 Downloaded C:\Documents and Settings\<my username>\Local Settings\Temp\WowAceUpdater\Omen-r75388.zip size 329650 filesize 329650
    [5/28/2008 10:51:43 PM] 09 Trying to read a corrupted xip file
    [5/28/2008 10:51:43 PM] 01 Omen - Error During Update (Will Retry Automatically)


    followed by tons of

    [5/28/2008 10:51:43 PM] 09 System.IO.IOException: The process cannot access the file 'C:\Documents and Settings\<my username>\Local Settings\Temp\WowAceUpdater\Omen-r75388.zip' because it is being used by another process.
      at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
      at System.IO.File.Delete(String path)
      at WowAceUpdater.WowAceFilesServer.DownloadFile(String fileUrl, String localFileName)
      at WowAceUpdater.MainForm.DownloadAndExtract(String addonName, ExternalMode skipExternals, Boolean skipVersionCheck, Boolean deleteBeforeExtract, ICollection`1 list, ICollection`1 listDone, ICollection`1 listCurrent, TextWriter outputWriter, Object oLock)
    [5/28/2008 10:51:43 PM] 09 Mode: Omen:WITH Update: n/a -> WITH Externals 75388 UNSTABLE 
    [5/28/2008 10:51:43 PM] 09 Omen - Updating to rev +75388
    [5/28/2008 10:51:43 PM] 09 [url]http://files.wowace.com/Omen/Omen-r75388.zip[/url]
    [5/28/2008 10:51:43 PM] 01 Omen - Error During Update (Will Retry Automatically)


    Going into that temp directory, I see the zip files. All but one are zero-length files. The remaining one looks like a good zip file.

    For now, I'm just getting the zip files from the files.wowace.com list directly and unpacking them by hand.
    Posted in: Updaters
  • 0

    posted a message on "error during update (will retry automatically)" infinite loop
    Starting today, for no reason, WAU crashes immediately upon startup. I uninstalled it, and reinstalled from the latest link (via IE). The build is now displaying 1.9.46.739, and seems to work fine up until I try to update some existing addons.

    I do not have WoW installed in the Program Files folder; it's always been off on another drive and path. [edit: WAU finds this location with no problem]

    Now, when I choose update, the output window spams "error during update" for each addon I've selected, and retries. It never stops, and never prints what exactly the error is. Choosing "Cancel Update" from the File menu doesn't stop anything; I have to kill the application entirely. I have diagnostic logging turned on, but once I choose update everything kind of locks up, not sure where to find the logs.

    In the Interface/AddOns tree, for each of the addons I'm trying to update, I see a pair of folders, "foo", and "foo-rNNNNN". I didn't look further, just blew those folders away.
    Posted in: Updaters
  • 0

    posted a message on Omen2
    Ha, nice. Love that game AI sometimes. There were several other weird things happening that time which I've never seen before during the event ("why is Blackheart attacking the wall?"), something was definitely wonky on the server's end that evening. Doesn't sound like it's worth bothering with on Omen's end.
    Posted in: Raid AddOns
  • 0

    posted a message on Omen2
    Using 74823, got this error during the Blackheart the Inciter fight, while charmed and running around:

    Error: attempt to concatenate local 'target' (a nil value)
    File: ...ddOns\Omen\Libs\Threat-2.0\ThreatClassModuleCore.lua
    Line: 1237
    Count: 2
    ...ddOns\Omen\Libs\Threat-2.0\ThreatClassModuleCore.lua:1237: in function `getTransaction'
    ...ddOns\Omen\Libs\Threat-2.0\ThreatClassModuleCore.lua:1079: in function `AddTargetThreatTransactional'
    ...AddOns\Omen\Libs\Threat-2.0\ClassModules\Warrior.lua:196: in function `?'
    ...ddOns\Omen\Libs\Threat-2.0\ThreatClassModuleCore.lua:1204: in function `?'
    ...men\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:146: in function <...men\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:146>
    [string "safecall Dispatcher[4]"]:4: in function <[string "safecall Dispatcher[4]"]:4>
    [C]: ?
    [string "safecall Dispatcher[4]"]:13: in function `?'
    ...men\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:91: in function `Fire'
    ...rface\AddOns\Omen\Libs\AceEvent-3.0\AceEvent-3.0.lua:70: in function <...rface\AddOns\Omen\Libs\AceEvent-3.0\AceEvent-3.0.lua:69>
    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    No, it's not an issue at all. It's just a needless inconsistency, being displayed in a raid and hidden in a party for no obvious reason. Is there a reason to not unconditionally put the player's own revisions in Threat.partyMemberAgents? I don't know all the ways in which that table gets used; if doing so would cause complications then it's not worth it.

    Basically, those of us who don't know Threat/Omen well enough to fix major bugs would like to contribute smaller patches to smooth the minor bumps.

    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    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!


    Any modern vi clone supports all of those.
    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Quote from licwid »

    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.)
    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Quote from Farmbuyer »

    It'd also be nice if the revision number could be printed out via slash command (maybe just as a line before the list of subcommands, when the user types "/omen" and no args). Currently there's nowhere in the game to see the revision number besides the title bar, and if the title bar is hidden, oops.


    So yeah, I finally got tired of not being able to find the current revision number while in game, and I don't have spare screen space to display the title bar. It turns out that the banner printed at the start of the "/omen" help list isn't controllable by Omen code, it's all done by mixins and there's no way to slip an extra line of text through. (Maybe you're all rolling your eyes, but it was news to me.)

    So I did this instead. I realize it's not localized.

    --- Config.lua 2008-04-14 16:43:56.000000000 -0400
    +++ Config-changed.lua 2008-04-14 16:41:50.000000000 -0400
    @@ -693,6 +693,13 @@
                desc = L["Open the configuration dialog"],
                func = Omen.ShowConfig,
                guiHidden = true
    +        },
    +        version = {
    +            type = "execute",
    +            name = "Print Omen/Threat revisions",
    +            desc = "Print Omen/Threat revisions",
    +            func = function() Omen:Print(Omen.version) end,
    +            guiHidden = true
            }
        }
     }


    I also considered having a fake entry in the table, called "version" but with a desc field of Omen.version, and a function that didn't do anything.
    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    During the quest "Teleport This!", I used the Mental Interference Rod to possess one of the demons up in Netherstorm. Even though I didn't have Omen displayed/active at the time, I immediately got this error:

    Error: attempt to concatenate a nil value
    File: ...men\Libs\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua
    Line: 158
    Count: 1
    ...men\Libs\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:158: in function `ProcessActor'
    ...men\Libs\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:115: in function `?'
    ...men\Libs\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:97: in function <...men\Libs\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:96>


    Because I don't have the title bar displayed when Omen *is* running, I'm not sure of the exact revision or how to find it. [edit: opening Omen.lua, there's a 69623 rev there]

    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Quote from Gilora »

    Go to the profiles section and select the Default profile. Change any settings that need to be changed.

    Log on your other toons and then load the Default profile.


    What Gil said. (Holy crap, it's Gil!)
    Loading other char's profiles does nothing at the moment.
    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Using 67732 and engaging Doomwalker, we get this:

    Error: attempt to index local 'self' (a nil value)
    File: ...en\Libs\Threat-2.0\NPCModules\Outland\Doomwalker.lua
    Line: 17
    Count: 1
    ...en\Libs\Threat-2.0\NPCModules\Outland\Doomwalker.lua:17: in function `func'
    ...\AddOns\Omen\Libs\Threat-2.0\ThreatNPCModuleCore.lua:377: in function `?'
    ...men\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:146: in function <...men\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:146>
    [string "safecall Dispatcher[20]"]:4: in function <[string "safecall Dispatcher[20]"]:4>
    [C]: ?
    [string "safecall Dispatcher[20]"]:13: in function `?'
    ...men\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:91: in function `Fire'
    ...rface\AddOns\Omen\Libs\AceEvent-3.0\AceEvent-3.0.lua:70: in function <...rface\AddOns\Omen\Libs\AceEvent-3.0\AceEvent-3.0.lua:69>

    Posted in: Raid AddOns
  • To post a comment, please or register a new account.