We've Moved! Just as Gamepedia has joined forces with Fandom, this wiki had joined forces with our Fandom equivalent. The wiki has been archived and we ask that readers and editors move to the now combined wiki on Fandom. Click to go to the new wiki.

Forum:Standardized terminals layout - Pt.II

From The Vault - Fallout Wiki
Jump to: navigation, search
Forums: Index > Wiki discussion > Standardized terminals layout - Pt.II

This forum is a continuation from prior discussion regarding this topic, as it has been deemed that the topic needed a bit of a refresher in a more productive direction. So we are going to start off with CompleCCity's proposals, and work from there. Before we get to that, however, the purpose of this continuation is single-fold: the arguments involved, here, have been going on for much too long, and it is past-time to find a solution. Because of this, I have written up a rough-draft for some guidelines/policies, which will be included in the 'Comments' section for discussion and critique. GarouxBloodline 17:09, 22 February 2016 (UTC)

CompleCCity's Proposals

There are two reasons I've been rather inactive here:
First, the new format of the raw data pages, and
second, the ongoing, fruitless dispute between Ant2242 and Tagaziel.
The first thing makes me feel irritated and the second listless.
One says "yes", the other "no", one says "A", the other "B" – never a "maybe", never an "AB".
So I've decided to cut all this down to some questions that in my opinion need to be answered if we want to come to a conclusion.

1. Shall the raw game data look like

  1. the version recently submitted by Tagz for the FO3 notes, the most complete option, kind of an image of the game data?
    +   as complete as possible
    -   um… useless?
  2. the former version, still be found at the FNV notes, copied directly from a G.E.C.K. export and thus indeed "raw" data, structured by IDs?
    +   clean of redundant information; linkable, quotable, searchable; structured
    -   still a wall of text; errors may occur while structuring or through multiple copy-paste-actions
CompleCCity: I prefer the latter version; it serves the purpose and one can work with it, not so with the "image". Once completely structured, ID'd, and linked, I propose a (semi-)protection of those pages.
Tagaziel (talk): I'd be in favor of making a compromise: A wikitable including as much data from the first, while retaining the searchability of the latter; also adding the ability to sort the table.

2. Shall certain terminals

  1. furthermore be contained in an overview page, together with all other terminals for the related location?
    +   easy navigation between related terminals; no additional work
    -   one has to know the location to find a specific named terminal; clutter, hard to find certain entries, lots of scrolling; even more clutter and scrolling for certain locations
  2. get their own article?
    +   individually named terminals can be searched for; focussed content; more layout options
    -   more work, more articles; layout has to be defined (guideline); related terminals are not combined
  3. still be listed amongst related on a location overview page, with individual, specifically named, or otherwise important terminals getting their own article?
    +   look above and sum up
    -   look above and sum up
