Template talk:ArenaNet image

Skill icons

I suggest to create a specific category for skill icons, under ArenaNet icons. This would avoid the merge of all icons in a single category. Do you agree? Chriskang 22:21, 22 July 2010 (UTC)

I'm okay with it. If it turns out the icons they've shown now are different from the icons in release, we could always cycle these icons into a "beta/unimplemented icons" category. --Riddle 22:31, 22 July 2010 (UTC)

Versatility

This template is currently too limited in its utility. For example, all images within the skill animations category are either without a template (so they have the wrong copyright) or twice within the same category tree (once for being inside one of the Skill animations subcategories and another due to this template, which automatically adds everything to the ArenaNet image category or one of its main subcategories).
I would like to change the template so by default it works as it does today (automatically adds an image to a given category), but with a command line that may be used to cancel the automatic categorization. It would allow us to replace all image templates used within the ArenaNet images category with a single template, while still keeping the template simple enough for users who don't know how command lines work. Erasculio 00:11, 10 August 2010 (UTC)

Sorry for having to ask, but basically, you want it to add images to a subcategory rather than a subcategory and the default ArenaNet image category?-- Shew 02:38, 12 August 2010 (UTC)

A subcategory of the default ArenaNet images category, ideally. But that would add too much complexity to the template; we would need more than a dozen "if x then y" code lines to fit all possible subcategories. So what I would like would be the template to continue working by default as it currently does, but with a new option to turn off the automatic categorizarion, so we may manually add the subcategories when needed. Erasculio 13:06, 12 August 2010 (UTC)

What would the purpose of using the template be if you're gonna override the default categorization/add your own anyways? If you're just going to override the default categorization and add your own, wouldn't it work better to just add the specific category in the image summary? Imo, the if statements would be a good course of action.-- Shew 15:39, 12 August 2010 (UTC)

The license. Since the ArenaNet images have a different license than common wiki content, we have to use the template due to the license it states. It's also useful for some other notices, such as the note we have about screenshots.

But hey, if someone is willing to add all those lines of code to fulfill all if conditions, go for it. I wouldn't oppose it. Erasculio 16:23, 12 August 2010 (UTC)

Why can't it just put the images into identical subcategories on the ArenaNet images category? So concept art would categorize under the Concept art sub category and ArenaNet concept art. Or am I just confused? -~=Ϛρѧякγ (τѧιк) 16:58, 12 August 2010 (UTC)

Okay, I have modified the template now, to have an additional parameter, that overrides the automatically set category. When categorizing please set the first parameter as well (if possible), to make the correct text and color appear. If possible the automatically set one should be still preferred, at least unless you are categorizing something into a new appropriate subcategory. I'll check from time to time what categories are used very often and will add respective shortcut names for those (plus replace all the previous usages). poke | talk 18:16, 12 August 2010 (UTC)

To be used like this. poke | talk 18:18, 12 August 2010 (UTC)

Although this is done for this one, may I say I personally hate the auto-categorizing for many cases. Most particular cases being NPC and location templates from the GWW (which put the NPC or location in multiple categories - many of which are redundant). Point being: For the future, can we add the parameter to remove the auto-categorization on all templates of the like (or even for which auto-categorizing does not work for when there are multiple categories automatically added)? -- Konig/talk 18:31, 12 August 2010 (UTC)

