Terraria Wiki:Community noticeboard

Simplified Chinese
I've requested that the Simplified Chinese translation project become a separate language wiki, and I've been told the separate wiki will probably be created sometime this week. That project seems to have a lot of interest, and I think this will be better to enact now, rather than wait until the move would become more complicated.

When the wiki is created (there will be an announcement along with links), wiki editors will largely be responsible for performing the move: Equazcion ( talk ) 17:11, 27 Jul 2015 (UTC)
 * Pages can be created at their English titles at the foreign wiki, by any English-speaking editors who decide to help with the move. They can then be moved to their Chinese titles by the Chinese-speaking editors. Those editors who understand what the Chinese titles ought to be can of course create pages directly at their Chinese names.
 * We'll need to alter links and template code to convert from the /chs subpage scheme.
 * I've recommended User:Noyastary as their first site admin.

Weapon reorganization
Just throwing this out here. I partly made this as table practice, but I feel that having so many weapon types all bunched together on Guns is not only confusing, but somewhat indicative of the overall poor categorization of weapons, tools, items, enemies and phenomena across the wiki. I'm putting this forward as part of a proposal to reorganize stuff into categories that make sense while still adhering with hard limits set by the game itself, particularly the Master Templates. Anyone have any thoughts, ideas or objections? Is this page even substantial enough to stand on its own? Gearzein (talk) 21:11, 29 July 2015 (UTC)


 * We probably need this. Technically "Gun" isn't a weapon class, and Rocket Launchers are. "Guns" should probably be used to list only bullet-firing weapons, since that's a clear game distinction.


 * I would indeed adhere to the classes the game appears to recognize, so that we'll have true sources for which items belong where, with less to argue over later. I say this because when you say that things are currently poorly categorized, it makes me think you intend to create new sub-categories. While this is simple enough in most publications, on a site that anyone can edit, it can get messy. The Guns page itself is a good example -- it was probably intended originally to be a tight little subcategory of ranged weapons, but everyone kept adding things that appeared to be guns, no matter whether they fit the original intent of the page. This is inevitable, and the choices are then either perpetually policing and reverting, or creating an "Other" section as was done there.


 * Applying this to your sandbox article -- I would call this page "Launchers", to have more of a distinction from Rocket Launcher -- or maybe "Explosive launchers", to avoid having things like Stake Launcher and Snowball Launcher added later. I'd also avoid inventing terms like "conventional", "technical", "as-intended", and rather be more literal/intuitive. I'm not sure what "as intended" actually means in this context, and "conventional" and "technical" are similarly unclear until reading further how you've chosen to define those. People often read no further than big bold names when editing (ie. page and section titles). Equazcion  ( talk ) 22:07, 29 Jul 2015 (UTC)


 * I don't have any intent of creating new subcategories within existing groups- Guns stops at Guns, not Automatic Weapons or what have you. What I had in mind specifically when I made that comment was the weapon master template, for which "melee weapons" and "other melee weapons" are more realistically split between "swords" and "everything else" (though admittedly, there are a lot of swords), and the incongruity among means of classification between the proper wiki Categories, article text and infoboxes, templates and the "big list" pages. I don't have a whole ton of great solutions for fixing this and similar problems, so I'm throwing together prototypes and looking for feedback on them.
 * All the text is placeholders. When I put down "conventional" I laughed because I absolutely knew it would have to be rewritten, but I was in a hurry, and it was more important to convey the idea behind it rather than the "finished" product, which will necessarily be different just because of the nature of a wiki and the possibility of future changes. As for the title, I was stuck between Launchers and the less good sounding Rocket Weapons, leaning strongly towards the former, so it'll likely end up there.
 * The extra items on Guns will be removed eventually, with the key problem being where they'll go in the end. That's the problem with many of these changes- I can't see a Flamethrowers page surviving very long, but if they aren't guns, where else do you put them? Gearzein (talk) 23:06, 29 July 2015 (UTC)
 * Flamethrower-like weapons (I think there are 2?) don't really need to go anywhere. There happen to be several launchers and bullet-firing guns, which the game treats as united classes in certain situations, so it makes sense to have sub-listings for them, but not everything needs to go in such a sub-listing. We have the ranged, melee, magic, and summon listings, and that's where the categorization would probably end for most weapons -- unless we got creative in inventing new terms, which I'd again foresee not being a very good idea in the end. In the nav templates we could be a little more categorical(?) as in maybe having a sub-grouping for the two "flamethrowers", just to avoid a very long list of the "other" ranged weapons, but creating an individual article to maintain for a list of those two items is probably not necessary. Equazcion  ( talk ) 23:22, 29 Jul 2015 (UTC)
 * It actually didn't occur to me that they could just not be categorized, and that there doesn't necessarily have to be a sub-list for every weapon to fit into. Weapons like the Paintball Gun still have a place on Ranged weapons, but Other ranged weapons seems like a silly page to think about. That makes this much easier.
 * While I'm here I'll go ahead and ask if there are any thoughts on Repeaters relative to Bows, since the existence of auto-firing bows makes them now technically indistinguishable. Other than that I'll wait for a bit more feedback, and as long as there or no objections (or if no one else says anything) I'll go ahead and push Launchers forward later tonight. Gearzein (talk) 23:43, 29 July 2015 (UTC)

