Terraria Wiki:Community noticeboard

Community Noticeboard

Do not post game suggestions, game bugs, or game technical support requests on this page. Use Terraria's official forums instead.

This page is for general discussion about the Terraria Wiki. To start a discussion, click here (+).

• Have no idea what to do? Check out the things to discuss and the things to do!
• For administrative issues, see the admin noticeboard.
• In case you need some help with editing pages, Wikipedia's "How to edit a page" article is a great source of information.
• To practice editing, use the Terraria Wiki Sandbox.

Below is a list of trusted editors who have knowledge of Terraria on particular platforms and in particular areas. This resource is meant to offer a means of verifying and adding wiki information. Please do not contact the users listed for gameplay help – instead use the forums.

User Desktop Console Old-gen Console Mobile 3DS Other/Notes Ferretwings Wiki code, tables, advanced templates ReedemtheD3ad ✔️ ✔️ ✔️ Breathlessblizzard ✔️ Source code, wiki code Awesome diamonds ✔️ ✔️ Trialsphere ✔️ Switch

If you need to adjust your entry on the list, feel free to edit the table. If you wish to remove yourself from the list, you may do so as well.

If you would like to be added to the list, please click here and include your username at the bottom (only those with user accounts will be considered), and your area of expertise.

​Stubs ​Info Requests ​Rewrite Requests

Article Stubs (11) Template:Critter info Food and drink potions Grasses Loadouts New Chinese version history Paintings Phorum Shortsword Plants/tr Terraria Wiki:Projects/DPS/Weapon DPS chart Pululu Frisbee Solutions Rewrite Requests (5) Guide:Defending against invasion events User:Funmikey07/Version Differences Game controls Hornet/it Tutorial Information Requests (4) Article Requests Cages Missing placed animations and sizes for the 1.4 cages. Light sources Brightness percentage is a bit vague, so this either needs to be clarified or replaced with tile distance. There are also multiple unknown brightness levels. TModLoader * Information as to how you obtain the April Fools Joke. * Differences between the desktop version and the tModLoader version, including the lack of Shimmer and a reduced max stack. Tile IDs Part8 Missing sprites of cages.

Archives
2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023

Requests to be added to the contributor list at the top of the Community noticeboard page

If you'd like to be added to the above resource list of editors, please include your username below (only those with user accounts will be considered), and your area of expertise. – Ferretwings ^(talk) 01:16, 18 May 2017 (UTC)

Request to be added

Hello. I am a long time player of Terraria Desktop, and I have much experience with it. I would love to be added as an editor so I can help update the wiki with new and changed items and features from the 1.4 update. I have already been working on updating the upcoming features with new information, and I would be glad to continue to quickly bring out accurate update information. Fireboltthecoolcat (talk) 23:14, 15 May 2020 (UTC)

Added. --Rye Greenwood (talk) 18:16, 22 May 2020 (UTC)

Request to be added

Hi, I'd like to be added to the editors list. I've been helping around the wiki recently creating item pages, copyediting, and reporting vandalism. I play Desktop and have basic familiarity with the source code, so I can pull up information about item functionality, vendor sales, etc without too much trouble. On the wikicode side, I've learned how to use a good number of the standard templates+infoboxes and I'm hoping to pick up more through practice. You can check my contributions page to see where I've helped out, or contact me in the Discord under the same username. Cheers! Breathlessblizzard (talk) 22:38, 19 May 2020 (UTC)

I've added you. Thank you so much for your help :) – Ferretwings ^(talk) 23:06, 19 May 2020 (UTC)

Request to be added

Hello! I'd like to be added to the editors list. I mostly play mobile, but can readily test pretty much anything on the Console version (latest version, Xbox One), and will sometimes be able to test some Desktop things. I'll hopefully be able to be editing a lot more actively, and am currently working to achieve consistency, especially with the flood of 1.4 articles. Thanks for your consideration! —ϟAwesome_Diamondsϟ^「talk」 17:57, 21 May 2020 (UTC)

Added. --Rye Greenwood (talk) 18:16, 22 May 2020 (UTC)

Request to be added