CompleCCity: I prefer the third option. I would make the overview a "main article", the individual pages can transclude the content from the overview. (There may be problems with formatting, I don't think that the {{Transcluded}} can work together with {{Transcript}} or <pre>.) The terminal links on the location page should call the individual pages, which then contain the {{Main}} hint.
CompleCCity: I propose to expand the layout section of many location pages by their respective sections, the local cells with an individual name on the Pip-Boy map or at least an own cell name. For some locations that is done, but for many there's only one layout paragraph, summarizing all integrated sections. With this done – or perhaps already before – the LOCATION terminals pages should reflect the sectioning of the location. A really small example, but one I've noticed: the Grayditch terminal entries, though only two, should be separated into Brandice's house terminal and Recently built shack terminal – to stay with the location naming. This doesn't make lots of sense for exactly this example, but other LOCATION terminals pages would benefit from it (not all, though): Less clutter, less repetitions.
Tagaziel (talk): A compromise, third option could be good and with enough transclusion, this will require only a modest amount of effort. Hell, if we wanted, we could create a master list of EVERY single terminal in the world!

3. Shall repeated content of one location's terminals (like the Welcome Screen or mass mailings)

  1. appear for each terminal with this entry on the overview page?
    +   propriety, integrity, chronology; in game feeling
    -   clutter, hard to find certain entries, lots of scrolling
  2. be separated from individual entries, perhaps put on top of the page or being otherwise hinted at?
    +   less clutter, no repetitions while reading; focus on individual entries
    -   chronology difficult to present; reservations regarding integrity
CompleCCity: I prefer the latter. Integrity is given in my eyes when all entries are presented somehow, and their chronology is preserved. Though there may be better ways, but examples how to do this were given.
Tagaziel (talk): Absolutely the latter. Chronology can be generally retained with ordering of the entries, which is an arbitrary decision we have to make. The games never really present terminals in any given order, as locations are open and non-linear.

4. Shall the terminals look

  1. like the best possible way in emulating the game, while parallel illustrating the quotation state of the entries?
    +   unique layout; in game feeling; clarity, that content wasn't written by a contributor but is directly from the game
    -   unique layout; hard to transclude layout; can appear strange to certain readers; more cluttered
  2. like every other standard page in the wiki, with several sections and default formatting?
    +   no distraction by layout; easy integration into other pages (e.g. {{Transcluded}}, {{Main}})
    -   loss of quotation character; prone to unqualified edits
CompleCCity: I don't have a fixed opinion about this. I like the current feeling of the font, the layout; makes it clear, "that is a terminal". But I understand the formatting limitations it brings with it. And that icon, the pen 'n' paper doesn't really suit an electronical note.
Tagaziel (talk): First of all, "unqualified edits" is a fictitious, non-existent problem that has never been an issue, not a single damn time (and I've been here since 2006). We can't let imaginary problems define our policies. Our pages are clearly local copies of game sources and once they're transferred to the wiki, they don't have to be disturbed. Any edit to the source page can be easily identified, verified, and reverted. As such, we need to focus on one thing: Presenting the information in a clear manner that's free of distractions. Anyone visiting a terminal page on the wiki doesn't want an emulation of the terminal: They want to know what content there is. If they want a generic terminal's content, they should be directed to the appropriate terminal. If they want the content of a particular terminal at a particular location, they should be able to open a page containing a compilation of all the terminals unique to the location and be able to browse them without having to sift through content they've seen a dozen times. Case in point: Fort Hagen terminals. There's one unique terminal at the location and the page reflects this. Clear. Understandable. Efficient.

So far these are the main questions coming to my mind by now.
Feel free to add more questions, more advantages and disadvantages, your own comments. (Please try to maintain the given formatting, and "sign" adds with your username.)
If you want to discuss certain aspects, please don't do this within the questions, add a new section instead.

I'd say we leave this some time for consideration and addings. After that someone with the appropriate knowledge could make some poll out of it.

So, what do you think? -- CompleCCity (talk) 13:36, 13 February 2016 (UTC)

I approve! Tagaziel (talk) 18:28, 22 February 2016 (UTC)

Guidelines & policies proposal

  1. Garoux's ideas
  2. What Ant has already standardized across the wiki for at least four years.


  1. Frakin' pick a standardization and finish it.
  2. The terminals pages are done by location as the overview. Then comes the terminal content as is presented in game. Anything else is editing the content itself.
  3. All terminals must be presented as is or you are editing what is there. No one but Bethesda gets to decide to add or remove from the terminals.
  4. See above.

This whole argument is unbelievably frakin' ridiculous. While some people bicker about how these pages should Look Like there is plenty of actual work to be done. Hit the random button and you are likely to hit a page in need of an update or complete rewrite. I honestly believe that if I complied all the lists and attempts at actually finishing these pages I could write an entirely separate wiki with it. ...But enough about the blackjack and hookers lets all stuff this nonsense and actually get back to editing.--Ant2242 (talk) 17:54, 22 February 2016 (UTC)

This is what we are doing, setting down a standard so that we can have a clear idea of what we are going to do. Now:
What you linked aren't guidelines. They aren't official wiki policies. They're your personal ideal, which you are now passing off as somehow the official standard of the wiki. They're not.
Your claim that anything that doesn't represent the terminals as they are in-game is editing the content is without merit. The mere fact that we're presenting terminal content on this wiki is an edit in itself, as it lacks the surrounding game. The point of this discussion is to arrive at a method that does not create a clusterfuck like this version of Fort Hagen terminals, but something that is actually usable to people visiting the wiki. We are all familiar with your stance,you've made it all too clear. Now let's get to work on creating an actual official standard for us to work with. Tagaziel (talk) 18:15, 22 February 2016 (UTC)
Please do not use that holier-than-thou argument, to avoid coming to a collective agreement, when it was pedantic editing, that you have also participated in, that led to this discussion in the first place. I have been trying to separate myself from these arguments, as, frankly, the prior discussion forum gave me a headache reading it. But a decision needs to be made, now; preferably, one that involves everyone working together to come to a solution.
Anyways, what the can of opened worms has now revealed, is that we have room for editing etiquette to be established - etiquette that was not needed until now. So it is time to get onto a productive train of discussion, and figure out an etiquette that benefits the wiki most. GarouxBloodline 18:17, 22 February 2016 (UTC)
Bullshit. The Entirety of the wiki is Standardized. You just dislike what is in game and wish to rewrite the look of the page. How about a better example of what this policy is; Citadel terminal entries, Rivet City terminal entries, Prydwen terminals, Vault 75 terminals (and I recommend you review the difference in the format, especially for Vault 75).--Ant2242 (talk) 18:23, 22 February 2016 (UTC)
The new policy will retain positive aspects of your proposed guidelines, while eliminating the negative. Such as vandalizing pages by removing information (eg. Creation Kit IDs, which are important). Also, your attitude is unwelcome. You are aggressive and counter-productive. Tagaziel (talk) 18:28, 22 February 2016 (UTC)
Bullshit. The actual guidelines are all done. And so is your attitude. Again why the Frak would we waste more wiking time carving up pages that are done until we get the time to create whatever this model that was discussed is? Checking the source texts is not an easy thing when no one bothers to check them let alone actually verifying them from beginning to end for errors. You know what, this whole "conversation/debate" is a complete waste of time. As some people clearly have the intent of carving up the pages to their satisfaction. Good frakin; luck with another Fraking incomplete wiki project. ...You know, I think that I should just dump everything from my lists (that is not already on here... or is it) onto the wiki and let the wiki sort thorough it.--Ant2242 (talk) 18:49, 22 February 2016 (UTC)

They aren't done. They weren't accepted as a policy or guideline, but impressed upon the wiki by you. And no, checking source texts wasn't a priority because the content on the wiki is not the source text. It's a local copy used as reference material and thus prioritized navigation and ease of use. And given that it all comes from the game, I don't see how it needs to be checked for errors when most of it was copied directly from the game.

Nobody's looking down on that work. Personally, I'm puzzled why you would be doing it, given that the only source that exists is the game. Whatever's on the wiki is a copy edited for use as reference material. Tagaziel (talk) 21:40, 22 February 2016 (UTC)

WOW. Just wow.
A) Source texts are what verify the content of the wiki. Source texts are from the game itself. However if they are inaccurate to the game then they are wrong. Thus making the referenced content wrong. Since you haven't noticed there have been instances of vandals, errors, and accidental omissions over the years that no one noticed before I literally went through the pages with the corrected files.
B) Yes, yes you are looking down on the work. You are literally debating that it is correct to modify what the game presents - which by your own statement is what is the source - for the sake of how said pages look. The way I see it there is two real options here;
  1. Leave them as the game depicts them as accurately as we can. Keeping the context, grammar, spelling, and content.
  2. Link directly to the Rad data pages. (Which needs to be standardized and completed - otherwise it would have been completed already.) Forgoing all context, and overview pages. Why have them at all at that point?
