Talk: Admin noticeboard/Archive02

Archives

Noticeboard
Discussion
- Current page
- Archive 1
- Archive 2

Immune table[]

For some reason the {{Card by ability table}} on Immune isn't appearing. Out of curiosity, is this a bug, or working as intended? If the latter, that's fine, I'll just remove the template and maintain the list manually, but it seems odd since it works for all the other keywords. -- Taohinton (talk) 18:21, 24 January 2014 (UTC)

Well, it didn't have a concept set up for it. That's pretty easy to do. See the concepts in Category:Card semantics for examples, but I've set it up anyway.

But apparently Immune also isn't getting added to |abilities in the card data, which is needed for {{Card by ability table}} to find them. I don't know yet if this is an issue with the importer or with the card data itself. I'll follow up with the dev team ASAP. OOeyes (talk) 20:51, 24 January 2014 (UTC)

I talked to dev briefly, and all I've heard is that Immune not being added is probably a issue with the importer. Since it wasn't definite, I decided to wait for more firm information before passing it along, but I haven't heard anything more yet. It looks like they're going to be busy this week, or at least for a few days, so we're probably going to have to wait a while more on this, unfortunately.

Right now, though, I think we'll be able to add it to the imports and it won't have to be added manually. For the time being, the |addabilities parameter could be used to add it, with the tradeoff that if it does get added to imports, there'd be the chore of going back and removing it to keep it from being listed twice. OOeyes (talk) 19:33, 24 March 2014 (UTC)

Come to think of it, another option would be to put it on the data pages themselves. Worst case: it doesn't get added to the importer and the next import removes it. I'll leave it up to you and the community if you want to address the issue temporarily or wait for more firm information. OOeyes (talk) 19:35, 24 March 2014 (UTC)

I've gone ahead and added it to the data pages. This seems like a pretty good solution, and there are only 3 cards with the ability, so it shouldn't be too much trouble if it gets overwritten ;) -- Taohinton (talk) 20:59, 24 March 2014 (UTC)

Miscellaneous card issues[]

1) Cards with zero mana cost currently have no mana value at all recorded in the card data, with the result that they are showing up in tables with no information at all in the mana column. This is a bit unclear, especially for players unfamiliar with those cards, and simply doesn't look very good. Ideally we'd have a mana cost of "0" listed for all those cards. If it's a lot of work, it's something that could be incorporated into future overhauls, but ideally it's something we'd have in place. A simple workaround might be getting the tables to list zero mana cost if no number is supplied.

Changed {{Card data}} to add 0 to spell cards when no value is specified. It may take the wiki a little time to update. Due to a minor mistake I made, you may see a few cards show something like 1, 0

. The mistake is corrected, but some might linger for a little while. OOeyes (talk) 14:48, 2 February 2014 (UTC)

2) There seems to be a display size discrepancy between regular and golden cards. This can be seen on data pages, eg. Data:Cards/Rampage(454), but also shows up when {{Card}} is used. -- Taohinton (talk) 13:58, 2 February 2014 (UTC)

The aspect ratios aren't the same. I'll have to pass this up. I don't know why they are different sizes. OOeyes (talk) 14:48, 2 February 2014 (UTC)

Just to be clear, I think they do want to be displayed the same size; as the bottom of Rogue demonstrates, the discrepancy is noticeable and looks a bit odd. -- Taohinton (talk) 00:50, 3 February 2014 (UTC)

Tooltips[]

With the card data problems almost behind us, this is in my opinion the last big "must-have" feature for the site to be fully functional. Mouse-over tooltips for cards would greatly improve the site, although we may want to wait until the card images have all been uploaded, if that issue would cause unsightly problems. -- Taohinton (talk) 13:59, 2 February 2014 (UTC)

There are a few approaches we could use, and it depends a lot on what you want in the tooltip. Using just the images probably wouldn't be a big deal. Creating tooltip pages that can be edited is another approach, and a feature I already have in place on Neverwinter Wiki. And this wiki might have another option in that it might be possible to tie into Hearthpwn's tooltip system, though I'll have to investigate that further. OOeyes (talk) 14:21, 2 February 2014 (UTC)

I think for Hearthstone simple card images would be ideal. That should give players everything they need to know about the card from a link - helping them to identify/remember/discover its basic properties, and view its art - and they can click on the link for detailed notes, strategy, etc. Regarding HearthPwn, I guess it might be a small difference; but my feeling would be that it would be better to be self-contained, and have total consistency between tooltips and the pages they link to. At the least, it can be a handy way to alert you that something's gone wrong with the card data, etc. -- Taohinton (talk) 01:04, 3 February 2014 (UTC)

Alright, I had to make more changes to my tooltip code than I initially anticipated, but it seems to be working correctly at the present time. I've put it in place, but it's not completely finished. I'm working on getting "loading" and "missing image" images set up. Let me know if you encounter any problems; just because it's testing well on my end doesn't necessarily mean it's completely right. OOeyes (talk) 15:15, 5 February 2014 (UTC)

This is a wonderful addition to the wiki! It feels much more alive now. --

Fluxflashor : (Talk) 16:26, 10 February 2014 (UTC)

Great to have the tooltips in place! A few thoughts:

The fading in and out looks nice, but it seems to be causing a few problems. Firstly, when briefly moving the mouse across a link, the image takes a full second to appear and disappear. Try this over a series of links (such as the recent changes list or card lists on Druid) and you get a kind of cascade of fading cards. Move the mouse back and forward a few times (which is surprisingly easy to do by accident) and you get a kind of strobe light-show which can go on for some time. It seems this could be fixed by removing the fading, and making the cards just appear and disappear. This is the style used on HearthPwn and Wowpedia, and allows for quick browsing of lists without image hang-over (eg. Priest abilities).