Hi! I'd like to be added to the editor's list. I have (what I'd like to think) an extensive knowledge of most Terraria Desktop version mechanics, as well as features and content. I've joined pretty recently in order to help with 1.4 content additions, and I helped to start adding happiness quotes for the happiness quotes project to most NPCs, as well as preparing to start the DPS project (to find the average DPS of weapons). Thank you for reading, no hard feelings if I don't make it. DanZeMan (talk) 12:49, 3 June 2020 (UTC)

Request to be added

Hello, my name is Trialsphere, I am constant player of the game and have over 340 hours on Nintendo Switch. I know the game mechanics well, tend to recognize glitches fairly quickly when they pop up, and know most of the tips or tricks a player might need. I would love to be added as an editor so I can help add information that might have been missed on pages and help the terraria community as much as I can. I thank you for your time and consideration. Trialsphere (talk) 17:41, 12 June 2021 (UTC)

Added you to the list. --Eraloiz (talk) 09:49, 17 June 2021 (UTC)

Music Box (PS4 version)

Music Box

On the console version, the (Snow) and (Ice) Music Boxes are opposite what is captured on the wiki page. Same with Music Box (Boss 4) and Music Box (Boss 5).

I took screenshots of each, as seen below. KM100 suggested "it would probably be better to have the name switched instead of the info (such as Snow (Pc only.png), Ice (Console only.png)), or a simple note describing how they're switched. Having all the info and links listed twice with a ton of icons becomes quite confusing." I posted the proposed results on the Terraria Wiki:Sandbox page, but I'm not sure if that looks acceptable. I'd appreciate any feedback on this, so the proper changes can be made to the page.

• 

  Music_Box_(Ice)_PS4

• 

  Music_Box_(Ice)_PS4_Location

• 

  Music_Box_(Snow)_PS4

• 

  Music_Box_(Snow)_PS4_Location

• 

  Music_Box_(Boss 4)_PS4_Queen_Bee

• 

  Music_Box_(Boss 4)_PS4_Ocram

• 

  Music_Box_(Boss 4)_PS4_Eye_of_Cthulu

• 

  Music_Box_(Boss 5)_PS4_Golem

• 

  Music_Box_(Boss 5)_PS4_Pirate_Invasion

• 

  Music_Boxes_PS4

Thanks in advance. --NibKing (talk) 19:19, 19 June 2015 (UTC)

It looks good to me. Although it extends the list, I think it's much clearer to list the versions separately like this. I added a footnote to your sandbox version to tie the info together and explain the existence of duplicates. Equazcion ^(talk) 19:44, 19 Jun 2015 (UTC)

I'm just gonna copy/paste what's in the Sandbox then. Glad you added the notes, because I wasn't sure how. --NibKing (talk) 20:07, 19 June 2015 (UTC)

Version categories

This was sparked by an old argument begun originally by User:Dxos3, which he recently brought up again at my talk page.

The issue is that a console player, for example, has no place to turn in order to see a straight listing of content available on their platform alone. We have Category:Console content, but this is populated only by {{console only}}, {{pc/console only}}, and {{console/mobile only}}. The Console content listing is therefore missing most of the content available in the console edition, ie. the content that all versions contain. One could argue that a console player can easily determine which items they will and won't have access to, but some players may wish to see a browsable list of everything available on their platform alone, without having to click other things and be disappointed by a "pc-only" message.

User:Dxos3 originally wanted an organized page with sections and graphics, but this proved to be somewhat unfeasible -- it would need to be created manually (it was started at one point but languished and was eventually deleted), and even if done initially would likely (I think) end up deteriorating.

Since we already maintain those "____ only content" banners pretty diligently, filling out these categories with their missing content seems like a good compromise. I've added an "allversions=yes" parameter to our infoboxes, which would add all-version content to all the content categories (eg. Category:Console content would then list all content available in the console edition). I also created {{all versions}} for use on pages with no infoboxes, which does the same thing.

I may be able to mass-add these parameters/templates to the necessary pages via bot. I wanted to present this here first for comment. If you have thoughts on whether or not this should be done feel free to say something. Equazcion ^(talk) 13:51, 20 Jun 2015 (UTC)

My only question is how mechanics and other pages will be handled. Pages like Fishing will be listed in the PC Version category because of their "____ only content" banners, but will core mechanics like Defense end up on the page, or is their inclusion (or lack thereof) even something to be concerned about? Regardless, it seems like a good idea, and would definitely help some users who want an absolute list. --KM100 ^(talk) 04:48, 23 June 2015 (UTC)

I think an initiative like this should be limited to ID-tagged entities like items and NPCs; I feel it goes without clarification that most mechanics are in all versions of the game unless specified, and those that are would hopefully remain pretty limited (I can't think of any other than fishing itself). That said, I think it's a much more solid idea than the original proposed page of links, and generally endorse both better use of categories and fewer dedicated list pages across the wiki. Gearzein (talk) 09:24, 23 June 2015 (UTC)

Now THIS, THIS is a compromise! Thank you so much for listening, I appreciate it. I think this method would be very beneficial to everyone especially with the advent of 1.3 messing everything up. I think console players would love a category page like this and the associated parameters that go on there wiki pages. However, I do think that the category should be very accessible from listing it in a place where players can just click a link and it will take them to the category page. And graphics should be added on the category list IN MY OPINION... I do warn though that it will take some time to fill in the rest of the pages as currently there is only 134 pages listed on there...User: Dxos3

Console/mobile history

Adding to this and maybe a really good idea here but in all the items (yes I know it would be an insane amount of work at this point) if we can start adding to the version history the version of which it was introduced to console and mobile as well? Below is just a quickie example. Console/mobile version pages can also be created just like the pc versions to make it to where players can still reference to them directly by page or when chatting in talks about when items came in or such by adding the version tags to their posts.

slight note on below: I know my formatting is horrid but its early in the morning and cant really think of everything.

-- History --

• {Console_Version}
• 1.06: Introduced
• {Pc_Version}

• 1.2.4.1: Now sells animal skins.

• 1.2.4: Fixed issue where Scorpions worked with King Statue and Traveling Merchant did not.

• 1.2.3.1: The Traveling Merchant can no longer spawn in lava. Fixed bug where Queen/King Statues didn't teleport Stylist and travelling merchant respectively.

• 1.2.3: Introduced.

DragoHanter (talk) 16:28, 20 June 2015 (UTC)

That's an entirely unrelated suggestion, so I've moved it to its own section here -- but yeah the console/mobile histories could be better organized and perhaps separated. Equazcion ^(talk) 17:08, 20 Jun 2015 (UTC)

Bug Policy

I've been thinking about the "no bugs" policy on this wiki. I wasn't here before the policy, so I may not fully understand the reasons for its existence, but I think it's too strict. The PC version at least, currently has mercifully few serious bugs, but with with imminent release of a major new version, it's entirely possible there will be some new ones. In particular, I think there should be some allowance for documenting bugs which are both harmful (as opposed to exploitable or just funny) and reproducible. Like if (totally made up) using the new multi-chest quick sort near two piggy banks destroys the items that should be stacked there, I think it would be appropriate to warn people about that until it got fixed. Is this worth considering, or is it better to cross that bridge when we come to it?—BlueMana (talk) 04:49, 26 June 2015 (UTC)

I didn't voice my concerns here either, because by the time I knew of the policy it was already long-since enforced. But, I definitely agree that it's getting too strict. It's starting to become more of a pain to remove the bugs that everyone keeps listing (such as the temple door bomb glitch, or mismatched npc quote glitches) then it is to remove the bugs that are completely unsourced and probably made up. Obviously, some restrictions need to stay in place, so there aren't "Bug: starting up the game might delete all your items!" posts everywhere, but a "remove nearly everything that isn't 100% intended" policy is starting to get tiresome. --KM100 ^(talk) 05:07, 26 June 2015 (UTC)

(edit conflict) See here for the discussion that led to the rule. It explains the reasoning. In short, bugs are largely anecdotal -- ie. unverifiable, could be fabricated, and would always nevertheless remain in articles forever, since it also couldn't generally be verified whether or not they were fixed. Bug lists got very long and were mostly useless. That said, the most prominent bugs can be posted, ie. those the developers have openly discussed, or those that are detrimental, consistently reproducible for everyone, and warrant warning players against behaviors that would trigger them and resultingly damage their world or player files. As far as exploits go (the ones that haven't been discussed by the developers), they can be a slippery slope and lead to a decline in wiki articles to cheat forum status. It might be tough to craft rules regarding which of them can and can't be posted so as to avoid that eventuality. I'd be open to re-examining it though. Equazcion ^(talk) 05:13, 26 Jun 2015 (UTC)

The current bug policy does do a good job on preventing unverifiable bugs from being posted, the problem are those people who don't read the policy (or believe their bug is an exception to it) continue posting glitches. It gets pretty irksome when I have to constantly undo the same mobile version glitches that I can personally verify (and have videos documenting them). I do think that major exploits (e.g. duplication glitches) should stay off the wiki for the most part, but I feel as if easily-repeatable or verifiable dangerous glitches should still be allowed to stay.

I agree that it'd be hard to get a policy that specifies exactly what can and cannot be posted, though, and it'd be even harder to get everyone to follow it, so I'm fine with waiting until further word. --KM100 ^(talk) 05:29, 26 June 2015 (UTC)

One block to that may at one point have been that most of the bugs you're describing, ie. those that everyone experiences, were confined to mobile, and our consistent trusted editors were all PC players who couldn't verify them. If you wanted to personally be the gatekeeper for mobile bugs, we could start allowing those that everyone would undoubtedly notice and feel a need to post, based on your judgment. Bug reports still wouldn't serve much of a purpose here, but not having to perpetually revert them could be reason alone to allow the ones that keep getting reported and can be verified by someone trusted. I won't take it upon myself to say this should be done though, I'm just putting it out there as one possibility for discussion. Hopefully others will chime in on that or other possible solutions. Equazcion ^(talk) 05:40, 26 Jun 2015 (UTC)

I think we've come pretty far in six months, enough to have trusted regular editors who can confirm whether widely-reported bugs in certain versions are actually true. The policy is ignored enough as it is- with the upcoming increase in traffic, we'll have a lot more people coming through to report that certain things don't work as intended- but fortunately, with a large enough sample it should be a lot easier to weed out false positives and nonsense.

Additionally, I voiced my concerns at the time that the possibility of bugs becoming long-term functionality still existed, and unfortunately that seemed to come to pass, as many bugs remained in the mobile versions for a very long time, particularly the rarity of Vitamins and similar debuff-immunity items. The Ankh Charm and associated items are very common and high-profile accessories for players of all types, and unfortunately I'd have to admit that as a wiki, we failed in our primary responsibility of conveying accurate information to players for a distressingly long period of time. It's worth considering letting up on the policy a little bit. Bugs definitely need to be controlled and vetted in some way before they're placed in public view, but it's looking strongly like the effects they have on game functionality can't just be ignored or deferred elsewhere- especially if everyone's encountering them. Gearzein (talk) 06:04, 26 June 2015 (UTC)

These posting will be in public view immediately, as people post bugs to whichever article they feel they apply to. Preempting bug postings by directing people elsewhere via an interface message has not, as we've seen, been completely effective (although it has cut down on bug postings drastically, I think, if you compare to the volume we used to get). We could move posted bugs off to a temporary holding page for verification as they come, but that's not much better than reverting, as we would still need to perform the move each time, and people will still re-post the same bugs to the articles after they're removed, since they will not know this had already happened.

Once we accept that people will be posting bugs in public view immediately: Our choices are whether to revert them or let them be. It's a nice ideal to say we can simply allow bugs that most of us regulars think are accurate and widespread, whilst reverting others that we don't, but in practice that doesn't seem like it would be quite as simple as it sounds (in my mind). It would be difficult to revert some bug postings on the grounds that "I haven't seen this so widely reported yet and/or I think most of us wiki regulars haven't experienced this bug yet and/or I don't think this bug is as important as the others you can see we've allowed; so I'm removing it" (an exaggerated way of putting it, just to illustrate the potential difficulty and the way those reverts might be interpreted, rather accurately, despite any careful wording we would choose).

Whichever solution we put into practice should include some way to show consistency, for example via a policy, or an individual decision-maker to appoint per platform, or else hold a discussion for each new bug that appears, hope that several people participate each time, and then have that saved discussion to point to as rationale for reverting a particular bug in the future. Equazcion ^(talk) 06:45, 26 Jun 2015 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ That said, I made that rather long reply late at night and may have overcomplicated things. I agree a bug like Ankh Charm ingredients being rarer than intended (if that was the bug you refer to) is something that should be on the wiki if true. It's one of the rare examples, though, of a useful bug report as far as the wiki is concerned. I almost never see bugs like that posted, ie. important malfunctions that could cause wasted time and headaches if players aren't made aware. I actually don't remember seeing anyone post this particular bug. If it's accurate then it's good that we're discussing it now and can decide to allow it on the page. However, the current bug policy would actually already allow for this particular example. The remaining question is still whether not to revert the more minor glitches, misquotes, and exploits in the future, and if so how to decide practically which stay and which go. Equazcion ^(talk) 13:30, 26 Jun 2015 (UTC)

So it sounds like the standard I suggested (harmful and repeatable) is closer to current policy than I realized. Perhaps all that is needed then is better clarity about when it's allowable to post bugs. What if there was a rule that bug reports must include a link to a TCF thread where the bug in confirmed either by a staff member or a clear consensus of users?—BlueMana (talk) 14:42, 26 June 2015 (UTC)

I think that's actually a pretty good idea. Harmful, repeatable, and including a link to confirmation or consensus at the official forum; and in the policy I suppose I'd explicitly specify that "harmful" includes things that merit warning in order to help players avoid a severe annoyance, as in the Ankh Charm example. What do we all think of that? Equazcion ^(talk) 17:34, 26 Jun 2015 (UTC)

PS. We just got another one of these. As a separate issue, are we still addressing the possibility of allowing exploits or minor bugs that get posted perpetually? Equazcion ^(talk) 17:51, 26 Jun 2015 (UTC)

This sounds workable- it's largely the same policy we had previously but the meaning of "verifiable" is hopefully clear enough to act on. As for the door of the Jungle Temple, I was under the impression that was fixed, but even if it's still around, it could be considered to present somewhat of a risk to new players who may try to breach an otherwise indestructible structure before they're prepared. If phrased properly- as a warning similar to the one that Lihzahrds spawn prior to Hardmode rather than an exploit or sequence-break- it'd be worth considering. Gearzein (talk) 19:57, 26 June 2015 (UTC)

They announced it was fixed on Google Play and iOS. Amazon still doesn't have that update, so I suppose it could be Amazon users who are still reporting it; or else they thought they fixed it but they didn't. In any event, we still don't really know how to handle repeated minor bug reports in the future. KM100 did bring up the point that it gets tiresome reverting the same bug repeatedly that he can personally attest to. I suppose we'll have to continue doing that for now though, since no consistent alternative is apparent yet. Equazcion ^(talk) 20:52, 26 Jun 2015 (UTC)

Global file usage

Greetings from Russian wiki. I want to ask you about the service (absolutely all). When you delete files on your wiki (English section), please check the use of the file in the other language sections of Terraria Wiki. This is necessary to avoid the presence of red links. If you do not already know, our wiki uses a centralized storage system overall. This means that any file on the base (English) wiki can be used in all sections of the same wiki. For example, image of File:Blue Slime.png used in the Russian wiki thanks to this system, although Blue Slime was not uploaded on the Russian wiki because it is called a direct linkas if it were uploaded - ru:File:Blue Slime.png.

Since the global usage of the file is not displayed on the English wiki, then kindly requested to check each file before deleting when used in any section Terraria Wiki.

There is another option, dear members of the Curse, set on the wiki this extension: mw:Extension:GlobalUsage. This will allow all users to monitor file usage by other language sections.

Again, administrators and bureaucrats, if you delete a file in the English wiki, please before deleting move this file in all language sections where it is used, so that no unforeseen red links. Equazcion, please do this kind of mandatory rule for all administrators. If the extension is not set, then let everyone removers checks every file on each section. Section is not too much, it will not take much time.

Thanks, good luck in filling articles with the upcoming update. Alex Great ^talk 05:27, 28 June 2015 (UTC)

mw:Extension:GlobalUsage is probably ideal. For now I wrote a script that will let us check foreign uses of images. The new link, "List Foreign Uses", should show up for everyone at the top of image pages. If it's not there yet, do a hard refresh (ctrl-F5). Equazcion ^(talk) 12:04, 28 Jun 2015 (UTC)

Very useful. Thanks for support. Alex Great ^talk 12:51, 28 June 2015 (UTC)

For File:Wandering Eye (2nd form).gif doesn't work. Alex Great ^talk 12:56, 28 June 2015 (UTC)

No problem :) Should be fixed now. Ctrl-F5 to refresh javascript. Equazcion ^(talk) 13:07, 28 Jun 2015 (UTC)

