Add priority information to mount announcement
tflo opened this issue · 22 comments
With the recently introduced mount summon announcement, it would be great to also see the priority of the summoned mount.
My use-case is this:
I have keybound an OPie ring with five buttons for the LiteMount macro /litemount priority <n>
, with n ranging from 0 through 4. This allows me to quickly change the priority of any summoned mount, if I like to see a mount more often or less often.
Problem is that the priority is not the only factor that affects the perceived frequency of a mount; there is also an RNG factor. Thus, it happens quite often that I think “oh, nice mount, let’s increase the priority to 2”, then launching my OPie ring and clicking the ‘prio 2’ button. But in reality, the mount already was on priority 2. (Tested this by occasionally checking the priority in the mount list before actually clicking the button.)
If the mount announcement included the priority of the mount, it would help to avoid these completely redundant priority-change clicks: I would see the priority in the announcement and think “oh, nice mount, priority 2 is OK, I thought it was lower; just bad RNG then” and would not superfluously click the ‘prio 2’ button.
I hope it’s somewhat understandable what I’m trying to explain ;)
The priority info could be included in one of two simple ways in the announcement:
- As a digit, for example after the mount name: <mount name> (<priority>)
- Color-coded: you could use the same priority colors you are already using in the mount list. So, a prio-1 mount would have a green announcement text, a prio-2 mount blue, etc.
Thanks for considering
– Tom
When you are talking about the announcements, do you mean the chat announcement or the on-screen display?
Any of the two, ideally both.
The problem is, I think you might literally be the only person who wants it.
This may be true, because, I think, there are also very few persons who are using buttons or keybinds to set the priority on the fly. If more people would do that, I’m sure they also would appreciate what I’m suggesting :)
I thought the coloring the announcement was a good idea, but I tried it out and really all the colors are very hard to see.
I imagined this could be a problem. Sure, white or yellow texts are usually better to read with the various backgrounds. But I think also that in this case top-notch readability is not absolutely crucial:
- If the on-screen display gets a bit lost due to a similar environment color tone, there’s always still the announcement in the chat.
- Unless you have 600 mounts on priority 1 or higher, I think that even a partially readable announcement (as the worst case) is already enough to make our brain reconstruct the entire name of the mount.
- And, after all, we are not talking about the announcement of a deadly cast that would lead to an instant wipe if we miss it one time out of 10 ;)
But the coloring thing was just an idea, I'm not fixated on it in any way.
Another idea would be to let the user select the display font for each priority. So, I would choose something like: Regular for prio 1 mounts, Italics for prio 2, Bold for prio 3, and BoldItalics (or an entirely different font) for prio 4 mounts :) Just an idea…
I also tried some sub-text (not sure exactly what it would be but screenshot shows an example). I really don't like it. It turns the nice clean announcement of what the mount is into some technical UI information.
Yes, I wouldn’t like a subtext either. (But, looking at your example, in the chat the “Total summons” could be a nice addition.)
Have you tried how it looks with my proposal, i.e. just the priority number appended to the mount name?
For example:
Hulking Deathroc (2)
Hulking Deathroc [2]
Hulking Deathroc – 2
Or the other way round:
[2] Hulking Deathroc
Or maybe, if technically possible, with a smaller superscript or subscript digit:
Hulking Deathroc ²
Hulking Deathroc ₂
As an alternative, can OPie display the current priority in the menu? It would be relatively easy (and not impact anyone else) to add a command or function that would get back the current mount priority, which OPie could use in the menu display if it supports that kind of thing.
Not sure what you mean with menu. The OPie buttons can take an icon and a label, but – to my knowledge – the label can not display dynamic values.
My buttons are simply like this:
#label 2
#icon 2143094
/litemount priority 2
So no, I don’t think it supports that kind of thing. And having to click the button to display the priority would defeat the purpose.
Or some other place in your UI it could show that isn't in the announcement?
Yes, it was my next thought, if I can leverage the priority from the LiteMount DB with a WeakAura, and popup the priority number after PLAYER_MOUNT_DISPLAY_CHANGED (or whatever). So, if LiteMount provided a function that returns the priority, this would certainly be handy – independently of if you add the option to display the prio in the announcements.
I tried looking up the OPie documentation but it seems to be discontinued and the documentation has been deleted.
The author stopped playing WoW and add-on development (one year ago, IIRC), and since recently also his add-on pages are no longer online. However, you can find an archived version on archive.org: OPie, OPie guide
– Tom
Hmm, that's a tough one to know what to do about. Thanks for the clear explanation.
When you are talking about the announcements, do you mean the chat announcement or the on-screen display?
This is pretty easy to do technically. The problem is, I think you might literally be the only person who wants it. So I have to decide what is the right thing to do for the most number of people, that won't confuse people, and whether it's worth adding another option that takes up UI space, needs translating, and I have to maintain.
I thought the coloring the announcement was a good idea, but I tried it out and really all the colors are very hard to see. It took ages of experimenting with colors to decide on the yellow as the one that looked the best and was the most visible. It's a shame I really liked the idea.
I also tried some sub-text (not sure exactly what it would be but screenshot shows an example). I really don't like it. It turns the nice clean announcement of what the mount is into some technical UI information. At minimum it would have to be an optional setting. I modeled the announcement after the Blizzard zone/area change display since I thought it looked good.
I think it is more likely I could add something to the text chat, since it would not be so ugly (or actually is already kind of ugly so it won't be any worse). I'll think about that for a bit.
As an alternative, can OPie display the current priority in the menu? It would be relatively easy (and not impact anyone else) to add a command or function that would get back the current mount priority, which OPie could use in the menu display if it supports that kind of thing. Or some other place in your UI it could show that isn't in the announcement?
I tried looking up the OPie documentation but it seems to be discontinued and the documentation has been deleted. :(
I've decided to put an option into the UI to enable priority coloring for the on-screen display, since I think it's not bad and people can choose if they are happy or not with it being harder to read.
I'll put out a release once I can get the option text badly-google-translated enough.
I'm not sure what to do with the chat message, so I'll leave it for now. I think it would be nice if it said something like the sub-text but the idea of getting a complex message translated just makes me feel tired.
I thought the coloring the announcement was a good idea, but I tried it out and really all the colors are very hard to see.
I imagined this could be a problem. Sure, white or yellow texts are usually better to read with the various backgrounds. But I think also that in this case top-notch readability is not absolutely crucial:
I sort of agree and sort of don't. It's not critical but the whole purpose of having the announcement is to see the name so having it not be very visible is bad. (Except for you, where you only want the priority and not even really the name. :))
Unless you have 600 mounts on priority 1 or higher, I think that even a partially readable announcement (as the worst case) is already enough to make our brain reconstruct the entire name of the mount.
This literally me, so perhaps you chose the wrong argument. Haha!
But the coloring thing was just an idea, I'm not fixated on it in any way.
I'm still feeling like the coloring, if optional, might be the easiest/best of a bunch of not-ideal options. I need a bit of time to mull it over.
Another idea would be to let the user select the display font for each priority. So, I would choose something like: Regular for prio 1 mounts, Italics for prio 2, Bold for prio 3, and BoldItalics (or an entirely different font) for prio 4 mounts :) Just an idea…
Unfortunately that would be an enormous amount of work, so not something I would do.
Have you tried how it looks with my proposal, i.e. just the priority number appended to the mount name?
Sadly that won't work, for a non-technical reason. You know what it means, and I know what it means, but everyone else is going to send me a ticket or a complaint about what is this number and why I should probably die. I don't have the energy or the time for that. :(
Not sure what you mean with menu. The OPie buttons can take an icon and a label, but – to my knowledge – the label can not display dynamic values.
That's a shame. In my head the middle "anchor" ring of the OPie menu could maybe have the current priority in it. I guess not.
Yes, it was my next thought, if I can leverage the priority from the LiteMount DB with a WeakAura, and popup the priority number after PLAYER_MOUNT_DISPLAY_CHANGED (or whatever). So, if LiteMount provided a function that returns the priority, this would certainly be handy – independently of if you add the option to display the prio in the announcements.
I think it is possible to do that at the moment, though because it's poking at the internals it's rather awkward (I could certainly make this much shorter and supported):
local function GetCurrentMountPriority()
local m = LiteMount.LM.MountRegistry:GetMountFromUnitAura('player')
if m then
return m:GetPriority()
end
end
Apologies for thinking out loud, I'm not sure what to do yet overall.
Please try LiteMount 9.2.17
Perfect 😊.
Almost😉. Is it intentional that the display in the chat is not colored?
Concerning readability, I have no issues at all, so far. (This week is perfect for further testing, as excessive rep grinding in Pandaria with lots of mounting/dismounting in different zones is on my schedule.)
local function GetCurrentMountPriority() […]
Thanks for this, very handy. Made a small WA display that sits near the border of the screen , where the second number is from GetSummonCount().
But I don't think there's much need for that now…
Thanks a lot for the new feature!
– Tom
PS:
once I can get the option text badly-google-translated enough
In German, I would write “Farbe nach Priorität”
I tried coloring the chat and it looked awful like angry fruit salad, so I'm not going to color it. I'll look at a different chat message later, but there's a lot of other LiteMount work ahead of it in the priority queue if I have time for thinking (spoiler: sadly I don't). So I'm afraid the colored on-screen option is all you're going to get, at least for the time being.
You can probably make your weakaura print more details to the chat, if you need the output there.
Incredibly, "Farbe nach Priorität" was exactly what bad google translate said!
Happy adventuring, X.
I've made #97 to remind myself to look at the chat announcement later, and plan to close this off. Feel free to subscribe to it (or whatever the mechanism is) if you want to be notified if I actually get around to it.
OK, now done quite a few hours of testing:
The color solution is absolutely fantastical. For me, no serious readability issues at all, and I really went thru lots of different zones and color tones. If there is a low contrast between background and text in some occasions, then it is easily compensated by the large size of the announcement. (It is not too large either, it is exactly right!)
And, you were right to not implement the “appended number” variant. The coloring method is just elegant and simple, and I got used to it pretty quickly.
I tried coloring the chat and it looked awful like angry fruit salad, so I'm not going to color it. I'll look at a different chat message later
If you’re going to add the info(s) as text in the chat (as by the description of #97), then even better! (I just didn’t dare to ask for it ;) In the chat, contrary to the on-screen text, a bit more technical information doesn’t hurt.
Incredibly, "Farbe nach Priorität" was exactly what bad google translate said!
Astonishing. Google translator seems to get better then, maybe usable some day ;)
As a side note, DeepL is in general the far better translator. It doesn’t have as many languages as Google, but at least for German, English and French I can assure you that it is incredibly good, as I use it for work in these languages (technical writing stuff).
Thanks again, for your work and for your responsiveness!
– Tom
Please assist if you are able:
https://www.curseforge.com/wow/addons/litemount/localization/languages/94/phrases#418144
Beschwören: %s (Priorität: %d, Zählung: %d)
Sorry for my late reply.
This is difficult for me, because I don’t play this game (or any other English games) in German. One reason is that many German localizations sound very weird.
This one also sounds strange, although it seems to be “correct” in a literal sense.
To make it a bit less weird, I would write:
“Reittier: %s (Priorität: %d, Zähler: %d)”
…which means: ‘Mount: %s (priority: %d, counter: %d)’
Why not “Zählung”? “Zählung” rather refers to counting something that is present at a given time, eg “Volkszählung”, ‘population census’. But for example when displaying the visitor count on a webpage, you would rather write “Besucherzähler: 23476” (not “Besucherzählung”), because the object of the count is something that comes over time, and the “Zähler”, ‘counter’ advances each time by one.
For the first part: If I were you, I would completely omit the “Summon:” in the message. By the nature of the add-on it should be implicit that the message is about the currently summoned mount:
“LiteMount: Lucid Nightmare (priority:2, count: 378)” looks fine to me.
--> More compact message, and less translation worries ;)
Thanks for your help; it is definitely a big challenge trying to translate fantasy concepts into other languages. I think Deutsche is one of the hardest languages.
LiteMount does print some other messages (mostly for debugging but some of the slash commands also print) so I'm not confident to get rid of the Summon: beginning. Maybe it would be obvious if I changed it to
"%s (Priorität: %d, Beschwörenzähler: %d)”
or Aufrufzähler or whatever the correct construction is for Aufsitzen zähler?
I don't think "Reitter" is right, it's indended to be the name of the action (verb) not the name of the thing (noun). Blizzard's term is inconsistent, sometimes I think they use "Beschwören" and other times "Aufsitzen" (and "Absitzen" for dismount).
E..g, "Zufälliges Lieblingsreittier - beschwören" is the text in the mount journal for "summon random favorite mount".
Maybe it would be obvious if I changed it to […] "%s (Priorität: %d, Beschwörenzähler: %d)”
I would use the past participle then: “%s (Priorität: %d, beschwört: %d)”, which means ‘summoned:’, or “Beschwörungen:” (the plural of Beschwörung), which would translate to something like ‘summonings’.
“Beschwörungszähler”, although correct in analogy with the “Besucherzähler” from my web page example above, sounds very constructed and technical. (“Beschwörenzähler” is wrong.)
or Aufrufzähler
Well, if Blizzard is also using the verb “aufrufen” for ‘summon [a mount]’, then this is way better. In my perception, “beschwören” works rather in conjunction with a demon/ghost/monster or such (where you can not use “aufrufen”, btw).
“Aufrufzähler: ” is acceptable, though also here I would prefer just the plural of the noun: “Aufrufe:” (‘calls’, ‘summonings’), or the past participle “aufgerufen:”.
I don't think "Reitter" is right, it's indended to be the name of the action (verb)
I proposed the ‘mount’ noun because “Beschwören:” sounded overly odd to me here. If “aufrufen” is also part of the Blizz vocabulary, then the latter is acceptable. Though I prefer your idea to put the ‘summon’ label into the ‘count’ part of the message (see above). “Aufsitzen” does not really work here, it’s the translation of ‘to mount’ (the verb).
To sum it up: IMO from best to worst:
- %s (Priorität: %d, Aufrufe: %d) or %s (Priorität: %d, aufgerufen: %d)
- Aufrufen: %s (Priorität: %d, Zähler: %d) or Aufruf: %s (Priorität: %d, Zähler: %d)
- %s (Priorität: %d, beschwört: %d) or %s (Priorität: %d, Beschwörungen: %d) – Only if you have to use the “beschwören” word
- Beschwören: %s (Priorität: %d, Zähler: %d) – Only if you have to use the “beschwören” word
Good choice!
Btw:
After you said this…
Unless you have 600 mounts on priority 1 or higher, I think that even a partially readable announcement (as the worst case) is already enough to make our brain reconstruct the entire name of the mount.
This literally me, so perhaps you chose the wrong argument. Haha!
…I tried that approach and set all my mounts that before were at prio 0 (i.e. the vast majority) to prio 1. (I do not have 600 mounts but still 480 ;)
Somehow I like it better, because I now see mounts that I have not seen for ages ;) But, this also changes completely the way LiteMount “works”:
Before, my “normal favs” (~70 mounts) were prio 1, my “preferred favs” (~20) were prio 2, and my “darlings” (~5) were prio 3. The rest was prio 0.
Now, with prio 1 as base for the “ordinary” majority (i.e. the previously “normal favs” merged with all the ordinary ones), I’m somehow missing an additional priority level. Sure, I will reassign some previous prio-1 mounts to prio 2, but then there is lacking something between prio 2 and prio 3 ;)
Have you ever considered to add an additional priority level? It seems to me the current 3 levels (0 doesn’t count bc it’s off, 4 doesn’t count bc it’s exclusive) have been designed for a usage like mine before, i.e. the ordinary majority off (prio 0).
But now, with the mass of mounts all in prio 1, effectively I only have 2 “fav” levels remaining (2 and 3). Having 3 effective fav levels, as before, would be great.
Sure, I can go back to my previous usage model, but as said I like it ;)
Hi there. Have to say, I'm very happy with the current set of priorities and don't intend to change them. They are a good balance between power and complexity and so far nobody has seemed confused about how they work (important so I can spend my time working on LiteMount and not answering questions :)).
You have to draw a line somewhere (you have 4 categories of "favorite" levels but others might have many more).
You can probably hack a solution to turn the ALWAYS priority into a real higher level instead by doing:
Once (per profile):
/run LiteMount.LM.Options.db.profile.priorityWeights[4] = 18
Every reload:
/run LiteMount.LM.Options.ALWAYS_PRIORITY = 5
but it's not something I'm going to support in the base addon.
Happy adventuring, X.
and so far nobody has seemed confused about how they work
I’m not confused either, as far as I can tell ;)
ou have to draw a line somewhere (you have 4 categories of "favorite" levels but others might have many more).
Don’t get the point here. What is a “category of favorite level”? I had 3 levels of favs. (the max that the add-on allows, if we include prio 1), no idea how many “categories” I had (or have). Probably I’m just not understanding bc of my limited English.
You can probably hack a solution to turn the ALWAYS priority into a real higher level instead by doing:
Already thought about that (essentially turning an almost unused level into a real fav level; actually, I am using it, but just for one swimming mount, no idea why;)
But, this then would be another add-on in my git folder of the ever-growing collection of add-ons where I have applied patches for different reasons (mostly because the add-on is no longer maintained, but also just personal mods like this one would be.) --> Maintenance work with every author update
So, just forget what I posted above. If you – as the author – are happy with 2 fav levels, then OK so. I’m already more than happy with your add-on, because it does all I need, and – above all – it allows me to do my very individual things via the script (“Advanced Options”). The priority system is a bonus, and I’m happy to have it, as it is.
Just as a minor follow-up, a fun way of doing this is to make your own tiny addon that patches (the running copy of) other addons when it loads. You only need two files like this:
TfloAddon/TfloAddon.toc
## Interface: 90205
## Title: TfloAddon
## OptionalDependencies: LiteMount
TfloAddon.lua
TfloAddon/TfloAddon.lua
if LiteMount then
LiteMount.LM.Options.ALWAYS_PRIORITY = 5
end
Thanks for the hint! I did this once, with Skillet, to disable it on launch (bc it prevented other add-ons from scanning the recipe collection, eg ArkInventory), but hen forgot about that. Good point.
Btw, shameless self promotion, if you are also interested in pets, try my add-on PetWalker
Well, shortly afterwards I dropped Skillet completely, because – back then, and also currently – it is a pile of bugs.
LiteMount.LM.Options.ALWAYS_PRIORITY = 5
I did this now as you suggested. Actually, to make the “new” priority 4 work as intended, I also had to write an additional priority weight to the DB:
LiteMountDB.profiles.Default.priorityWeights = { 1, 2, 4, 6, 1 }
(I’ve also set the MAX_PRIORITY
to 5, so, just in case, I still have an ‘always’ priority available, as before. Fortunately, your GUI allows for an additional priority without any issues, and I can even filter for it with ‘Uncheck All’.)
Thanks again