Hearthstone Wiki talk:Admin noticeboard

Archives

• Noticeboard
  • Current page
  • Archive 1
  • Archive 2
  • Archive 3
  • Archive 4
  • Archive 5
• Discussion
  • Current page
  • Archive 1
  • Archive 2

Output list template

When creating visual lists of cards like on Mech, it's a fiddly job to convert the lists of cards into the required wiki text. What I've been doing is copying the lists of names from concepts when they're used, or directly from the tables when not. Then I have to manually remove all the superfluous info, and add in {{Card| <original text> }} on each and every line. While this is doable, it's a bit time-consuming, vulnerable to errors, and as more cards get added will become an increasingly laboursome task, especially with several dozen different lists on the site. It occurred to me that a template like {{Custom card table}} could be produced that rather than making a table would automatically render a list of relevant {{Card}} calls. This would also solve the problem of needing to remember to update each and every list each time something changes in the game.

That would be an ideal solution; if that's not possible, a template that simply outputted a <nowiki> text string would work; I could simply run it on a sandbox page, then copy and past the text into the pages themselves. This would still require manual effort, but would save me a huge amount of typing, and risk of human error. Alas, my knowledge of queries is not sufficient to allow me to do this myself. If you are able to make something like this, it would save a huge amount of time and help keep the site thorough and up to date, too. An example of the kind of text string that would need to be outputted can found in sections like this. -- Taohinton (talk) 18:42, 5 December 2014 (UTC)

Ack, I didn't see this yesterday. Anyway, yes, this is simple, pretty much blending a little code from {{Custom card table}} and most of {{Card}} together to make {{Cards}}, along with adding a |type= parameter. I'll ask about animated cards too when I talk to them about images tomorrow. — oOeyes 00:37, 15 December 2014 (UTC)