Mirrored images

I created a new template: Template:Mirror. If the community will take it, for all the images, you can specify a single standard that all such pictures should look to the right by default. I.e. some NPC files should be reuploaded (to the right). If someone is not a mirror, then the idea is failure. Alex Great ^talk 13:41, 28 June 2015 (UTC)

Or maybe specify a single standard with looking to the left. I mean that all the images looked in one direction only. Alex Great ^talk 13:45, 28 June 2015 (UTC)

Pedguin stream

For whoever happens to be paying attention right now:

We don't normally do this here, but I felt I had to point out that Cenx and possibly Redigit are currently offering additional 1.3 info at Pedguin's 1.3 changelog analysis stream, going on right now: http://www.twitch.tv/pedguin. Equazcion ^(talk) 14:41, 28 Jun 2015 (UTC)

Achievement section in related pages

Hi. I'm wondering, is there a guideline to follow about listing related achievements in a page ? I mean ... For example :

• The Twins : by killing them, you'll earn "Ophthalmologist" (Xbox, PS3), or will contribute to "Buckets of Bolts" or "Mecha Mayhem" (PC 1.3).
• Blood Moon : if you survive the night, you'll earn "Red Moon Rises" (Xbox, PS3, iOS) or "Bloodbath" (PC 1.3).
• Angler (but also fishing) : linked to "Servant-in-Training", "Good Little Slave", "Trout Monkey", "Fast and Fishious", "Supreme Helper Minion!" (PC 1.3).
  

