Would it be possible to implement some kind of visual indication when syncing occurs and who its syncing with? It's just trivial i guess, but i wouldn't mind knowing when Recount actually syncs, so i know that my data is correct. DamageMeters had this, and i liked it. Completely optional ofcourse.
Recount invokes sync exchanges only under two conditions: You join a group, and after the group has left combat. It only syncs with folks who were out of the theoretical combat range (isvisible).
I can see eventually adding visual feedback though I find it not a crucial feature. But before I ever do that I'd want a better sync solution than is currently in place. Trouble is I know of no better solution.
Dunno if its intended, but i consider it as a glitch :
environmental dmg (eg falling dmg) is switched (enabled/disabled) by the non-trivial mob checkbox. Id rather consider environmental as unknown, but dunno what the author intended there.
You could add a little star symbol next to the player name, indicating that that player has Recount installed and data you are displaying is synced from that player. Players without stars would then be unsynced.
I'm a bit confused with this new combatlog range. It got described as ''Tracks as much as the Combatlog can see''. Does this mean that increasing View Distance (graphical setting), will make the combatlog track more?
That's a good question but as far as I know view distance does not affect mobs the same way as it affects environment, if it affects mobs at all. Also I don't know what the shortest view distance is and if that's not beyond typical mob loading distance. Also mobs can in fact be loaded into view rather late, as anybody who has flown over outlands with just some latency has probably experienced.
Really I do have only limited hard evidence about a lot of this, and basically the whole behavior of the combat log range still anchors about a Slouken post that states that the combat log range is now all that you can see.
Certainly lack of precise knowledge of this is one part why it is hard to come up with really good (that is fast and bandwidth-friendly, yet accurate) syncing algorithms.
Certainly I have seen quite a few things, specifically things reported to self that are odd (i.e. one not seeing self-reported heals at the level others see it) which cannot be explained by any range theory. I have no clue under what conditions this can occur or if it even can be predicted and countered in any meaningful way (in lieu of brute force syncing which is basically a no-no for loads of people given the bandwidth demand).
@csun: Unknown isn't quite right either (this describes sources and targets that for technical reasons are currently unidentifyable). Really ideally there should be a "Other" or "Environmental" category. I'm not sure if this really warrants the effort though. I'm fairly content with the environment being a non-trivial "mob" for now.
That's a good question but as far as I know view distance does not affect mobs the same way as it affects environment, if it affects mobs at all. Also I don't know what the shortest view distance is and if that's not beyond typical mob loading distance. Also mobs can in fact be loaded into view rather late, as anybody who has flown over outlands with just some latency has probably experienced.
Really I do have only limited hard evidence about a lot of this, and basically the whole behavior of the combat log range still anchors about a Slouken post that states that the combat log range is now all that you can see.
Certainly lack of precise knowledge of this is one part why it is hard to come up with really good (that is fast and bandwidth-friendly, yet accurate) syncing algorithms.
Certainly I have seen quite a few things, specifically things reported to self that are odd (i.e. one not seeing self-reported heals at the level others see it) which cannot be explained by any range theory. I have no clue under what conditions this can occur or if it even can be predicted and countered in any meaningful way (in lieu of brute force syncing which is basically a no-no for loads of people given the bandwidth demand).
What kind of bandwidth are we talking of here? xx Mbytes? If so i can understand the issue, i remember that my game really stuttered back when i used DamageMeters and it was syncing (Molten Core days with standard ADSL).
The original brute force algorithm used to sync very frequently (forgot, but I think it was in the range of every second or so) every combatants data with everybody. I cannot tell you how much actual bandwidth but there were numerous accounts of people getting disconnected during raiding because of this and indebth analysis of this back when. You can probably find a lot of dicussion about this via google.
The problem is that the accuracy of the sync at least naively is linked to the frequency of syncing. Certainly with limited combat log range syncing used to be much more needed. This isn't really the case so much anymore.
Current Recount's syncing volume is very low (absolutely and in comparison). Because you only ever receive once per player combatant maximum, and even then not every time, and this only at the end of combat or when joining. The downside is that this method is heuristic and can fail under various known and unknown conditions. (Hence why there are repeated posts where people find their recounts not showing the same data even though sync is enabled... the heuristic failed to deliver the ideal). The heuristics improves with more people syncing but it will never be ideal due to various reasons, one being that the sampling of discrepancies is too infrequent and the assumption to bypass this isn't perfect in reality (the assumption being that UnitIsVisible() defines the combat log range).
New: Incoming bandwidth is datasize (which is one combatant entry only)* 1 per Recount-using player at combat end now. Outgoing bandwidth: Just your own data i.e. datasize * 1. Rate: At most once every few seconds.
Old: Incoming bandwidth is datasize*combatant number (players and NPCs)* Recount-using player. Outgoing bandwidth: datasize*combatant number (players and NPCs). Rate: Every second.
Even now I have reports of people claiming they get DC'd when they die while using recount. It's very hard to link those credibly to syncing and the bandwidth. But it is still possible to deactivate the sync code via /recount sync for those that have concerns.
I did testing of bandwidth with addonspamfu when I implemented the new sync code and the bandwidth was basically negligible even compared to addons that do random guild syncing or the unknown random things that auctioneer used to do (or still is doing?). And it certainly was negligible compared to threat meters.
Before Recount was topping addonspamfu by a large margin.
My own private view on syncing is that it is either mostly obsolete, or for the few cases where it isn't (Kalecgos) it is extremely costly to get right hence not faithfully feasible.
People want to see the same numbers when comparing their recounts but truth be told, even if all recounts show the same number there is no guarantees that this in any way better reflects the situation than if you don't do this. After all you could still be missing data that the combat log for random reasons decided not to report.
For very good performance analysis and stuff you don't need syncing really. And virtually everyone uses WWS with just one combat log parse, which is basically equivalent to using Recount without syncing.
But it's in there to at least try to offer something resembling the ideal. Of course the real ideal would be if blizz implemented that when in a raid instance all combat log events of raid members are broadcast to everybody in raid. That'd solve all syncing problems in the most viable way. But if that's technically even possible I don't know.
I'm not aware of any systematic difference between melee or ranged though there certainly can be discrepancies for damage dealers. Most obvious discrepancies seem to happen for healing and it's unpredictable. Sometimes two folks within the same raid will come out perfectly equal sometimes not even though it's not at all obvious that those folks stood out of range from each other ever, had unusal numbers of corpse runs etc.
To really get at the bottom of this I'd need a lot of time and data. Ideally many combat logs of exactly the same raid with known recount discrepancies and do a line by line comparison. Currently I don't have this data and I probably also don't really have a lot of time to do the analysis.
There is one specific known kludge, relating to old data when updating to recent recounts. Deleting your current data and reloading UI should resolve this and fix it indefinitely. If it doesn't let me know.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI can see eventually adding visual feedback though I find it not a crucial feature. But before I ever do that I'd want a better sync solution than is currently in place. Trouble is I know of no better solution.
environmental dmg (eg falling dmg) is switched (enabled/disabled) by the non-trivial mob checkbox. Id rather consider environmental as unknown, but dunno what the author intended there.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumReally I do have only limited hard evidence about a lot of this, and basically the whole behavior of the combat log range still anchors about a Slouken post that states that the combat log range is now all that you can see.
Certainly lack of precise knowledge of this is one part why it is hard to come up with really good (that is fast and bandwidth-friendly, yet accurate) syncing algorithms.
Certainly I have seen quite a few things, specifically things reported to self that are odd (i.e. one not seeing self-reported heals at the level others see it) which cannot be explained by any range theory. I have no clue under what conditions this can occur or if it even can be predicted and countered in any meaningful way (in lieu of brute force syncing which is basically a no-no for loads of people given the bandwidth demand).
What kind of bandwidth are we talking of here? xx Mbytes? If so i can understand the issue, i remember that my game really stuttered back when i used DamageMeters and it was syncing (Molten Core days with standard ADSL).
The problem is that the accuracy of the sync at least naively is linked to the frequency of syncing. Certainly with limited combat log range syncing used to be much more needed. This isn't really the case so much anymore.
Current Recount's syncing volume is very low (absolutely and in comparison). Because you only ever receive once per player combatant maximum, and even then not every time, and this only at the end of combat or when joining. The downside is that this method is heuristic and can fail under various known and unknown conditions. (Hence why there are repeated posts where people find their recounts not showing the same data even though sync is enabled... the heuristic failed to deliver the ideal). The heuristics improves with more people syncing but it will never be ideal due to various reasons, one being that the sampling of discrepancies is too infrequent and the assumption to bypass this isn't perfect in reality (the assumption being that UnitIsVisible() defines the combat log range).
New: Incoming bandwidth is datasize (which is one combatant entry only)* 1 per Recount-using player at combat end now. Outgoing bandwidth: Just your own data i.e. datasize * 1. Rate: At most once every few seconds.
Old: Incoming bandwidth is datasize*combatant number (players and NPCs)* Recount-using player. Outgoing bandwidth: datasize*combatant number (players and NPCs). Rate: Every second.
Even now I have reports of people claiming they get DC'd when they die while using recount. It's very hard to link those credibly to syncing and the bandwidth. But it is still possible to deactivate the sync code via /recount sync for those that have concerns.
I did testing of bandwidth with addonspamfu when I implemented the new sync code and the bandwidth was basically negligible even compared to addons that do random guild syncing or the unknown random things that auctioneer used to do (or still is doing?). And it certainly was negligible compared to threat meters.
Before Recount was topping addonspamfu by a large margin.
My own private view on syncing is that it is either mostly obsolete, or for the few cases where it isn't (Kalecgos) it is extremely costly to get right hence not faithfully feasible.
People want to see the same numbers when comparing their recounts but truth be told, even if all recounts show the same number there is no guarantees that this in any way better reflects the situation than if you don't do this. After all you could still be missing data that the combat log for random reasons decided not to report.
For very good performance analysis and stuff you don't need syncing really. And virtually everyone uses WWS with just one combat log parse, which is basically equivalent to using Recount without syncing.
But it's in there to at least try to offer something resembling the ideal. Of course the real ideal would be if blizz implemented that when in a raid instance all combat log events of raid members are broadcast to everybody in raid. That'd solve all syncing problems in the most viable way. But if that's technically even possible I don't know.
To really get at the bottom of this I'd need a lot of time and data. Ideally many combat logs of exactly the same raid with known recount discrepancies and do a line by line comparison. Currently I don't have this data and I probably also don't really have a lot of time to do the analysis.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium