User talk:BuffsEverywhere

Updating armour pages

Just wanted to say thanks for the incredible work you've done so far on all of those armour pages. That's a lot of information you've had to sort through and clean up! G R E E N E R 00:49, 21 December 2018 (UTC)

Thank you! I appreciate the feedback! BuffsEverywhere (talk) 01:25, 21 December 2018 (UTC)

About NPC images

There's a Shared Model Project, which could save you time when adding character model images to new or existing articles. Or You can help improve it ^^ - J.P. 15:33, 22 December 2018 (UTC)

Thanks for the heads up! However, I think having the right background is important - it makes finding some NPCs easier, which in my opinion is more helpful than just documenting the model. BuffsEverywhere (talk) 20:49, 22 December 2018 (UTC)

Thanks for fixing spam on my user page

saw your revert, thank you :) -- KillerRabbit 👯💬 13:50, 16 March 2019 (UTC)

Glad to help! --BuffsEverywhere (talk) 14:12, 16 March 2019 (UTC)

Kinda tempted to revert that

with regards to this edit, NPC's are not really supposed to be set as located inside POI locations. This may be a reminder for me to go through and replace the location=poi with location=area-name. -Chieftain Alex 07:11, 6 November 2019 (UTC)

Yup, that's true but even if the NPC was set incorrectly, it's better that the template shows a POI than a dash... --BuffsEverywhere (talk) 09:15, 6 November 2019 (UTC)

"There is no minimum number of contributions required to voice an opinion on the state of the wiki or community."

This isn't necessarily always the case. On GWW, users had to have an account and had a certain number of qualifying edits to participate in bureaucrat elections. horrible | contribs 11:46, 13 June 2020 (UTC)

That is a massive stretch and was only there to prevent mass creation of new accounts for potentially stacking votes. Neither wiki however has ever had a metric for minimum contribuitions, for someone to have an oppinion. Thats a strong misread of that rule, Horrible. -- Salome 11:50, 13 June 2020 (UTC)

Yes, but i think it's applicable here. Otherwise a flood of IPs/New users could come in and determine what the wiki says regarding this topic. horrible | contribs 12:16, 13 June 2020 (UTC)

Nope. It doesnt apply. The wiki rules through consensus, not voting. The only reason their was a limit on BC elections is because voting was an integral element of the process itself. If ip's and new users have an oppinion, they are more than welcome to engage with the discussion being had. It will go into the pot of discourse and debate that the wiki community is engaging in and will be afforeded the weight due to the merits of the oppinion itself. You can not be arguing in favour of a more inclusive wiki environment, while simulataneously arguing that some shouldn't be afforded a voice.

Anyway sorry for having this debate on your page Buffs. -- Salome 12:29, 13 June 2020 (UTC)

“On GWW, users had to have an account and had a certain number of qualifying edits to participate in bureaucrat elections”

There is a very simple reason for that though which does not apply anywhere else: Bureaucrat elections were solely decided by the vote tally, i.e. the number of votes. During the voting stage, there was no more discussion and only the actual vote itself counted. So to prevent abuse, we required every voter to be an actual member of the community.

This does not apply to anything else though: Discussions are not decided by vote counts or by who is the loudest. People are encouraged to form consensus, and for that every voice is welcome, regardless of whether that user is a long-term contributor, a new contributor or an anonymous user just there to voice their opinion. poke | talk 12:43, 13 June 2020 (UTC)

Fair enough, I see that I misunderstood the reasoning behind it and shouldn't have confused strict voting with a community-driven consensus. horrible | contribs 12:50, 13 June 2020 (UTC)

Image check

I disagree with this edit, because this way we are checking for something that in general is not missing. The related skills/traits have already lots of cascading templates, in rare cases they are already at the limit, so adding a redundant template call that can be avoided matters in my opinion. Sure, I kinda see why you added it, but overall your edit was relevant for 4 days (last Friday skill preview until this Tuesday to the beta release), now all traits have an existing icon set again. In my opinion we should endure the redlink icon replacements or set "icon = Skill.png" in the infoboxes if one can't bear it anymore. --Tolkyria (talk) 22:28, 17 August 2021 (UTC)

I added it for related traits because the template weirdly displayed the missing icon as text, so it was really ugly. You can revert it if you want, but I think the next 2 previews/betas will have the same issue. I don't like setting the icon in the infoboxes like that because they'll all have to be unset again. --BuffsEverywhere (talk) 02:08, 18 August 2021 (UTC)

Not sure why we already need this before the traits have been available, in my opinion it's not justified at all, endure it, hide it or set the icons (honestly the skills/traits pretty much need an edit anyways on release, there the set icon parameter can be removed easily). I reverted it. --Tolkyria (talk) 15:57, 18 August 2021 (UTC)

Trait infobox edit

Your trait infobox edit which changed from "Is historical::N" to "Has availability::Current||Future" caused "The following query condition could not be considered due to this wiki's restrictions on query size or depth: [[:Current]] OR [[:Future]]." in the improved skills/traits queries, resulting in 182 (!) Special:ProcessingErrorList complains on 69 pages in total, removing several improved skills/traits from the result format templates related skills/traits. Each of the OR part counts as individual query term, with the game mode and the specialization restrictions four are already taken, then one for the context, one for the profession, one for the status leaves one for extra categorization (e.g. type, weapon, etc...). The additional future query search is too much an exceeds the query limit. Please be more careful and try to test it in your sandbox. --Tolkyria (talk) 15:57, 18 August 2021 (UTC)

So I guess you went for the probably most elegant solution, I don't know if it will work out 100% but at least in a natural language context marking the future not as historical make sense. Then we could probably reconsider also the "Current||Future" band-aid fixes in the templates Recharge table, Related skills, Skill list, Skill list by property, Trait list, Trait list by property depending on how much we actually want to show. At least the first two listed templates, where Recharge table previously also exceeded the query depth, could use "Is historical::N".

Please keep in mind that the templates Skill infobox/subobject and Trait infobox/subobject set the property Is historical directly for the subobject, this property should definitely match the main skill/trait page. --Tolkyria (talk) 19:27, 18 August 2021 (UTC)

Thanks for finding the errors in my edits. SMW is so complex and yet so limited in what it can do, it's infuriating. I thought it would be a simple change to add an OR operator but apparently not!

I've edited Recharge table to use "Is historical" and also corrected the property for the subobject templates. I previously had a request to limit showing related future skills and traits to only future pages so I've left the rest as they are for now. --BuffsEverywhere (talk) 22:19, 18 August 2021 (UTC)

Probably we are pushing the limits of SMW a little bit to far, farer than the SMW devs imagined. But considering the improves skill queries, every query search term is relevant, none can't be really omitted. Well, another idea to reduce the query depth by one would be to create a property that allows to select the main skill/trait page only and ignore the split subobjects. This would replace "Is for game mode::Default||PvE" with a query of one depth less giving us a little bit more space. I haven't thought it through completely but it should be straight forward... something for the future.

Yes, it might be wierd to already list the EoD elite specializations in offical lists, e.g. boon/condition lists, see Might; so your status page check equals future is okay. --Tolkyria (talk) 22:34, 18 August 2021 (UTC)

Maintenance

Please do not edit templates until the maintenance is complete tomorrow. —Kvothe (talk) 13:26, 31 August 2021 (UTC)

Automated skill tables

I know it's kinda ironic that on the one hand I create powerful automated skill tables and on the other hand I warn you here now about their usage.

Automated smw template have one big issue, namely they completely annihilate any form of historical documentation as they are only taking the current state of the wiki into account with no option to consider previous versions.

Hence, in my opinion, we should handle the usage of such templates by considering following questions:

1. Are we able to create the skill table by hand?
2. Is the skill table the only one that groups skills in this particular way and thus is it from historical relevance?

If we answer both questions with yes then we should keep a manual skill table row to preserve documentation. If we answer the first question with no but the second with yes then it's kinda tough to decide and depends on the individual page. All other cases, namely answering the second question with no, can easily use an automated generated skill table.