Switched from fadeIn() to show() and fadeOut() to hide(). OOeyes (talk) 01:18, 18 February 2014 (UTC)

Tooltips are currently appearing from not only regular text links, but also image links/{{Card}} usages, 'diff' links in edit histories and recent changes, and section 'edit' links on the pages themselves. We don't really want tooltips in any of these cases. I'm not sure whether we want to have them appear from page titles in recent changes/watchlists either; having them only appear in content usage (ie. when linked on pages/talk pages themselves) would be fine with me.

Managed to exclude links that don't contain any text content. Ideally, this would only not set up a tooltip for those links that already have the regular or gold image inside them, but that will have to wait until I can try some different schemes for querying this information from the server. Other links will have to wait until I have time to sort out the best ways to identify and exclude them, and might not be possible in some cases. OOeyes (talk) 01:18, 18 February 2014 (UTC)

I gave it some time to get used to it, but I definitely feel the card images want to be made a bit bigger. The size we have them for {{Card}} would be about right I think, or if that seems too big, {{Card infobox}}.

The size is calculated based on the vertical height of the browser viewport within a certain range. I adjusted the formula. Note that it won't enlarge the card images beyond the native image size (or if it does, it's a bug).

All tooltips seem to be defaulting to golden versions where available. My perspective is that it would be better to use the regular versions. Since we have non-animated golden images, as it stands pretty much the only difference is the colour of the frame, which changes from the significant class colours to a uniform gold, removing class/neutral distinction and making all the cards look the same. Golden versions are also seen far more rarely, which to me makes it make sense to use the standard version for tooltips instead. If it's set up this way in preparation for animated golden images, that might work, although I'd have to see how it looks to say whether that's the most appropriate version for regular tooltips.

I don't know of any plans to animate golden cards. Switched over to default to regular card images because it's not that difficult an adjustment to make. OOeyes (talk) 01:18, 18 February 2014 (UTC)

Finally, tooltips don't seem to be appearing for non-relevant cards. I can't see any real problems having tooltips for these cards would cause, and it would be handy to have them work with these.

Added Category:All cards to allow the tooltip script to process all card links. OOeyes (talk) 01:18, 18 February 2014 (UTC)

Good work so far, and sorry for the list! -- Taohinton (talk) 14:08, 16 February 2014 (UTC)

Update[]

Made an important bug fix today to resolve an issue that could cause tooltips to keep displaying the loading image indefinitely after the tooltip was loaded. I'm putting an issue list for things I'm hoping to work on this weekend. OOeyes (talk) 18:32, 6 February 2014 (UTC)

Known issues and planned improvements[]

Behavior
- If the mouse cursor manages to get over a tooltip, this can cause it to repeatedly fade in and out and stop moving with the mouse - this seems to be fixed now, leaving this here in case it's observed again later.
Performance
- Algorithm to detect links to cards can likely be streamlined significantly, but a little more research is needed. If so, tooltips should begin functioning more quickly after the page loads once the streamlined algorithm is in place.
- Algorithm to load tooltips when hovering over links can probably be streamlined by using a protected template on the wiki to combine two server requests into one. This may speed up tooltip loading time noticeably.

Making the tooltips load faster on bulk pages like Artists would be great. Just linked the page on Twitter, but unfortunately it takes about 20 seconds before any tooltip images start to appear at all, including the placeholder image, which can give people new to the wiki the impression that we just don't have tooltips on the site. On pages like Lord Jaraxxus it's more like 4 seconds, which is okay although obviously faster would be great. -- Taohinton (talk) 13:16, 10 August 2014 (UTC)

Frontpage Overhaul[]

I'd like to discuss an overhaul of the frontpage here on the Hearthstone wiki. It's currently quite bland and, as biased as I may be, we need a section for esports! One big issue I see with the current design is that because it is formatted through a single table, you end up with some weird whitespace places. It isn't a bad thing in a couple of boxes, but our primary box at the top for "The Game" is pushing all the sweet content down.

Do we even need "The Game" as a section? As of right now, it's just Blizzard copypasta and doesn't really tell anyone anything important. In my opinion, we should make this a newbie info box where we can link to any guides we may have on the wiki or offsite. Move it down a bit on the page so that it's accessible, but the actual game stuff is even quicker to get to.

Then there's the Heroes and Class boxes. I think we should pick one or the other. The hero pages themselves already provide a link to the class pages in their introductory sentence, and if needed, we could also create a new hero infobox to have quicklinks to their different card types, leveling rewards, hero power (absent from the hero pages), and a link to their full lore article on Wowpedia. I propose we expand the size of the hero box horizontally, and give all our heroes some nicer images like this. Once they start adding more heroes to the game, the format would need to be tweaked (maybe half height images?), but we shouldn't be seeing those added for a while.

The trailer is outdated and doesn't really serve a purpose on the page. Let's get rid of it.

The cards box could use some pictures as well.

The Abilities box is incorrectly named; These are mechanics/keywords.

The Game Mechanics box doesn't really have anythign to do with the rules of the game. It's more of a feature/game overview if anything. Game modes could also be tossed in there without much of an issue.

Wiki Community is great since this wiki still needs many more volunteers to help out, but once we're happy with the helpers we have, we should just tack something onto the sidebar for this.

I'd like to get a box on the right side going for Tournaments and Teams at the very least. A featured article somewhere would also be a great addition to the front page. Maybe we could do featured card articles for a while until we get things more esports stuff fleshed out.

