NetHackWiki talk:Style guide

Formality

So when can we start calling this the official style guide? --ZeroOne 18:34, 27 June 2006 (UTC)

I think that the style guide still needs more work. The style guide makes some assumptions that I fail to understand, and even makes recommendations that I might want to disagree with.

The good thing about this style guide is that when someone wants to know the best way to cite source code in footnotes, or to make pretty tables, or which templates to use, then we can refer them here.

The things that might or might not need changing: (1) the recommendation against ==Introduction== at the start, because maybe we want the TOC at the top of some pages. (2) the Wikipedia-Memory-Alpha-et-cetera "{{disambig}}" feature, which seems unnecessary to me. (3) the general principles which defer to Wikipedia, because this wiki is not part of Wikipedia. (4) possibly something else. --Kernigh 20:24, 27 June 2006 (UTC)

I used {{disambig}} on Fire, which seems appropriate. Wikipedia isn't perfect, but I do think it is, in general, sane enough to be better than nothing. Please do feel free to modify this guide. I hesitated to call this a formal/official style guide, since this wiki is still young and doesn't need an excess of rules just yet. --Jayt 21:59, 28 June 2006 (UTC)

Actually {{disambig}} looks good for pages that need to be like redirects, but to more than one page. Like fire is now. Later maybe someone will write a longer document about fire, and it might not be a "{{disambig}}". Interestingly, there is also a Special:Disambiguations page, but I do not seem to understand it yet. --Kernigh 03:28, 29 June 2006 (UTC)

I added Template:otheruses a few days ago... it seems to be pretty useful. GreyKnight 05:11, 13 August 2006 (UTC)

Templates

Should the "name" section of a template include the item type? For example, potion of object detection lists "potion of object detection" as the item name, and scroll of genocide lists "genocide" as the item name. I'd prefer the latter because the item names can get pretty long and make the template table wide. --Eidolos 23:39, 13 August 2006 (UTC)

I'd prefer the latter too. Perhaps replacing "Name" with "Potion"/"Scroll"/"Wand"/etc. would help. --Jayt 17:43, 14 August 2006 (UTC)

Should "Cost" be renamed to "Base cost" or "Base price"? The internal field name (cost) can obviously stay, but should the output remain an unqualified "Cost"? --Eidolos 23:39, 13 August 2006 (UTC)

I see what you're saying. We don't want to get into the details of buying vs selling prices. Calling it "Base cost" should be enough of a prompt to make the reader think "Hmm, is cost not constant? Perhaps I should look for an article on cost". So yes, I think it should be renamed "Base cost".--Jayt 17:43, 14 August 2006 (UTC)

Or we could keep it as "cost" but make it a link, Cost. --ZeroOne 18:02, 14 August 2006 (UTC)

That too. I don't have a strong preference either way. Perhaps the number ("300zm"), which currently links to Zm, should link to Cost. I think the table would look funny with only one heading being a link. --Jayt 20:23, 14 August 2006 (UTC)

Yeah, that's an option too. Or we could make the rest of the headings links, too. --ZeroOne 20:31, 14 August 2006 (UTC)

[[Aleax]]es vs [[Aleax|Aleaxes]] vs redirect

I think the header says it all, really. [[Aleax]]es is the quickest to type, and is nicer to read in the source. On the other hand, [[Aleax|Aleaxes]] is nicer to read on the page. On the gripping hand, we could just create redirects every time we come across a situation like this. My personal preference is the second one ([[Aleax|Aleaxes]]), but what does everybody else think? GreyKnight 03:04, 19 August 2006 (UTC)

Uh, [[Aleax]]es looks just like [[Aleax|Aleaxes]] to the end user (without looking at the source, which is which? Aleaxes / Aleaxes). I'm all in favor of [[Aleax]]es over the other two. --Eidolos 04:21, 19 August 2006 (UTC)

Hmm, I see mediawiki automatically "gobbles up" the rest of the word in such a case... I hadn't known it did that, so I guess this invalidates that part of the question. GreyKnight 04:29, 19 August 2006 (UTC)