--Ant2242 (talk) 21:59, 22 February 2016 (UTC)

It appears this is a discussion about a standardization or guideline at all, and not how it shall look like.
And as before we have two opponents being unable to move from their respective points of view. (Sad for having to say it this way…)
Normally there are only a few ways to get out of such a situation:
  • One person leaves the discussion and the topic. – Something I don't want and I don't hope to happen!
  • The discussion stops, and the topic will be handled different by different people, no standardization is found. – Bad!
  • Someone with the appropriate position is giving out a directive, normally ignoring the opponents' points of view. – Do you really want this?
  • A third and different point of view is found, to the taste of all involved parties. – First steps to this have done, by Ant2242, by Tagaziel, and by me, with comments on this by GarouxBloodline. Why don't we walk further on this path?

EditorID (BaseID) Header Object bounds Model Note
Signature: NOTE
      Data Size: 1662
      Record Flags
      FormID: NOTE - Note [0007E3BF] <CapitalPostTerminalNote3b> "CapitalPostTerminalNote3b"
      Version Control Info 1: 0A 43 04 00
      Form Version: 15
      Version Control Info 2: 01 00
Corner #0
        X: 0
        Y: 0
        Z: 0
      Corner #1
        X: 0
        Y: 0
        Z: 0
By Walter “Street Beat” Munroe