I'm going to be working on something in User:Fluxflashor/Sandbox throughout the day. I'll reply back when I've got something worth sharing, or someone else responds with their thoughts! -- Fluxflashor : (Talk) 17:11, 10 February 2014 (UTC)

I've completed a preliminary pass of a new frontpage. I think the tournaments box needs to be relabeled to competitive, and it will then include the events list and either a list of teams or players beside it, it looks awkward being so big at the moment. The headings need to be linked to relevant pages and modified to match the current heading color on the homepage, and the tournaments box needs some new colors to better match the wiki, but I think this is a great start to something new. Anyone have any comments? --

Fluxflashor : (Talk) 19:46, 10 February 2014 (UTC)

I like it so far. One design note: the extension we use for mobile removes everything from the main page except elements with an id beginning with mf-, so before you deploy, all boxes you want to see on the mobile version will need a unique id starting with mf-. OOeyes (talk) 20:03, 10 February 2014 (UTC)

Ah, that explains the mf ids, I'll get on it. While on the subject of mobile browsers, the mobile site is using the old theme with the textured background. I don't recall seeing anything for the mobile theme anywhere, where is it stored?

Oh, and the current version of my mockup also does not work at all on mobile, so I'll have to look into squashing the bugs. --

Fluxflashor : (Talk) 20:13, 10 February 2014 (UTC)

MediaWiki:Mobile.css. OOeyes (talk) 20:25, 10 February 2014 (UTC)

Bookmarked for future use, thanks! --

Fluxflashor : (Talk) 20:27, 10 February 2014 (UTC)

Okay, a few thoughts. I like the pictures - I think they add a lot of colour and life to the page, which is great. I think showing the card types like that is good too. I have an issue regarding the class/hero links - while I completely agree that the previous system was messy, I think we need to either provide links to both hero and class pages, or even just class pages. The reason is that when readers click on a link like "Jaina Proudmoore", they want to find out what it's like to play as Jaina, what cards she has, what hero power she has, what her strengths and weaknesses are in the game. All of this info is found on Mage. When they link to

Jaina Proudmoore, all they get is a description of what she did back in Warcraft III with pre-Lich King Arthas, and an explanation of why her hair is white. None of this actually has anything to do with or affects 'Jaina' in Hearthstone in any way - it's just background fiction from earlier games, novels and comics. It's nice to be able to explore at some point, but nowhere near as relevant or priority as exploring the class. Many readers are also going to be familiar with most of the heroes already from WoW (or earlier games).

While we could add hot-links to some of this info from each hero page, I feel that's essentially a work-around for a misdirection of traffic. Mage is the page that describes Jaina in Hearthstone -

Jaina Proudmoore is just background lore. This will become even more apparent as we get additional heroes, with radically different characters (eg. Garrosh and Varian) and yet absolutely identical abilities. Beyond perhaps emphasising the class link even more, I don't think we should add further class summary info to the hero pages, but rather direct to that info on the class pages.

The only thing is, "Jaina Proudmoore" looks better than just "Mage"; ideally, we need to find a way to link to both class and hero pages from the front page that looks nice. In theory you'd just add this in text ("Mage: Jaina Proudmoore" or "Jaina Proudmoore (Mage)"), but in practice this tends to look pretty messy. One solution is to add a separate Classes box underneath like this, which offers class links while de-emphasising the Heroes box. This looks nice, although it doesn't solve the problem perfectly. A more head-on option would be this, which makes sense game-wise but may be a bit too much visually. -- Taohinton (talk) 23:27, 13 February 2014 (UTC)

I can't say I really disagree with you. Originally I did feel that it looked very silly having both on the page, but I can definitely see it working better when the icons for both heroes and classes aren't mirrored.

Adding more class specific information to hero pages adds a lot of redundancy to the wiki and generally should be avoided, so yes, classes box underneath the heroes box is likely the way to go. Now, the big question, should the class icons be smaller than the hero icons, or should they be the same size? I've got highres images from the client I can upload for the images, so we can edit them into any dimensions needed - although these might actually already be uploaded by me. Using the class icons from the game itself instead of the WoW ones is preferred in my eyes, but let me know if you feel differently. I'll try and get stuff fixed up on my sandbox this weekend or later this evening. --

Fluxflashor : (Talk) 22:43, 14 February 2014 (UTC)

I would definitely say the ones from Hearthstone if they look good, and the ones you've added look great! I simply used the current icon files that are used on the hero and class pages. I'd suggest using these circular images instead of those for the icons too, perhaps at a slightly larger size if necessary. Is there a reason the mage one looks different? Are the others hand-edited or simply taken from a different appearance in-game? Also, I assume it's an error in the divs that's stacking them vertically? -- Taohinton (talk) 14:32, 15 February 2014 (UTC)

While I'm curious to find out the reason for the differences, I should say my first impression is that the non-mage ones look better; more colour and shine, and less grey border. I would probably favour those ones, even if their borders are slightly modified from the exact game icons. -- Taohinton (talk) 21:43, 15 February 2014 (UTC)

The mage one is an edit from the HearthPwn deck listing page. The in-game icon borders are slightly off on some of the icons so I was going to import the hearthpwn version of the icons over for a more polished look. The vertical alignment is just some missing css - didn't want to make any major changes to the site css until I have more to add to it! Custom CSS is here User:Fluxflashor/hydra.css. I'll get two versions of the icons up this soon for comparisons sake. Sadly, been a bit busier than I had planned to be this weekend. --

Fluxflashor : (Talk) 02:35, 17 February 2014 (UTC)

Resuming the overhaul[]