If we must have redirections, I'd only have them for monsters that pluralize with some modification to the base word (such as elf -> elves, or violet fungus -> violet fungi) so we don't have to use the pipe link form at all (just say [[elves]] and it'll redirect you to elf, BUT not for, say, [[quantum mechanics]]). But redirecting only a subset of the plural monster names could lead to problems and would be inconsistent. --Eidolos 04:21, 19 August 2006 (UTC)

May I be so bold to ask why singular names are preferred? It might be usefull to have a plural name when talking about the entire species and singular name when being specific. E.g Liches can be about all 4 liches and Lich about only the lowest L. Elf can be about the race, Elves about the enemy class. Not that it's really important, just got confused by this. --BlackShift 05:42, 29 August 2006 (UTC)

It's mostly a matter of convention, but one good reason for having singular article names is that if the article is at [[orc]], you can easily link to [[orc]] or [[orc]]s , but if the article is at [[orcs]], then you have to use [[orcs|orc]], or a redirect. Again, there's nothing wrong with redirects (other than creating more potential double redirects), but if we are going to choose between singular or plural (and we should, for consistency), then I think singular is best.

Of course there are some naturally plural articles: Liches and Elves might be good. If so, Lich should redirect to Liches as the whole point of Liches would be to collect all relevant information in one place. For the Elf race, we should have Elf (race). --Jayt 11:41, 29 August 2006 (UTC)

Variants

SLASH'EM (old section)

However, this is a NetHack wiki, so consider twice whether SLASH'EM-only articles are worth creating.

I think they are: (a) SLASH'EM is not just another roguelike or hacklike - it's a close fork, meaning code occasionally comes back to vanilla NetHack (the wizard patch being the major example) and this symbiotic relationship is acknowledged in the NetHack souce, (b) SLASH'EM is considered on-topic in RGRN, so why not here?, (c) people are going to add SLASH'EM articles anyway (it's already happened), so they may as well do it in a way that minimises the interference with vanilla articles. --Jayt 10:58, 1 September 2006 (UTC)

OK, as long as the emphasis is still on creating articles about vanilla NetHack. :) --ZeroOne 16:17, 1 September 2006 (UTC)

Yes, of course :-) This wiki's primary objective should be to document NetHack, and NetHack should always take priority when there is potential for confusion. --Jayt 16:04, 2 September 2006 (UTC)

2018 revisiting

12 years later, and the variant scene has exploded far beyond SLASH'EM. But the wiki still hasn't settled on an appropriate set of rules for handling all these variants. I swear that I've participated in some previous discussion on the subject, but I can't seem to find it either here or in IRC logs. Oh well.

To address the above discussion, yes, it's clear by now that the wiki is THE definitive source for NetHack-related information, more so than any one person writing up spoilers, and variants are not so separate from NetHack that their documentation needs to go live somewhere else. For the most part, this is fine since variant specific stuff can go on its own pages (e.g. Air dash), or if necessary "Foo (Variant X)" and "Foo (Variant Y)" pages, or have a bunch of pages as subpages of the variant like dNetHack does. The main issue is how to handle variant discussion of some thing on a vanilla page about that thing.

There are four offenders I've noticed, thankfully none of them very common:

1. Multiple variants change something and they all do so differently, so the page starts to obtain multiple level-two sections (with the == syntax) all describing how that variant changes something. The problem is that the table of contents quickly becomes unwieldy after even two variants have had their say.
2. A variant section grows out of control and becomes a substantial fraction of the page. A good example of this would be the SLASH'EM Valkyrie strategy guide, which up until recently lived on the Valkyrie page and was half as large as the vanilla one until it was chopped out into its own page.
3. Variant information is scattered into the regular sections of the article, either as subsections or sometimes as one-line sentences. This makes the information both easier to miss and more muddled for vanilla readers.
4. A variant makes a small or insubstantial change to something, and the page for that thing is given a variant section containing one sentence or barely relevant chunk of strategy which the page doesn't really need.

With that in mind, here's my proposal for dealing with variant information on vanilla pages (much of which is already followed, but we're talking about putting it in the style guide):

• If there is a substantial change made by the variant with a notable impact on strategy, then it's fair game to put on the page; if not, just put it on the main page for that variant.
• All variant information should go in a level-two ==Variants== section near the bottom of the page (but above the encyclopedia entry), which should be broken up into subsections for each relevant variant. Avoid having chunks of variant information in the main sections of the page, even if it seems to be organized better into those sections.
  • The one exception to this rule is if there is only one variant, in which case the level-two section can just be titled after that variant; e.g. ==SLASH'EM== or ==UnNetHack==. But if a second variant is ever added, both variants should become level-three sections under a Variants section.