There is already a section about history of changes, but nothing about achievements. With the arrival of 1.3, it will be more important to list those ... --ChoirJ (talk) 21:56, 28 June 2015 (UTC)

There's no current guideline or consistent practice, as far as I'm aware. I can't see any reason not to include them on pages for items/characters that directly trigger them. Equazcion ^(talk) 22:16, 28 Jun 2015 (UTC)

If you were asking how they should be listed, I would just add an item to the Notes section of each page. Perhaps later we'll devise a template and/or separate section if people think that has become necessary. Equazcion ^(talk) 22:19, 28 Jun 2015 (UTC)

So what's the plan for the Wiki and 1.3?

1.3, being the final main update and a huge one at that is certain to cause some manner of chaos when released. So with two days ahead, there is a wonder if there is some manner of contingency plan in place to reduce the mass of crossfire edits and more. 76.125.252.80 02:40, 29 June 2015 (UTC)

There's no need for any such panic. I know I, at least, won't just be regulating these edits, I'll be making them. All of our sysops are regular users, and all of our users are players, and we're all here because we use this resource frequently and want to contribute to it. That's how a wiki's meant to work- high traffic can never really be a negative, because the majority of users are here either to read or fill in gaps with what they know, and the ratio won't meaningfully change just because the volume does. The plan is to continue as usual. Gearzein (talk) 03:35, 29 June 2015 (UTC)