Along with the new skin deployed today, I'd like to try to resume this stalled overhaul, hopefully getting a new main page in place perhaps by the end of the week. I think the mockup produced by Fluxflashor is a pretty good start, but I'd need some help setting up the tournaments section. Obviously, styles will have to be adapted to the new look, but before I get started on adapting this, does anyone have any further input on the current mockup? — oOeyes 16:35, 24 June 2014 (UTC)

I'd been planning on suggesting the exact same thing, but was holding off until the main makeover was sorted out. I think the mockup is pretty solid, although I may tweak the ability lists, etc, when I get around to it.

My one concern is the Tournaments section. The main issue is the amount of ongoing work to maintain it and keep it keenly up to date, since it will be such a prominent part of the front page. It's really not my area or something I think I can be the one to keep up with; I'd be happy to contribute in various ways but I'm way too busy with other things to be responsible for regularly creating new listings, etc, and it sounds like Flux is pretty busy these days between his sites. If you or someone else can take on the task, that would be great; if not, I'm concerned that having a constantly out of date listing of events on the front page might be far worse than simply not having one. -- Taohinton (talk) 05:47, 27 June 2014 (UTC)

I have much the same concern. There is some desire internally here for the front page to have some kind of "competitive" section, but I agree it would be best to not have something that requires continual maintenance as such things are nearly guaranteed to fall out of date at some point. This leaves me at something of a loss as to what to do with that area. I'll see if I can get in touch with Flux. Meanwhile, if anyone has any ideas for a "competitive section," I'd love to hear them. — oOeyes

02:19, 30 June 2014 (UTC)

For lack of any better ideas, I've just resorted to replacing that section with the PlayHearthstone Twitter feed. This left me with surprisingly little more to do; the mockup was more up to date with the current main page than I expected. You can see the restyled mockup here: User:OOeyes/Hearthstone Wiki. I'll wait a couple days for any comments or requests. Barring anything major, I'll put it in place this weekend. — oOeyes

Looks good. I've added a Curse of Naxxramas highlight box. This should help funnel people to important/current content (currently Naxx), and helps keep the wiki presentation fresh and interesting for those who aren't new to the game. My suggestion would be to maintain it with new features/current content, which I'd be happy to do. In quieter times it could be taken down or even used to highlight articles. Hopefully I haven't messed the coding up too majorly adding the box. -- Taohinton (talk) 23:17, 5 July 2014 (UTC)

Sets, card data and tables[]

I'd like to suggest adding card set to card data and the card infobox display. I see this data is already found on Hearthpwn, so I assume it is available but simply hasn't been used in our system. It's obviously a key piece of info, but is missing at present. Adding this would allow us to make card set concepts, which would allow us to provide tables of each set, which would be great. I'd suggest adding the info just above Rarity in the infobox, and linking the text to the appropriate section of card set, where I'd place the appropriate table.

This raises a related matter, which is that it would be great to be able to collapse the card tables. The tables on pages like Minion for example are already fairly massive, and they're all going to get bigger and bigger as the game expands. Having collapsible tables (with the option to have them default to collapsed) would allow us to provide comprehensive listings on pages like Card set and Rarity (these are strangely missing from the site at present; for a list of all epic cards you have to look on three separate pages), without making the whole page half a mile long, and would make it possible to have several tables on a single page (eg. Rarity), with the reader opening the ones they're interested in.

Regarding adding set data, I can see this might require re-importing the data for all the cards. If that's too big a task, I suppose it could be done manually. Obviously it would make sense to have that data included in future imports.

I'm assuming concepts run from card data, meaning you can't really have an automatic table determined by data not found there. If that's the case, I'd also like to suggest adding an uncollectible parameter, similar to devonly and current, in order to allow for a table of uncollectible cards. The current visual list is nice, but will grow pretty unmanageable with the addition of further cards, and of course isn't sortable in any way. If 'uncollectible' is already a parameter in the Hearthpwn data (which it doesn't seem to be) that could be directly loaded from there instead. -- Taohinton (talk) 13:03, 3 March 2014 (UTC)

I'll have to talk to dev about this when I can. It seems like the card sets should be something we can import if the data is present on Hearthstone, unless that's something that's done manually done over there behind the scenes. If not, I can set up parameters on {{Card infobox}} and modify {{Card data}} to read this in from that source. It already does so for things like devonly and such, mixing together the user-supplied and import information. uncollectible can be handled the same way. I'll describe this a bit more in a response to the request below. OOeyes (talk) 03:54, 4 March 2014 (UTC)

I've responded below regarding uncollectible. -- Taohinton (talk) 14:08, 4 March 2014 (UTC)

Any news regarding making the tables collapsible? Ideally with an auto-collapse option so that I can include them on Card set and Rarity. -- Taohinton (talk) 23:20, 28 March 2014 (UTC)

Incidentally, I've long found the sort function on tables on pages such as Minion to be somewhat dysfunctional. I've assumed this was specific to my setup (Safari, Mac, OS 10.7) but it may be affecting other users too. The behaviour varies by table, but largely makes sorting by most columns not work at all, and/or jam up the table until I reload the page. The "Showing all X cards" row also gets sorted as though it were a real row. -- Taohinton (talk) 23:30, 28 March 2014 (UTC)

Ack, sorry. I missed the notification on this. mw-collapsible has an unfortunate side effect with these tables, revealing rows or columns that are supposed to be hidden based on the width of the browser window. It looks like it'll be necessary for me to write my own little script to handle this. On the sorting issues, the news is better, as I've figured out how to solve them. I'll set aside some time tomorrow to get the fixes in place on all the tables. OOeyes (talk) 09:24, 15 April 2014 (UTC)