Language projects
Look at this page. I think its very useful for community. If you want you can edit it or etc. ← Alex Great talk 12:52, 1 August 2015 (UTC)

ko interwiki
Portugease and Chinese (zhtw) wikis unsupport Korean interwiki in sidebar. Game widow I think you can fix it. ← Alex Great talk 09:51, 2 August 2015 (UTC)

Dyes
Since Dyes are still kind of disorganized, I've thrown together an incredibly rough prototype table. While Compound Dye and Bright Dye seem to have gone over well enough, a crafting table doesn't feel like the best long-term solution for organizing the convoluted network of recipes that dyes entail. The main focus of this table is seeing the dyes in action. Feedback on the table layout is recommended, but personally I'm more concerned with reactions to the images, particularly the standard dyed item being showcased. I used Silver Armor because of a recommendation on the Terraria subreddit that I kind of agreed with- it's the closest to white I could think of while not being particularly flashy or seeming silly or out of place. I personally use the Unicorn mount for testing dye effects, because of how large and white it is, but I wasn't sure if it would be basic enough for general use. Alternatives I've considered are the Pharaoh set, Wedding set and Ghost set. If there are any other suggestions, that's what I'm looking for, though the table as a whole could probably stand to be laid out better, so give me whatever you've got.

And yes, I'm aware the images need to be cropped better. I used Camera mode's snapshot frame to capture them, but apparently the bottom pixel row of a character sprite bleeds into the next block. Gearzein (talk) 06:05, 3 August 2015 (UTC)
 * Looks good, but it might only work if we keep all the individual dye pages around. For a while now, there has been talk of merging dyes into one or a few larger articles. If we're dreaming up new layouts we might want to finally implement one that will allow us to eliminate most of the individual dye pages. Is this meant to do that? If so, we should additionally sandbox test using some of the more complex dyes-crafted-from-dyes so we can see how well this might work out to replace a mass of standalone pages. See Talk:Dye for the various concerns. (pinging User:Gamablaze, User:KM100, User:Setheral). Equazcion  ( talk ) 09:29, 3 Aug 2015 (UTC)
 * That was the hope, at least. There's no context on the test page, so I don't know how clear it is, but this would replace the existing tables on a page like Basic Dyes. It's not optimal, since you can't exactly link to individual table entries like you can page sections, but ideally the individual links in "crafted into" would connect the subpages- clicking the red and black dye icon would redirect to to Compound Dye, from which the player could find the entry on an identically laid-out chart that would explain in the same fashion both what was needed to create the item and what it could be made into. This would also cause a search for "red and black dye" to bring a reader to the Compound Dye page. It may not be perfect, but it's not much difference from how furniture works currently.
 * The only information on most of the individual pages is the crafting recipes and an image or two; hopefully I've compressed that into a single row on a chart. I'll go ahead and add some more rows for the sake of clarity in the meanwhile- for some reason, it didn't occur to me at the time that the most basic dyes weren't the most diverse sampling of use cases. Gearzein (talk) 09:51, 3 August 2015 (UTC)
 * We can add anchors for each dye so they can be linked like sections can. Any HTML element with an ID will do that. On a wiki we'd generally use  (no spaces allowed in the ID; link would be #Red_Dye). This would probably be best done automatically via a new template or a new option in a current template.  Equazcion  ( talk ) 10:57, 3 Aug 2015 (UTC)
 * I created dye to list dyes while automatically creating an anchor for each one. When we convert each individual dye page into a redirect, we can include an anchor in the redirect (#dyename) to scroll the page automatically to the particular dye. Also note the template ing for generally listing crafting ingredients in a table. Equazcion  ( talk ) 16:40, 3 Aug 2015 (UTC)

Base Tips
I would like more defense tips for bases of all types. Right now there is only or mainly tips for bases above ground but I'm sure some people would still like to have bases underground.

Tips for defending Npc's that are underground against wraiths and reapers is something i think would be very helpful.
 * Unfortunately, there are no tips in the base guide for your specific concern because these threats are part of why underground bases are so unpopular. Guides are written by the community through research and testing, though, so if you devise any solutions and would like to add your own recommendations, feel free to edit the guide. Gearzein (talk) 03:50, 7 August 2015 (UTC)

Use of version icons in text
Is there a standard for use of version icons, particularly as seen in templates such as mobile version and the like, in paragraphs? While they're useful in tables, it looks and feels amateurish to have icons in the middle of the page text. I've been omitting them, but I wonder every time if it's against policy to do so. It may be worth reconsidering the policy if it is.

Also, not that I think it will change much, but the Style Guide should be amended to explicitly forbid some weird stuff that's been popping up lately, like the repeated use of version numbers in page text and parentheticals such as (needs testing). We really shouldn't have to say things like "using strikethrough on the previous sentence is a bad idea" but it might bear repeating, assuming someone actually bothers to read the style guide. Gearzein (talk) 03:42, 8 August 2015 (UTC)
 * There's no explicit policy on platform icons. It's a matter of style, though still unstated. I think we generally include them when we're listing differences between platform content/behavior. It helps (I think) to make those differences easy to spot. Stuff that needs verifying should probably be tagged with verify. The types of rules you're suggesting aren't the kinds that would practically address these issues, I think -- the people who put version numbers and those types of parentheticals into article text are not the same people who are putting in the time to read the rules.


 * Part of the way a wiki works is always going to be drive-by editors making corrections in non-ideal ways and more experienced editors integrating those into the article later on. The Moon Lord page is a good example: Much of the Notes and Tips sections are made up of drive-by corrections, as newbies find it less intimidating to add little bullet points rather than edit article paragraphs. Much of it should now be written out into an Attacks or Behavior section. There's no way to actually avoid this happening in the future. IT's just the nature of the beast. Equazcion  ( talk ) 06:00, 8 Aug 2015 (UTC)

Armor naming conventions
As I was putting together the table for ranged weapon armor sets, I noticed that the way armor images are handled is inconsistent. Some armor pages have multiple images covering each variant in one infobox, while others use a single image or pair of images with all three head types together. Individual head variant sprites are mostly on the wiki already, though only the male variants exist, and they're only used on Defense. Access to these head variants as separate images would help table construction greatly, especially considering that individual weapon types now list armor and accessories that benefit them as well and need to be able to present the image appropriate to the table entry. I'm proposing that pages for sets of armor be switched over to the six-image style (for the most part seen on Hallowed armor), and the larger three-head compilation images be removed- since infoboxes now support images separate from the page title, they're no longer a necessary workaround to have all variants displayed in a single infobox.

Also, this is only a small sub-issue, but the character gender variants are also off- male variants are the standard name_armor, while female variants are spread out between several naming conventions- name_armor_Female, female_name_armor, female_name_headtype, or name_armor2 are the ones I've seen so far, in the cases where these images exist at all. I feel _armor_male and _armor_female would be both more appropriate and more consistent.

I realize I'm stacking projects on top of projects, but aside from getting the missing images, this seems like a task that could be largely handled by bot. Gearzein (talk) 03:35, 10 August 2015 (UTC)
 * My variant is:

I also think that we need some convention about wearer. For example Wearer (player) must have only one color of eyes, skin, hair and etc. if it used for Armor articles. Or maybe best variant is using a Manequin for all armor and Vanities. ← Alex Great talk 05:38, 10 August 2015 (UTC)
 * For male: File:Copper armor.png
 * For female: File:Copper armor (F).png
 * I have good idea. Do you see some articles about Football Commands at Wikipedia? In infobox used kits. This kits used a template images for all-World footbal kits. For example see infobox at Manchester United. Do you see red kit (home colours)? This kit is not only one image. This image is a part of pisces of this kit (T-shirt, lines, socks, trousers). This is a generated kit that used in all Footbal infoboxes at Wikipedia. It is realy simple than upload many million of images. I want to add same template form to infobox. We need only one player character (or manequin) and uploading all tile parts of armor and clothes. So... for one full image we need only: player, helmet, breastplate and boots (4 images for one armor kit). We maybe need to upload many tileparts of clothes. But this is fully conventional variant, I think. For example for Adamantite armor set we need: all 3 types of helmets, breastplate, boots and player (player is unifiyed image) - it means 6 images instead 3 full set images. Yes, yes. At result we need more and more variants if images, but I think it is good Idea. And we also can add .js-script that can switch images from male to female (I have one of this). So... If you like this idea, I can test it in my sandbox. Maybe this Idea will be fail. I don't know. No, no.. This is bad idea. ← Alex Great talk 05:53, 10 August 2015 (UTC)
 * I actually don't think that's a terrible idea, just not for this purpose. People have previously expressed interest in a "dye simulator" of sorts, but it would actually be much more expensive in terms of file space to have individual armor pieces. It would also be a ton of work.
 * As for a standard armor model, I think the default generated character (as seen in the Accessory images) should do fine. I guess we could change some details if people wanted to, but most helmets will cover enough of a player that the model doesn't really matter past a certain point. Gearzein (talk) 08:28, 11 August 2015 (UTC)

Dynamic Page List & other new extensions
A MediaWiki extension called Dynamic Page List (DPL) was recently enabled at English Terraria Wiki. It allows us to create list pages dynamically, instead of having to create them manually. For ease-of-use I created the dpl template.

DPL not only allows us to list pages, but also include stats from article infoboxes. See Swords for my first test of this functionality.

I believe this method of creating item/entity lists will be superior to our current method. When stats need to be changed or corrected, their article infoboxes will be the only place where changes will need to be made. We'll no longer need to manually match up values across several pages. Hopefully our various list articles will be converted into DPL lists gradually, as various details or issues are ironed out.

DPL can also be used more simply to display a single infobox value from an article. I created dpl2 for this. For example,   will output the damage value for the Copper Broadsword: .

The following additional MediaWiki extensions have now also been enabled at English Terraria Wiki (see the links for documentation):
 * Gadgets - Allows administrators to add custom wiki features that users can enable via Preferences.
 * ImageMap - Lets us make specific areas of an image into clickable links.
 * JavascriptSlideshow - Alternate method of creating animations, instead of having to upload animated GIFs. Static wiki images can be specified as animation frames.
 * Labeled Section Transclusion - Allows us to transclude page sections individually, instead of having to transclude an entire page and use "noinclude" to exclude portions.
 * CharInsert - Allows admins to provide clickable interface links that let users insert various coding into an article's edit box more easily.
 * Editcount - Lets us show a user's edit count.
 * MyVariables - Enables some additional magic words for use in wiki documentation.

Feel free to experiment with these, but of course be careful to preview and test first if implementing them in live mainspace articles. If you have any questions let me know. Equazcion ( talk ) 21:26, 10 Aug 2015 (UTC)

Health bar and hearts
Hi, I created a series of templates (taken from Minecraft Wiki). These templates generate a bar similar to that used on Minecraft Wiki. Templates is not completed yet. Look sandbox at Russian section. And you will understand everything. ← Alex Great talk 06:31, 11 August 2015 (UTC)
 * Trying to render enemy health using the ingame health bar is a stylistic choice I've never agreed with the Minecraft Wiki on. They still have to clarify the amount of health or damage that the heart display is meant to represent in every instance it's used, and when dealing with enemies that have health exceeding the player's natural cap, the graphical representation breaks down into just another number next to an already stated quantity.
 * The reason why it's not workable for our wiki should be obvious in its test implementation- Terraria deals with much higher numbers than Minecraft, and they're much less uniform, very often lower than or not divisible by 20. Many cases where this is used would just result in another number in the infobox, adding more data without contributing any new information. Gearzein (talk) 08:06, 11 August 2015 (UTC)
 * I might see the appeal for damage values, to have a graphical representation of how much health a player can expect to lose when hit, but players' widely varying defense stats would make that similarly less than helpful. It was a good idea, though I think not practically useful here. Equazcion  ( talk ) 08:16, 11 Aug 2015 (UTC)
 * Thank you for your feedback. ← Alex Great talk 11:45, 11 August 2015 (UTC)