Very well. I just wanted to pop in, shout 'Yellow Alert, Shields Up!', to make sure there was at least something in place. I actually meant nothing by my 'panic' note in the change summary. 76.125.252.80 08:11, 29 June 2015 (UTC)

1.3 pre-release streams

Due to the fact that information from the 1.3 pre-release video streams is not anything we can verify, I'll be continuing to revert and delete this info when no good references are included. However, I'm going to trust that our admins and a few select trusted wiki regulars (you probably know who you are) are posting accurate info. For those editors:

• Please only create pages or post information for content you saw with your own eyes, or that has already been referenced to a dev posting before.
• Keep information on new items general, as specifics may be less reliable from merely seeing a video. Remember that item and character stats you see may not represent base stats, as they may be altered my modifiers or other boosts that might not be apparent to the audience.
• Please also continue to confine 1.3 information to articles exclusively on 1.3 content, rather than updating articles on exiting content to show 1.3 changes.

The purpose of the points above is so that we don't have a bulk of questionable material to sift through later. Of course, once the release happens, everyone can post whatever they find in the game, since the rest of the hive can then verify it immediately (more or less).

None of this applies to the Upcoming features page. That page will be moot in the next 36 hours or so (as opposed to newly created pages for individual items, which will serve as their permanent wiki pages), so I think we can relax the standards at that particular page somewhat. Equazcion ^(talk) 10:38, 29 Jun 2015 (UTC)