Sorting issues should be fixed on all the tables now. I might have some time during my current project to whip up a collapsible table script for the card tables in the next few days. OOeyes (talk) 07:12, 17 April 2014 (UTC)

As I haven't decided what to do with the tournaments section on the main page, I instead took the time to catch up on this. The card tables are now collapsible. You can use |collapsed=yes on any of the card table templates so they appeared collapsed by default, assuming I didn't accidentally miss any. — oOeyes

16:08, 30 June 2014 (UTC)

Card data, abilities and mechanics[]

On a similar note to the above, I've been thinking about how to solve the discrepancy between the cards listed on certain ability/keyword pages, and the cards which actually use those mechanics. For example, Summon lists all cards with the Summon ability parameter. The thing is, this parameter seems to be missing for quite a few cards, such as Hogger, Imp Master and Mirror Entity (which all summon minions). My guess would be that the ability isn't added when the Summon is a triggered effect, or otherwise conditional, such as Bane of Doom. I'm assuming that concepts and the related tables will only work directly through card data pages, in which case we need some way of tagging the card data.

I thought perhaps we could add the ability manually through the content pages using |abilities, but this doesn't seem to work. If the problem is that this parameter is effectively overwritten by the card data, a slightly messy but perhaps fairly good solution might be to add another parameter (eg. ability or abilities2) which would simply allow for a separate manual list of abilities. The two parameters could then both be used for concepts, and both could be listed in the infobox.

This all brought me to thinking about providing listings for non-keyword mechanics such as destroy effects. Again, sooner or later these pages will grow too big for visual listings, and these also lack any sortability, but the mechanics themselves are well-worth listing. It occurred to me that we could add a mechanics parameter, which would not be displayed in card infobox, but would allow us to tag pages with mechanics such as 'destroy'. This would allow us to list these cards in tables, which would be great for those pages, allowing us to provide a similar level of functionality on all ability/effect pages. This seems a reasonably good solution to this sorting problem.

As I've said, my knowledge of the technical side of this stuff is limited, so any better ideas would be most welcome. -- Taohinton (talk) 02:44, 4 March 2014 (UTC)

This is possible, but slightly tricky due to abilities being a list. We might need two different parameters: one that adds to the list and one that overrides the list, or perhaps just adding to the list is sufficient. The code to accomplish this is a little ugly, but not too bad.

Right now, Hearthstone Wiki is still using the older approach to this. Conceptually, the full data set is living in properties on the data pages in this approach. The user supplied information, unfortunately, is currently living in properties on the content pages, and then when they are saved or recached, the data pages bring that information in their properties, so in essence, user-supplied information is on both sides. The data page side of things is what the concepts look at, and there's we get a lot of the caching issues.

The newer approach actually sets properties on the content pages, actually treating the data pages like an invisible template. Data pages only set just enough properties for the content pages to find them, but the full data set lives content side. This has a couple advantages: the data page being treated like a template means MediaWiki knows that a change to the data page affects the content page, so it should recache on its own in most cases. Secondly, any user-supplied data gets added directly to the data set the concepts are actually using, so only the listing pages should need to ever be refreshed for that. I just recently set this up on EQNext Wiki for EverQuest Landmark, and so far it seems to be working like a charm.

I bring this up because if we want to keep increasing the amount of user-supplied data in the data set, the newer approach is probably more convenient in the long run, but switching things over will take more time and potentially introduce some temporary problems as the full data set switches its "home", so to speak, and well, it's much newer, so there might still be unknown problems. (And this would even affect the new tooltip system, unfortunately; it'd need to be updated too.) Either way, I still have work to finish up on EQNext, so it'll probably be a day or two before I can start work here. OOeyes (talk) 03:54, 4 March 2014 (UTC)

Sounds good. Adding user-supplied data seems to be fairly necessary to make a nicely sortable set of card data, so I certainly don't see it going away any time soon. With regard to abilities a second parameter to add to the list would be ideal. I could actually use this to provide a slightly more accurate list of abilities too, eg. adding Destroy for

Vaporize.

Regarding parameters themselves (assuming that still holds), it occurred to me that one way to reduce the number of individual parameters would be to swap mechanics for tags. Since the parameter is hidden it seems we could just use the one for all sorting purposes, rather than needing to create separate parameters for each type of tag. You could then scrap plans for uncollectible too. I'm guessing that would work fine, and would save me asking you to create a new parameter every time I want to set up a table for something new ;) -- Taohinton (talk) 14:08, 4 March 2014 (UTC)

Just wanted to leave a quick update. I was able to get a start on this and may be able to do some more tomorrow, but I have surgery on Friday. Most of this work should be done during off hours if possible since it will disrupt a lot of functionality temporarily, so the weekend will be a bad time to finish this up. I'll try to set aside time to finish it up late Monday night. OOeyes (talk) 18:48, 12 March 2014 (UTC)

That's fine, no rush. Best wishes with the surgery. -- Taohinton (talk) 19:38, 12 March 2014 (UTC)

Going to need to talk with dev a bit tomorrow to get more information about adding card sets, so I'm going to schedule the finishing-up work tentatively for late tomorrow night. And thanks, the surgery went well. OOeyes (talk) 01:51, 18 March 2014 (UTC)

While I haven't added all the requested features, the changeover of all templates and other code to the new system is complete. For the most part, pages seem to be switching smoothly over to the new system, but I have observed some that are being slow to switch over. I expect we'll have some lingering issues into tomorrow. I'll talk to one of the other wiki managers tomorrow about running a bot over the card data and content pages to get them to regenerate, which I expect to solve the slow changeover issues.