Capital Post Staff Writer

What American child alive hasn’t heard the story of the Pint-Sized Slasher, that diminutive demon in a clown mask who stalks and slashes the innocent residents of supposedly safe suburbia? It’s just one of the many folk stories parents use to scare their youngsters into behaving themselves. Or is it?

According to Germantown police chief Joseph Field, the Pint-Sized Slasher may be more real than many people would like to admit. “After reviewing the autopsy results of the Linden Street slayings, we have confirmed that the force and direction of every knife wound are consistent with an attack from a much smaller assailant. A child, to be precise.”

Add to the sinister forensic findings this statement from Christopher Atkinson, the one surviving victim of the adolescent assassin, and it becomes clear that the Pint-Sized Slasher does indeed walk among us: “The clown! The clown! He’s going to kill us all, do you understand me? He stabbed my brother Shaun right in the face! He killed my brother! The little clown!”

But assuming the Pint-Sized Slasher is indeed a real, tangible threat to the peace loving residents of D.C. suburbia, one question remains: why? What could possible motivate a child to don a clown mask and murder innocent people in cold blood? We may never know. At least not until the miniature maniac is brought to justice. Until then, all we can do is lock our doors, kiss our children goodnight… and pray they live to see morning.
Do we really need the header and object bounds? And who shall do all the work? ;)
Anyway, the page should be assigned as transcribed per se.

  • Own pages for default "Open lock" and "Reprogram turret" terminals, with variants.
  • "Terminal"s all together on a location related page, that only links the above mentioned. Order first by relevance or uniqueness, then by walk-through-the-location.
  • At least uniquely named terminals or unique types of terminals (like the "Suspicious Terminals" in the H&H Tools Factory) get their own page, so they are to be found if someone looks after. Not sure about what transcludes what…

@3: If you don't agree with either, GarouxBloodline, then what's your proposal?
I think that repeated welcome screens and shared entries (notes) should be listed for a group of related terminals only once, noting it of course. The entries however should somehow appear in the chronology of each terminal, though only with their loading command. That all can serve as structure for ordering the terminals by relation as well, grouping those with shared entries.

@4: I think, the main argument between Ant and Tagz…
I said I like the current look. But also I think here's a great potential for improvements.
What if we said, those commands usually beginning with > are per se transcripts?
The welcome could remain/be presented in <pre></pre> or as transcript.
The note itself should be a transcript, but perhaps with a new icon.
Example layout:

Welcome to ROBCO Industries (TM) Termlink
 This terminal is for the express use of the Vault

Press Release


For Immediate Release:
Vault-Tec to Subsidize Enrollment for Malden Families

WASHINGTON DC - In response to growing national concern for the safety of our children in the event of a nuclear attack, Vault-Tec officials have cooperated with local government in Malden, Massachusetts to provide subsidized enrollment fees for any families wishing to sign up for residency in Vault 75. The newly-opened Vault is attached directly to Malden's Elementary School, ensuring a swift evacuation should an attack come during class time.

"Safeguarding the future has always been our priority," said a Vault-Tec Spokesperson, "The opening of Vault 75 gives us all extra peace of mind, knowing that the children of Malden will be safe, even if the worst comes to pass."



Somehow my just uploaded icon interferes with the text, don't know why. Isn't it just possible to change the class=va-transcript-text in a way that the text is more indented, has more distance to the icon?
For the welcome text perhaps an own template has to be created, making the box smaller, matching the content, or a fixed width of say 40 spaces – that's where the terminals break lines in the header.
And the transcript for terminals should be an own template with a suiting icon, like said before.
New intermediate comment: What about my new terminal transcript icon? ;o) Could someone please explain to me, why {{Transcript}} uses {{Icon}}, but doesn't support the sizing of the icons, always puts it to large, around 32px or so? At least my efforts to change this were fruitless. -- CompleCCity (talk) 21:34, 6 March 2016 (UTC)
So much by me for now. I beg you, let's get out of this in a constructive way.
You may remove the table when all have seen it. And you may move this whole section to the bottom of the page if that suits better. -- CompleCCity (talk) 11:26, 24 February 2016 (UTC)

