Help talk:Editing

From Valve Developer Community
Revision as of 10:32, 29 March 2011 by Thelonesoldier (talk | contribs) (Zoomed out)

Jump to: navigation, search

Is there any way to make new pages?

I've got a bunch of tutorials and other stuff on Steam that could be with being added.

I think you just need to modify the url in your address bar to go where you'd like. If I wanted to start a page on "stuff", I'd use the address http://developer.valvesoftware.com/wiki/Stuff . No doubt there is an easier way, but there are some significant differences between the SDK wiki and other wikis like Wikipedia. User:Geogriffith
Clear and simple information on how to create new pages should be added here. This is one of the most common things that people have trouble with. --JeffLane 01:27, 1 Jul 2005 (PDT)

How do I add pictures?

Does anyone know how to add pictures? True_Unity 08:26, 11 Dec 2005 (PST)

<<You see that link over yonder that says Upload file? Push it—ts2do (Talk | @) 11:43, 11 Dec 2005 (PST)

Additions

Added bullet points. I noticed someone added something about redirects. 6-28-05 User:Geogriffith

Added some more info about math symbols, equation rendering. Looks like it's not enabled though because I can't get it to work, am I doing something wrong? -- MrAnderson 13:55, 4 Jul 2005 (PDT)


Code tags

(This discussion originated on the Talk:areaportal page, and was moved here.)

I am pleasantly surprised that you (Jeff) put so much effort into it with pictures and all. From being just a footnote mentioned as parts of several bloated articles, areaportals now have a beautiful "home". However, as uncomforting it is telling you this, the entity <code> format you used was scrapped years ago. (It looks ugly and distracting, and confusions over "light" entities has been unheard of.) Do you mind if I remove the code tags? --Andreasen 10:37, 20 Sep 2007 (PDT)