"Future" Flag

It seems one of the biggest problems being faced right now is the persistence of people uploading future content on mainspace articles. Having future features on these articles is definitely a problem, but it seems sort of silly to revert all edits relating to them. So, I think this could handle that:

   <!--FUTURE (Upcoming mechanics) FUTURE-->

All upcoming features on main articles could be flagged with this, until the release of 1.3, when all instances of "<!--FUTURE" and "FUTURE-->" could be removed via bot. This would theoretically hide them until the release of 1.3, and then reveal them with minimum hassle. Now, I'm no bot expert, so I'm unsure if this would actually work or not. Any opinions? –KM100 ^(talk) 17:43, 29 June 2015 (UTC)

The problem with future changes on main articles at this point isn't just the fact that they don't apply yet, but the fact that we don't know if they're reliable. I've been letting everyone put up new pages for stuff they saw in pre-release streams, and have been tagging those with a template/category for later review. Content within other articles might be a little more tedious to sift through later and verify -- it wouldn't just be a matter of un-commenting it. My opinion is that this should wait til info can be checked right away. While these do comprise most of our reverts at the moment, there really aren't so many of them that it's a remotely serious problem. Equazcion ^(talk) 17:52, 29 Jun 2015 (UTC)

Alright. I guess flagging everything with these would probably be more work than just reverting them, anyway. –KM100 ^(talk) 18:10, 29 June 2015 (UTC)

