Widget talk:Account achievements

Bits

Right now this widget provides support for id = "achievement<achievement id>" only (don't get me wrong, this is great!). Would it be possible to process the unlocked bits too and hence be able to check for id = "achievement<achievement id>-<unlocked bits number>"? Then we could increment through the {{achievement table row}} parameters "objectives" and "collection" and check those to. Would this slow down an achievement page too much or are there any other negative side effects? --Tolkyria (talk) 17:51, 27 September 2020 (UTC)

Processing the unlocked bits too can be done; shouldn't have any noticible impackt in terms of speed either. The only negative side effect i can think of is that it might end up graying out the wrong objectives/collection items if they are not sorted as they are designated unlocked by the API; which i assume could maybe be the case for older achievements, though i don't know to what extend - or if at all even - that is the case. The bits are already in the response as it stands; they are simply left be for the time being though. Would changing it so that it also grays out all elements assigned a class of achievement<achievement id>-<unlocked bits number> be fine or do you need it to be the id? Nightsky (talk) 02:18, 28 September 2020 (UTC)

Okay, not matching the in-game order is a valid point. I'm aware of Explorer achievements using the parameter objectives where the bits contains empty text, e.g. Ascalon Explorer (scroll down a bit) which we here on the wiki don't take into account. I guess checking for those on the API/achievement page and remove them would be an overkill. Similar to ask for the item/skin id for collections based on the unlocked bits numbers and check for the id instead here (this would ensure to gray out the correct items only).

All other API unlock checks use id, so in order to have one general unlock check template it would be nice to have it here too, e.g. {{Account unlocks list}}. --Tolkyria (talk) 09:30, 28 September 2020 (UTC)

Actually, I should have given some motivation before requesting something:

1. This idea exists since at least edit (October 2019) but never got implemented. I don't know the exact reason, but I guess the wiki hasn't been ready for this. At this time all we had was the more or less useless property Is part of collection which is set to items and skins without any rule (there is no differentiation between what is exactly needed for the achievement) and furthermore doesn't provide a way to sort it in the in-game order. At this point I doubt that we can fix it (over 7000), actually we don't need to... leading to point 2.
2. In the meanwhile, the {{achievement table row}} parameters "collection" and "objectives" (and their according properties) have been added which provide the in-game order and specify exactly if the item or skin is required for the achievement.
3. Wiki editors keep adding {{Account unlocks list|achievement item}} (being able to checking for equipment skins only) to achievement collection pages that rewards non-equipment items (e.g. trophy items, etc...), resulting in awkward reverts: "Sorry, this is not possible right now".

--Tolkyria (talk) 15:30, 28 September 2020 (UTC)

Regarding

1. The way i understand "...a new widget for individual achievement pages which will show skin-by-skin or item progress." would be that it means to create a new widget which to put on individual achievement pages (like e.g. Ruler of the Skies or Lion's Arch Exterminator) having it gray out things there rather than on the achievement category overview pages where this widget is usually found. And as to why it didn't get implemented i would assume maybe because there isn't an individual page for every achievement (e.g. Ascalon Explorer, which you mentioned before, has no page for it specifically) so it wouldn't have been possible everywhere; though this is merely speculation.
2. While the collection and objective parameters might be intended to keep things in in-game order, if the API order is any bit representative of the in-game order then that seems to not have worked out as well as the order of the Ascalon Explorer achievement bits found on Explorer is not really reminiscent of the order found in the API where the later starts out with Plains of Ashford (with "Plains of Ashford: Langmar Estate" stray as second to last) while the former lists Black Citadel bits first.

And regarding to what you mentioned before ("Similar to ask for the item/skin id for collections based on the unlocked bits numbers and check for the id instead here (this would ensure to gray out the correct items only)."); if i understand you correctly there then it would technically be possible to have the widget gray out things like achievement<achievement id>-<item\skin id corresponding to bit> (though probably more likely separated as achievement<achievement id>-item<item id corresponding to bit> and achievement<achievement id>-skin<skin id corresponding to bit> (so generally as achievement<achievement id>-<bit type><id of bit type corresponding to bit>) in case an achievement shares an item and a skin with the same id) with (an) additional request(s) to /v2/achievements provided /v2/achievements lists bits in the same order as they are "listed" in /v2/account/achievements (which is likely the case as otherwise it would be pretty useless) and even then only for bits identified by id's (like e.g. skins and items) and not bits of type "text".

In short, graying out bits would probably indeed best be added to this widget as it would cover all achievements weather they have a page or not. Though implementing that using the bits themself only is made problematic by the order of the objectives on the wiki not neccessarrilly being the same as the order in the API and implementing it using the bits as a reference to the results of (a) request(s) to /v2/achievements to use the id's found there is problematic as that doesn't cover all possible cases as some don't have an id as e.g. bits of type text. Nightsky (talk) 18:56, 28 September 2020 (UTC)

Okay, my bad, I definitely checked the wrong achievements before proposing it, these had nice behaving "text" bits. The reality is a different one, I suggest to scrap the idea applying this to the parameter "objectives".

Then only the individual collection achievement pages remain, being able to gray out achievement<achievement id>-<bit type><id of bit type corresponding to bit> would be great! I don't know whether this should be a standalone widget or not. Probably a new standalone widget taking an achievement id and checking those for unlocked item/skin ids is enough as otherwise the API check on achievement category pages would be inconsistent (graying out collections but not objectives). --Tolkyria (talk) 19:41, 28 September 2020 (UTC)

You have a point with it possibly appearing inconsistent and a standalone widget truly seems to make more sense. So it should be a widget that is

• to be used on individual achievement pages in a separate section (as e.g. seen under "Collection items" on Master of the Storms (or is it intended to apply directly to the "Collection:" section generated by the {{Achievement box}}?))
• graying out things with an id of achievement<achievement id>-<bit type><id of bit type corresponding to bit> (No sure here how feasible it is at the moment to get the achievement id for the items in the list (if the widget is to be used in a separate section with a separate list) with smw. If that is a bit to difficult to get and if we can assume that it would only ever be one achievement per page it might be easier to have id's of the form bit(s)-<bit type><id of bit type corresponding to bit> only which would eliminate the need to get the id of the achievement via smw there. (Seems like get the achievement id would be no problem at all if it concerns the "Collection:" section at least since there it's available as a template parameter.)) and is
• supplied the achievement id. (This is good as that would make it easy to eliminate the need to query the API for every single achievement to get the corresponding ids for the bits from it and add css rules for all of them even if only a few of them would apply. (Though that would also be possible using e.g. a query selector for all of "*[id]" and regexing the values to get which ids are actually needed.))

Do i understand it right that way and or does anything in braces apply? Nightsky (talk) 21:27, 28 September 2020 (UTC)

I do not see the problem with graying out collections but not objectives (implementing code for collections only) on the category pages. At least all collections I have edited in the past have the same order as it is ingame (no hidden text bits or otherwise).

Personally I would not be opposed to move the collection parameter from items to skins since there are only very few exeptions where it is actually the item and not the skin that is needed (could that not be done with a bot?).

Side note: The new "Fractal Fighter" achievements do show the objectives/completed fractals ingame, but the API has them - not sure if v2/account/achievements can check for the new weekly achievements. Again a text bit, but that would then actually show something you can not check ingame. —Kvothe (talk) 21:34, 28 September 2020 (UTC)

The "problem" with graying out collections but not objectives on the category pages and it looking weird is likely verry subjective. I mean i'm fine with implementing it using the bit only and not do a lookup for the id, would make it easier for me, though i thought we'd agreed on looking up the ids already, no?

I'm not sure what exactly you mean with moving the collection parameter from items to skins. (In the infoboxes?)

That's interresting actually as not having that in-game is really anoying. This sounds like something that would be for it's own widget though as we would have to include the text bits on the wiki for it to work but as they don't show up in game we don't have them there. Furthermore since they show up on the API and not in-game i assume that, based on the "Dragon Bash" achievement that appears at reset since the introduction of those weekly achievements, it is possibly bugged in game and is supposed to show what has been done and what hasn't but it isn't doing that. If that were the case it would not need it's own widget of course. (I mean it wouldn't neccessarrilly really need one either if we'd just include the text bit's on the wiki anyway.)