Regarding your edits on List of <profession> skills, I would answer both questions with yes. First, the table already exists so there's no effort involved. Sure game update changes needs to be changed manually but that's exactly the point of the second question, namely to have at least one overview page where the skill history is preserved. Weighting up gain versus loss, I prefer to keep the manual tables on such specific and unique overview pages to be able to look up skills in a large scale format (obviously /history skill pages are nice but they miss the bigger context).

Overall I think in the first category (twice yes) are weapon, skill type and list of profession skills overview pages. For example in the second category (first question no, second question maybe) are large pages as Chain or Sequence skill that have been outdated for quite some time as noboby bothered to keep the up to date. There the only reasonable way is to use automated tables to provide the wiki editors the current available content.

Conclusion: Please keep in mind that in my opinion your edits on List of <profession> skills are quite invasive as they remove any form of documentation and no longer preserve history. --Tolkyria (talk) 08:54, 18 October 2021 (UTC)

To be clear, are you talking about the edit history of those pages? If so, in my opinion those edit histories are a mess and it's hard to find useful information with them anyway. I don't think the edit histories are more important than ensuring the information displayed is up-to-date, complete, and formatted in a nice and consistent way. For example, Guardian, Warrior, and Ranger did not have type subheaders for their utility skills. --BuffsEverywhere (talk) 10:12, 18 October 2021 (UTC)

Yes, sorry, should have been precise, I mean the Revision history. The revision history is what it is, either properly commented or a total mess, in both ways providing information how the page looked like at a certain editing date (if we use manual tables of course; automatically generated tables would just take the current available content). That's the price we pay by adding automated tables.

Regarding your concerns: I doubt that there had been an outdated skills, these tables are updated pretty much immediatedly after a game update change; adding skill type subheaders by hand shouldn't be that hard. Also, you haven't even reached the tricky parts, for example tool belt or glyph skills, which probably can't be done automatically. Hence there will be either discrepancies between the used templates (automatic/manual) or certain content will be no longer available. Overall I fail to see the benefits from your edits, manual skill tables rows are way superior in terms of customization and history preservation than automatically generated tables. --Tolkyria (talk) 19:01, 18 October 2021 (UTC)

Collection Template

I added few related achievements to some vendors using this nice Template:Collection_achievement. But it doesn't work with Ancient Orrian Spoon, probably because that item has variants template and other items have fm table. So items should be standardized with one template or Collection Template enhanced to catch more. Unless I'm missing something - 178.37.143.211 22:26, 15 March 2022 (UTC)

The link to the items created by the variants table is item name#item1...item2...item3, etc so you can use {{Collection achievement|Ancient Orrian Spoon#item1}} to refer to the Fine spoon and item2 for the Masterwork spoon.

I agree that the items should have a standardized template. Personally I would prefer to convert pages using the fm table to the variant table, however there are hundreds of pages that use the fm table so it's a huge task with not much benefit.

--BuffsEverywhere (talk) 00:00, 16 March 2022 (UTC)

You're right, thanks for the info, those templates create different links, fm table has named arguments (Fine, Masterwork) and variants has unnamed (item1, item2). So other link format will make Collection Template work. But probably this may be problematic later, if added on merchant's page, and later someone change template used on item's page, then it would break display of collection on merchant's page. Wonder if Collection Template could have version for a merchant's name and auto-listing all collectible items for that merchant - 178.37.143.249 00:52, 17 March 2022 (UTC)

Indeed that would break the display of the template but fixing the links is simple. I can make another template to autolist a merchant's collectible items but will it be that useful? --BuffsEverywhere (talk) 10:20, 18 March 2022 (UTC)

No shortcuts please, using the full subobject name may be a little bit more tedious but in the end it's not worth it and would make things more complicated. For example we initially set up the collection parameter to allow items or skins where items were automatically redirected to their skin. It turned out that some collections are in fact requiring an equipment item and not the skin (e.g. PoF elite specialization collections) so we had to run through all collections and reassign the correct item/skin. In this process we also added the subobject suffix to have full control which in my opinion we should not give up easily.

Furthermore, when we are trying to simplify/change this, then the correct subobject name helps alot, for example allowing to search for insource:"<item name>#fine" or insource:"<item name>#masterwork" to change all used instances. --Tolkyria (talk) 11:21, 18 March 2022 (UTC)