This can also be done manually be saving the data page with no changes and then saving the content page with no changes; this should force both pages to fully and properly switch over. The telltale sign that a set of pages hasn't switched over yet is an infobox empty of anything except a 0 mana cost; the data page will probably also say it isn't being used by a content page.

As there doesn't seem to be any serious issues at the moment, I'm going to turn in for the night and work on the new features and any lingering or newly discovered problems tomorrow. OOeyes (talk) 10:05, 19 March 2014 (UTC)

We have a bot running over the data and content pages now to iron out the lingering switchover issues. By tomorrow, any issues still around are not likely to be due to simple slow switchover and will need further troubleshooting.

Support for sets has been added to {{Card data}} and {{Card infobox}}. I'll get in a request for a new import to add this information, which hopefully will address the lingering problems with missing or incorrect images as well.

Support for added abilities, custom tags, and marking a card as uncollectible have been added to {{Card infobox}}. At the moment, the latter two just invisibly set information to properties. I'll set up new templates soon that will let you list cards by these tags. As for uncollectible, is it safe to assume that we want to exclude these from lists? If so, I'll make that adjustment soon as well. OOeyes (talk) 00:56, 20 March 2014 (UTC)

I don't think we want to remove uncollectible listings. At first glance it seems like they shouldn't be included, since they can't be collected. However, in practice most of these cards are effectively collectible - minions like

Mechanical Dragonling can be summoned at will, it's simply summoned through another card,

Dragonling Mechanic, which is collectible. Overall, we definitely do want to list these cards, although in an ideal world we'd have some simple way to mark them as uncollectible. I have a couple of ideas for that, but as it stands I'm happy to leave things be for the time being. -- Taohinton (talk) 18:21, 20 March 2014 (UTC)

Just in case you haven't checked back yet - we do seem to have a couple of problems hanging around following the changes. Firstly, every card page starts with " {{#if:| ". Some start with a special linked " … further results{{#if:| ". Secondly, the pages with the latter error are having identity issues (eg.

Mirror Image,

Spellbender, which feature the data for the spell and not the minion). Thirdly, abilities displays for the infoboxes are appending " [[{{{addabilities}}}|{{{addabilities}}}]] " to the end of any other abilities. -- Taohinton (talk) 18:18, 21 March 2014 (UTC)

The first and third were the same problem and are fixed. I changed the second to display a more useful message. Unfortunately, the old method of using card types and such to pull the correct data page are no longer available. I also added a new category, Category:Ambiguous card infobox usages, to identify any pages with this issue. I'll spend a little time fixing some of these today. OOeyes (talk) 19:52, 21 March 2014 (UTC)

One remaining bug is tables on abilities pages (eg. Taunt), which are listing card titles as [[|Example]]. Also, the golden versions are missing from infoboxes. -- Taohinton (talk) 17:50, 23 March 2014 (UTC)

Ack, I thought I had updated the ability queries along with everything else, but seems I missed them. But easily fixed. The infobox error was also thankfully trivial and is now fixed, though that one may take some time for all of them to catch up. OOeyes (talk) 21:34, 23 March 2014 (UTC)

Implementing[]

I've finally gotten around to beginning to implement this system ~~(final details still being iterated)~~ for all the card pages. The general plan is to tag all cards with abilities and tags (secondary qualities like Triggered effect and Area of effect) through {{Card infobox}} (and the card data itself where already present), and use that to set up tables. So far this has been going pretty well, but there are a few things I could do with some help on:

I've been unable to get a concept to work sorting based on Is part of set. I'm not sure why, and I can't find any substantial help online re: concepts. I'd like something like Concept:Basic cards for each set, so I can make tables. [Or this might work through the combo template; see below]

If you could make |tags be displayed in the infobox (presumably titled Tags:) that would be great.

It might not be needed ~~once things are finalised, but in the process of iterating/inevitably having better ideas half way through implementing I was wanting~~but I was wondering if it was possible to make a concept with various possible criteria (e.g., one or both of two possibilities)~~, and wondered if that was possible/how to do so~~. An example would making Concept:Cards with Damage accept either "Damage" or "Deal damage" for |abilities.

Another aspect of the plan is to be able to tag cards according to the expansion/adventure in which they were added, as well as for art. I was going to do this through another parameter (I had started adding a provisional |hiddentags parameter to template calls) but having explored concepts a little more, ~~I think I'll probably~~I've added these through categories, and have the concepts find them that way. Since I didn't really think we should have these tags shown in the infobox, using categories seems to make sense to add some visibility, and saves adding another parameter too. I thought I'd share the plan here just in case there's some technical reason to do it the other way that I'm not aware of. -- Taohinton (talk) 16:49, 26 July 2014 (UTC)

No great rush on the above, but I wanted to check the post found you, since I know it's easy to miss things when I edit multiple sections of the page in quick succession.

Related, I just discovered the custom templates you posted on the noticeboard itself back in April; I think I was unwell or very busy at the time and never really took them in, and since we'd talked about concepts previously I went that way when I started to implement the plan. The templates would have been perfect for what I've been doing with the concepts I guess (although making the concepts hasn't been problematic, with the exception of sets) - except that they're card-type specific. What we would need is a single template like that which works for any card type, be it minion or spell or weapon. Ultimately, I assume the template would provide the same functionality as {{Card by ability table}} and the concepts, but a fair bit more neatly, which would be great. If it's not too much work, a combined template would save some time in the future. -- Taohinton (talk) 16:40, 11 August 2014 (UTC)

Archiving[]

I've moved the old and resolved discussions over to the archive. The process is obviously a little subjective; it seems like we shouldn't rush to move recent discussions over when there's a chance another related issue will crop up (as they often do). I'm assuming the idea is to leave discussions related to ongoing issues, regardless of whether the discussion itself has concluded, to allow readers to review and contribute to the discussion related to the issue. As mentioned in the edit summary, I've moved talk related to missing card images since it's inconsequential and part of another topic anyway. Feel free to move things back.

Regarding new issues, I'm assuming I should be posting them on the new noticeboard, and that any ensuing discussion will be transplanted here and replaced with a summary (I'm new to the system). -- Taohinton (talk) 19:14, 24 March 2014 (UTC)