In the end i don't mind much in what way it should be done; i just have to know it so i can actually do it. (I mean i can also just (would probably anyway) first do something over on Widget:Test? to see if it's even what's actually requiered and if i actually understood it correctly, but i thought i'd ask first if i understood it correctly before doing it and then it turns out to be wrong and ends up not being used that way anyway.) Nightsky (talk) 02:15, 29 September 2020 (UTC)

Kvothe is speaking about an off-topic that doesn't relate to this: namely the item/skin infobox parameter "collection". People expect it to be on the item page although only the skin counts; thinking of "related to collection" it actually makes sense to list it on the item page though the skin counts. Hence in my opinion the related property (namely Is part of collection, counting over 7000 entries, hence it can be fixed that easily) is useless for proper smw queries that needs exact differentiation. But for me it doesn't matter as there is Has achievement collection which preserves in-game order and exactly specifies which if the skin or the item is required.

Honestly, I don't know my exact request anymore, dealing with the incomplete API is just frustrating. --Tolkyria (talk) 09:33, 29 September 2020 (UTC)

Relevant ids + bits

Alright so I was just tweaking this widget to use className and not ID - I was thinking that using class is better because that way we could have more than one element with the same id with no funny business. However, relevantIds is giving me a headache - if I convert to classes there's the potential for mixed classes such as "heading achievement4557" for example. Any thoughts on if we were to apply the CSS with data attributes instead, and mark up the elements annotated with a context css class like "account-widget-context-achievement"? -Chieftain Alex 18:38, 15 October 2020 (UTC)