SMW property chain sorting

Hi, regarding your edit on Sold by where you added Has vendor.Is historical, Is historical, Has vendor, Has vendor section, Has item quantity. As far as I know SMW is still not able to handle this as you would expect. Namely, it reorders the sort properties by their property chain length, here it would turn this into Is historical, Has vendor, Has vendor section, Has item quantity, Has vendor.Is historical. It's a bit hard to figure this out in this particular query, but here's an easier example: Asking for the skill fact Might stored in a subobject and trying to sort first by profession number and then alphabetically by the skill name.

{{#ask: [[Has fact::Might]]
| ?Is for skill.Has profession sort order
| ?Is for skill
| sort = Is for skill.Has profession sort order, Is for skill
}}

Unfortunately, this is turned into Is for skill, Is for skill.Has profession sort order and therefore ruins the whole sort idea. The idea to fix it there was to introduce the self-referencing property Has page name to bring it on one level, namely Is for skill.Has profession sort order, Is for skill.Has page name.

Here, this trick isn't possible, however it seems to be not neccessary anyways. If I understand the code correctly, then Vendor table row inherits the historical status of the vendor. This means if the vendor is historical then also the vendor item subobject is set to historical and thus the first sort property Is historical from the old implementation is enough to sort it properly. I think you just got fooled by the slow SMW property purging as the subobject status is obtained with a self-referencing #show query and thus each page would need two purges (first for the infobox, second for the vendor subobject).

Try {{sold by|Leather Bag}} and purge historical vendors that appear in the middle of the table, they will be sorted at the end afterwards. --80.121.14.31 08:45, 16 September 2022 (UTC)

You're right, I was fooled by SMW not updating the subobject property even after purging. I'll undo the change as it doesn't even do what I expect it to do. Thanks! --BuffsEverywhere (talk) 17:38, 16 September 2022 (UTC)

Heart completion template

Sorry to interfere in your creative sandbox process for a heart completion template but wouldn't it look better if you do something fancy like Template:Legendary unlock text rather than the plain and boring Template:Mail format.

We have the following incredible images on the wiki which are ready to use (see also this discussion from 2016!):

• File:Renown Heart completion.png
• File:Renown Heart completion (infinity).png (with the template parameter option infinity to swap between those two)

--Tolkyria (talk) 10:04, 5 March 2023 (UTC)

You're right, that template is a lot better! I looked for the 1st image but didn't find it so thanks for uploading it!

In my opinion, the template should automatically use the 2nd image in repeatable hearts, but at the moment the heart infobox does not set a repeatable heart property. --BuffsEverywhere (talk) 10:27, 5 March 2023 (UTC)

Edit: I think the images might need to be resized to fit this template. There's too much empty space at the bottom of the image. Btw feel free to edit my sandbox. --BuffsEverywhere (talk) 10:52, 5 March 2023 (UTC)

Oh, that's definitely not a no-brainer like the legendary unlock text. There with a 1024x324px image it was pretty straight forward, here with a 512x512px it's much more complicated.

I played around a bit and tried four different options in your sandbox:

• default: your suggestion with reduced empty space around the image
• hard cut: cutting off the image at the bottom with a horizontal line
• inside white: moving the title inside the text with white font color, here we could also get rid of the horizontal line between the title and the text
• above: placing the image above and outside of the box (I think we can discard this)

--Tolkyria (talk) 12:39, 5 March 2023 (UTC)

If we find an image we're happy with, suggest we crop the one we want in the end rather than using negative margins if possible - these can be a bit funny when we're adapting css for mobile. -Chieftain Alex 13:09, 5 March 2023 (UTC)

charged quartz crystal nitpick issue

your recent change for Template:Recipe_list_result_format seems to be broken. you can check how these are now from Siege Novice's Guide (mystic forge recipes), and Crafting#Time_gated_recipes (charged quratz). The aim for my change was to display "Other" from charged quratz since it's been showing mystic forge. --Targal (talk) 08:22, 5 October 2023 (UTC)

Thanks for telling me, it should be working now. --BuffsEverywhere (talk) 15:10, 5 October 2023 (UTC)