Yeah, we just fell into bad habits and lost a lot of usefulness of the board by treating it like a regular talk page. That's on me too; I should have been shifting discussion over here. It works best if relatively brief descriptions of issues are on the board itself so everyone who's interested can see what's up quickly. Letting it turn into a wall of text prevented that, so I'm going to exercise more discipline in the future and move things over here when they start turning into a discussion.

As for the archive, thanks for the help. Now that things are cleaned up, we'd just normally treat this like a regular talk page and just archive old topics when it gets long. It was just busy yesterday, so I ended up splitting the archiving task into parts this time. That's not normally how I would do it. OOeyes (talk) 19:45, 24 March 2014 (UTC)

I've also left the Immune table topic unarchived, as I haven't heard back from you yet on it. -- Taohinton (talk) 19:18, 24 March 2014 (UTC)

Missing images and inconsistent image sizes[]

An import is being done now to address the missing images, but there are a couple of updates I need to pass on:

We now longer generate images for enchantment cards.
The card images are automatically cropped from our model viewer to get the minimum width and height. This is different for normal and gold card images, so we'll have to work on adapting templates on our side to deal with the size and aspect ratio differences.

So please let me know what templates you know about that need to be adapted, and I'll get it on my list to work on. OOeyes (talk) 22:18, 27 March 2014 (UTC)

Good to have all those red links sorted ;) However, I notice we still seem to be missing golden versions for uncollectible minions. For example, we have a golden version of

Dragonling Mechanic, but no golden version for

Mechanical Dragonling. These obviously do exist, but strangely were also missing from the January 10th imports.

Possibly related to the import are the 41 pages in Category:Pages with unknown cards, which apparently "contain {{Card}} usages that do not link to any known card on the wiki." Doesn't seem to be the case though; Jonathan Ryder is a good example. Presumably nothing to worry about, but I thought I'd mention it anyway in case I'm missing something.

On an entirely unrelated note, I'd like to suggest linking the class, rarity and type in infoboxes, as you've already done for card set. -- Taohinton (talk) 23:18, 28 March 2014 (UTC)

No, the issues have no relation that I can see. The missing gold versions is something I will have to pass up as the import neither uploaded a gold version or indicated there was one. The category issue just seems to be caching trouble. I'll see if I can get a bot run over those pages to force everything to update. And I have updated the infobox. OOeyes (talk) 07:31, 17 April 2014 (UTC)

Infobox player[]

Is there a way to stop the {{Infobox player}} template from stretching out images to 220px width if it exceeds their basic size? In many cases the images are smaller than this, with the result of making them stretched and grainy. I know that |thumb prevents images from being oversized in this way. -- Taohinton (talk) 21:41, 28 June 2014 (UTC)

I've added |frameless to the image code. IIRC, that prevents any image from being enlarged to fit while still shrinking if necessary. — oOeyes

11:22, 29 June 2014 (UTC)

Great, much better. -- Taohinton (talk) 20:21, 1 July 2014 (UTC)

Miscellaneous issues[]

Since the new skin I've been noticing a lot of links are red even when the linked page exists. This may be solely with redirects; many false redlinks are to redirects, but I can't be sure others I've witnessed haven't been. Doesn't seem like a real problem, but thought I'd mention it anyway. -- Taohinton (talk) 01:16, 10 July 2014 (UTC)
Do you have an example we can investigate? I'm not sure how the new skin would have affected that... — oOeyes 14:46, 10 July 2014 (UTC)
Alas, I was very unwell at the time, and I think it must have been my brain confusing colours in a really crazy way ;) It's a wonder I was able to contribute as much to the wiki as I did! -- Taohinton (talk) 17:58, 22 July 2014 (UTC)

Does Hearthstone Wiki:Users have some purpose, or reason for existence? If you don't know of one, it seems it should probably just be deleted; it was created by an IP address with no other edits, and has no use that I can see. -- Taohinton (talk) 01:38, 10 July 2014 (UTC)
None that I'm aware of. My initial thought was that there must have been some red link to it somewhere, but What Links Here suggests the only link is from this page, so I have no idea what the thought process was behind creating it. — oOeyes 14:46, 10 July 2014 (UTC)
Thanks. I've deleted it for now. -- Taohinton (talk) 17:58, 22 July 2014 (UTC)

Boss pages like Patchwerk are showing "Cost: 0" in the infobox. Is it possible to have mana cost not display for heroes? I can't see any need for Set to be displayed there, either. -- Taohinton (talk) 02:22, 26 July 2014 (UTC)
Templates updated to not assign a 0 mana cost to heroes as long as no mana cost is supplied, and now for any card just in the Boss set, sets are hidden. May take a bit for everything to catch up. — oOeyes 22:17, 26 July 2014 (UTC)