I took some time away from the wiki and mulled the issue over with a fresh mind.

  1. I agree with the table format. It's searchable, very much usable, and relies on actual underlying data, rather than the (largely useless) string dumps the GECK spits out.
  2. I agree, generic terminals should have their own pages - with the caveat that whenever they crop up, they are only to be linked to from any overview articles, to preserve navigability. I just looked at the vandalized Switchboard terminals article (sorry, there's no alternate way to put it, cramming all those entries there offers no added value, while removing descriptive terminal names, taken from the Creation Kit IDs no less, is equivalent to vandalism as it ruins navigation) and it looks horrid. I'll also add that terminals need to have a descriptive name. It's not part of the transcript, but navigation too, which means we should focus on what's important to the user.
  3. Ditto. Shared content should be marked as such and posted once to avoid repetition.
  4. The commands are largely irrelevant, since they're re-used constantly. I'm not against including them, but the template could include an additional parameter for them and move them out of the way, while clearly marking them down and explaining what they are. As it stands, there's no explanation as to what these seemingly random text strings do.

Let's wrap this up in March and move on to standardizing. I'll be asking Kastera and Leon to help me with the articles once this is agreed upon. Tagaziel (talk) 11:04, 4 March 2016 (UTC)

  1. Tables are not searchable. (also the search bar on the "Recent changes" page isn't functioning like it does on the rest of the pages.)
  2. The Raw data pages are not useless dumps.
  3. Generic terminal pages Unless they are apart of a regional location Or Apart of Other terminals. Not All Terminals With Generic Commands Are Generic. I forgive you for your vandalization. Just please keep in mind that when you rename an ingame object you are the one editing content. And yes all the headers and terminal names are content.
  4. Commands are apart of the content. Some terminals have them and some do not. Removing them is to remove content. All commands ARE LABELED AS TO THEIR PURPOSE.

Seriously why don't you just push for a complete removal of the terminals pages and like directly to the GECK pages? It removes all that pesky context and content that you dislike. Furthermore all the articles are in a Searchable standard. If you actually are going to keep Gutting them like this I will keep reverting it. --Ant2242 (talk) 21:42, 4 March 2016 (UTC)


CompleCCity's final thoughts

  • Raw data pages
    • I don't think that table there above is a really good idea. If staying with <pre></pre> formattings to retain the transcript/quote character of the notes and put in so much more – and in my eyes redundant – informations, the raw data pages really blow up. We don't need the object bounds, and all important information from the header is already included if we have the ID and the model.
      • Let's reduce that table to "EditorID", "FormID", "Model" and "Note". Enough!
  • Terminal pages – quoting myself
    • Individually named terminals or specific types of them get their own pages as an extra to the inclusion on a location based article.
    • The article is named LOCATION's terminals.
    • The order should use relevance or individuality of terminal content rather than a walk-through-base. Also shared content can be used to group entries, giving more structure.
    • So called Terminals should get a descriptive name*, based on owner, if clear**, content, or EditorID. Original in-game-name, EditorID, and FormID have to be noted.
    • *If there's only one Terminal in a location, then it's called Terminal on the page.
    • **I remember Jenny DeSoto's terminal – which could be deducted by reading the e-mails –, placed on Jenny DeSoto's desk – but who the frak was Jenny DeSoto and where in hell was her cubicle?
      • For certain locations should be considered to give these descriptive names simply by describing the specific place where they can be found… Entrance hall terminal, Wall terminal, Weaponry terminal – as examples.
    • Generous terminals (unlock, turret control) have to be mentioned together with their location, but aren't placed with content, only as link.
    • As already mentioned a split into more sectioned locations would be possible to reduce the amount of terminals for certain pages. If a factory building consists of more than one level, then there could be a FACTORY GROUND LEVEL terminals and a FACTORY UPPER LEVEL terminals page.
  • Shared content
    • Shared content has to be placed only once.
    • Terminals that share content have to be grouped, to simplify the process of depicting the SC. (That leads to a less cluttered TOC as well.)
    • It has to be made clear, where in a terminal's content's history that SC was placed.
    • Nada más.
  • Transcripts
    • I do really think that layout has to be redone. But that's a thing for later…
  • Further comments
    • Tables are not searchable by the wiki's search function, but they are with the browser's. And who would search the wiki for an entry in the raw data pages?
    • What do you think of my terminal GIF? ;)

-- CompleCCity (talk) 22:36, 6 March 2016 (UTC)

Addressing CCC's points:

Going to try and get this back on track, by discussing some of CCC's proposals:

  1. I absolutely agree with Tagaziel's compromise solution, here. I see a best of both worlds, with no negatives.
  2. With the guidelines and policies that I wrote up for discussion, I believe that my opinion lines up very nicely with option 3. When it comes to generic terminals, I still believe that a general pages are needed - not unique articles for each.
  3. I am actually not sure if I agree with either. Chronology is great and all, and it works in most cases with good organizational skills. But when it comes to related articles, I believe that there needs to be a bit more professionalism involved in keeping connected terminals together, instead of spread out, losing context.
  4. Transcriptual (heh - I made up a word) information needs to be kept as accurate as possible. But accuracy cannot be followed to religiously, that we begin to lose wiki quality. We might be an encyclopedia, but we serve our users, first, and as such, we should always stay true to keeping our information as concise, and descript, as possible, for their leisure.

Those are my thoughts, at the very least. Hopefully they are constructive. GarouxBloodline 04:53, 23 February 2016 (UTC)


This... debacle, has been going on for long enough, and an executive order has been made effective, in order to stop this infighting, and get everyone's editing back on track. Before I conclude this forum, I am going to explain my thought process, leading up to my final decision, as I have been appointed the mediator, to come to a compromise solution:

  • An argument from Ant, is that as an encyclopedia, we must adhere to the games and their content verbatim. This is a very valid argument, as when it comes to technical data, especially transcripts, we must remain as faithful as humanely possible, in order to remain a professional wiki.
  • An argument from Tag, is that when non-descript terminal names are used within our article space, to the point where multiple nondescript terminals are included in the infoboxes, our articles are brought down in both quality and professionalism. This is also a very valid argument, as our users come to this wiki in order to discern information at their leisure. Having a myriad of nondescript links, does little more than bog down the processes involved with our readers getting the information that they want, when they want it.

Both of you are right, in your own ways. Because the both of you are right in your own ways, I had drafted up a series of guidelines and policies that will be going into effect this week. After I conclude this forum, and set some ground rules, I will be updating these drafted rules, and they will be up for further discussion until the end of the week, in which they will then become set-in-stone. I will have a separate forum up for discussion purposes, and until the end of the week, this will be everyone's chances to see to some changes being made, if said changes are deemed necessary.

As for the ground-rules:

  1. In the case of non-decript terminals being in a larger number than 1, on any given article infobox, descript names are to be given. Ultimately, our users are the most important aspect of this wiki, and although we should never cheapen our quality towards the lowest common denominator, I feel strongly that we should never overly inconvenience our users in such a way.
  2. The edit-warring must stop. We might have a small community at the moment, but it still does none of us any good to foster such a hostile environment, especially between our leadership. Healthy competition is always fine - outright hostility, is not. Any further edit-warring on this matter, especially once the new rules become permanent, will be met with administrative action. This goes towards every party involved.
  3. On our terminal overviews, we must still remain as loyal as possible towards in-game information. Terminals, as Ant has standardized, are to remain the same, with a sole exception: The primary header must be descript, with a secondary section being used to note the actual, in-game name. This will be the both of both worlds.

To CCC, you have made some very interesting points, and we will be talking to you further. I am especially interested in the .gifs you have been playing around with in this forum, which should go nicely with our wiki's terminal aesthetics. Thank you for being the voice of reason in this affair, and I do hope that you will continue being a voice of reason for the wiki. Thank you everyone for contributing, and should anyone have any immediate questions, feel free to continue using this forum, or my talk-page. Thank you. GarouxBloodline 08:11, 7 March 2016 (UTC)