(Reset indent) Thanks to poke, this template is almost perfect now. We may now use it to replace the old {{screenshot}} template (which I have tagged for deletion, after removing it from currently active content on the mainspace) and the {{GW1 image}} template (although that one I'm not going to fix).
The only issues left are the trailer image template and the website image template. Both have a notice the current ArenaNet image template does not have ("This image has been taken from the official Guild Wars 2 website or one of its linked sites. As such, it may be an incomplete or outdated version of the content it represents") and a functionality it does not have either (the trailer image template identifies which trailer the image comes from and gives a link to said trailer, which is relevant in order to let people know from which stage of development the image is from).
Do you people think it would be worth to add those two functionalities to the current ArenaNet image template, or would you rather keep it as it is in order to avoid making the template even more complex? Erasculio 16:33, 13 August 2010 (UTC)

First, I wanted to integrate those into the ArenaNet image template, but after thinking about it for a while, I changed my opinion.. Both of those template serve the main purpose of specifying the image license, and both are reproducing parts of this template's auto categorization. However the licensing information should be always given by the ArenaNet image template, so the only thing that those two template give are additional warnings that the images might be of a lower quality. But if I follow our recent discussions correctly, we don't want to name images based on their source anyway (like trailer images), so it shouldn't matter that they are lower quality images from trailers, we just have those images and replace them with better ones as soon as those get available. So we rather should replace those templates by a low-quality notice and use this template for the licensing stuff. poke | talk 20:48, 13 August 2010 (UTC)

Actually, I would like to keep those old screenshots. Not in the articles themselves (since we would have better screenshots for those after release), but just to document a stage in the game's evolution (just as we keep linking to that very old GW1 video, in which the game looks a bit like WoW).

We could keep two separate notices, one with the license and the other talking about the low quality (and/or old images), which is what was used before. But the reason why I tried to merge both notices (resulting in the current trailer image template) is because IMO having the two notices look rather ugly - having everything in a single notice looks prettier. Erasculio 13:12, 15 August 2010 (UTC)

No, you didn't get what I meant. When we have a screenshot or concept art captured from a trailer for example, and at a later point, ArenaNet decides to put those images on the website or somewhere else, then we can simply replace the lower quality trailer image with the better quality image from the website. Both images hold the same content, but the latter is just of better quality. So we would always have the best quality image of a specific concept art or screenshot here. It doesn't matter where it came from, we just replace all lower quality images with better ones. And if ANet decides not to release an image in a higher quality, we simply keep our version, which is then still the one with the best available quality. As such no need for a "low quality" warning is needed, as we always have the best one of one motive. poke | talk 13:49, 15 August 2010 (UTC)

So we wouldn't need the second notice at all? Sure, that works too. Erasculio 00:51, 16 August 2010 (UTC)

Icon license template not showing on file pages

i r nub and not know do how fix to it. --Xu Davella 04:00, 10 September 2011 (UTC)

When you redirect a page, nothing else you put after that shows up on the page (though it still categorizes).

PS: Stop redirecting those icons please. No need to undo, since Poke's gonna do a botrun at some point, but for future reference. - Tanetris 14:45, 10 September 2011 (UTC)

Yeah no worries. I did see that discussion before I made the edits but because the image formatting page wasn't changed to reflect it I went ahead and redirected the icons anyway. But if poke's gonna do a bot run anyway, it's probably better that I at least categorize them like I have been to save him time, I'll just leave out the redirecting. --Xu Davella 08:44, 12 September 2011 (UTC)

parameter proposal: id

→ moved from User talk:Dr ishmael

First, the parameter has a specific intended use in a DPL context.  The fact that it is not currently part of the normal output of the template does not make it any the less a formal part of the interface specification.  If you insist that the information be used, I can make it part of the 'ArenaNet Content' category specification.

Second, you are not following the procedures specified for dispute resolution.  You are supposed to discuss the change before arbitrarily removing it unless the change has broken something important.  In this case, the change definitely did not break anything.

So, please put the change back where people can see it and discuss it.  --Max 2 14:11, 9 July 2012 (UTC)

Template documentation is there to tell the user how the template works. That template does not recognize or use an "id" parameter, therefore it has no place in the documentation. This is not an issue under dispute, that's just how it is.

Could you explain how you intend to use this with DPL? If you can make a good case for it, then we could modify the template to actually use it. As I've said before in other places, the file ID is meaningless, and you could just as easily use the wiki filename to discern the different files. —Dr Ishmael 14:20, 9 July 2012 (UTC)

'Template documentation is there to tell the user how the template works.'  Wrong! Template documentation is there to tell the user how the template is to be used.  I am not suprised you do not recognize the distinction or how important it is.  If the documentation is done properly, people can use a well documented interface even when the implementation of the documented function is completely rewriten.  In fact it is a sign of absolutely retched documentation if the documentation simply says how it is implemented!

Good documentation is one of the early steps in building a good system.  It allows information to be coded before the system is built to use that information.  That means such things as the meaning of a template parameter has to be specified before the code to actually use its value is writen and in some cases even planned.  Having the specification forms the basis for planning, design and development.  Insisting on having an implementation before doing the specification is completely backwards.  In fact, this kind of documentation is required ahead of time for good system design!

You ask for implementation details like how it is to be used with DPL.  Those details have not been developed at this point.  What is known is that something like these 'ids' were used with GW to tie the game's help system into the Wiki.  Without a sufficently large sampling of this kind of data, it will not be possible to test the feasability of such a project.  So the documentation is very much an issue and it should be restored and discussed.  Deleting without discussion was very much out of line.  The fact that you can not think ahead far enough to see that a potential like this needs planning and fore thought and that you consider such activity 'meaningless' says far too much about your attitude on the future.  --Max 2 15:17, 9 July 2012 (UTC)

You're twisting my words and arguing semantics. By "how it works" I of course meant "how calling the template works," not "how it is implemented," which should've been obvious from how the wiki's documentation is written in general.

You're also wrong about the IDs used in gw1:Guild Wars Wiki:Game integration. Those are IDs of the quests, locations, skills, etc. not IDs of the icon files.

Finally, I would thank you for dispensing with ad hominem attacks in the future. They do nothing to advance your argument. —Dr Ishmael 15:27, 9 July 2012 (UTC)

I may be nailing your words down and giving them a more precise meaning than you intended, but semantics is all about meaning.  You may think you ment 'how it works' to be about 'how calling the template works', but that is not how it came out.  From the rest of your context and focus on implementation, the meaning you conveyed was, in fact, 'how this implementation of the template works'.  In fact, 'how calling the template works' is specified in the PHP code that implements this Wiki and is completely off-topic.  I was specifying 'how the "id" is to be used', which is exactly what you now claim to have ment.

The IDs in GW are none the less identifiers of objects inside the game, and the internal mechanics of GW may well be different from those of GW2; the IDs for icons and exactly how they are used is being investigated.  We have the IDs of some things available and I want that information on record even if it is not obviously useful at the moment.  In fact, I expect others will be able to make better use of the information than I will.  But to make use of the information, it has to be available, and to be available there has to be a way to record it.  That was what I was documenting.

As for the ad homium remarks, they were characterization of your behavior and attitude, not your person.  If you see them as attacks, then you apparently think they are short-commings.  That means you can change them if you want, but that is your decision.  If you are a little less heavy handed with deletions as a result of my calling your inappropriate activity to your attention, then something will have been accomplished.  Better would be for you to correct for that bad behavior.  --Max 2 16:16, 9 July 2012 (UTC)

Really, so you're saying ANet is going to point users to icon IDs instead of item IDs? That doesn't seem plausible. Also, the documentation vs implementation vs design, generally you have a design with a set purpose, then you implement and document. Documenting future features w/o any design doesn't seem logical. --JonTheMon 16:22, 9 July 2012 (UTC)

I'm going to stop arguing with you about what I meant. You seem to be deliberately misinterpreting me, and if so, then no explanation I give will be acceptable to you.

I know how the internal game IDs work. File IDs are in no way related to skill/location/item IDs, they are as arbitrary to the game engine as they are to us - simply an identifier that says where to find the file within Gw2.dat. Each object (skill/location/item) is composed of multiple data files - a skill has an icon texture file, texture files for the animation effects, a pair of strings in text files for the skill name and description, and probably (I haven't nailed this down this yet) a set of parameters from a data file that determine the skill's effects and their scaling factors.

I object to your personal attacks because they assume things about me that are completely incorrect. I work as a software developer at a large corporation that has a well-structured project management process. Usage documentation is the last step in that process. What you are describing is not usage documentation but requirements documentation, which is the first step of the process. Requirements are used to write a design document describing how to implement the client's requirements, which the developer follows as they implement the project. Only after the project is implemented, tested, and approved, do we write usage documentation.

Obviously, we don't follow any formal process like that quite so strictly here on the wiki, but that's basically why I asked you to explain your intended usage for the id parameter - you updated usage documentation without going through any other step of the process. —Dr Ishmael 16:34, 9 July 2012 (UTC)

Those dat extractors the files and IDs related to this drama come from just assign every file a number starting from 0 in the order they encountered it. No point documenting or keeping those numbers as they are not official IDs and may already be completely off by the next build that contains file updates. --zeeZ (talk) 16:41, 9 July 2012 (UTC)

Actually, no - Gw2Unpacker still does that, yes (at least, the version I have does, and I don't think there's been a newer version posted), but Gw2DatBrowser (which is more efficient anyway) uses the internal file IDs stored in the Master File Table within Gw2.dat. It's likely that those IDs are fairly static, but they're still meaningless other than making it easy to compare files between builds. —Dr Ishmael 16:44, 9 July 2012 (UTC)

Not to interrupt this heated debate, but those file Ids are static and while I don't know how much use they would be here on the wiki, they are gold when it comes to reverse engineering the game. Server packets use those file Ids to reference everything. When a file is updated it is given a new file Id, but also keeps the old one. So at that point two Ids reference the same file. The original Id never changes. 78.47.250.35 17:06, 9 July 2012 (UTC)

I also have worked with formal development procedures and with large corporations.  I have also seen where those procedures lead when abused, ignored and corrupted; the results can be quite ugly.  Since we do not have formal procedures in place, and the project, as such, is still vary amorphous, and this is only one small part of the requirements, I tried to find a place to specify the 'id'.  The requirement is to record the id, so I put the documentation where it would make the most sense. The icon images expose the id, so that is where I put their description.  It would help if you would put that documentation back.

(In fact, one of the first things I did as part of a project team back in the '70s was to point out that the governments documentation requirements had an internal structure with more than a little redundancy.  Large sections that had been copy/pasted between the various documents could be seperated and included in the reports except that the formatting software did not have an 'include' capability.  I added that ability. The change was released through DECUS. The team took the basic observation and refined it which improved the groups work product and reduced costs.  I have built on that basic understanding and adapted what existing frameworks provide to the needs of a project.  In this case, we have a specification for identifier information that can definitelty be associated with ArenaNet images, so I stuck the specification into the documentation of the associated template.  Admitedly unorthodox, but appropriate given the context.)  --Max 2 17:43, 9 July 2012 (UTC)

(Reset indent) Arguments of semantics and personal experience get us nowhere, so let's cut the argument down to the core issues. The general issue here is whether a template's documentation should list a parameter that the template itself does not actually use. I say no, as this could be misleading for users. Also, it is bad practice to overload a template call with unused parameters for any reason.

The specific issue is whether file IDs are worth storing on the wiki. Again I say no, because they provide no information of any value. Technically, it is also illegal, since they can only be found through reverse-engineering ArenaNet's software, which is against the EULA (Anet's so-far light-handed approach to dat file extraction notwithstanding, doing something as potentially provocative as posting the file ID on every icon across the wiki would be unwise). Anyone who wants to track changes to the individual files between game updates should maintain their own file_id↔wiki_filename index as a local file on their own system (I'm already doing this myself for skill icons and map tiles, makes it very easy to write scripts to check the differences). —Dr Ishmael 18:21, 9 July 2012 (UTC)

That is still not an excuse for pulling the documentation before it could be discussed!  Put it back and discuss it so we all can have a say on it . --Max 2 20:28, 9 July 2012 (UTC)

Aren't we having a discussion right now? And like Jon said above, you don't document (in usage documentation) something that has not been implemented yet. —Dr Ishmael 20:31, 9 July 2012 (UTC)

No, we are discussing if it should be discussed and if you were wrong for shutting down the discussion in what should be the proper place to discuss it.  I also strongly disagree with your opinion that "you don't document something that has not been implemented yet."  The discussion has to start someplace.  I have identified that the image used for icons has the distinctive propery of tying several conceptual parts of the semantic structure together.  I used the template as the starting point for the discussion.  You improperly deleted the starting point for that discussion.  Rather than start an edit war, I came to you and told you the information needed to be put back where it belonged.  You have failed to put the information back. Put it back!

The discussion of legality does not belong on you page.  At the minimum your opinion about it shows a rather gross limit on your understanding of the issues involved.  In particular, you, as a third party are more at risk of breaking their rules by maintaining your index than posting such an index here would be.  Here they have to option of deleting the information if they think it should not be 'out'.  They do not have that option with files you maintain on your 'third party' system.  --Max 2 22:04, 9 July 2012 (UTC)

What you added to the template is still visible - that diff can serve as the "starting point" of the discussion, and indeed it did serve as that, as the issue is being discussed right here. If someone wants to know what the issue is, they can see that diff and join in the discussion. pling 22:32, 9 July 2012 (UTC)

Fine, let's ignore all side issues (e.g. legality) and get to the bloody point: is file ID a valuable piece of information to have? You still have not addressed this question with any concrete proposals of how it would actually be used. —Dr Ishmael 22:36, 9 July 2012 (UTC)

Plingggg: You know that is not true.  If it were true, there would be a discussion about this on Template talk:ArenaNet image and there is not.

Dr Ishmael: That discussion belongs on Template talk:ArenaNet image after you have put the parameter documentation back where it belongs.  To answer that question here would move the discussion from its proper place to your domain.  Put the documentation back and I will discuss it there.  --Max 2 22:54, 9 July 2012 (UTC)

restart: parameter proposal: id

Now that it's in the right place, let's have the discussion. —Dr Ishmael 23:00, 9 July 2012 (UTC)

As someone that really enjoys reverse engineering GW, I think it would be kind of handy to have id info available on the wiki. Saves me time looking it all up myself. Just to be perfectly clear though that file Ids are not the same as enumerated ids for maps, skills, and such. 78.47.250.35 23:19, 9 July 2012 (UTC)

(Reset indent) To properly start this discussion, the proposed addition should be shown and not on some old revision where it will be hard to find.   That is:

---

keyword parameter id

Optional and not displayed. This information is provided for consistancy checking purposes. It is an identification number used internally by the game for reference purposes. It may eventually be used to connect help requests from the game to a context in this wiki.

---

Note that this template is used in association with ArenaNet supplied images and this parameter would only be appropriate for images that represent objects associated directly with the game.  So far I have been attaching this information to icons of items, but there are also icons for actions and many other kinds of game objects.

The ids are arbitrary, perminant numeric designators.  The current batch of information may in fact be incorrect.  If it not correct, it can be corrected by those with access to the definitive information. 

While the ids are associated with images, they also have other associations.  Exactly what those associations are is speculative at this point, but the following associations are very likely to exist:

• The image — which provides the player with a handle to attach to their own understanding of the game object. 
• Inventory items — with all their associated attributes. 
• Item names — with the spelling associated with the language the player selects for their display.
• Help requests from the game — not specifically known to be available or unavailable as a capability, but the ids will almost certainly be used to designate what the game wants the Wiki to display. 
• The identifier itself is unambiguous — it always designates the same thing. 

However the normal wiki user will not be interested in this information per se.  They will, however, be interested in the consistancy of the wiki as a whole and this information will assist in supplying that consistancy. 

If the information is not to be supplied through this particular template, it should be supplied through some mechanism.  Without it, it will be difficult to tie detailed technical information about the game to wiki content.  --Max 2 00:42, 10 July 2012 (UTC)

"The ids are arbitrary, perminant numeric designators. The current batch of information may in fact be incorrect." That's contradictory. Also, why would we even care about image IDs? Images are associated with items or quests or whatever and aren't ever directly used; in-game links to the wiki will never be for images. And all the associations you listed, yeah, those all tie to the item itself, not the icon image. --JonTheMon 01:49, 10 July 2012 (UTC)

Jon: Are you being deliberatly obtuse? It is perfectly possible that the information I have is incorrect.  In contrast, the information the game actually uses is an arbitrary perminant numeric designator.  If I have made a mistake, the mistake can be corrected. 

The ids have several associations as I said above.  One of those associations is to a particular image.  The in-game link will be to all the associated information, including, but not limited to the image.  Because there are multiple associations, including one or more in the player's mind, saying the link will never be to any particular kind of thing is just plain nonsense.  Given such an id, any of the associated information, including the image, can be used to answer the game's request. 

However, it all has to anchor someplace.  An image is as good an anchor as any and better than some.  For example, images are not subject to much in the way of editing, so their information content is stable.  The images in question are all the property of ArenaNet or NCSoft and need a special license displayed; that license display is part of 'AreanaNet image' template, so the template will be present in every case where in id could be used.  And that brings us back to the question "where could the association be made that would be better than here?"  --Max 2 02:30, 10 July 2012 (UTC)

The information you are recording are essentially just memory locations. What happens if they change an image location or remove one, causing all other images to shift? I can see no scenario where the game would want information from the wiki based on an image id. An item/item page doesn't care about the image id associated with the image for the item, just that there is an image for the page (based on naming). --JonTheMon 03:03, 10 July 2012 (UTC)

As was previously stated, file Ids will never change. And again these are not enumerations and would have no bearing on in-game integration, but are just for reference. 78.47.250.35 03:28, 10 July 2012 (UTC)

Also as previously stated, the file IDs have no relation at all to the data structure ID of items/skills/etc. Skill IDs are assigned as the skills are implemented, starting from 0. Item IDs are assigned as the items are implemented, starting from 0. Skill IDs and item IDs will overlap, meaning a skill and an item can have the same ID number, but that does not mean that they reference the same file ID for their icon texture. Currently there are only ~2000 skills in the game, meaning the max skill ID is ~2000; however, most of the skill icons have file IDs ranging between ~102700 and ~104000. Is that conclusive enough?

tl;dr file_id <> item_id —Dr Ishmael 04:59, 10 July 2012 (UTC)

Is it just me or someone else also didn't see any concrete usage for these ids as far as this discussion goes? - – Valento ^msg 06:08, 10 July 2012 (UTC)

The bottom line is they really will only be useful to people RE'ing the game and have no relation to struct ids/game integration such as skill/map ids as stated above. These structs only use these ids to reference assets. For example Divinity's Reach is map id 18 and map file 191265. 78.47.250.35 06:37, 10 July 2012 (UTC)

So I conclude that they're not needed since it won't add anything useful and will only serve as a way of promoting RE'ing, right? – Valento ^msg 06:41, 10 July 2012 (UTC)

If you don't give a shit about the quality and consistancy of the information in this wiki or about the ability to verify that information against information gathered about the game but not related to some pet author's verbage, you would be correct.  If you are willing to let some people check for consistancy and correctness without having to blather about things other people might not be brethless over, then this information is useful.  (There might even be a few who do not want this wiki to be the best source of game information, like those who make competitive games.)  --Max 2 08:39, 10 July 2012 (UTC)

I'm sorry, but I'm having trouble understanding what sort of argument you're trying to make here. Are you implying that there will be trolls intentionally providing incorrect data to the wiki? Knowing the file ID of an icon isn't going to help with that, because there's no way to map that file ID to the actual game object information.

As Mr. 78.47 noted above, file IDs are really only of interest to people exploring the dat file, the general readership of this wiki has no use for them. For that purpose, it would make more sense to start up a spreadsheet on Google Docs that you could share with other interested people, for the purposes of mapping file IDs to their usage (not just for icons, but everything else, too). —Dr Ishmael 13:18, 10 July 2012 (UTC)

(Reset indent) Dr Ishmael: Please open your mind.  The 'trolls' are much more likely to throw up arguments against doing our best than anything else.  As for spreadsheet on Google Docs, that is exactly the wrong thing to do.  That would put the information in the hands of third parties (yourself and Google Docs) and not in a place where ArenaNet could control it.  They may allow the information here precisely because they can review and control it where that is not true elsewhere.  --Max 2 14:25, 10 July 2012 (UTC)

You've got it completely backwards. Given their attitudes towards the same activities in GW1, Anet has a very hands-off approach to RE activity. Thus, keeping any RE information off the wiki (or at the very least out of the primary namespaces) is best, because otherwise it would force Anet to take a stand against it.

But once again, you have derailed the discussion onto a side issue that has no direct consequences. Since you have yet to provide a valid use case for storing file ID on the wiki (that hasn't been invalidated by the facts of how the game works), I'm going to remove myself from this discussion and spend my time on more important tasks. —Dr Ishmael 14:44, 10 July 2012 (UTC)

That is a gross non-sequitor.  There was (and is) some discussion of internal game structure on GW1.  There would probably be more if it did not meet such fierce resistance from people like you.  You are also declaring you judgement that the reasons I have provided are not valid to be the ultimate answer.  Bullshit!  --Max 2 14:56, 10 July 2012 (UTC)

That's because that and this are game wikis, not reverse-engineered-game wikis. Any .dat mining was done to assist in that goal and was outside the scope of the wiki and so mostly kept off the wiki. --JonTheMon 15:15, 10 July 2012 (UTC)

That is an arbitrary decision on your part.  There is no reason that some 'reverse-engineered' game information can not be included here, as long is it does not interfere with the other parts of the wiki. In fact, this is one of the few places that can post information about game internals that does not run afoul ArenaNet's and NCSoft's stated policies.  The fact that they do have control here, even if they decline to exercise it, makes a significant difference between what can and can not be allowed to be posted.  --Max 2 15:56, 10 July 2012 (UTC)

No, that's not arbitrary. The purpose of this wiki is documenting the game experience, not the inner workings of the game that are shown in other ways. --JonTheMon 16:07, 10 July 2012 (UTC)

It is an arbitrary decision on your part that selected postings about game internals is not part of the game experience.  It also fails to account for the fact that no other forum exists with the permision to post that kind of information that this wiki has.  --Max 2 16:19, 10 July 2012 (UTC)

I've said it elsewhere but it applies here to: Just because you can doesn't mean you should. Also, the "can" is debatable, since RE is frowned upon and having that on the official wiki might be considered tacit approval. --JonTheMon 16:29, 10 July 2012 (UTC)

And you have set yourself up as the arbiter of this wiki's content.  :-(  And you are the one to grant or deny such approval.  I do not think so.  You represent neither ArenaNet nor NCSoft.  --Max 2 16:40, 10 July 2012 (UTC)

No, the arbiter of content is consensus, which you do not have. If you can get consensus for this, then it can be re-added. And while I do not represent Anet, I can be aware of what may or may not be approved. --JonTheMon 17:54, 10 July 2012 (UTC)

That is right.  The arbiter is consensus.  The problem is that you have claimed to represent the consensus far too often and far too quickly for me to trust your judgement on that any longer.  I also do not trust you to speak for ArenaNet or NCSoft, especially when their inaction implies a much more likely outcome completely at odds with your prediction.  What I do trust you to do is to try to bully people into doing what you say using false arguments and claims to an authority you do not have.  --Max 2 19:30, 10 July 2012 (UTC)

self-link for certain types?

{{ #switch: {{lc:{{{1|}}}}} | concept art | fansite kit | video = <span style="display: none;">[[Media:{{PAGENAME}}]]</span> }}

I can't figure out why that bit of code is in here, or why it is applied selectively to only a few types. The edit that added it (both here and on GWW) had a blank summary. It's been confusing me for a while when I've been examining delete-tagged "concept art" images - check "What links here" to make sure it's empty... hmm, there's one link, better fix it -- wait, it links to itself? Derrr...

The only plausible reason to do something like this is to keep the file off of the Special:UnusedFiles list, although I can't see the point of doing that. If the file isn't used, why hide that fact? If no one objects, I'll remove this seemingly pointless bit of code the next time it bugs me. —Dr Ishmael 14:58, 28 January 2013 (UTC)

Drogo is nuts, revert away. -Chieftain Alex 18:26, 28 January 2013 (UTC)

Check the dates, Poke added it to GWW about 6 months earlier. —Dr Ishmael 19:43, 28 January 2013 (UTC)

Oh in that case I'll read the wikicode properly. Perhaps Poke didn't want any deletion happening on Orphaned concept art - its often difficult to obtain and hard to reacquire if deleted, potentially impossible if from deleted external sources. better date range for discussion ;) -Chieftain Alex 19:56, 28 January 2013 (UTC)

That’s basically the reason. Back then we had a page called “Not-orphaned images“ where concept art, that currently didn’t have a place to be displayed, would be added so it won’t show up in the list of orphaned images and get deleted. To prevent having to add them all manually there, and making a huge cluttered list, we later came up with a template that did this to tagged pages. And as concept art is usually something we want to keep regardless of it being used, we made them not orphaned by default.

The idea behind the selection of those types is that we usually upload everything from the fansite kit but don’t necessarily use them; and videos (meaning animated gifs) were usually only linked from skill articles showing the skill animations but never included somewhere (because they would slow down the pages far too much). Other resources like screenshots are not included because there is no real guarantee that they contain anything that should be kept. If you still want to keep one alive, we have that template here too. poke | talk 07:02, 29 January 2013 (UTC)

Alright, that sounds reasonable. I'll try not to let it bug me in the future. —Dr Ishmael 14:23, 29 January 2013 (UTC)

caption property

We could have a caption parameter to a Has caption property for the image.--Relyk ~ talk < 18:15, 17 May 2013 (UTC)

And what would be its purpose? poke | talk 13:18, 18 May 2013 (UTC)

@Poke, what is the {{#vardefine:sl|1}} for?

Per the title, there is a variable set called "SL" for images that are fansite kit, renders, animations, icons or concept art. What was the purpose, is it still relevant, and should we remove it? -Chieftain Alex 19:08, 29 October 2013 (UTC)

Look up 2 sections. I didn't mention the variable name, but it's the same discussion. —Dr Ishmael 19:36, 29 October 2013 (UTC)

Interesting… the point of the variable, “sl” or “self-link” (probably), is to enable the self-linking that I explained above. It seems that I introduced the variable to make each type configurable within each’s single line, but never actually got around to check the variable for evaluating it. Oops! I fixed that now… poke | talk 20:24, 29 October 2013 (UTC)

Item icons

Icons are set to self-link, and I'm not sure why. I'm going through karma items and others and consolidating icons. The result will be a ton of unused icons, mostly duplicates of the generic fine and basic weapon icons, and the various karma armor set pieces. I suppose there's no harm in leaving them, but if they should be deleted, icons should probably not self link. Psycho Robot (talk) 03:25, 15 January 2014 (UTC)

*ahem* —Dr Ishmael 04:04, 15 January 2014 (UTC)

Okay, I'll try to be constructive. While I can understand why it was done in the past for concept art and similar, I don't know why it was ever done for icons. I would think that it's not even necessary for concept art anymore, since we have plenty of lore articles to use them on. —Dr Ishmael 04:10, 15 January 2014 (UTC)

I seen that! I just only saw people discussing using it for concept art and videos. It looked like icons was added later, but I dunno for sure, or for what reason. If it was done without any discussion, it can just be undone without discussion, right? Psycho Robot (talk) 04:39, 15 January 2014 (UTC)

Icons had that behavior too because we had lots of icons in GW1 that were superseded by newer icons. The old icons were never documented anywhere, but at least kept around so they could be found. If this isn’t necessary anymore, we can surely remove the behavior from the default and use {{not orphaned}} for those cases where it’s still necessary.

Same with concept art, although for those I’d be reluctant to do that as from experience, concept art on articles is very often replaced by other images which may (or may not) seem more appropriate (e.g. a screenshot).

In the end, my main priority is that we don’t delete stuff we otherwise don’t have anywhere. If we keep a few duplicates that shouldn’t be any problem, but losing media is. poke | talk 06:51, 15 January 2014 (UTC)

I'd be quite happy to not have these unused icons (most of them are just replaced dupes). -Chieftain Alex 11:44, 15 January 2014 (UTC)

I would not be opposed to, if there were any case of a unique unused icon, keeping it in some orphanage, but right now all this behavior is accomplishing is keeping a zillion dupes of "File:Fine Longbow.png" et. al. from appearing as unused. Besides, even if the icon were to be updated, the old version would still be in the file history, would it not? Psycho Robot (talk) 19:06, 15 January 2014 (UTC)