I mind. I think it has been established as part of this wiki style to code-tag entity names amongst others. --Tourorist 13:03, 20 Sep 2007 (PDT)
Uh, name five articles that still has the code tag (that isn't 1-2 years old). --Andreasen 13:45, 20 Sep 2007 (PDT)
There was some discussion of this last year, but it was not conclusive enough to merit changes as the reasons given were completely subjective and there was no consensus. The Help:Editing#Formatting_guidelines page reflects the closest guide to current usage, as well as a number of existing articles on the site that use the tags in this way. The age of the articles is also not very relevant. In fact, it's the opposite if most of them are using this format and there was no consensus on a change. In the case of this article, I actually got most of this formatting when I moved sections from the original Controlling Geometry Visibility and Compile Times page.
That said, I don't feel that strongly about this either way, so if a significant number of editors come to a consensus and want to change it in some way, that's fine. Though I do feel that entity names really need some visible marking to show that they are not just English nouns. They are keywords with significance and are almost always the focus of the text. It's the same reason we highlight other keywords like Menu Titles. Why would it be any different? There are precedents in technical documentation for this. Capitalization is often used for important keywords, but that would just be confusing in this case. Another other option is bolding, which might work better. Hope that helps. --JeffLane 18:52, 20 Sep 2007 (PDT)


I tried to find the previous discussion we had about this, but couldn't find it.
I rarely see code tags being used in articles, so I don't think that the Help:Editing page is reflecting the current usage. I've seen only three pages that uses the tag for entities as of late: Controlling Geometry Visibility and Compile Times, areaportal (this page), and the one that User:Tourorist "codified" himself, believing that the tag was current usage.
The reason for this is natural: Besides being an unnecessary eyesore to readers, "<code>[[entity]]</code>" also takes twice the amount of characters to write (including special characters) than "[[entity]]", and entities are used much more commonly than console commands and file paths are.
As for special marking, many articles doesn't focus on a particular entity, but of a topic involving many entities, where they themselves are often just mentioned as mere alternatives, or even exceptions (like "Prop_physics should not be used for this."), drawing attention to totally different topics. As it is now, when entities are first mentioned, they are linked to (according to current guidelines) which is marking them in blue, and the topic is then understood. If need be, we could mark them all in blue, every time they're mentioned. That should be the closest natural markup for authors, and just looking at this very text, that markup should make all the entity names stand out, without drawing too much attention to it.
I can't argue with technical documentation standard, but judging by the article you just wrote, turning a matter-of-factly (technical) article into something a little more greeting and fleshed out, I don't think that the VDC is a 100% technical manual. Also, if compared to wikipedia, I don't see any technical lingo being marked up there.
Entities are rarely even able to be confused with nouns. Of all the entities (I checked the lists.) only four doesn't have an underscore (_) in them: Cycler, gibshooter, infodecal, and light. There are two easy methods to deal with these:
  1. You can set the topic by linking to the entity article at its first mention (and if in any way unclear, later mentions as well), like above. The latter mentions of it is then obvious.
  2. You can refer to it as "the xxxx entity". The only entity that even comes close to being confused then, is the light entity, if someone would assume that the article was about weight instead of lighting, which would be virtually impossible to do, considering how different these topics are. When dealing with light entities as a category, one can refer to them as "light source entities" to avoid confusion.
I wish there was a significant number of authors around to vote for any change, but considering that most articles currently use the lighter "[[]]" markup, that change would be back to using code tags. It's easier to remove the guideline than to change most of the articles in the wiki. One can't seem to find entity code tags through the search engine, but could I, I would gladly hunt down the last remaining code tags myself, if only allowed, because it makes every mention of them a bother. --Andreasen 06:48, 21 Sep 2007 (PDT)
I wasn't the one who introduced this practice, if that's what you imply. And like Jeff, I am neither for nor against on this issue, my sole interest (as evident from my contributions) is in overall consistency of wiki, whichever way we go. --Tourorist 07:23, 21 Sep 2007 (PDT)
I'm not at all blaming you for following what you believed to be current standards. --Andreasen 08:34, 21 Sep 2007 (PDT)
The VDC documentation is technical writing, like any type of help files or user manuals are. Creating content with the Source Engine is a technical subject. It is from that perspective we try to evaluate these kinds of decisions.
I would agree with a change if it's a positive one, or even an equal one, but I'm not convinced that removing all the entity formatting is positive. They are an important keyword, essentially a cross between a menu command and a piece of code (depending on the context), and their exact name is significant. Text formatting of some type needs to reflect that distinction when no link is present.
The suggestion of standardizing formatting in blue is reasonable one, but would make them look like false page links, so it shouldn't be that, and adding color tags is prone to errors. Using bolding after the first link is a better alternative since it has simple wiki syntax. That would put them on the same level as menu titles and commands, which does make some sense from the perspective of most of our users. For them, picking entities is a menu choice in Hammer and the primary context they will see them (few of our users read the .fgd file, for example). Italics is another alternative, though they don't read particularly well in this typeface and point size, and readability is critical for entity names.
As an aside, I've never been too happy about the extra gray shading behind the text in the code tags. It too dark on some monitors and lighter on others and the monospace typeface that shows up with code tags is really sufficient for the purpose. I will likely remove it in the site-wide CSS, no matter what we decide with entities. --JeffLane 11:16, 21 Sep 2007 (PDT)
The gray background is now removed from code tags, and the space between section headings is now slightly increased (especially level 2 sections). --JeffLane 14:47, 21 Sep 2007 (PDT)
When you wrote that the format had precedents in technical documentation, I assumed the highlighting in gray was some sort of technical manual standard that I must have never seen before, but this page tells me it's pretty in the hands of the manual designer.
Why would linking to them look like false page links? All entity pages has been written, so unless they are spelled wrong, they'll definitely be blue - not red.
Although I prefer bolding over code tags, the users just see the entities in the plain, unformated text format and font, if that's what you mean. I've never seen entities as titles or commands - just plain names - but I can't speak that much for other users. I really wish more people would take part in this discussion.
I don't see any changes in the CSS. I've tried updating the page. Perhaps I will have to delete the browser cache for the changes to take effect. --Andreasen 16:16, 21 Sep 2007 (PDT)
You likely just need to Bypass your browser cache.
I misunderstood when you said "we could mark them all in blue", which suggested to me blue text formatting, not linking. Now I understand that you meant -- that entity names could be linked at all times. This seems like an excessive choice and is not common practice for hyperlinking (which is link on first mention, and not thereafter, though I think you know that). The link you provided seems to be targeted at technical writing for printed works, but still reinforces what I have been saying -- technical terms deserve special formatting/emphasis. I never said that gray shading was some type of standard, though I could see how you could have misunderstood my statement. I said visible marking of significant keywords has precedent in technical writing. Beyond that, the exact formatting is not as critical as long as it is consistent.
With the removal of the gray background shading, and short of any more overwhelmingly compelling discussion, this matter has received enough attention and I consider it resolved. Code tags can be used for entities in any new articles and added to existing ones incrementally. --JeffLane 15:42, 22 Sep 2007 (PDT)
Okay, now that my cache has finally been updated, the code tags are not quite as disturbing anymore, so I consider it an acceptable compromise. I'll start using them, though it'll be a lot of pages to change overtime.
Yes, linking to entities consistently would not have been common practice, but still more discreet than the grey highlighting.
The link I provided also seemed to stress not to overdo highlighting.
...but all's well now. Just a little difficult to write down, but at least it looks decent now. --Andreasen 16:20, 22 Sep 2007 (PDT)
Actually, especially looking at the plural forms (for instance "path_tracks"), this is only half as ugly as gray highlighting, but that might just be my opinion. Users, feel free to add your input. --Andreasen 09:12, 23 Sep 2007 (PDT)

Tutorial credit template & guidelines

I have asked Mark if I could port the tutorials from sdknuts to here, and he liked the idea, I have started working on the port but I have a couple of questions/requests

  • Is there a information template like eg template:note, template:tip or template:warning?
  • I think it would be nice if we had a template to give due credit (either to myself or) to the author of the article (eg Mark in this case)
This could be eg Template:Cc-by-sa-3.0
Do we have any templates like this on wiki?
I don't think such template exists, but creating one might work nicely towards giving credit to the original author of the tutorial, particularly in cases where a tutorial is written somewhere outside the VDC and is then ported here (like Mark's SDKNuts tutorials). Tutorials strictly written "inside" the VDC don't really require this information, since you can easily check the history page and find out who created the tutorial.
In general (not simply in tutorials), every uploaded image should follow the image use policy, which states that every image should be uploaded with copyright information (stating that it was either created by the user that's uploading it, or that it belongs to the public domain, or that it is under the GNU Free Documentation License, etc...). It is clear that most people don't follow these guidelines: for example there are loads of Valve games images that aren't clearly marked as such. However, creating a Valve version of the Template:Ubisoft-screenshot wouldn't be strictly necessary, if you at least provide that information when you upload a picture based on one of Valve's works. But of course creating such a template would standardize that and make it easier and quicker to insert that information when someone uploads images based on Valve's works. I would vote for template. Note that the Public Domain template already exists here on the VDC.
Specifically, tutorial images shouldn't be different from any other image, and should give credit to its original author, not necessarily via a template (unless, for example, it is released to the Public Domain, or on other similar situations where a template would be applicable). A simple "Image originally created by <name-here> on <date-here> for <tutorial-title-here>." would be great.
Regarding the question about giving credit on tutorials:
A) Either we're talking about a VDC wiki user that creates and develops a tutorial right here on the wiki, in which case I don't believe he should actually write down any credits (it's really not necessary because you can check the history page and see that he created the tutorial; plus it goes against the nature of a wiki...)
B) A tutorial is ported from another site (preferably with permission!), and in that case my opinion is that you should definitely give credit to the original author.
Guidelines for giving credit (situation B) would be, in my opinion: adding a == Credits == header on the end of the tutorial's article page, whether it be
  1. By use of a formated "credits template", as suggested above (I think it would be the best thing to do, for standardization purposes);
  2. Simply by writing something along the lines of: "This tutorial was originally written by <name-here> on <date-here> at the site <site-here>, and later ported to the VDC." or any other variation (could also be standardized...). --Etset 03:15, 8 Feb 2008 (PST)