The other way round, we need minions with 0 Attack to show 0 Attack in tables (eg Minion#Minion card list) rather than simply not displaying a value, which can be a bit ambiguous. -- Taohinton (talk) 02:22, 26 July 2014 (UTC)
And now templates are updated to add a 0 mana cost to minions if no value is provided. This may also need a bit to catch up. — oOeyes 22:17, 26 July 2014 (UTC)

I've been meaning to ask for some time whether there's a reason tables cap their width at about 60% of my screen size. It squishes up the tables and makes them longer than they need to be, due mostly to the description/flavor text, and leaves a large empty margin down the pages. If this is a bug you're not seeing, I can link a screenshot. -- Taohinton (talk) 16:52, 26 July 2014 (UTC)
Table sizing around floating elements is awkward in a variable-width layout, and early on, card pictures were floated to the right of the tables to add visual flavor. As I recall, the editors at the time just put a 800 pixel width on it and left it at that, figuring that would leave enough room on most displays. I've just done some quick and dirty fixes for narrower displays.

There are two ways we could change this. It would take only a moment to just extend all the tables to full width, but they'll overlap any of those floating images or other elements if they are still around. Another would be to wrap them in a div that's smarter about floating elements and make the tables 100% of that, but then any table with anything floating to sides of it won't be full width, and I'll need more time because all the table templates need to be edited. It's basically up to editor/reader preference here. — oOeyes 22:17, 26 July 2014 (UTC)
I spend… quite a large amount of time scrolling up and down tables these days, and I can't recall seeing any side-floating images of late. It's possible there are some, but I can't imagine they could be on more than a few pages. In my opinion, there's no real need to be able to put images there, and the sacrifice in making the table more squished and lengthy would probably not be worth it even if we wanted to. The quicker option therefore seems perfectly suitable to me. -- Taohinton (talk) 23:46, 26 July 2014 (UTC)
I've updated the CSS to take care of this. You may have to perform a full refresh to see the change. — oOeyes 02:38, 27 July 2014 (UTC)
Brilliant. That is much better, thanks. -- Taohinton (talk) 18:14, 27 July 2014 (UTC)

It would be great to have the races/subtypes in the infoboxes linked, e.g., Demon. -- Taohinton (talk) 19:10, 26 July 2014 (UTC)
Done. — oOeyes 22:17, 26 July 2014 (UTC)

The card list on General minion cards isn't working. I'm guessing this is because it's looking for 'General' when general minions simply have no subtype value. I'm not quite sure of the correct tech for this, so I thought I'd direct it your way. -- Taohinton (talk) 02:23, 11 August 2014 (UTC)
Yes, that's why it wasn't working. I probably inadvertently removed the default of "General" at some point. I've corrected the issue in {{Card infobox}}. It should resolve as the wiki catches up with the change. — oOeyes 03:01, 11 August 2014 (UTC)

After considering it for some time, I think I'd like to ask that cards from the basic set don't display their rarity in the infobox. The reason is two-fold: one, rarity for basic cards is completely meaningless, and potentially confusing; and two, due to the latter, people consistently edit the card data to mark common basics as free (or 'basic' rarity which isn't even a rarity), which while easily reverted is growing increasingly tiresome. Removing the display should make things clearer for everyone. -- Taohinton (talk) 11:23, 15 August 2014 (UTC)
This is doable. I'll take a look at this and other requests within the next few days, as it looks like I'm going to be pretty swamped this weekend. — oOeyes 20:47, 15 August 2014 (UTC)

Another minor problem: After having problems editing Rarity for over a week, I experimented on some sandbox pages, and discovered it was something about the use of {{Card by ability table}} which was causing the problems. However, it seems it's only when the template uses a specified concept that the problems occur, and worse with some than with others. The issue is that opening and previewing edits on the page when it includes several of the templates take a long time to load, while trying to save edits including the templates usually fail all together, even after repeated attempts; no problems when showing changes though. -- Taohinton (talk) 04:13, 20 August 2014 (UTC)
- Yeah, saving has additional processing overhead than just previewing, and the extra processing can add the extra time for it to hit the timeout. That's unfortunately just a indication of trying to do too much on one page. Sadly, collapsing the tables doesn't prevent them from loading or being processed; it just hides the content. There's no "load-as-you-need-it" happening, and the automation of the query templates adds overhead on its own. So, in short, I just don't think you're going to be able to have a table for each rarity on a single page. And each individual table can only show 500 anyway, so as the game grows, showing all cards of the lower rarities will probably become an issue anyway. It may be best to limit this to the rarer cards. — oOeyes 06:56, 20 August 2014 (UTC)

I've moved the tables to separate card list pages like Free card list. However, this is a clunky solution, splits info and wastes time. It's definitely preferable to not having tables though.

Having done this, I realised that a far preferable solution would be to have tables that load data only when you open them. Wowpedia uses such features to allow for multiple long lists on the one page. It's not a priority, but something like this would be a better solution; waiting a few seconds to load a table is much better than causing these kinds of page problems, and a lot more convenient than having separate pages.

Regarding card number limits, we're currently at about 230 for the commons, with only 100 new cards in total planned for the coming expansion, so hopefully this won't become an issue too soon. -- Taohinton (talk) 19:51, 24 August 2014 (UTC)

Card watermarks[]

It would be great to have the watermarks on cards such as the Naxx cards shown in the Hearthpwn images (they're currently missing, making them not match the cards' actual appearance in-game). Example. We already have the swirls for expert cards present in those card images, and from the looks of it each adventure/expansion will feature a unique watermark on its cards, so it would be worth adding them for each. -- Taohinton (talk) 17:28, 5 August 2014 (UTC)

I've brought it up with the Hearthpwn team. This is something they can do, but unfortunately, they can't put any kind of priority on it. They will try to fit it in if they can find time for it, though. — oOeyes

18:25, 5 August 2014 (UTC)