• There should be no level-four or lower subsections, to keep the table of contents clean. If an editor feels that the variant section needs multiple subsections, then that may indicate that it's getting long enough to warrant its own page.
• Variant articles that have or are moved to their own pages can be linked from the main page in the top level ==Variants== section (that is, it doesn't need a whole subsection just for one link to the main page).

--Phol ende wodan (talk) 10:37, 18 August 2018 (UTC)

This seems to be the standard for several pages that have information on multiple variants, and should be on the style guide. Luxidream (talk) 14:02, 18 August 2018 (UTC)

I also completely agree. Admittedly I did it wrong in the early days of SLEX where I scattered SLEX-specific stuff into main articles, but if I stumble over that now, I'll move it in the variants section (and I also agree that there should only be one "Variants" section if an article mentions several) :) A bunch of SLEX-specific pages are in my userspace specifically to avoid clogging up the rest of the wiki, too. --Bluescreenofdeath (talk) 14:09, 18 August 2018 (UTC)

Added it to the style guide. --Phol ende wodan (talk) 17:47, 29 August 2018 (UTC)

Variants seems to have been left out of the list of standard sections; added. Everyone OK with this? It's a de-facto standard at this point in any event... -Actual-nh (talk) 03:43, 2 April 2021 (UTC)

Subpage nomenclature

Related issue: it would be nice to standardize the way variants name and organize any subpages they might have. This has nothing to do with the above section - I don't propose changing what we already have for variant info on main-space pages, just the names of subpages for a specific variant. There are several forms bouncing around currently:

• Feature (Variant)
• Variant Feature
• Variant/Feature
• Feature/Variant (e.g. Valkyrie/SLASH'EM)
• User:VariantAuthor/Variant/Feature
• Variant:Feature (no variant currently does this - using a namespace for that variant)

Ideally, we would decide on a single format to use, add it to the style guide, and move all variants' subpages to fit that standard.

Personally, I favor Variant/Feature, but I think the "Feature (Variant)" is the most commonly used right now. However, "Feature (Variant)" feels ickier and more bloated to me.

I'd particularly like other variant authors to chime in on this. --Phol ende wodan (talk) 01:39, 3 October 2019 (UTC)

Suggested new section - Internals

For source-divers, it can be useful to know which code macro/function is related to which function. This is not always clear – e.g. M2_STALK is the macro that determines whether monsters follow.

On the other hand, putting this in the main body of the article could be extremely distracting for the many wiki readers who do not source dive.

I have started adding an "Internals" section to provide such information, where I believe it may be useful. This helps source-divers reconcile the code to the spoilers without unduly distracting non-source-divers. This would be in addition to annotating the source itself.

I propose this is added to the style guide.

--Rogerb-on-NAO 20:51, 15 July 2008 (UTC)

agreed. -Tjr 22:31, February 19, 2010 (UTC)

agreed. Besides source divers, this helps wiki editors when reviewing or updating an article. Furey (talk) 13:22, 13 June 2024 (UTC)

{{subst:unsigned}}

Why does this say {{unsigned}} and {{unsigned2}} must be substituted? IMHO this makes the talk pages rather less readable; also there is no technical requirement (as in, without subst: they would not work) forcing them to be substituted (in fact, most uses of them I've observed don't use subst: for them, but still work fine; see also Special:WhatLinksHere/Template:Unsigned).

wikipedia:Wikipedia:Substitution mentions that templates in signatures (which seem similar to {{unsigned}} in a way, as it basically acts as a replacement signature) can cause server strain when updated; I don't know whether this applies to a wiki like NetHackWiki (which doesn't have nearly as many pages and users as Wikipedia), but I wonder why Template:Unsigned would need to be changed at all. --Bcode (talk) 03:53, 13 November 2012 (UTC)

These two Wikipedia articles say that they should always be substituted: Wikipedia:Template:Unsigned and Wikipedia:WP:UNSIGNED. I do not know the reasoning. --99.239.147.0 04:38, 13 November 2012 (UTC)

That's Wikipedia, though. What is valid for them might not apply here, which is why I ask here. (FWIW, the page about substitutions also seems to say it is debatable whether this template should be substituted. Obviously, current policy there is to substitute it, though.) --Bcode (talk) 04:44, 13 November 2012 (UTC)

sigs

are there any guidelines as to what may or may not be in a user's sig? i would say (and who am i?) that the purpose of a sig should be to discretely identify a user in a way that is useful to the reader. if a user were to, say, use colour in such a way that it obscured the text (picking as a random example black on dark purple) would there be any sanction? or if they included a dumb joke clever reference instead of their username would someone with authority object? i include some of the guidelines from Wikipedia, which some some editors think is pretty good.

When customizing your signature, please keep the following in mind: A distracting, confusing, or otherwise unsuitable signature may adversely affect other users. For example, some editors find that long formatting disrupts discourse on talk pages, or makes working in the edit window more difficult. Complicated signatures contain a lot of code ("markup") that is revealed in the edit window, and can take up unnecessary amounts of narrative space, which can make both reading and editing harder. The WMF's "Flow" project (which will replace the current Wikipedia talk page system) probably won't support custom signature formatting (details). Your signature must not blink, scroll, or otherwise inconvenience or annoy other editors.

• Avoid markup such as <big> and <font size="3">(or more) tags (which produce big text), or line breaks (<br /> tags), since they disrupt the way that surrounding text displays. The use of non-breaking spaces to ensure that the signature displays on one line is recommended.
• Be sparing with superscript or subscript. In some cases, this type of script can also affect the way that surrounding text is displayed.
• Do not make your signature so small that it is difficult to read.
• As some users have vision problems, be sparing with color. If you insist on using different colors in your signature, please ensure that the result will be readable by people with color blindness, defective color vision, and other visual disabilities.
• Do not include horizontal rules (----).

--194.116.198.185 13:21, 24 January 2014 (UTC)

Personally I'd go even further and ban colors and font tricks in sigs altogether. Also I don't get why you'd want to change your login name to some other text in your sig... --paxed (talk) 13:47, 24 January 2014 (UTC)

I agree with paxed in spirit. But I'm a bit reluctant to make a lot of rules that should be common sense. --Tjr (talk) 19:55, 24 January 2014 (UTC)

Oxford comma

Continuing the discussion on American versus British (international) English, I'm curious if there's a rule on the use of the Oxford comma on this wiki. I ask because I'm noticing a lot of people omit the comma (by the international convention) and I've already corrected it a few times as part of larger grammar correction edits. I ask because, while I'm not going to go out of my way to correct the omitted comma anyway, I think it could be annoying to other users if grammar edits continuously remove or replace a comma in an article.

It seems reasonable to me to assume that the American convention would be ideal, since NetHack is a game largely produced in America, but its international appeal brings this reasoning into question. I should point out that the Wikipedia style guide suggests that the Oxford comma be used or omitted on a case-by-case basis to avoid ambiguity. Any thoughts? Crawldragon (talk|nao|wiki) 16:33, 19 October 2014 (UTC)

I'd argue the Oxford comma as matter of style isn't something you'd need to "correct" either way, except to conform with style guidelines, the absence of which you did seem to correctly point out.

IMHO, it probably needs no special rule, either: keep it however it is in current articles unless adjusting it helps resolve ambiguity. It's not as if a little inconsistency here and there could ruin the world :) —bcode ^{talk | mail} 17:14, 19 October 2014 (UTC)

Beatitude vs "BUC status"

We have an English word "beatitude" that describes the blessed-ness of an object. Many places in the wiki use beatitude, many use "BUC status." There should perhaps be a consistent use? I would prefer the word, for several reasons:

1. "Beatitude" is an actual word, already present in our language.
2. "BUC status" is fairly cumbersome to both read and speak.
3. We might expand the vocabulary of people by one word if we use it more often.
4. "Beatitude" is a really cool word to use.

--lilmouse

Personally I vastly favor "beatitude" as well. As devil's advocate, there are two arguments in favor of BUC that I can see: first, the minor one that technically its definition only means blessedness, and could be ambiguous about curses; and second, the term "BUC-identified" is way more prevalent than anything else. "Beatitude-identified" is clunkier, "bknown" only makes sense if you source dive, "curse-tested" is ambiguous since it can mean just cursed/noncursed, and I can't think of any other contenders. I was recently making some edits to the BUC page and thinking if it would be worth it to move it to Beatitude and set up the redirect from BUC, but held off because the various BUC-identifieds in the page wouldn't have made that much sense otherwise.

Maybe that is the best thing to do, to swap the page and the redirect, and have the de facto standard be "beatitude" for most uses and "BUC-identified" where appropriate? (In a lot of cases a sentence containing it could probably be reworded anyway.) --Phol ende wodan (talk) 22:15, 17 August 2018 (UTC)

Gender style guidelines: "he or she" vs "they"

There are articles which sometimes fail to keep gender neutral language (often using "he"). We should specify either using "he or she" in all cases or use the singular "they."

Wikipedia does not have a preference (but does require using either "he or she" or "they" and not "he") - https://en.wikipedia.org/wiki/Wikipedia:Gender-neutral_language

I would prefer using "they"/etc.

1. It has a history of use as a singular gender neutral pronoun (as noted in https://www.merriam-webster.com/words-at-play/singular-nonbinary-they). (Given players in NetHack have either a masculine or feminine gender, using "they" as a non-binary pronoun isn't important to the game.)
2. It's widely used in modern language and easy for people to use.
3. It's a lot shorter to type than "he or she" and less cumbersome.

Namespaces

In the namespace section I would suggest adding some lines on Nethack-tangential content. It's recommended this be kept out of the main namespace for various reasons, one being that everything there can be picked up by Special:Random. As a starting point for content important to the User but without an obvious home in the wiki, it's suggested to create pages using the name format User:Foo/Your_Page_Here. Wikid (talk) 08:32, 6 August 2019 (UTC)

"Luck" capitalization

§ Capitalization says the following:

"Always use 'Luck' when referring to the in-game attribute; use 'luck' to refer to good RNG or other 'out-of-game' luck. Conversely, do not capitalize things that the game does not capitalize and treats like common nouns ..."

Self-contradiction in record time. The game refers to the in-game attribute using a lowercase 'l' in every instance. Some examples:

• "You have extra luck."
• "Kill a unicorn of your color and you kill your luck."
• "Some allowances are permitted in case the player gets stuck; however, they will lower your luck." (from the Guidebook)

In an exhaustive search of the 3.6.6 source code, the only instances I found of capital-L "Luck" were the internal variable name used to reference the attribute (which should be ignored like all other variable names—we don't capitalize "hallucination") and a handful of code comments (which could just as easily be referring to the variable name, and there are far more comments with lowercase 'l').

So, I motion that the stipulation for capitalizing "luck" be removed. — Ardub23 (talk) 23:08, 9 June 2020 (UTC)

I would argue that Luck is an exception to the general "don't capitalize things that are used as common nouns in-game" rule. The Luck/luck distinction for in-game versus out-of-game luck is well established and used everywhere on the wiki; it's the most concise and clearest visual shorthand for distinguishing the two. In addition, capitalizing Luck is consistent with the style guide saying "In general, if the game or the source code capitalizes something, it should be capitalized on this wiki."

There's a case to be made for amending the sentence in the style guide about not capitalizing things to avoid contradictions. Perhaps to "With these exceptions, do not capitalize..." or "Conversely, do not capitalize things that the game or the source code do not capitalize..." --Phol ende wodan (talk) 23:51, 9 June 2020 (UTC)

The source code capitalizes "Luck" only in the same way it capitalizes "Hallucination", "Stunned", and "Race"—i.e. only in internal code not visible to the player. The wiki doesn't capitalize those terms. If we were to base capitalization on the source code (which I strongly oppose), then we'd have to deal with the fact that, apart from the variable name Luck, most of the code's references to the stat are lowercase. (Not all, but a great majority.)

As for the distinction between the in-game stat and out-of-game fortune, this is always clear from the context. Out-of-game luck is infrequently mentioned on the wiki in the first place, and almost never using any variation of the word luck. (There are loads of other ways to refer to the results of RNG.) No human being who reads "high luck" or "luck penalty" would even consider that general good fortune might be the topic at hand. We've never needed a distinction between in-game "Confusion" and out-of-game befuddlement, or between in-game "Wisdom" and out-of-game acumen. There are hundreds more words where such a distinction could be made; why is luck the only one that's special?

And I hate to be the contrarian, but it's downright inaccurate to say that the capitalization is "well established". It's splotchy at the very best. Even the article on the subject has around three times as many instances of "luck" as of "Luck", discounting ones where the choice of capitalization is otherwise unambiguous. Removing the stipulation would cause far less of an upset than actually following it. — Ardub23 (talk) 04:07, 10 June 2020 (UTC)

I am reasonably sure the Luck/luck convention is older than the Wiki, having been common on rgrn. I don't think it is always clear merely from context which is meant; I have often wanted to refer to the whims of the RNG "luck" and Luck in the same piece of writing about the game. I think it would be a mistake to abandon this convention. Pinkbeast (talk) 05:06, 10 June 2020 (UTC)

People have been mis-capitalizing things that are lowercase in-game for as long as doing so has been possible, but that doesn't mean the wiki should too. Can you give an example from the wiki of a sentence that benefits from the distinction? (I've seen one or two worsened by it, with ugly constructions like "unLucky" in place of more sensible ones like "low luck".) — Ardub23 (talk) 08:50, 10 June 2020 (UTC)

Adding a guideline on how to format the first sentence of articles

What would people think about codifying the Wikipedia style guidelines at https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#Format_of_the_first_sentence and https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#First_sentence in this style guide? They're mostly followed pretty widely on this wiki, but there are some scattered first sentences here which don't (e.g. spellbook of finger of death, wet). --Phol ende wodan (talk) 00:51, 27 June 2020 (UTC)

Support. A great majority of Wikipedia's guidelines are well thought-out and useful for any informational wiki, and this is no exception. (My rule of thumb is to follow Wikipedia's guidelines unless there's a half-decent reason not to.) The most important section in an article is the lead section, and the most important sentence is the first one. So it's a good idea for it to have the most important information about the article subject presented in a clear, straightforward way. For instance, the spellbook of finger of death article's lead section should mention that the spell creates a death ray, which instakills most creatures it hits. — Ardub23 (talk) 21:11, 30 June 2020 (UTC)

Support The last time I checked, Wikipedia had a style guide that I'd prefer over many "professional" ones. -Actual-nh (talk) 00:15, 3 February 2021 (UTC)

Consider the usefulness before adding text?

I wonder if we could add something to general principles about trying to only add useful information to the wiki. One doesn't need to add sentences to the wiki every time one learns or experiences something new.

In many cases, the information already exists. Reiterating it on the same page is unnecessary, only increasing the length of the article, and repeating the info on multiple related pages means more work keeping them updated as the game changes.

In some cases, the information added is just plain incorrect; for instance, if I use a wand of death and it fails to kill a monster, I could run to the wiki and state that a given monster is immune to death rays. Wow, important strategy tip! But if that's not already on the wiki, I am probably wrong! The real cause may be that the monster was wearing a cloak of MR, or that I mislabeled the wand.

At this point, I should check the source code, use wizmode to test more wands of death out on the same monster, or confer with experienced players. It's not helpful to anyone if I go around writing strategy articles from a sample size of "the most recent game that I just played".

In short, I suggest we add a few new entries to NetHackWiki:Style_guide#General_principles:

• Add new information to the wiki only from a place of certainty and knowledge
  • If you don't have certainty, acquire it from wizmode tests, source code, or community consensus
• Don't bloat the word count
  • Don't belabor the point by restating information that already exists
  • Don't spend several paragraphs drilling into a corner-case scenario that new players need not realistically concern themselves with

Testbutt (talk) 04:53, 2 February 2021 (UTC)

Support. With regard to duplication, a statement of - to emphasize the possibility of the info already being present, even if not noticed by the writer - "check to see if it is someplace else" (and perhaps something about possible movement of info or that putting in a link to it may be all that is needed)? -Actual-nh (talk) 00:19, 3 February 2021 (UTC)

Support. However, there are still some situations where it's difficult for a beginner to know if something is a corner case or not. For example, the case where you fall into a pit with a cockatrice corpse in the Sanctum is not uncommon, because there is a guaranteed spiked pit. --Luxidream (talk) 19:44, 4 February 2021 (UTC)

Support and concurring with Luxidream above, though I also personally feel like not duplicating information (along with most of what you've suggest) should be standard practice for a wiki anyway. --Umbire the Phantom (talk) 04:30, 5 February 2021 (UTC)

Abstain. I would not mind if the style guide said: don't restate information that already exists, and read source code or do wiztests before editing. However I do not want a "certainty and knowledge" type of wording, because that is likely to scare off new editors. If you want to guide new editors towards talk pages that would be cool, though. Furey (talk) 13:31, 13 June 2024 (UTC)

Should similar monsters of the same class be on the same page or on different pages?

There is some dissent about whether to group together similar monsters on the same page. Compare Naga, which has all of its monsters on the same page, with Dragon, which has separate pages for each monster.

I'm in favor of grouping together similar monsters, because often, monsters aren't differentiated enough to merit their own strategy pages. For example, blue dragon could probably be included in a general page about dragons with a note that its breath weapon can destroy wands and rings. --Luxidream (talk) 06:50, 3 June 2021 (UTC)

Support. Talked this out on IRC with Luxi and aoei, and while I tend to do things differently personally (source: guy who split the dragon pages), I can see an argument for consolidating information in this manner somewhat, enough that I'm willing to give it a go - I'm experimenting with Simpletabs atm to see how well it'd play out. --Umbire the Phantom (talk) 07:00, 3 June 2021 (UTC)

Riders now uses Simpletabs. Now the links on Death (a disambiguation page), Pestilence (a redirection page), and Famine (a redirection page) resolve to the top of Riders, not to the individual monsters. As a reader, when I search for "Pestilence", I want to read about Pestilence, not start at the top of the Riders every time. I tried adding tags to the Riders article but that did not work. Furey (talk)

Yeah, I'm aware - that was back when I was willing to try the "keep multiple monsters on a single article", a long while ago. Then I decided "this is stupid" and have been working on splitting stuff ever since (and of course, there's a sheer quantity of it). I can earmark the Riders for a split into proper monster articles to be done today/this weekend, I suppose. --Umbire the Phantom (talk) 15:43, 9 June 2024 (UTC)

Sounds good. I'm working in a sandbox at the moment anyways, so you may likely finish before I do. Furey (talk) 15:54, 9 June 2024 (UTC)

Squared away finally. --Umbire the Phantom (talk) 07:38, 9 October 2024 (UTC)

Capitalization

So, I remember talking to Ardub about the subject earlier this year, and he mentioned that it felt like (to paraphrase) an arbitrary exception that can be a bit needlessly confusing. It's come up again with cathartes and a few other people, so at minimum I think it's worth formally bringing up here. What're your thoughts on this text convention, and for those who dislike it, what would you replace it with (if anything)? --Umbire the Phantom (talk) 02:45, 30 March 2024 (UTC)

I think it makes sense to drop the the capitalization. The overwhelming majority of uses of the word "luck" on NetHackWiki are about the game mechanic, and having to capitalize "Luck" everywhere seems strange. In addition, the game itself doesn't capitalize "luck", and uses the terms "lucky", "unlucky", "good luck", and "bad luck" in enlightenment messages. I think we should replace the capitalization policy with another one specifically about the word "luck" though.

Proposal: On NetHackWiki, the word "luck" should always refer to the game mechanic, unless it is clear from the context that it refers to informal luck (e.g. "lucky RNG rolls") -- and even then, that should be discouraged in favor of synonyms ("fortunate", "hapless", etc.), or rewritten altogether.

Don't write something like this:

• If you are unlucky, you may encounter a chameleon imitating an arch-lich while solving the final level of Sokoban.

Instead do something like this:

• There is a small chance that you will encounter a chameleon imitating an arch-lich while solving the final level of Sokoban.

On IRC or other places where informal discussion happens, players might use "luck" to refer to bad RNG rolls, but we're NetHackWiki and can take time to carefully write things to avoid ambiguity. Cathartes (talk) 16:07, 30 March 2024 (UTC)

My opinion hasn't changed since I brought this up before on this talk page. The arguments I saw then in favor of keeping the capitalization are that the source code's Luck macro is capitalized, and that capitalizing it could theoretically resolve ambiguity. The source code argument is pretty clearly an impromptu justification for the rule; if it were really the reason, we'd be capitalizing things like Stunned and Race too. And the ambiguity argument is unsubstantiated: I've still seen no evidence of the capitalization actually helping with ambiguity on the wiki. I have, however, seen it lead to errors in quoting game messages.

Making an exception by capitalizing 'luck' creates problems, and the one it purports to solve is vanishingly rare if it exists at all. I'm fine with Cathartes's suggestion if it'll appease the people who imagine that ambiguity is a problem. — Ardub23 (talk) 08:05, 2 April 2024 (UTC)

I searched for the word "unlucky" and got some results like these:

• Beartrap This is a trap that will clamp onto any monster or adventurer unlucky enough to stumble onto it, dealing 2d4 damage.
• Helm of opposite alignment Erinyes are significantly buffed to further resemble their inspirations in the Furies: their ability to appear upon a character wearing the helm represents a major hazard to both stronger characters that actively plan to use the helm and unlucky ones that put on the non-cursed and unidentified helm.
• Wizard of Yendor pity the unlucky Caveman who has the Sceptre of Might stolen with no other source of MR ...

Current rule: the reader sees that the word is uncapitalizaed, so it refers to out-of-game luck. IMHO this does not work very well. Cathartes proposed rule: these sentences should be discouraged or forbidden, because they are likely to confuse some readers. I agree with Cathartes. And I can go change some of these myself. unlucky -> unfortunate, changes coming up. Furey (talk) 11:36, 8 June 2024 (UTC)

Fine by be. --Umbire the Phantom (talk) 15:43, 9 June 2024 (UTC)

After over two months, there's been no objection to Cathartes's proposal. Shall we go ahead and incorporate it into the style guide? Since the proposed replacement guideline isn't about capitalization, I think it'd be most appropriate to put it under § Tone, possibly in a new subsection. — Ardub23 (talk) 00:39, 14 June 2024 (UTC)

I support cathartes proposal. I did a pass over "unlucky", but there are still plenty of changes that say "lucky", which I am going to leave. I encourage those who care to join in and make some edits. You don't need to wait for the style guide to change if you think certain sentences are confusing. Furey (talk) 07:55, 14 June 2024 (UTC)

Right. I'll consider the matter settled and try to formalize it in the style guide ASAP while working out exactly how else to update said guide to reflect current editing standards - the fewer "unspoken rules", the better in this case to prevent future miscommunications. --Umbire the Phantom (talk) 04:15, 19 June 2024 (UTC)

Capitalization II

There's been no action on Cathartes' proposal, so I am going to make a specific proposal:

• Section "capitalization". Delete this sentence: Always use "Luck" when referring to the in-game attribute; use "luck" to refer to good RNG or other "out-of-game" luck.

That's it. I just want this specific sentence gone. It's a kludge, people don't follow it.

Opinions and votes please? Furey (talk) 04:02, 19 June 2024 (UTC)

Spotted and noted, I don't think there'll be much need to discuss it since it's basically the logical conclusion of the above agreement that was reached - said agreement will be acted on shortly, since I'll start editing the style guide to reflect agreed-upon suggestions, additional guidelines and hard rules. --Umbire the Phantom (talk) 04:06, 19 June 2024 (UTC)

Futureproofing and source references

So Furey mentioned a proposal about dealing with source code references, which prompted me to consider making this post.

The gist of it is: we need to figure out a method to make sure we don't have a repeat of what happened when 3.6 was released, with the inevitable formal release of 3.7. The {{upcoming}} template is doing a decent amount of work in that regard, and the current active contributor base is already pretty good about specifying versions in source references, so I didn't see the need for a proposal at first - but after thinking it over, I'm not only fine with a proposal being made, I'm going to make one myself.

In light of upcoming versions and the "inherited" situation where many aspects of the wiki's articles and templates were created with the assumption that 3.4.3 would be latest stable for the foreseeable future, I want to know: how exactly should the wiki as a whole deal with this situation? Obviously there need to be several critical updates made to the Style Guide and other critical pages (which is also in progress, with thanks in part to Furey as above), but I think we should have as directed of a roadmap for the path forward, and I'd like all users that see this, however active they are normally, to pitch in on where we should go. --Umbire the Phantom (talk) 04:07, 22 June 2024 (UTC)

My vision is: Every reference to source code must explicitly specify a version number. But we can't get there from here in a month. Maybe we can't get there at all before 3.7.0 releases. However, we can do a lot of things, like start purging the facilites that cannot even accommodate explicit version numbers, like all those hidden-version redirection pages like allmain.c. And talk about the function redirection pages, we can find out if any pages use them, but we cannot find out if any editors use them. I don't, I find functions by having tabs open with 3.4.3 include/extern.h and 3.6.7 include/extern.h. But maybe others do. In other words, there's a lot we can do just with current facilities. If people want to go this way, which I hope we do. Furey (talk) 04:29, 22 June 2024 (UTC)

I agree that every source code reference should specify a version number. Citations using file redirects are the most problematic since there's no easy way to determine the intended version (at least an omitted version in {{refsrc}} is documented to be 3.4.3). I don't think any active editors use them anymore, since those were last updated for 3.6.1. I recommend deprecating usage of {{reffunc}} and {{function}}. Cathartes (talk) 00:47, 24 June 2024 (UTC)

I have a proposal at https://nethackwiki.com/wiki/NetHackWiki:Community_Portal#Proposal_to_eliminate_bare_filename_redirectors_such_as_.5B.5BDungeon.h.5D.5D_.2C_.5B.5Battrib.c.5D.5D.2C_and_.5B.5BArch.des.5D.5D for anyone interested. Furey (talk) 01:08, 24 June 2024 (UTC)

Looking at Template:Function

Expert eyeballs needed at Template talk:Function. Am I reading it right? If so, maybe style guide should say something about not using it. Furey (talk) 12:32, 27 June 2024 (UTC)

No eyeballs received. Oh well.

I needed to fix a lot of "Function" references in the source code annotations for NetHack 3.4.3 source. They were resolving to 3.6.1 source. So I went ahead and created Template:Function_343. I may create "Function_361" as well. It's impossible to make a "Function_367" because NetHackWiki does not have 3.6.7 source code and GitHub has no way (that I can find) to refer to function names in a URL fragment. In 3.6.7 articles, I've been changing "Function" to "Refsrc" with nethack=3.6.7 and comment="function foo". Furey (talk) 13:35, 4 July 2024 (UTC)

Capitalization of 'the' in artifact names

I've recently seen some articles capitalize the word the in the names of artifacts, such as The Sceptre of Might. I believe that the style guide should advise against capitalizing the in cases like that.

That style of capitalization appears in-game only when the artifact is unidentified (you'll see "a mace named The Sceptre of Might" for instance). The word the is not particularly capitalized in any other context, including all quest dialogue and related text. ("Shaman Karnov glimpses the Sceptre of Might in your possession.")

The name on an artifact item is a string that kind of exists in a vacuum, whereas quest dialogue is full sentences of running text—much more like what we have on the wiki. That, coupled with the fact that non-capitalized in-game uses greatly outnumber the capitalized one, mean that the convention of following the game's usage favors non-capitalization.

Something like this might be added to § Capitalization:

Do not capitalize articles like the after the first word in a sentence, even in proper names like those of artifacts. The Sceptre of Might, for instance, should be styled as "the Sceptre of Might" mid-sentence. However, the first word in the title of a creative work, such as Terry Pratchett's The Light Fantastic, should always be capitalized.

See also: Wikipedia:Manual of Style/Capital letters § Capitalization of The

— Ardub23 (talk) 05:03, 16 October 2024 (UTC)