Fallout Wiki
Advertisement
Fallout Wiki
Forums: Index > Wiki discussion > Proposal: More Bug Policy Revisions


Overview[]

So something recently was brought to my attention after a rather unexpected edit war: apparently our content policy with regards to bugs limits the listing of bugs to only one article, period. I understand the idea behind this in the broader scope, but for certain cases this leads to a rather undesired side-effect, namely the partial obscuring of critical game bugs.

Most bugs within the Fallout games are what you would call "trivial", or at least such that they do not have a major (or sometimes any) impact on actual gameplay. However, there are a small number which can be considered "show stoppers", things that if you run afoul of them your game will be dramatically impacted. One type is more of a useful bit of trivia to know, while the other is something that can literally make or break a playthrough. The current bug policy treats both types exactly the same, and in effect limiting the availability of knowledge on these critical bugs unless someone happens to realize Bug A relating to NPC B will only be listed in Quest Article C because it is tangentially related to that quest.

To put it in other words, I cannot think of any good reason that potentially game-breaking bugs shouldn't be mentioned in multiple places. Obscuring this information for the sake of organization helps nobody. Yukichigai (talk) 20:39, March 14, 2013 (UTC)

Proposal[]

I propose a slight alteration to our current policy on bugs. While I agree that most bugs do not warrant inclusion in every single article they're related to, I propose that serious or game-altering bugs be allowed to be listed on multiple articles. This could be accomplished easily using transclusion, which would ensure the bugs remain consistent across the multiple articles they would appear in.

What defines "game-altering" or "serious" is something I have difficulty putting into words, but the closest I can get is "anything which would seriously or permanently impact a game in progress." It's one of those maddening "common sense" things that you can't quite put into words, but I think you know what I mean. -- Yukichigai (talk) 20:39, March 14, 2013 (UTC)

Comments[]

I see no one has commented on this for some reason, so I mine as well give it a shot. This wiki has a bit of a love-hate relationship when it comes to bugs. We've had a project for bugs, we've had to make up multiple templates to help sort bugs and we have the number of problems with false bugs or things that are not even bugs being added. I've seen multiple people asking why we even list bugs, with the only argument against their removal being that they bring in viewers. If this were to become a policy we would need a better definition of what is and isn't serious than what's common sense. Paladin117>>iff bored; 01:11, April 4, 2013 (UTC)

The reason I didn't comment on this is that it needs to be discussed before it becomes a proposal. And this isn't even really a proposal, just a statement that something should be changed. FollowersApocalypseLogonihil novi sub sole 02:35, April 4, 2013 (UTC)
I'm honestly having trouble seeing what the difference is between the two. Seriously. If I need to add a bit more to this to make it "officially a proposal" then please let me know what it is. -- Yukichigai (talk) 02:30, April 27, 2013 (UTC)

I'm a bug skeptic. However it may be possible to use the transclusion template to minimise the work. Have a Bug heading, and then use transclusion to repeat the same bugs on the quest. This way they only need to be updated and maintained on the location. However, whilst this will eliminate maintenence on the quest pages, it may mean a few bugs that arent linked to the quest but in the location. Agent c (talk) 03:03, April 4, 2013 (UTC)

A little creative sorting of bugs on the parent pages should take care of that. Fortunately the game-bending bugs tend to be spaced out, not crammed together into one location. For the most part I think we'd be transcluding one or two bugs at a time if we did this. -- Yukichigai (talk) 02:30, April 27, 2013 (UTC)

You can't expect everyone to have the same definition of "game-altering" or "game-breaking". Thus, you cannot impose an arbitrary definition for this purpose. As such, any change will be extremely difficult if not impossible to implement/enforce, not to mention it will be in violation of FW:ORG as it stands. --Skire (talk) 23:39, April 4, 2013 (UTC)

Being a violation of policy is not much of an argument since this is a proposal to change policy.
As for the rest, there needs to be a discussion a definition for "game-altering"; I don't know why you thought I was suggesting we use an arbitrary definition. The simplest definition I can think of is "any effect which will permanently alter the player's gameplay experience, including the ability to complete quests or attain rewards." A five-second visual bug wouldn't fall into that definition, but a quest becoming unable to be completed because you talked to NPCs in the wrong order would. -- Yukichigai (talk) 02:30, April 27, 2013 (UTC)
I for one would like to see specific examples of what you would define as "game altering" and "game breaking" bugs so we can understand what you are basing the difference between the two on. Please use some examples from articles.--Kingclyde (talk) 19:21, April 29, 2013 (UTC)

I did a quick review of our bug policy, under the header where do bugs belong and I believe that most of the content criteria is correct. The first rule for instance defines that a bug should stay with the bugged entity (i.e. a NPC, weapon or quest). Makes sense to me. If I'm understanding your "game altering" theory correctly, if I don't talk to a NPC in the correct order as exampled above, that would cause a quest problem thus the bug report would belong on the quest page only. Putting it on the NPC's page and then on the general bug page would clutter both pages with redundant and unneeded duplications. Now if this bug was in the main quest and became a "game breaking" bug it would still be in the quest page and below it the fix would be listed to reload to a previous save and to follow the quest stages properly. Simple. As for the final rule in the bug policy under the header where do bugs belong, the applies as well in this situation. I simply can see no need to duplicate the bugs a stick them everywhere.--Kingclyde (talk) 21:22, April 29, 2013 (UTC)

Okay, take the "talk to the NPCs in the wrong order" example to the real situation it's based on: the Gomorrah receptionist and the quests How Little We Know and For the Republic, Part 2. During one stage of FtR2 you are asked to talk to someone named Liza O'Malley about a situation at the Gomorrah. If you do that, you are then asked to speak to the receptionist, which in turn starts the quest How Little We Know. However, if you skip Liza and talk to the receptionist, How Little We Know becomes bugged and cannot be completed, and in some situations can cause FtR2 to get locked as well. Keep in mind that until you talk to Liza there is NO indication that talking to the receptionist is "jumping ahead in the quest" or even related to that quest, and depending on the circumstances you can even get the receptionist's quest-breaking dialog before FtR2 even mentions the Gomorrah at all.
That is the kind of thing I'm talking about: a bug where it may be related to the quest, but can be triggered by doing something that a reasonable person wouldn't think is related to the quest, and thus wouldn't think to check the quest page for any bugs relating to their current course of action. -- Yukichigai (talk) 01:17, May 26, 2013 (UTC)
Advertisement