Got a concept over at User:Chieftain Alex/sandbox6 - I've prototyped it using an older version of the widget, will see how to rewrite it before making it mainspace. -Chieftain Alex 19:29, 15 October 2020 (UTC)

User:Tolkyria/Sandbox2 (Revision &oldid=2155756) Stormcaller Armsmaster is an anomaly in the api, but the graying out works (tested on User:Tolkyria/Sandbox (previewed in revision &oldid=2155348). Not sure if Tolkyria checked all other collections not on Legenary Collections and Black Lion Collections. Those two pages should match the API order now. —Kvothe (talk) 12:48, 17 October 2020 (UTC)

My sandbox table contains all achievements that have a collection, obtained by the following query: {{#ask: [[Has context::Achievement]][[Has achievement collection::+]]}}, and compares the API collection items/skins (I used the API item/skin ids to query for the related item/skin names on the wiki) with the currently documented wiki colletion items/skins. Thanks to Kvothe, the wiki collection order matches the API order (which should be also the in-game order). --Tolkyria (talk) 13:31, 17 October 2020 (UTC)

Changes are live. I've modified the achievement table row template, not sure what else will be affected. -Chieftain Alex 13:19, 25 October 2020 (UTC)

Seeing as you didn't end up rewriting it to use only classes can i do that now then or is there a specific reson to stick with the data attribute and a "context css class" i fail to see? Because as far as i can tell classes would be sufficient. Nightsky (talk) 01:48, 26 October 2020 (UTC)

Does it need rewriting if it works? I think it's neater to keep the data-id outside of the CSS classname/id. -Chieftain Alex 10:02, 26 October 2020 (UTC)

I mean.. it would effectively remove the data-id attribute and the need for a "context css class" which should mean less template include size. (That would effectively end up being class="achievement42" for the completion of the achievement itself and class="achievement42-bit24" for bit completion. (Altough it would be class="achievement42 achievement42-bit24" to more easily gray out the bit(s) even if the achievement is complete. (Alternatively adding all bits as selector individually as well then; would work too of course. (I don't think there's a space separated value starts with selector, is there? Because if so that would be even better; though i guess contains (similar (not exactly the same) to how it is used curently) would work too.))) No data attribute or extra class for selection needed. (Though the id will still have to stay for section links obviously. (Though it could also be changed to name for that but i think id fits it better anyways.)))

As for keeping the data-id value outside of class and id; why use a seperate attribute if it would work just fine with a class? As it is at the moment it ends up as a attribute in the CSS selector anyway; so it's not outside of CSS, if that's what you mean? (I personally think using a class for CSS is more organic than using an attribute if given a choice.)

So while no, it technically doesn't need to be rewritten if it works; i still think it would be beneficial though. If only to reduce template include size, though i don't know if that's much of a problem even. I'd imagine using classes would be more intuitive than attributes though, but that might just be cause i usually use them. I had a stronger feeling about this yesterday but that seems to now have subsided; should have probably waited a day to see if it remains on the next. It still doesn't feel right to me though to use an attribute for styling purposes, but i'm now not so much interrested in changing it anymore as.. it works i guess; i don't know, lost interrest or something. Wasn't a good day today; maybe that's to do with it. Nightsky (talk) 01:20, 27 October 2020 (UTC)