I am using this atm (only this image has been updated) image:WiseClips03.jpg
Image for wiseClipped a tutorial ported from sdknuts.net originally created by --wisemx, the image is a screenshot of software copyrighted by Valve." . --Peter [AGHL] 04:54, 8 Feb 2008 (PST)
Sounds perfect :) If a Template:Valve-screenshot template is later created, we can then update images with the template instead. But for the time being that suffices ;) --Etset 05:05, 8 Feb 2008 (PST)

Entity-Specific Templates

Shouldn't these just have their own category page? This page feels like it's just more related to general wiki editing. --4LT 04:00, 29 Jun 2008 (PDT)

Is this a minor edit or major edit?

I've been conflicted on a few occasions from random editing sprees. The conflict is I'm not sure if the edit I made was minor or major. This may be self-explanatory for some, but maybe I can get confirmation. I realize fixing grammar, indentations, links, and other minor things should be marked as minor edits. I've been marking my edits as major when updating {{otherlang}} templates to {{otherlang2}}. Same question with the {{cleanup}} template. Would you consider this a major update or minor? --Mattshu 02:22, 2 March 2011 (UTC)

I usually consider all cleanup templates besides deletion templates to be minor, but honestly I'll sometimes forget to change the checkbox or accidentally set it the wrong way. I don't think it's a big deal; if you're worried about it the edit summary is probably more useful than the major/minor checkbox anyway. Thelonesoldier 04:02, 2 March 2011 (UTC)
I thought the same thing, until I noticed you can filter edits by minor or major. I wasn't sure if there was some set standard anywhere. —Mattshu (Talk) 04:07, 2 March 2011 (UTC)
This is probably the closest we've got: Wikipedia:Help:Minor_edit. EDIT: Well, that says not to mark insertion of tags as minor. Alas and alack. I still personally don't think it's a big deal and honestly when doing a huge series of edits at once it can be a nuisance. *shrug* Thelonesoldier 04:09, 2 March 2011 (UTC)
I always decide on this depending on if it would be a "newsworthy" edit to anyone who is busy enough to filter out the minor edits from being displayed (like the admins probably do). Would that typical guy like to know of my edit, or would he be bothered by it taking up space? --MossyBucket (formerly Andreasen) 06:54, 2 March 2011 (UTC)

Zoomed out

I noticed this article always displays slightly zoomed out, including the wiki bar on the left. I found the revision that started the problem, here, but I can't spot what line is causing the problem. Can anyone else? Thelonesoldier 05:12, 15 March 2011 (UTC)

I don't think it was always like this, was it?—Mattshu (Talk) 03:24, 24 March 2011 (UTC)
That's what I'm saying, the problem started at the revision I linked to above. It doesn't exist in earlier revisions. Thelonesoldier 09:05, 25 March 2011 (UTC)
The spoiler (or endspoiler, for that matter) tag was causing the problem. I wonder if the initiated <div> tag in spoiler does not close when endspoiler is used afterwards? I dono, but for now I removed the example usage, wasn't really priority to see an example anyway. —Mattshu (Talk) 06:59, 28 March 2011 (UTC)
Great, thanks. Thelonesoldier 10:32, 29 March 2011 (UTC)