Broker Recount incorrectly confuses the label and text fields. When I tell Fortress to not display labels I do not want to see Recount and other broker object sitting there with a gigantic wide label. Instead I want to see the label disapear and only the icon remain. Please fix this, and if you can pm me what Broker you copied the code from I can go get that fixed too so this endless cycle of copying bad code can stop.
I am or have used the broker with both statblockcore and buttonbin, behavior is as intended. Are you positive that this is an issue with label vs text and not fortress handling it sensibly when one or the other is set?
You'll have to touch a lot of addons I think because this is after some generic broker from the statblock family.
Finally the spec isn't clear. Per spec for generic brokers type and text are required whereas label is not. So if I want to provide a minimalist broker you are inclined to do exactly what broker_recount does, i.e. set type to launcher and set the required text to whatever the launcher is.
I understand that the separate quicklauncher spec has no required text field and an optional label field. If anything this is inconsistent between a generic broker and a launcher broker.
At this point I think it's best if the display addon gracefully handled text data given that you'll find a lot of brokers that use it the way I do thanks to the inconsistency in the spec. Above all the display has to handle text fields for non-launchers anyway...
Maybe ask or modify fortress to show similarly graceful behavior for text field on launchers as either statblockcore or buttonbin already does?
*text Required string The text to be shown.
*label string A title for your feed, often shown to the left of the text, user might choose to hide this. If missing, the dataobjectâs name may be used instead.
*icon string Full path to a texture, often shown to the left of the label or text.
Now this is what these 3 fields are intended for and are documented to act as:
1) text - this is required because this is the actual OUTPUT. If you display say total gold or experience or whatever it goes here. Note that it can be set to nothing if instead you only show stuff on mouse over, or do not ever show output but are a launcher for example.
2) label - this is the title just as the document describes it. This is the field that you need to be setting to display the LABEL "recount". This is the same label I want to disable and be left with only the 3rd party involved here which is the icon:
3) icon - you have correctly done this part and it is in fact the only part I want to see. I do not want to see "Recount" when I disable the label field. I can NOT disable the text field since that kills every single correctly implemented broker that actually uses the text field for output. The number of correctly implemented ones exceeds the number that are not.
So, please be reasonable and implement the spec which is quite clear and unambiguous...
Finally, which statblock(s) are badly implemented? I need to go get them fixed so they stop being a terrible examples.
I posted to clarify in the libdatabroker thread earlier and await discussion. I think there are a few things that need clarification about this. I agree that I should use label, I am however not happy with the current spec and do not consider it clear and useful for all the use cases that are relevant.
For example broker_recount supports tooltips, that's also against the spec but makes a lot of sense for me. I do not really intend to make the broker conform to a standard until I have some clarity what the situation is and how to best achieve what makes sense.
On top of it lots of displays (statblockcore, buttonbin) support, per your argument, the spec wrong, else broker_recount wouldn't work with them, on top, they simply shouldn't support tooltips for launchers but luckily they do, against the spec.
In short the spec needs clarification before there is a sensible way to fix this. Then displays need to conform, and brokers. But I don't think we have that situation yet.
As for other statblocks, I'd suggest you contact their respective maintainers. It isn't really my thing to keep track how others write and maintain their brokers over time. I'd suggest, if you have the patience, to first await conclusion of the discussion that we'll likely have about the spec before pressing this issue though.
There is almost a 300 point difference between Recounts DPS and HitsMode DPS. So which addon is showing the correct DPS for me?
Probably neither. Since "DPS" is a fairly vague definition.
Is it "damage done / total time in combat"?
Is it "damage done / time in combat from first hit to last hit"?
Is it "damage done / time someone in your party entered combat to last person exiting combat"?
What about your pet that started attacking first, but you entered 10 seconds later, should your DPS time including that 10 seconds?
What if you died but your dots continue to tick for another 18 seconds, should that 18 seconds be included, but the moment you died, you already went out of combat? And should that damage even be included?
Different addons use a different variation for DPS calculation.
Probably neither. Since "DPS" is a fairly vague definition.
Is it "damage done / total time in combat"?
Is it "damage done / time in combat from first hit to last hit"?
Is it "damage done / time someone in your party entered combat to last person exiting combat"?
What about your pet that started attacking first, but you entered 10 seconds later, should your DPS time including that 10 seconds?
What if you died but your dots continue to tick for another 18 seconds, should that 18 seconds be included, but the moment you died, you already went out of combat? And should that damage even be included?
Different addons use a different variation for DPS calculation.
Would there be any possibility of fixing the way extra attacks are tracked by this addon? Currently the addon assumes that the attack immediately following the combat log "You gain X extra attacks through Sword Specialization" entry. Below is my post detailing the way the combat log actually reports extra attacks:
I have retested this functionality periodically since that time (including as recently as last week) and it still works this way. I'm a little bit tired of rogues popping up every other week to tell me that Sword Spec has been changed because Recount told them so; it'd be fantastic if this could be fixed.
shadow: You need to download the latest version from wowace here manually as the downloader likely will give you a beta, which this isn't yet flagged as. If it still doesn't work let me know.
vulajin, stan: I'll look into it.
oloffi: Are you sure you are using the latest version? I tried to reproduce the problem without luck. If you find a tangible way to reproduce this let me know.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
You'll have to touch a lot of addons I think because this is after some generic broker from the statblock family.
Finally the spec isn't clear. Per spec for generic brokers type and text are required whereas label is not. So if I want to provide a minimalist broker you are inclined to do exactly what broker_recount does, i.e. set type to launcher and set the required text to whatever the launcher is.
http://github.com/tekkub/libdatabroker-1-1/wikis/data-specifications
I understand that the separate quicklauncher spec has no required text field and an optional label field. If anything this is inconsistent between a generic broker and a launcher broker.
At this point I think it's best if the display addon gracefully handled text data given that you'll find a lot of brokers that use it the way I do thanks to the inconsistency in the spec. Above all the display has to handle text fields for non-launchers anyway...
Maybe ask or modify fortress to show similarly graceful behavior for text field on launchers as either statblockcore or buttonbin already does?
*text Required string The text to be shown.
*label string A title for your feed, often shown to the left of the text, user might choose to hide this. If missing, the dataobjectâs name may be used instead.
*icon string Full path to a texture, often shown to the left of the label or text.
Now this is what these 3 fields are intended for and are documented to act as:
1) text - this is required because this is the actual OUTPUT. If you display say total gold or experience or whatever it goes here. Note that it can be set to nothing if instead you only show stuff on mouse over, or do not ever show output but are a launcher for example.
2) label - this is the title just as the document describes it. This is the field that you need to be setting to display the LABEL "recount". This is the same label I want to disable and be left with only the 3rd party involved here which is the icon:
3) icon - you have correctly done this part and it is in fact the only part I want to see. I do not want to see "Recount" when I disable the label field. I can NOT disable the text field since that kills every single correctly implemented broker that actually uses the text field for output. The number of correctly implemented ones exceeds the number that are not.
So, please be reasonable and implement the spec which is quite clear and unambiguous...
Finally, which statblock(s) are badly implemented? I need to go get them fixed so they stop being a terrible examples.
For example broker_recount supports tooltips, that's also against the spec but makes a lot of sense for me. I do not really intend to make the broker conform to a standard until I have some clarity what the situation is and how to best achieve what makes sense.
On top of it lots of displays (statblockcore, buttonbin) support, per your argument, the spec wrong, else broker_recount wouldn't work with them, on top, they simply shouldn't support tooltips for launchers but luckily they do, against the spec.
In short the spec needs clarification before there is a sensible way to fix this. Then displays need to conform, and brokers. But I don't think we have that situation yet.
As for other statblocks, I'd suggest you contact their respective maintainers. It isn't really my thing to keep track how others write and maintain their brokers over time. I'd suggest, if you have the patience, to first await conclusion of the discussion that we'll likely have about the spec before pressing this issue though.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumProbably neither. Since "DPS" is a fairly vague definition.
Is it "damage done / total time in combat"?
Is it "damage done / time in combat from first hit to last hit"?
Is it "damage done / time someone in your party entered combat to last person exiting combat"?
What about your pet that started attacking first, but you entered 10 seconds later, should your DPS time including that 10 seconds?
What if you died but your dots continue to tick for another 18 seconds, should that 18 seconds be included, but the moment you died, you already went out of combat? And should that damage even be included?
Different addons use a different variation for DPS calculation.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium:o
No idea lol.
Betas&Release: Either above link or: http://wow.curse.com/downloads/wow-addons/details/recount.aspx
I hope it will help some people in Spanish Versions of World of Warcraft.
Can people give this a test run? Once I get basic OKs on esES, ruRU and frFR I'll move it from alpha to beta.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderatorhttp://elitistjerks.com/764238-post48.html
I have retested this functionality periodically since that time (including as recently as last week) and it still works this way. I'm a little bit tired of rogues popping up every other week to tell me that Sword Spec has been changed because Recount told them so; it'd be fantastic if this could be fixed.
Hi Elsia, I tried to make a test but recount is still in english. Can I (in anyway) to force recount to use spanish localization lua?
Once I can test the addon I'll check it and give you a report.
Thanks in advance.
vulajin, stan: I'll look into it.
oloffi: Are you sure you are using the latest version? I tried to reproduce the problem without luck. If you find a tangible way to reproduce this let me know.