Excellent, thanks. This is a great improvement for the wiki structure, reducing and centralising maintenance a lot, and making sure the lists stay up to date, too. Just a couple of things: 1) The |type parameter requires 'Equipment' instead of 'Weapon' for some reason. We long since changed all the cards to 'Weapon' (since that's the word used in-game); I'm guessing a template somewhere never got updated. This seems to affect concepts too, so it would be good to have the system updated to use 'Weapon' - that's the actual |type value for the cards. 2) Hero powers aren't included for some reason. They're included in the tables like {{Custom card table}}, but not {{Cards}} for some reason. It would be good to have them included.

A miscellaneous but table-related bug is that {{Custom spell card table}} is for some reason lacking the collapse feature. -- Taohinton (talk) 03:59, 16 December 2014 (UTC)

{{Card infobox}} was still assigning Equipment to Property:Has card type. I've changed it, though as usual with changing things on the input side of the properties, it may take time for everything to catch up.

I found the bug responsible for spell card tables not being collapsible. It's fixed now, though the old code may linger in people's caches for a while.

As for hero powers not being included, I'm confused. Both templates use Concept:Cards first and refine their results from that. That concept does not include hero powers. Aside from {{Cards}} having an extra condition for the type, their selection criteria are identical. In testing, I couldn't get either to show a hero power. The only reason I could see for any difference is that {{Cards}} would have trouble for a card for which there was no image. Can you provide an example where the table does have a hero power showing? — oOeyes 05:10, 16 December 2014 (UTC)

It seems the hero powers show up in all tables which use concepts: Lesser Heal on Restore Health, Life Tap on Card draw, etc. Example connected concepts would be Concept:Cards with Restore Health and Concept:Cards with Draw. However, {{Custom card table}} doesn't include them.

It would be good to have them included, since they're important (often primary) examples of ways you can produce healing, draw cards, generate armor, etc. -- Taohinton (talk) 06:03, 16 December 2014 (UTC)

Another miscellaneous related problem: it seems both {{Custom card table}} and concepts like Concept:Cards with Durability-related are pulling all cards with either the 'Durability-related', 'Armor-related' or 'Health-related' tags. All tables and concepts pull all cards for all three tags, indiscriminately. It seems this is due to all of those phrases also being redirects to Attribute; I changed 'Damaged-related' to also redirect to that page (which it should have done anyway) and now that's being lumped in there as well. -- Taohinton (talk) 06:15, 16 December 2014 (UTC)

Right, the other concepts don't do any selection by type, so there's nothing to exclude hero powers. I've added Hero Powers to Concept:Cards, though I'm not 100% sure this won't cause hero powers to show up somewhere where they aren't wanted. If it does, we'll probably need an additional concept instead.

And yes, Semantic MediaWiki treats redirects as defining an equality relationship, and yes, it's is often inconvenient rather than helpful since it requires thinking about redirects in a much stricter sense. The developers call this inreferencing and consider it a feature despite redirects often being used for relationships other than "is equal to." With that kind of a redirect setup, the [[Has type::Page]] on Property:Has tags could be set back to [[Has type::Text]] and things should work as expected once all the property values catch up to the change; that's the only way to "shut it off," so to speak. Alternatively, perhaps you could put a table listing the cards with those tags on each of those pages. — oOeyes 06:50, 16 December 2014 (UTC)

It's getting pretty early here, so I'll process the second half of that when I've had a bit more sleep ;) Regarding the first half, it appears to have worked. I'm not sure where they'd pop up that would be improper but it looks fine so far.

Something you've adjusted has however caused a whole ton of cards to get de-cached (or whatever the correct term for that is), ie they've disappeared from tables and are red-imaging when directly invoked through {{Card}} (eg Warlock#Warlock_minions). This has happened a lot recently and is a bit problematic, not only because it breaks the card lists, but also since we get people trying to edit to fix the pages, which then has to be undone. Manually re-caching all the cards (which I've done before) takes quite a while, and the cards sometimes take days or weeks to recover by themselves. Any chance you could push a refresh through? -- Taohinton (talk) 07:24, 16 December 2014 (UTC)

The card pages have been resaved. Any pages with card tables might still need a refresh, but the properties should be fully updated. — oOeyes 08:28, 16 December 2014 (UTC)

Also, on the redirect issue. this might help: [1]. If there's any way to shut that "feature" off, I've never found any documentation for it. All that can be done is change the redirects back to normal pages or changing the property type to text. Might need to refresh some or all the card pages either way. Correction: I've found a setting for it, just missed it because I was expecting it to have "inferencing" in the name, but I have to talk to dev team because the setting isn't in the control panel for wiki managers right now. (And it'll probably still require refreshing when I can flip the switch.) — oOeyes 15:16, 16 December 2014 (UTC)

Redirect equality issue

While I need to wait to hear back from the dev team, our attempt to set $smwgQEqualitySupport to SMW_EQ_NONE is not disabling the feature as far as we can see. You can still see Attribute in Property:Has tags instead of Armor-related, Health-related, and so on, even though that feature should be disabled now. We may have to resort to one of the workarounds previously mentioned.

• We can change the type of Property:Has tags from Page to Text. We lose autolinking on tags that way, though the infobox and table templates don't rely on that. Mostly, we'd lose linking on the property page itself, the SMW special pages, and any queries that don't shove their results through a template. (But there probably aren't any that don't use templates.) Taking this option might be nothing more than a nuisance for me when troubleshooting issues.
• Change the redirects back to normal pages. While this is a bit hackish, you could put the content of each of the relevant sections on Attribute on each page, (like Health on Health-related) and then transclude as templates ({{:Health-related}} in the appropriate spot).

Either option will cause a number of pages to need updates. The first one will probably cause most card pages to need resaving, so either way, you'll probably need the bot to help out. Of course, we might still figure out what's going on, but it's good to start thinking about what option we'll resort to if we can't find the issue. — oOeyes 02:19, 18 December 2014 (UTC)

Golden cards

Up until now we've used static png images for golden versions on the site, just the same as for the regular versions. However, Hearthpwn is now using animated gifs, ~4MB each, to show off the golden versions. This means we need to either start using their animated versions on the site, or need to be supplied with high-quality static images for each card's golden version.

I'm in two minds about whether we want animated versions on the site or not; they're great, but they do distract a bit, and can get a bit irritating when you're trying to read an article and that Iron Juggernaut keeps throwing sparks. 4MB+ also seems like a large amount of data to download each time you load a card page.

I'd be happy keeping static images for golden versions, but we'd need someone to make some high-quality ones (like the ones we currently have for pre-GvG cards). The stills created from the gifs are definitely too low-quality. -- Taohinton (talk) 02:52, 12 December 2014 (UTC)

Card sizes

A perhaps more critical issue for the images is that the card images from Hearthpwn for certain cards are much smaller than the others. This seems to be due to blank space having been deliberately inserted into newer versions of images, which results in the image being scaled down when viewed on the wiki. This is bad in two ways: the images are smaller, looking less impressive, less clear, and making it harder to read the text, as well as creating a lot of empty space; and the other images are still full-sized, making lists of both types look very strange. In addition, the animated golden card images are much larger than the usual images, for an even larger discrepancy. Good examples would be this, and the "Uncollectible" section of Goblins vs Gnomes#Druid.

I'm in no doubt that the smaller images are worse for the wiki; the difference in size makes the wiki look clumsy and broken, and the smaller images simply aren't as good. The whitespace serves no purpose on the wiki, and just gets in the way. I could probably remove the whitespace on some of these manually, but not for regular and golden versions of hundreds of cards, and this seems to be the new standard format. We need them trimmed down, unless it's possible to have the blank space automatically ignored. -- Taohinton (talk) 02:52, 12 December 2014 (UTC)

I agree, and sadly, there is no simple solution wiki-side. I'll pass this along soon, and I'll keep you updated as I hear back. — oOeyes 15:04, 13 December 2014 (UTC)

Thanks. I can try to fix the existing problem images some of the worst existing images for now; my main concern is for the future, when we get another batch of cards + golden versions hitting. Ideally whoever does the image processing for Curse could just trim the whitespace off the images when they're doing them, and mass-upload the trimmed versions to the wiki; I can handle moving the images to the correct titles, etc, if that helps. I'm not actually sure why they've made the change, since all the trimmed images we already have did come from Hearthpwn and Curse in the first place, including most of the GvG cards.

Most imminently, when/if we do get golden versions of the GvG cards uploaded, it would be great if they could be trimmed. -- Taohinton (talk) 23:48, 13 December 2014 (UTC)

Update: It seems fresh copies of pretty much all card images have been uploaded to Hearthpwn since I last checked, and they appear to be establishing yet a new standard, this one intended to allow enough room to create identical scaling for each card, regardless of bulky frame elements such as the legendary dragons, but without surplus whitespace. This is something I had considered suggesting myself, and I believe would be suitable for the site, although due to the usual image wiki caching delays, I can't 100% confirm yet.

I assume whoever's responsible is/was iterating on image standards for the site. Once they've settled on a standard, and assuming the new size does indeed prove suitable, this would mean all we need is for someone to upload copies of all the card images. -- Taohinton (talk) 22:44, 14 December 2014 (UTC)

Flux has confirmed that all the images have been regenerated to allow for certain elements on various cards. We also still have static png versions of the gold cards being generated as well. I've requested that the new versions be imported to the wiki, but I don't have an ETA at the moment. — oOeyes 19:34, 15 December 2014 (UTC)

Cards by ability and tag

← moved from Project:Admin noticeboard#Cards by ability and tag

I was working on the Mana page today and realized there should be a tag for cards that modify mana costs, which I added as a new ability (Modify cost). While I could have tagged the variable-cost cards like the Giants and the Volcanics under that tag, there were enough of them and the effect operated differently enough that I figured it would be better to give them their own tag, which I created a page for (Variable cost). It was at this point I discovered the In-hand effect tag, which of course is comprised almost entirely of the variable cost cards. So I've backed off applying that tag for now, in part because {{Cards}} and {{Custom card table}} specify that only one tag can be used at a time, and obviously I would want the variable cost cards listed in that table as well, and it would be pretty redundant tagging every single one with "variable cost" AND "in-hand effect".

BUT. As I was tagging up Molten Giant, I discovered that Crush and Drakonid Crusher both appear in the related cards table for Health, even though one uses the Damaged-related tag and the other uses Health-related. A closer look indicated that the table uses the undocumented {{Card by ability table}} template, although the only parameter is "Damaged-related". An even CLOSER look indicated that all 3 tables on that page (health, armor, and durability), all list the same cards. So lots of tags are being conflated. SO,

1. what magic is it that allows those cards to get in on that action,
2. shouldn't Armor and Durability just be separate groups from Health/Damaged-related,
3. can I make magic happen with "Variable cost" cards so they show up under "In-hand effect" lists too,
   1. and if so can I make Bolvar NOT show up under "variable cost" tables?

Many thanks! - jerodast (talk) 01:30, 12 July 2015 (UTC)

It's the fact they redirect to the same page. This is an SMW feature that we tried to disable some time back, as according to the documentation, this can be done. But for reasons still unknown, the configuration setting doesn't work. So all tags that redirect to the same page get treated as the same. You can see it here: Property:Has tags where a lot of them say Attribute because that's where it redirects. Probably the only way to get around it is to change the tags property to a text type, which I'd probably have to run a bot resave after doing. I don't think there would be any lasting side effects, but I'm not 100% sure. — oOeyes 02:24, 12 July 2015 (UTC)

I see. Just to be clear, it's only tags which get conflated, which is why "cards with X" and "related cards" still get be separate lists (one is an ability, one is a tag) even though they're on the same page? - jerodast (talk) 02:42, 12 July 2015 (UTC)

{{Card by ability table}} was originally written just to deal with abilities, but its parameter value is a concept, so actually it works with any query in a concept, like Concept:Cards with Damaged-related, which does reference the tag. Hence why all three tables on Attribute are the same. They all reference tags that redirect to Attribute, and SMW's unfortunate "helpful" behavior is to decide they are therefore all the same. — oOeyes 04:24, 12 July 2015 (UTC)

I'm confused how a page like Divine Shield works with two tables then; both use {{Card by ability table}}, and both Divine Shield-related and Divine Shield lead to the same page, but they don't have the same issues as the tables on Attribute. - jerodast (talk) 05:38, 12 July 2015 (UTC)

Divine Shield is getting passed as an ability and gets stored in Property:Has abilities. Divine Shield-related is getting passed as a tag and gets stored in Property:Has tags. The issue with the Attribute page is that each table is pulling up cards by tags all leading to the same page. The tables on Divine Shield are referencing different properties. — oOeyes 06:38, 12 July 2015 (UTC)

I've been meaning to get back to this for some time. We definitely do want to be able to have multiple listings on a page using the same property, so if this seems like the best way to do it, please do make it happen. -- Taohinton (talk) 23:01, 24 July 2015 (UTC)

Presumably to do with the switch-over, tables for Charge and Windfury are now blank, since the ability is categorised as eg "Charge (ability)" rather than just "Charge". This may have been compounded by my finally moving the pages over to the proper titles, instead of "X (ability)". I remember you mentioning a place to adjust these auto-links, but I can't find the discussion. -- Taohinton (talk) 17:09, 25 July 2015 (UTC)

{{Card ability page}} and for tags, {{Card tag page}} are the templates you're looking for. — oOeyes 03:22, 26 July 2015 (UTC)

Presumably to do with this, the data page system doesn't seem to be accepting redirects any more. This has led to a lot of red "missing card" links, where previously text like {{Card|Thaddius (hero)}} was auto-redirecting to Thaddius. {{Card infobox}} is doing the same, no longer accepting redirects in |datapage. Editors have now fixed most of the errors, but I thought I'd let you know in case it's unexpected. It's slightly inconvenient, but if it's a tradeoff for fixing the other problem, we can live with it. -- Taohinton (talk) 14:55, 10 August 2015 (UTC)

Possibly also to do with this: we've been getting a lot of cases where the Summon ability has been present on the data page for many months or years, but it appears was not translating through to the infobox until recently. As a result editors such as myself had added Summon via |addabilities since it was missing; now something has changed and the Summon from the data page is showing in the infobox, resulting in "Summon, Summon", and thus necessitating the removal of Summon from |addabilities.

So far I've only seen this with Summon, and it's too consistent to have been simple oversight by the people adding it to |addabilities. It's not a problem, but I'm curious if this is indeed the case, and thought it might be worth reporting anyway. -- Taohinton (talk) 19:53, 15 August 2015 (UTC)

After some poking around, I honestly don't know what would have caused this, but I failed to locate a specific example where this happened. There's too many summon cards for me to check them all to find one with a relevant history. It's probably not important since things are working correctly now, though.

An update I made to ParserPower a while back added a lot of new features, including the ability to remove duplicates from a list. I've modified {{Card infobox}} to do this for the combined ability list now. Before, all I could really do is glue them together crudely with a comma. If you'd like, it is now also possible to sort abilities (and tags as well). Alphabetically would be easy, but if a custom sort order is desired, it would be possible to establish a template to return sort keys for each ability, though that's probably overkill. — oOeyes 22:34, 17 August 2015 (UTC)

No worries. Removing duplicates would be handy, and alphabetising both lists would be great. For the time being all abilities/tags are equal in priority so that would be fine. Good stuff! -- Taohinton (talk) 23:25, 17 August 2015 (UTC)

Redirect equality part deux

Replying to the above, the change to text type shouldn't have affected those properties since I didn't change those. I think what happened the surprise upgrade to a much more recent version of SMW means the redirect equality we tried to disable some time back finally did get properly disabled. Ironically, even though changing to text type was a little more of a hack (since it disables linking through property and SMW special pages), maybe it was a better solution after all.

The remaining page type properties are:

• Has page (the content page where the properties are actually set)
• Has data page (the data page)
• Has target page (the page to link to in tables/lists, usually the same as Has page, but different for those encounter pages where the infobox is on a subpage)
• Has image (the image page for the normal card)
• Has gold image (the image page for the gold card)
• Is chosen from (for cards that come from Choose One effects, this identifies the content page for the card it comes from)

The problem with redirect equality in SMW only comes up when editors define redirects that mean something other than "x is just another name for y." This was a problem for tags because we had redirects like Damaged that meant "this is related to Health, which is an Attribute." The remaining page properties only deal with card pages, data pages, encounter pages, and images, and I suspect redirects to these will always mean "x is just another name for y." I can turn the feature back on and run the bot resaves, but if you're aware of any redirects to these that don't mean sameness, or can imagine editors would sensibly create any such redirects, it'll probably become an issue again in the future. Being more familiar with the wiki, you might be able to better assess that risk than I can. — oOeyes 17:22, 10 August 2015 (UTC)