Placed blocks images

Since there is a option to display placed walls, how about displaying solid blocks? I have seen it only here so don't really know if someone is working on it or not. Do you think it is a good idea to make such images, I'm personally interested in making it happen – File:Sturdy Fossil (placed).png (I hope this one has better quality than that Hay one). Kvikk (talk)

Image policy amendment for illustrative .gifs

This has been a concern of mine for quite some time, going back as early as the poor quality animation used for the beam sword's sword beam. Having several buffs, minions and pets flying around in a screen capture makes it difficult to determine what the image is trying to convey, and now that none of us are familiar with the items these images are trying to convey, I'm starting to notice how real a concern this was- for example, I don't know if this big goofy floating orange thing in front of the player is part of the Daybreak's attack animation or some other effect.

A good general rule for maximum visibility in animated images is to deactivate familiars and buffs, take off obtrusive armor and animated dyes, and check the lighting and weather before capturing footage to make into a .gif image for use on the wiki. One should also be sure to crop images appropriately to demonstrate the weapon, item or other phenomenon most effectively- the Daybreak example above conveys nearly no useful information to justify its continued use on the page, as it displays only the stock throwing animation and the weapon's normal sprite, not its effective range or a usable rubric of its velocity. Please also ensure that the background is not too busy or flashy. I can't ask everyone to have a distance-marked shooting range in their basement, but please be sure that you're at least filming over a solid color.

Note that this is not an open call to add more .gifs to the wiki- generally, animated images should be used sparingly, for both bandwidth and aesthetic reasons. However, in the event that a concept cannot be conveyed through text, these guidelines can help prevent your images from being tagged for deletion. Gearzein (talk) 13:37, 2 July 2015 (UTC)

Yes, these are good pointers all around. Equazcion ^(talk) 04:21, 5 Jul 2015 (UTC)

