It was more all healer who seemed to have trouble with the reset than just paladin (not a huge issue since healer are very unlikely to aggro, but it's quite annoying since they destroy the visualisation of omen).
On a side note, there is no reset when Supremus switch back to "tanking phase", but you are probably aware of this.
On Sunday we were killing Void Reaver and a Fire Mage had exceptional threat, although the fight had just begun. I suppose the threat wasn't cleared between attempts, but I cannot tell you if he had Omen installed (forgot to scroll up on the screenshot).
He is, in fact, running omen. There is no * at the end of name to suggest that he's running KTM :P
The description on files.wowace.com says this addon is still in beta. Is this your opinion Antiarc?
Because of the issues of last night with Omen, even after 3 updates and downloads of the whole guild, it had to be scrapped and we moved back to KTM just so we could continue. The change pace is frenetic and your responsiveness is appreciated. Could it be time to freeze the existing code base, work out all the bugs with threat calculations, display problems, and get a good known stable release so we can all move to it with confidence?
"Its built with Ace", "Its coded better!", and "It takes less memory!" only go so far with a guild full of people who could care less about development religion or don't know and will never know the difference between "embed" and "external".
I really want your mod to be successful, and maybe its just my guilds makeup and we shouldn't be using an "use at your own risk" mod. However, being a software guy myself I do know at some point you have to get a release out the door that is solid and stable.
The description on files.wowace.com says this addon is still in beta. Is this your opinion Antiarc?
Because of the issues of last night with Omen, even after 3 updates and downloads of the whole guild, it had to be scrapped and we moved back to KTM just so we could continue. The change pace is frenetic and your responsiveness is appreciated. Could it be time to freeze the existing code base, work out all the bugs with threat calculations, display problems, and get a good known stable release so we can all move to it with confidence?
"Its built with Ace", "Its coded better!", and "It takes less memory!" only go so far with a guild full of people who could care less about development religion or don't know and will never know the difference between "embed" and "external".
I really want your mod to be successful, and maybe its just my guilds makeup and we shouldn't be using an "use at your own risk" mod. However, being a software guy myself I do know at some point you have to get a release out the door that is solid and stable.
Yes its beta quality. It's also in active development, and is updated 1-5+ times a day.
There have been many 'good known stable releases' you just happened to have made the move when antiarc had dry coded in something that didn't work >_< (Note to antiarc: stop dry coding things :P)
Why should you use omen over ktm right now? If you can't get everyone to keep it updated, you shouldn't, but if you can it's MUCH smaller and better written than KTM. Hell if you don't believe me open up KTM's code and look around, then go look around in Threat.
Yes its beta quality. It's also in active development, and is updated 1-5+ times a day.
There have been many 'good known stable releases' you just happened to have made the move when antiarc had dry coded in something that didn't work >_< (Note to antiarc: stop dry coding things :P)
Why should you use omen over ktm right now? If you can't get everyone to keep it updated, you shouldn't, but if you can it's MUCH smaller and better written than KTM. Hell if you don't believe me open up KTM's code and look around, then go look around in Threat.
atm Threat+Omen uses more ram with libraries than KTM
KTM is modular and easy to read, well commented
Threat-1.0.lua, 1st glance
function ThreatLib:PLAYER_ENTERING_WORLD()
local previousRunning = self.running
for _ = 1, 1 do
...
end
...
end
now explain me what for "for _ = 1, 1 do ... end" is here?
atm Threat+Omen uses more ram with libraries than KTM
KTM is modular and easy to read, well commented
Threat-1.0.lua, 1st glance
function ThreatLib:PLAYER_ENTERING_WORLD()
local previousRunning = self.running
for _ = 1, 1 do
...
end
...
end
now explain me what for "for _ = 1, 1 do ... end" is here?
That is there to fix an issue with blizzard's code I believe. Has to do with the lag between when the entering world message fires, and when the player actually shows up in the game world.
Omen itself is like 10kb. Threat running is comparable to KTM's size, but it can be used by any number of ace addons that want to take advantage of it. Omen and Threat are also completely load on demand and are disabled 99% of the time.
KTM is NOT easy to use, you have to physically set main targets every single pull. Threat does this for you, tracks ALL mobs in an encounter (not just the ones the tank is on) and easily displays the information for your target.
Long story short, you don't want to use it? Fine. I really don't think Antiarc cares that much :P Omen was developed as an alternative to KTM, not a replacement.
(I really shouldn't be allowed to drycode away from WoW)
That was a bad evening yesterday, I really like Omen and hard locks are annoying. I ended up disabling all addons because I didn't realize what was causing the issue at first, it was interesting playing with a base UI for a bit .
Thanks for updating I had no issues with an update around 10 EST, but try not to do that again.
(I really shouldn't be allowed to drycode away from WoW)
As the above poster, we do appreciate your enthusiasm but a bad update pre-raid start can make the entire night of raiding miserable. Thankfully I figured out it was Omen causing my lockups and had all the omen users turn it off for the raid, but I still lost 7 gold in repairs figuring out it was omen locking me up.
Yes its beta quality. It's also in active development, and is updated 1-5+ times a day.
There have been many 'good known stable releases' you just happened to have made the move when antiarc had dry coded in something that didn't work >_< (Note to antiarc: stop dry coding things :P)
Why should you use omen over ktm right now? If you can't get everyone to keep it updated, you shouldn't, but if you can it's MUCH smaller and better written than KTM. Hell if you don't believe me open up KTM's code and look around, then go look around in Threat.
I made the move to Omen two weeks ago for the entire guild. Because of the issues last night I had to move back to KTM. I was updating to a newer version thinking it might be a good idea to get all the fixes from the last two weeks. Since I really can't tell what's changed and fixed from release to release easily its a crap shoot.
You don't seem to understand that most people don't care its "well written". To them, they downloaded the latest version last night and what happened? TPS calcs and threat was all wrong in one (that was the perception at least) and then a pop-up made it impossible to use it after a second update. To the average non-coding gamer that says "poorly written".
And I would hope Antairc cares if people use his addon. What I'm not sure he realizes is just how many people are using it and how important it is to move to a more pragmatic approach to updating.
I made the move to Omen two weeks ago for the entire guild. Because of the issues last night I had to move back to KTM. I was updating to a newer version thinking it might be a good idea to get all the fixes from the last two weeks. Since I really can't tell what's changed and fixed from release to release easily its a crap shoot.
You don't seem to understand that most people don't care its "well written". To them, they downloaded the latest version last night and what happened? TPS calcs and threat was all wrong in one (that was the perception at least) and then a pop-up made it impossible to use it after a second update. To the average non-coding gamer that says "poorly written".
And I would hope Antairc cares if people use his addon. What I'm not sure he realizes is just how many people are using it and how important it is to move to a more pragmatic approach to updating.
That would be the reason for my "(note to Antiarc: stop dry coding things :P)" comment.
You'll have to excuse my use of terms as I'm a CS major, so when I say well written, I'm talking about elegance of code and efficiency, not if it has bugs or not.
There is a reason Omen is in Beta and not RC, so we, the community, can help Antiarc find these sort of problems before Omen is widely used.
Unfortunately, given KTMs current monopoly, Omen is being used far more than it should be at the moment.
There is a reason it says 'Use at your own risk' and that's because it's still very much a work in progress, it's just not crashing 24/7 so it's testable now. Honestly, I'd suggest waiting for an RC release (which is what my raiding group is doing). We have encouraged some of our more tech savvy raiders to make the switch, but for the general group we've let them make the decision on their own.
I have a problem/Bugreport about Omen (More likely, Threat-1.0..) and wanted to poke in and see.
As an Elemental Shaman, Your main spell is Lightning Bolt
This gets affected by your lovely little talent called "Elemental Precision" for a nice amount of threat reduction.
However. If you add another fun little toy, Called [The Lightning Capacitor] you end up throwing out another Lightning Bolt once in a while. (Well, With a 43% critrate you end up tossing it out 1 in 7 bolts, but that's another matter) which in fact -doesn't- get the Threat Reduction from Elemental Precision talents.
Now I'm in a bit of a bind, as a threat-restricted class you are very dependant on your threatmeter to hold you back, and finding out that after, say, 4 minutes of combat you are ~13-18k higher in threat than you are according to the threat meter, you have some nice issues. :-/
Sad to say, I've wiped my party on the prince due to this bug a couple of times before I figured out what the heck was up. Hopefully this means someone will either fix it, or b) that its reported for posterity.
I have a problem/Bugreport about Omen (More likely, Threat-1.0..) and wanted to poke in and see.
As an Elemental Shaman, Your main spell is Lightning Bolt
This gets affected by your lovely little talent called "Elemental Precision" for a nice amount of threat reduction.
However. If you add another fun little toy, Called [The Lightning Capacitor] you end up throwing out another Lightning Bolt once in a while. (Well, With a 43% critrate you end up tossing it out 1 in 7 bolts, but that's another matter) which in fact -doesn't- get the Threat Reduction from Elemental Precision talents.
Now I'm in a bit of a bind, as a threat-restricted class you are very dependant on your threatmeter to hold you back, and finding out that after, say, 4 minutes of combat you are ~13-18k higher in threat than you are according to the threat meter, you have some nice issues. :-/
Sad to say, I've wiped my party on the prince due to this bug a couple of times before I figured out what the heck was up. Hopefully this means someone will either fix it, or b) that its reported for posterity.
Out of curiosity are the shaman lightning bolt and [The Lightning Capacitor] bolts named the same in the combat log? If so, that may pose a problem for figuring out threat of lightning bolts for an elemental shaman with the trinket.
Hopefully Blizzard did something to the combat log message that says like 'from Lightning Capacitor' or similar, and Antiarc just isn't catching it.
edit:
If they are the same, you could possibly watch the charge debuff (don't think it has a duration) and just apply what ever the threat difference is when it is removed. Though, that may be a kind of shaky solution to the problem.
That is there to fix an issue with blizzard's code I believe. Has to do with the lag between when the entering world message fires, and when the player actually shows up in the game world.
oh... lol... really? Are you sure? Do you ever wrote any code yourself?
I remember writing some simple code in basic when I was 7 yo and to make code run slower, I'd put some empty loop, but it's not even a case there. It is most likely used to mark a code block there or it might have just been left after some change and line can simply be removed. Just to clarify it was just an example or something useless in Antiarc's "clean" code, just opened a file for a few seconds. Nevertheless Threat code atm looks like a bunch of hacks all over it with variables/functions defined in order they were coded.
10 kb of code? well, then you can take addon A, get all of it's code into some other file, call it a library and keep a loader 1 kb in size and claim your addon is 1kb. Fact is Threat and Omen being run alone with it's libraries take more memory than KTM being run alone.
The only major advantage of Threat library is a fact that it uses parser library which is in fact the greatest advantage Ace mods have over standalone ones since it allows the most intense part of addon to be split between multiple mods, but it is hardly a Threat/Omen accomplishment.
On the other hand seeing how Threat/Omen doesn't really care about users, but more of it's bloated greatness and virtually less resource usage at the same time allowing such silly things as softlocks to be committed without any testing whatsoever into the main code branch, KTM with it's pcalls and slow paced updates seems way more friendly to end user atm
ps. besides that new KTM feature of user made bossmods that can be created and broadcasted to the raid RDX alike seems really sweet for when you learn new encounter or want to test your threat theories during the raid. Really looking forward for it to be released
oh... lol... really? Are you sure? Do you ever wrote any code yourself?
I remember writing some simple code in basic when I was 7 yo and to make code run slower, I'd put some empty loop, but it's not even a case there. It is most likely used to mark a code block there or it might have just been left after some change and line can simply be removed. Just to clarify it was just an example or something useless in Antiarc's "clean" code, just opened a file for a few seconds. Nevertheless Threat code atm looks like a bunch of hacks all over it with variables/functions defined in order they were coded.
Last time I checked that event did have an issue where you couldn't act on it right away, but I didn't write the code, so it's just a guess.
Originally Posted by Elhana
10 kb of code? well, then you can take addon A, get all of it's code into some other file, call it a library and keep a loader 1 kb in size and claim your addon is 1kb. Fact is Threat and Omen being run alone with it's libraries take more memory than KTM being run alone.
The only major advantage of Threat library is a fact that it uses parser library which is in fact the greatest advantage Ace mods have over standalone ones since it allows the most intense part of addon to be split between multiple mods, but it is hardly a Threat/Omen accomplishment.
Except again, only 10kb of code is loaded into memory most of the time, this is something KTM can't do, it's either off completely, or on. It can't just go 'oh it's raid time let me turn myself on' and then when you get out of the group go 'i'm not needed anymore, guess I should get rid of my code until i'm needed again' Also multiple addons use threat... That's 200-300kb of code that only has to be running once, rather than a number of times.
Originally Posted by Elhana
On the other hand seeing how Threat/Omen doesn't really care about users, but more of it's bloated greatness and virtually less resource usage at the same time allowing such silly things as softlocks to be committed without any testing whatsoever into the main code branch, KTM with it's pcalls and slow paced updates seems way more friendly to end user atm
ps. besides that new KTM feature of user made bossmods that can be created and broadcasted to the raid RDX alike seems really sweet for when you learn new encounter or want to test your threat theories during the raid. Really looking forward for it to be released
Wow. Did you even read this thread? Not care about it's users? Antiarc is putting in a very little feature, that I'm pretty sure I'm going to be the only person using it, solely because I asked him to.
What part of BETA AND IN ACTIVE DEVELOPMENT did you miss the first time? The code is NOT intended to be 100% stable. Bossmods can be created by users of threat as well. Yes the RDX feature is kind of nifty, but threat can do it as well, there just isn't an interface for it.
I really suggest you read the thread, and try and grasp why the mod was developed before you come here and start bashing it randomly because you jumped the gun and forced your raid to rely on a beta quality mod. Again, it says "Use at your own risk" on the addon for a reason.
Out of curiosity are the shaman lightning bolt and [The Lightning Capacitor] bolts named the same in the combat log? If so, that may pose a problem for figuring out threat of lightning bolts for an elemental shaman with the trinket.
Unfortunately, Yes. *sighs* Not as with the extra one from Lightning Overload, anyhow, I'll get a proper logparse out for it in case you need one.
Ehlana, stop trolling. Take it to the curse-gaming KTM thread.
Originally Posted by frmorrison
That was a bad evening yesterday, I really like Omen and hard locks are annoying. I ended up disabling all addons because I didn't realize what was causing the issue at first, it was interesting playing with a base UI for a bit .
Thanks for updating I had no issues with an update around 10 EST, but try not to do that again.
I appreciate all your work!
And yes, basically, this. Antiarc, I think we all know we're using "beta" software here, and that development builds are grabbed with WAU, and so forth. I think we've all come to accept that sometimes we'll run WAU and some mod will stop working due to a library screwup, or will start spitting LUA errors, or will have odd behaviors. And then we either live with it, disable it, or revert to a stable build. But I can't say I've ever had a WAU download that hardlocked WoW without any obvious indicator of what was doing it except checking a changelog from my last WAU runthrough to see which mods might have changed in ways that might be likely to cause something like that. Not to belabor the point, but beta or not, the reality is that thousands, if not tens of thousands, of people are downloading each new build that goes up on wowace every evening before raid time. It's reasonable to expect that things won't work perfectly and that maybe threat will be wrong for a given class or a given mechanic or there'll be a display glitch. I don't think it's reasonable to have an infinite loop that occurs 100% of the time in group combat, because something was never tested at all.
If there's a change to some random bossmod, or to threat calculations with a particular trinket, obviously you as developer can't run out and test that, so of course it's quite reasonable to expect the userbase to test it. But changes that may or may not completely crash WoW should not go live without a basic confirmation that they don't, you know, crash WoW, or pop up a bunch of errors. There are an awful lot of changelog entries like "drycode fix to blah blah" followed 15 minutes later by "fixed typo in blah" and 10 minutes later by "fixed another typo, oops." Stuff like that just makes me glad I didn't happen to run WAU during one of those windows.
So yes, thanks for all the work, but please be mindful of the practical implications of untested releases.
Rather than incite the KTM vs.Omen debate within this guild, can anyone give a range of revisions to be avoided? I'd like to be able to tell people individually "hey, your Threat is going to freeze you up, please update" without making a big post about it. I'd hate for a badly coded release to make me switch back to KTM - the performance increase on my girlfriend's computer is hugely noticeable.
Rather than incite the KTM vs.Omen debate within this guild, can anyone give a range of revisions to be avoided? I'd like to be able to tell people individually "hey, your Threat is going to freeze you up, please update" without making a big post about it. I'd hate for a badly coded release to make me switch back to KTM - the performance increase on my girlfriend's computer is hugely noticeable.
4413X to anything before 44144, I'd say? 44144 was:
* r44144 | antiarc | 2007-07-18 19:52:42 -0400 (Wed, 18 Jul 2007) | 1 line
* Threat-1.0: Fix to the hardlock error. Infinite loops are bad, mmmkay?
I was wondering if there were any issues regarding the TPS calculations that Threat performs. During Morogrim tonight, Omen was reporting that I was sustaining over 8000 threat per second with spikes above 10,000. I'd like to think that I'm some crazy-awesome tank but I really think that something is just a bit wonky. For more information, it seems that the TPS number slowly creeps up over the duration of a fight (The reason I think it was so high on Morogrim was because it's a relatively long fight with essentially full rage the entire time)
Anywho, cheers and thanks for a great addon.
I've changed the TPS calculations considerably over the past few revisions - what revision are you using?
Yesterday I encountered the bug that our tank was not showing up on Omen anymore. He had no Threat/Omen installed and was running KTM.
A /reloadui fixed it. Running with Omen 43550 and Threat 44023.
Damn, thought I got that one. I'll doublecheck it.
Also on Nightbane I had a weird TPS number. He was landing again, and I had 0 aggro but a rather high TPS display:
The TPS number on the bar is relative TPS; since a clear just happened, you may have had a DOT tick or something, which would have put you at a good bit of TPS over the tank. I should probably clarify that number to show that it's relative TPS.
On Sunday we were killing Void Reaver and a Fire Mage had exceptional threat, although the fight had just begun. I suppose the threat wasn't cleared between attempts, but I cannot tell you if he had Omen installed (forgot to scroll up on the screenshot).
Do you have this mage's revision number? I think I knocked this one out a bit ago, but I'm not positive.
I experienced some rather strange issues with Omen at Hydross yesterday, on most occasions the threat meter would go completely nuts after a phase switch, and on some(very few) it would be perfectly fine.
Screenshot of what it looks like, Haven being a hunter pet:
Hm. Seems that pet threat isn't being cleared properly sometimes on a threat wipe. I'll check into it.
Can you explain to a UI newbee how to get the total TPS over a fight please?
Enable and position the "E-TPS" (encounter TPS) column in Omen. It went in last night.
We had some problemes with Omen yesterday on Essence of Anger (last phase of Reliquary of Souls). The threat table seemed to reset but some people (especially a paladin) kept high threat even if they didn't do anything in this phase. Apparently, the wipe threat function didn't wipe threat of everyone or something like that.
I suspect this paladin was healing? He'd have shown high general threat, but should have shown at low/normal threat on a specific target. There's actually no special handling for the Souls encounter; it just handles new mobs as new mobs. A threat wipe in the module would probably clarify it.
On a side note, there is no reset when Supremus switch back to "tanking phase", but you are probably aware of this.
Which locale? I have a module in there, and it seems that it should work (when it picks up the emote "Supremus punches the ground in anger!", it should reset aggro), but if it isn't still, then it needs some work yet.
Originally Posted by Gurruk
The description on files.wowace.com says this addon is still in beta. Is this your opinion Antiarc?
It is, yes. Hopefully, this won't be the case for much longer.
Could it be time to freeze the existing code base, work out all the bugs with threat calculations, display problems, and get a good known stable release so we can all move to it with confidence?
As soon as I have the last few showstopper bugs knocked out, you betcha. I want to get there as much as anyone.
I haven't made an official release yet because there are still bugs that will seriously impact Omen's reliability in raids (the uber mage threat issue is one), which is very bad to release to non-early-adopters who update their mods once every six months. I want the first official stable release to be as...well, stable as possible.
Originally Posted by Elhana
atm Threat+Omen uses more ram with libraries than KTM
Threat+Omen sans libraries use about half of KTM's RAM, and they very certainly use far less CPU, which was the driving factor in the first place. In any setup where you have a decent number of Ace mods, Threat+Omen ends up using fewer net resources, both in terms of RAM and CPU.
now explain me what for "for _ = 1, 1 do ... end" is here?
That's a ckknightism, actually. It's an implementation of a case statement, since Lua doesn't natively support them.
More than anything. Threat's code structure is designed to be modular, so that changes can be made in the appropriate areas without having to dig through reams of code to find what you're interested in. Warrior threat change in a patch? Change the warrior module. New debuff in a boss encounter? Change the debuff module. New boss encounter to add handling for? Create a boss module for it.
And I would hope Antairc cares if people use his addon. What I'm not sure he realizes is just how many people are using it and how important it is to move to a more pragmatic approach to updating.
I very much understand this, and I have specifically not made an official release due to this. Subversion is, in the end, for source control, rather than a publishing platform. It is a de facto publishing platform in the Wowace case, but I have specifically not stamped the mod production ready, as I want people to understand that I am still aggressively developing it, and things sometimes break during that development.
Originally Posted by Spider
As an Elemental Shaman, Your main spell is Lightning Bolt
This gets affected by your lovely little talent called "Elemental Precision" for a nice amount of threat reduction.
However. If you add another fun little toy, Called [The Lightning Capacitor] you end up throwing out another Lightning Bolt once in a while. (Well, With a 43% critrate you end up tossing it out 1 in 7 bolts, but that's another matter) which in fact -doesn't- get the Threat Reduction from Elemental Precision talents.
Now I'm in a bit of a bind, as a threat-restricted class you are very dependant on your threatmeter to hold you back, and finding out that after, say, 4 minutes of combat you are ~13-18k higher in threat than you are according to the threat meter, you have some nice issues. :-/
Sad to say, I've wiped my party on the prince due to this bug a couple of times before I figured out what the heck was up. Hopefully this means someone will either fix it, or b) that its reported for posterity.
Unfortunately, yeah, this has me in a bit of a pickle as well.
Lightning bolts from the Capacitor are half threat; however, they share the same name as the Shaman's lightning bolt in the combat log, which makes distinguishing them tricky, to say the least. It's a to-solve issue right now, but I don't have a good solution at the moment.
If you proc the capacitor one in seven casts, and you have elemental precision, then your threat should be reported as:
8B * 0.9
When in fact your threat should be:
7B * 0.9 + 0.5B
So you should end up with threat showing slightly higher than it actually is.
If anyone has ideas, I'd love to hear 'em.
Originally Posted by Elhana
Just to clarify it was just an example or something useless in Antiarc's "clean" code, just opened a file for a few seconds.
Nevertheless Threat code atm looks like a bunch of hacks all over it with variables/functions defined in order they were coded.
I think you'll find most of those "hacks" are actually carefully considered decisions, made with the goal of optimizing Threat as far as possible. You are, no doubt, criticizing the heavy usage of locals; there's a reason for this. An upvalue lookup is significantly faster in Lua than a table lookup, and Threat has been written with this in mind.
10 kb of code? well, then you can take addon A, get all of it's code into some other file, call it a library and keep a loader 1 kb in size and claim your addon is 1kb. Fact is Threat and Omen being run alone with it's libraries take more memory than KTM being run alone.
This is certainly correct. It's also correct that in the vast majority of real-world cases, the majory of those libraries are shared between multiple mods, which lowers your net resource usage, which is the only thing that matters in the end. Stuffing your code in a library doesn't mean a lot if that library doesn't get re-used. In the case of Ace libs, it very certainly gets reused.
The only major advantage of Threat library is a fact that it uses parser library which is in fact the greatest advantage Ace mods have over standalone ones since it allows the most intense part of addon to be split between multiple mods, but it is hardly a Threat/Omen accomplishment.
Oh, I wouldn't say the only advantage. You're forgetting the significantly lower CPU usage, and the multi-mob support, and the fact that any number of mods may be written to display threat data now, and the fact that localization tends to be done more quickly and more completely, to name a few.
On the other hand seeing how Threat/Omen doesn't really care about users, but more of it's bloated greatness and virtually less resource usage at the same time allowing such silly things as softlocks to be committed without any testing whatsoever into the main code branch, KTM with it's pcalls and slow paced updates seems way more friendly to end user atm
Honestly, this is just a silly statement. Of course I care about the users. I'm user #1 myself. Bugs happen in software; quite often, in fact, in beta software. They get fixed in an hour and we move on with our lives. Anyone using Omen right now likely understands that it is still not even RC1 software. Does that mean I'm not embarrassed about my goof yesterday? Not at all - I'm not happy at all that I managed to miss it. But, what is there to do but patch it up and continue on?
So yes, thanks for all the work, but please be mindful of the practical implications of untested releases.
I certainly do try to be. I get a lot of feedback from EU guilds while I'm at work during the day, and do this weird fix-release-test thing with 'em. I syntax-check code locally before committing it, but without the full WoW environment, it's not possible to comprehensively check it, I'm afraid. Big changes generally get put off until just before I go home (where I then test ASAP), but yeah, sometimes, things just go wrong. The infinite loop yesterday was by far my worst goof yet, and I certainly hope to avoid repeating it in the future.
Apate, avoid revisions 44133-44142.
Looking at this, it appears that they were about...76 minutes apart. The sheer number of people that managed to snag those revisions in that time period is certainly humbling.
Looking at this, it appears that they were about...76 minutes apart. The sheer number of people that managed to snag those revisions in that time period is certainly humbling.
That's precisely because of the timing, though. If the bug had been introduced at, say, 10pm, and then fixed at 11:30pm, you likely wouldn't have heard much of an outcry at all. Just as you come home from work at 7pm and fiddle with testing and tweaking the mod, most people also come home around then, and that's the prime "pre-raid-start" window right there. Personally, I probably run WAU nightly at around 7 or 7:30 to update my mods before the raid. A lot of people do, and with the built-in "X has a newer version of Threat than you do" notice, a lot of people will relog to update again once they see someone with a newer build, right up until raid start time.
Odds are, if you commit a change before leaving work, and then test it right after you get home, a ton of people are going to download that interim build during that window.
07/19/07, 9:42 AM
.
Similar Threads
