tag:blogger.com,1999:blog-70944114201351596042024-02-02T07:19:06.844+01:00Real World FeralHelistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.comBlogger40125tag:blogger.com,1999:blog-7094411420135159604.post-33531737880179453852013-03-08T14:56:00.002+01:002013-03-12T16:31:33.978+01:005.2 combat log changesI've done some more (mostly random) work on the code, and I've decided that I should completely decouple some parts (like DoTs) to write them as "general code" calling some DoT-specific logic at times.<br />
Then 5.2 arrived and messed up the parsing.....<br />
Blizzard seems to have added 6 fields (one GUID + 5 integers) at random in combat log events. I say 'at random' because even if the placement is constant, the presence is not. Monk HoT ticks have this additional information, Druid HoT ticks don't. Looking at the data it *could* be that the data is about the spell/event target and the 5-digit numbers make me guess current HP/mana, but I have no idea what the additional 3 values may be, and even less I can guess why only some events have it.... (maybe it's a "work in progress" and they have not yet updated all spells to support it?).<br />
I have fixed the parser to be able to deal with the new logs, but I'm waiting to see if I can get some solid information on those numbers to see if there's anything exploitable for health (or energy) tracking.<br />
<br />
UPDATE: ok, my random guess is as good as anyone's after playing with SPELL_CAST_SUCCESS:<br />
<br />
Caster GUID, Caster HP, Caster Mana, unknown, Power Type, Power Amount *after the cast*<br />
<br />
If it's true then health/energy tracking has become a whole lot easier!<br />
<br />
UPDATE 2: thanks to the guys at WoL, the values are:<br />
<br />
1: GUID<br />2: Health<br />3: Attack power<br />4: Spell power<br />5: Resource type<br />6: Resource amount<br />
<br />Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-68163962898183084272012-12-20T09:27:00.000+01:002012-12-20T09:27:22.567+01:00DoT code rewritten, but........it doesn't work (yet :). Apart from de-duplicating the code, I have prepared a simpler (better?) framework to put in the checks for "errors". I'm also thinking about indicating the absolute/relative tick damage change on a DoT refresh, in line with the current trend of "refresh if damage is boosted".<br />
The absolute priority is making sure that the code does not segfault every time a dot is applied, as it is doing now :), and with the Christmas holidays coming up I should have enough time for a new better, shinier, release!<br />
<br />Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-36971519393144360342012-11-14T15:41:00.000+01:002012-11-14T15:41:30.772+01:00Rewriting in progress...Apart from minor fixes, like adding support for Shred! (which is not the same spell Id as Shred), so that Glyph of shred can be taken into account, I've started rewriting the way damage and DoTs are processed. For the moment I've improved the statistics, but I still need to un-triplicate the DoT code and I'm also thinking on how to correctly deal with block/absorb, so that damage is correctly taken into account.<br />
Sooner or later I should also add support for crit normalization (= "normalizing" your damage/DPS to the value it would have if you didn't have luck/unluck with crits or OOC), but that's still far away. The main objective is to get the visualization to correctly deal with everything.<br />
Side note: Garalon down, and the log has an interesting "problem". The legs are "recycled", in the sense that they don't behave like adds which die and repop: there's no UNIT_DIED event or anything similar, and they always have the same id. This is good, because you only have four "adds" in the display, but at the same time it's impossible to know from which moment to which moment they existed, so any attempt at calculating an aura uptime in % is impossible.....<br />
<br />Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-5873693756808941312012-11-10T09:01:00.000+01:002012-11-10T09:01:21.609+01:00Version 0.3.1 outI've just uploaded version 0.3.1, source only for the moment, I'll rebuild the windows executable during the morning.<br />
Notable changes are that I fixed one crash, and started adding support for Soul Swap. Problem is, it's a bit of a mess, and I never wrote "correctly" the code for DoT management, as a result I have the DoT code in triplicate (Rake, Rip, Thrash) so I need to do a lot of cut-n-paste when I add stuff to the DoTs. This cannot go on, so I'll rewrite the entire thing as soon as I can to centralize the DoT code. For the moment Soul Swapping rake works, the other DoTs are still swapped, but the swap is not recognized as a Soul Swap, so the code complains about a lot of stuff (Rip applied at less than 5 CP mostly).<br />
I've also added some more statistics on the attacks: in particular the calculation of the "real" DPE (damage-per-energy) associated to the attacks. This allows you to see how incredibly good Thrash is as soon as you can hit more than one target :)<br />
<br />Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-79141476769285491712012-11-08T15:54:00.000+01:002012-11-08T15:54:50.829+01:00Autodetection of talentsWell, I just realized that asking the player for talents is useless, since all the relevant ones are easily spotted in the combat log (source = you, spellid = the one of the talent), so I've modified the preprocessor to detect the talents.<br />
I've added skull bash to the energy tracking, and I've fixed an error which was reporting swipe twice in the OOC allocation pie chart.<br />
FB refreshes of rip now correctly propagate TF/DoC boosts, and the warning for too few shred extends is turned off as soon as you start to refresh rip with FB.<br />
Activity tracking is still a complete mess, reporting hours-long casts of Healing Touch, I'll have to look into that, but I'm starting to wonder if that display is of any use whatsoever.<br />
In the week-end I'll try to fix some more stuff and then I'll put out a new release.<br />
<br />Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-9504090414445265902012-11-05T15:21:00.000+01:002012-11-05T15:21:33.450+01:00Dream of Cenarius has no dosesOk, so I finally got a log with Dream of Cenarius. The good: my code to mark DoTs as "DoC boosted" worked on the 1st try. The bad: since DoC has two charges I was expecting it to be handled as a 2-stack-maximum self-buff. Well, it isn't. DoC, the damage part, spell id = 108381 does not have AURA_APPLIED_DOSE or AURA_REMOVED_DOSE, it's just APPLIED or REMOVED. I'm also thinking about a way to indicate which of your attacks are DoC-boosted beyond DoTs... I guess I'll add one more element to my display class to provide an additional "flag" to events.<br />
Apart this I have some weird stuff happening (all heals are marked as crits, go figure why), I had to fix once and for all the friendly fire problem (which was segfaulting the program), the "Cowardice" debuff/DoT on Spirit Kings was killing the health tracking since it has no source, I was getting some nice error report on Berserk cast, of the kind "Error: energy below 80" and at the same time "Error: energy above 79", which makes for a narrow margin of error :P<br />
As soon as I get that stuff cleaned up I'll go for a "prerelease"! Stay tuned (but don't hold your breath).<br />
<br />Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-32790466743542306342012-10-31T03:57:00.000+01:002012-10-31T03:57:55.387+01:00Health trackingActivity tracking is still MIA :), but health tracking turned out to be a lot simpler than I remembered from my tanking days. I think there are two reasons for this: first is that I don't care for precision, I just want to "give an idea", which makes life very much easier. When you're not dealing with exact numbers, you can safely ignore the total HP pool, effect of raid buffs on Stamina and temporary health enhancements (Might of Ursoc and friends). Of course the result will be approximate, but if you're sitting in bad stuff it'll show up clearly, and that was the original idea.<br />
The second reason is associated to the changes brought by Cataclysm: much larger health pools and "smaller" heals. In Wrath, tank HP were oscillating like mad, here I'm testing tracking on a DPS (much smaller damage intake) and huge health pools which are not meant to be healed in a single spell. As a result, the inconsistencies coming from the timing issues (sequence errors resulting in heals arriving before the damage is inflicted) are a lot less visible.<br />
I had to do some internal changes, so that on the health display zooming in provides better resolution for picking and displaying events (there are tons of small heals going on...), and I did some other minor quality of life improvements. As soon as I can get a windows compiler running, I'll create the "MoP release" and put it up for download. If you're curious: health tracking in the final Elegon phase looks like this:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIrbfH4JBNDuf4Ngsz52ohUBZIzgzfGUFCYUBw7Mc4hAD-J7Y107giHlfiqvd-cg_pbabV-XuhIGi0JfM2WUN_nMnR-suV0e9rGs6g_cWE31GUd9fO1t-U58qivZmjZyG9MC3RJNsVcPI/s1600/health-tracking-example.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="78" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIrbfH4JBNDuf4Ngsz52ohUBZIzgzfGUFCYUBw7Mc4hAD-J7Y107giHlfiqvd-cg_pbabV-XuhIGi0JfM2WUN_nMnR-suV0e9rGs6g_cWE31GUd9fO1t-U58qivZmjZyG9MC3RJNsVcPI/s320/health-tracking-example.png" width="320" /></a></div>
<br />
(in case you wonder: the final red line is Elegon one-shotting me with his final attack)Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-41175786256452700682012-10-29T16:20:00.000+01:002012-10-29T16:20:26.399+01:00The endless castSince I'm abroad I don't have access to any "new" logs to play with. In particular, I cannot test DoC/NV since I don't have here any logs where I used them..... I've put the code in, but I'll be postponing the tests until I can create some appropriate logs.<br />
So I have decided to add activity tracking: the idea is to see if you are a key-spammer (tons of cast failed due to GCD / low energy) or a classy-clicker (just press the key once exactly at the right time. Of course, it turns out that it's not so easy. Apart from the negative-time casts (which I can try to detect as instant cast since I have the spell effect just before the cast_success), I've found a new gem: SPELL_CAST_SUCCESS is used for instant casts, but it doesn't appear in the log for channeled casts. What I mean is this:<br />
<br />
10/17 00:10:27.143 SPELL_CAST_START,0x0180000001B138CB,"Helistar",0x511,0x0,0x0000000000000000,nil,0x80000000,0x80000000,5176,"Wrath",0x8<br />10/17 00:10:28.189 SPELL_CAST_FAILED,0x0180000001B138CB,"Helistar",0x511,0x0,0x0000000000000000,nil,0x80000000,0x80000000,5176,"Wrath",0x8,"Another action is in progress"<br />
10/17 00:10:28.959 SPELL_CAST_START,0x0180000001B138CB,"Helistar",0x511,0x0,0x0000000000000000,nil,0x80000000,0x80000000,5176,"Wrath",0x8<br />
10/17 00:10:31.163 SPELL_DAMAGE,0x0180000001B138CB,"Helistar",0x511,0x0,0xF130EBFA00004EBC,"Elegon",0x10a48,0x0,5176,"Wrath",0x8,308679,-1,8,0,0,0,nil,nil,nil<br />
<br />
The SPELL_DAMAGE event corresponds to the *first* Wrath cast (remember, Wrath has a fairly long "flight time"). This means that I have no way to detect that the actual casting of Wrath has ended, except guessing it from the fact that I had another CAST_START. This also means that I have no easy way of knowing if the player is idle or not. I'll need to do some tests, but I fear I'll be forced to go dig in the CAST_FAILED error message to see *why* it failed, in order to understand if it's just a key-spam while already casting (= you're not idle), or if the cast really failed because you moved (or the target died, ...), in which cast the CAST_FAILED indicates a transition back to the idle state.<br />
And it's actually worse: if you cast a single Wrath, I have no way of knowing that the casting has ended.... since the spell effect (SPELL_DAMAGE) will appear a lot later.<br />
<br />
I don't know why, but I'm starting to think that this whole "activity display" thing is a bad idea.....<br />
<br />Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-48755414411960405052012-10-25T07:33:00.000+02:002012-10-25T07:33:13.725+02:00Cast, instant cast, *negative-time* cast!More combat log weirdness.<br />
Even more weird since it cannot be due to multiple clients having different latencies and the lag-compensation code messing the timestamps: here I am healing *myself*:<br />
<br />
10/17 00:17:00.970 SPELL_HEAL,0x0180000001B138CB,"Helistar",0x511,0x0,0x0180000001B138CB,"Helistar",0x511,0x0,5185,"Healing Touch",0x8,92919,0,0,nil<br />10/17 00:17:00.991 SPELL_CAST_START,0x0180000001B138CB,"Helistar",0x511,0x0,0x0000000000000000,nil,0x80000000,0x80000000,5185,"Healing Touch",0x8<br />
<br />
The healing touch healed me 21ms *before* I even cast it.....<br />
In the best of worlds we would have SPELL_CAST_START followed by SPELL_CAST_SUCCESS and then SPELL_...whatever effect it does...<br />
Or maybe, for an instant spell we could just have the effect, or if we really want to keep track of client/server latency, SPELL_CAST_START followed by the spell effect.<br />
Clearly, we are not in the best of worlds.<br />
Before you ask: yes, this makes for nightmarish scenarios where some poor piece of code sees a cast_start and hopefully waits (forever...) for the spell effect to take place (solution: ignore the cast_start). It's bit like the horrible consistency errors you get on bosses like Ultraxion or Gara'jal where the logs of players from one "dimension" are missing all the information about those in the other dimension, leading to all possible aura-uptime consistency failures....<br />
<br />Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-65544345309280362522012-10-23T10:19:00.001+02:002012-10-23T10:19:59.678+02:00Updates, updatesThe list of stuff to add is growing, but the code is not :) this is not good.<br />
I need to add the heals/DoC detection/Wrathspam and I just found out that I messed up Soul of the Forest, which, unbelievably, actually appears as SPELL_ENERGIZE in the log.<br />
I have checked the damn Rip uptime log thing and it's trouble:<br />
- applied at (seconds) 12.831 (expected to end +16s later, so at 28.831)<br />
- refreshed 3 times by shred (so expected to end in total at +22s or 34.831)<br />
- gets refreshed by another Rip at 38.166<br />
Now, I know that one extra tick is possible, which would place the expiration at 36.831. I also know that the aura is "sometimes" longer (even if it appears correctly to end at the last tick in EventHorizon). But this is almost 1.5 AFTER the exceptional tick. It's not a +6s shred refresh, it's almost +10s refresh (9.33 to be exact). I don't know exactly how to deal with this. I will alter the BitW code to be a lot more tolerant (+3.3s/shred instead of +2s), but I'm wondering if something is going wrong...... the rip refresh mechanism has always been "weird", but it's the first time I see it being *so* weird.<br />
Whatever... I'll see if I can cook up a release in a couple of weeks.<br />
Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-73372987279977445262012-10-17T13:34:00.001+02:002012-10-17T13:34:54.400+02:00Elegon down, and Rip woes....Ok, so Elegon is down. Ugly down, we (barely) won. So I feed the log to the analyzer and I find that I suck (hardly a surprise), but also that there is a phase where Elegon is DoT-immune (I had not really cared much to check, it seems to be during the p2-p1 transitions, from a cursory look).<br />
But there's stuff going wrong: I have a BitW range which starts in phase 1, which is definitely wrong. Looking at the visualization it seems like there's a Rip which is lasting too long. I know that 1 extra tick is possible, but here it's more than that. Usually, even when one extra tick is added, the aura fades immediately afterwards, but here it seems like there's a refresh after half a tick, and this with 4 extra ticks. Since visualization is independent of the preprocessing, it means that there really is some spell_periodic_damage going on. I'll have to go through the log in detail to see what happens. Blizzard does weird stuff with the logs at times (and not just logs...) :).<br />
<br />Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-5247900560908065292012-10-11T17:55:00.000+02:002012-10-11T17:55:58.384+02:00RWF for MoPI've started updating RWF for Pandaria.<br />
<br />
There is a ton of changes, mostly in the amount of stuff to track. Some mechanics have changed as well, so my energy check for TF are failing systematically, I'll have to look into detail to see what's going on.<br />
I also have no idea on how to provide a "quick" display on the buffed status of DoTs, which can now be buffed by TF, DoC and (rarely) agi potion. I think it would be nice to be able to quickly see if a DoT was buffed and by what without being forced to hover on it, but there are a lot of combinations, so using colors would be an utter mess. I'll probably stick to "red = error, yellow = unbuffed, green = buffed by at least one thing" and let the user hover on the DoT to see the details.<br />
There were also some random changes in the combat log, such as the type of environmental damage being written lowercase instead of uppercase (which crashed the parser.....), I guess that with time I'll be able to clean them up.<br />
Well, at least the preprocessor to locate the execute (BitW) range works.<br />
Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-59995221571619566382012-01-31T14:40:00.000+01:002012-01-31T14:40:40.025+01:00RWF for 4.3 up and runningI've finished the FB preprocessing thing and found that the lack of AURA_REFRESH events for Rip was also messing up other things. I've put in a horrible workaround, but it works, so who cares? :)<br />
Contrary to my initial impression, melee haste auras continue to be a problem, Hunting Party is nowhere to be seen.... Also, several skills changed their IDs, so some detection is messed up, I'll think about this later on. Correct haste management is still on the TO-DO list: Heroism/BL/TW are correctly handled, but trinkets require a lot more work (= add them one by one), so they are out for the moment.<br />
After a hardware upgrade, my windows environment was completely reinstalled, so I'll have to reinstall Qt as well before I can compile the windows executable. I'll try to do it before the week-end.Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-55608491669210996462011-12-09T10:12:00.000+01:002011-12-09T10:12:00.012+01:00FB preprocessingSince detecting FB-refreshes is impossible, unless you wait for Rip to be refreshed a 4th time by mangle/shred, or go for a more reliable approach of checking if it ends when it shoud, I've decided to use a different way and do a preprocess phase of the combat log, where I only look for FB/Rip durations. This allows me to pre-flag the FB events as "refreshes" and makes the analysis code less messy.<br />
Alternatively, I could go for some on-the-fly log editing, adding AURA_REFRESH events for Rips where they should be. I'll try both approaches. Whatever the result, having a preprocess phase will make life easier for several other things (I could consider moving the OOC use detection there, for example).Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-77870727303483080852011-12-01T17:50:00.000+01:002011-12-01T17:50:35.330+01:004.3Melee auras: it seems like Improved Icy Talons is there. I need to check out more in detail, but this is good. No idea about the others, but there's hope!<br />
<br />
FB/Rip refresh: nope. Argh :(<br />
<br />
I think I'll just disable any error checking on FB and just report the time left on SR/Rip, leaving the user to decide if it's an error or not.Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-8344661505842548612011-11-28T13:31:00.000+01:002011-11-28T13:31:35.453+01:004.3 incoming, will the fixes be there?I'm still waiting to post a new release to see if 4.3 finally fixes all the crap which was not fixed or clearly added by 4.2. I mean:<br />
- melee haste auras not present in the combat log<br />
- Rip refreshing by Ferocious Bite reported in the log (which was working, but "disappeared" in 4.2).<br />
<br />
Together they make annoying things to do during the analysis, since they are not easily guessed. It's of course possible to code workarounds, but it should not be necessary, and I'm not too hot on playing guess-the-FB-refresh in multitarget scenario, only to see it fixed in 4.3.<br />
<br />
BTW a gem from the last logs I'm playing with, it's about melee haste auras:<br />
<br />
Hunting party?<br />
> grep Hunting 111102\ 203427.txt<br />
no output.<br />
<br />
Maybe Windfury Totem?<br />
> grep Windfury 111102\ 203427.txt | grep AURA<br />
no output.<br />
<br />
Ok, so it'll be Improved Icy Talons:<br />
> grep 'Icy Talons' 111102\ 203427.txt<br />
11/2 22:07:44.055 SPELL_AURA_APPLIED,0x01800000037824B0,"Unknown",0x518,0x0,0x01800000037824B0,"Unknown",0x518,0x0,55610,"Improved Icy Talons",0x10,BUFF<br />
Wonderful: in an entire raid evening with multiple wipes, we have a single application, from an Unknown unit to an Unknown unit....<br />
<br />
Insert obligatory "WoW coding going downhill, end of WoW, film at 11".Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-3372142607097424262011-06-01T17:41:00.000+02:002011-06-01T17:41:00.422+02:00Parallel cat-o-rama?I'm having some "fun" with OpenCL. If you have never heard about it, it's a computing language to perform general-purpose programming on GPUs. Since the current-generation GPUs pack a ton of processing power, it can lead to some impressive speed-ups, if you recode the time-critical part of your program and make them run on the GPU. Only caveat: the GPU is massively parallel, so if your problem is not suitable for parallelization, you have a problem (and you lose performance).<br />
Of course things are not as easy as the tutorials online make it: coding is trivial, but getting good performance is a nightmare of memory-access optimizations. This is because even if the GPU has massive computing power, the memory latency is enormous, and unless you arrange the execution of your code so that memory accesses (intrinsically slow) can be "coalesced" (= many programs access contiguous memory at the same time, leading to a single operation), performance gains can be minimal. Still, when things work it's fun: right now I'm trying different approaches for a 7x7 image box filter. I'm at x100 execution speed-up (note, filtering calculation only, I'm forgetting about the computer<->GPU memory transfers, which add some more time, bringing the speedup to some x40-50 "only"), but I'm trying to see if it's possible to do more....<br />
<br />
What's the relation to WoW? None. Except that making a cat simulator which can run on the GPU would be nice and allow for some serious kick-ass speedup of the simulations (simulating multiple combats is very parallelizable and very little memory-bound if all you care about is the final DPS).<br />
Genetic cat optimization algorithms, anyone? :)Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-26314793254339775452011-05-05T19:55:00.000+02:002011-05-05T19:55:02.918+02:00Energy reconstructionEven if I'm silent, the energy reconstruction code keeps improving. I've actually managed to have the "used" and "regen" totals match exactly. Ok, it was a test fight using only mangle and avoiding any weird scenarios, but it means that the changes which I did to the way energy tracking is performed are getting better and better. I still have some trouble with FB, and I need to test the +10% melee auras, because things look weird when I test on some real raid-25 fight.<br />
For the moment the melee haste auras are hardwired to "true", I'm still thinking about the best method to detect them.Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-59631679557791443202011-04-07T13:24:00.000+02:002011-04-07T13:24:28.563+02:00After too many Tol'Vir runs....<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLrsVKEsnhw_2jZsFyvA660EtXjTjzq3cEAvISyFK0j527serypAOqpf3SG5D_LUs7IPYIaIi5v9Act5YsmUYy5sCDe7WWMKoEYiVMq0XUcqJElfIIcd_HhfUUFIYNCVEKO041gsgUWBc/s1600/guild-level-25.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="161" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLrsVKEsnhw_2jZsFyvA660EtXjTjzq3cEAvISyFK0j527serypAOqpf3SG5D_LUs7IPYIaIi5v9Act5YsmUYy5sCDe7WWMKoEYiVMq0XUcqJElfIIcd_HhfUUFIYNCVEKO041gsgUWBc/s320/guild-level-25.jpg" width="320" /></a></div>Ok, completely useless (except for the mass-rez, which is nice), but still good to have. Ah you also get access to a mount, which I don't know if to define "ugly" or "more ugly".... in any case definitely not "beautiful".<br />
<br />
I'm planning a new RWF release shortly, but the detection of errors for the use of FB is still wrong, and I need to hack in a way to detect the melee haste auras, which ARE STILL NOT REPORTED in the combat log.....Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-13418911786236660902011-03-29T17:16:00.000+02:002011-03-29T17:16:12.987+02:00Primal MadnessIn the energy reconstruction I've hit another problematic detail: Primal Madness, which increases the energy cap to 120. This is not complicated in itself (my code can handle a changed energy cap just fine), the problem is as in FB: WHEN does the energy cap change happen? Is it client-side or server-side?<br />
<br />
Looking at the log, it seems like the Primal Madness aura is applied client-side, i.e. immediately after the cast of TF. This would mean that the +20 energy bonus is applied immediately. But during my tests I found a strange behaviour in one log: immediately after TF (which includes the AURA_APPLIED for Primal Madness), I have one cast which fails with "not enough energy", even the energy amount + the 20 provided by PM should make the cast possible. Seeing that the cast has failed, the code lowers the current energy value, which already includes the +20, and I fear that this is messing up with the rest of the reconstruction (ok, the effect will be small).<br />
<br />
I'll do some more tests, spamming mangle (or shred) while activating TF at different times/energy levels, so as to see if the +20 is applied at aura application time (= immediately), or it's postponed until the SPELL_ENERGIZE event provided by TF (which, BTW stays at +60 even for a PM talented cat).Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-35762052045458495692011-03-25T15:09:00.000+01:002011-03-25T15:09:50.369+01:00FB and extra energy consumptionLooking at my energy bar during fights seems to indicate that the same problem of client/server time "separation" occurs for Ferocious Bite. In a mix of the two scenarios of my last post, it looks like FB drains the base cost (the one which can be eliminated by OOC) client-side, i.e. immediately at the CAST_SUCCESS event, while the extra energy is drained at application time, i.e. SPELL_DAMAGE event. While this is not particularly complex in itself, it raises some questions on how the extra energy is calculated.<br />
<br />
Possibility 1: client-side. When you execute a FB, the client sends the server both the order to do FB together with the current energy level, while at the same time draining the base cost (which is guaranteed to happen). Upon actual execution, the server uses the energy value you sent (checking it for consistency) to determine the extra energy and sends back a message with the damage and with the energy amount actually used, so that the client can update.<br />
<br />
Possibility 2: server-side. The client just sends the order to FB while draining the base cost, the server looks at the current energy and determines the extra amount, returning it to the client together with the SPELL_DAMAGE event.<br />
<br />
The difference is small, and can be quantified to be the amount of energy regen occurring during the network transit (which can be non-negligible, especially if you're testing in SW...). Since I don't really know how to reliably test it without things being complicated, I'm assuming that the extra energy is determined at cast time, i.e. when you press the key the extra energy is EnergyNow - BaseFBCost (capped by the max extra energy), which is possibility 1. Whatever the case it won't play a major role.<br />
<br />
Apart from these minor details, energy reconstruction looks more reliable now, but I still have an error (more regen than used). What surprised me is that on the test log I'm using (shred only), it's almost exactly 40 energy, which is definitely suspect.... almost like one normal shred ended up being counted as OOC-powered..... I'll do more test runs and keep improving things.Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-49870317801924239602011-03-22T15:19:00.000+01:002011-03-22T15:19:16.224+01:00Energy.... againOk, I've decided to face reality and now I'm implementing energy tracking "right". Which means using the right events to perform energy updates. After some testing with VERY weird results, it turns out that using SPELL_DAMAGE events doesn't cut it, and energy tracking must be done right, i.e. using SPELL_CAST_SUCCESS to substract energy and SPELL_MISSED for energy refunds. SPELL_ENERGIZE to account for energy boosts was already done right. It's interesting to see the weirdness of energy checking/usage which is done partly client-side (SPELL_CAST_SUCCESS is client-side timing) and partly server side (SPELL_ENERGIZE provides energy at spell execution on the server). The result is for example that if you Mangle, the Mangle energy cost is subtracted immediately, while the energy return of Tiger's Fury is delayed by your lag. I'm also adding in handling of Primal Madness and the related /cancelaura to correcly manage the 20 extra energy provided by the talent.<br />
<br />
Overall, the new version will have a more reliable energy tracking (assuming the right values for haste are used), and also more reliable error indications.Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-57396954252139950952011-03-21T13:16:00.000+01:002011-03-21T13:16:21.734+01:00...and completely unrelated:In addition to WoW I'm also playing LotRO, with an elven hunter (which I later discovered being the absolute noob-indicator in this MMO) and an elven warden (which is sub-optimal, human is better, but I don't give a damn).<br />
<br />
Overall, I find LotRO to be a 2-3 years old version of WoW, with slower combat and annoying grinding (in particular traits and reputations), something which WoW has finally evolved out of.... almost (*cough* Tol Barad *cough*).<br />
<br />
As much as the huntard...hunter I mean...is absolutely bland when it comes to gameplay (press button -> do damage, press another button -> do more damage), the warden has an interesting feel, even if I've been too scared to actually go and tank an instance. The lack of an automated LFG tool is part of the problem, spamming LFF is not for me. I'll definitely try it sooner or later, the idea of a tank without taunt, holding aggro via AoE dotting and threat transfer is definitely a change.Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-18419993531176299992011-03-10T11:01:00.000+01:002011-03-10T11:01:50.996+01:00Back in businessAfter a pause, I'm restarting developement. I feel that my DPS is not up to par at the moment, and I need to know why.<br />
<br />
So I'm back coding RWF, fixing some long-standing problems (for example crashes when it incorrectly detects a enemy unit as a friend). I'm still thinking about a way to add combat-dependent stat weights, but for the moment I cannot think of anything except using the damage % from the various abilities and using the way they scale off the stats to determine the coefficients. One thing is sure: while this approach was definitely "sucky" in the past, due to combo point management, the current "never FB just spam shred" approach makes it a lot more precise, since combo point management has became almost meaningless.<br />
<br />
Stay tuned :) (but don't hold your breath).Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0tag:blogger.com,1999:blog-7094411420135159604.post-35248917430246188342011-01-01T10:56:00.002+01:002011-01-01T10:56:14.452+01:00Happy new year!Happy new year to all cats and bears (ok, and other forms too :).<br />
<br />
I've not been advancing much.... I'll try to restart the developement now that the leveling is out of the way and we're returning to a normal raid schedule.Helistarhttp://www.blogger.com/profile/01435861741164342377noreply@blogger.com0