Frequent banner drops

Okay, so I've noticed that banners are dropping differently for the new update. It seems that they drop every 50th enemy kill, rather than the 0.4% chance or whatever it was for each enemy. Is this true? Or is it a convenience? If this is true, we should probably start updating the pages. — Preceding unsigned comment added by 216.21.189.102 at 17:21, 4 July 2015‎

This is true and I believe we have been doing that. Equazcion ^(talk) 04:21, 5 Jul 2015 (UTC)

Should the Hoik have its own article?

What do you guys think? Template:Unsigned2

Being that it's a bug exploit, the general rule is that it wouldn't get its own mainspace article. It's mentioned currently at Guide:Travel. It could conceivably have its own guide page, if there is enough to say about it that warrants a separate page. Equazcion ^(talk) 04:18, 5 Jul 2015 (UTC)

Fix Tax Collector's place

the Tax Collector is a hardmode NPC, not a pre-hardmode one, since you have to purify Tortured Souls (which only spawn in hardmode) to get him as a NPC. Fix this on the main page MamiZa (talk) 00:48, 5 July 2015 (UTC)

Done. Equazcion ^(talk) 04:16, 5 Jul 2015 (UTC)

Events on main page

Currently, the Slime Rain and Martian Madness events on the Main Page of the Wiki are not classified to a platform in particular, even though they are limited to 1.3, which, in turn, is limited to the PC edition of Terraria. What I ask is that someone with the ability to edit the front page will add the indicator that those events are limited to the PC, so as to prevent the transmission of misinformation. If any information here is incorrect, creating a scenario where this change would be a poor decision, and would cause more trouble than leaving it be, please tell me, and I will edit this request or remove it all together. Thanks for reading and considering this request.Template:Unsigned2

Done. Equazcion ^(talk) 04:16, 5 Jul 2015 (UTC)

add the tax collector skeleton merchant pleaseTemplate:Unsigned2

Add them to what? There are already articles for them (Tax Collector, Skeleton Merchant), and those are linked on the Main Page. Equazcion ^(talk) 04:51, 5 Jul 2015 (UTC)

Add Expert Mode link to Front Page

I've noticed there's not yet a link to Expert Mode on the front page. If someone with the ability could put that in it would be very useful. I think just under the hardmode link would be a good place as it would balance out that table aswell. Thanks in advance.Template:Unsigned2

Thanks, done now. Equazcion ^(talk) 08:11, 6 Jul 2015 (UTC)

Upcoming features

I think something should be done with "Upcoming features", it could be misleading for some people cause 1.3 is out now. Not sure what was usually done in such case. And Lunatic Cultist should be added to "Hardmode bosses" section on Main Page.Template:Unsigned2

I agree we need to do something with upcoming features. Probably archive it. For now I've added Lunatic Cultist to the main page, thanks for pointing that out. Equazcion ^(talk) 09:08, 6 Jul 2015 (UTC)

(edit conflict) This has been kind of low priority given the volume of new content in 1.3 requiring a lot of focus elsewhere, but I agree. I'm gonna go ahead and suggest that the page be cleared for the time being, just to avoid confusion. Once our situation stabilizes we can start compiling developer comments on future updates, particularly Yoraiz0r and Skiphs' plans for an eventual 1.4, but for the moment, even direct developer statements are in a weird state where they might only be future features for a couple of minutes. I do think the page could still serve as a repository for distant mentioned features, similar to how the Minecraft wiki handles mentioned features (but ideally cleaner).

If there's no objection, I'll archive the last revision and replace the page with a short paragraph explaining that there are no plans in the foreseeable future.Gearzein (talk) 09:20, 6 July 2015 (UTC)

1.3 Update page

I asked this about 1.2, and am going to ask again for 1.3. It would be wonderful if there was a page for all things listed visually from "Category:Entities introduced in 1.3.0.1". I have started a page at User:Bws2cool/1.3_Update if you want to see an example. It would be great for linking to people who want to know what is new in the game, and to keep track of everything. Feel free to edit my page if you wish, or copy it to your own userspace. Bws2cool (talk) 16:30, 6 July 2015 (UTC)