Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by ThatOneReaper

  1. Soo... Putting aside that in the end I didn't have to face this dilemma.. Would you consider having to awkwardly tinker with the in-game menu to count as hackable?

    Because I almost would, since it's kind of non-intuitive and very likely you'd end up having necessarily to read the how-to.


    But in turn this would entail that we should kind-of rethink the "official criteria" for hackable.

    No rocket science (I have some little ideas) but still I wanted to hear others before going on with pondering.

    "Hackable" means that a feature or option can be enabled through either unofficial means (patches, mods, etc.) or built-in engine commands/options that are not explicitly made available through the in-game options menus (command line arguments, modifying official config files, etc.)


    In your particular case, if the feature can be enabled through the in-game options menu (abit in an awkward and roundabout fashion), it would still be considered native support.

  2. Well, of course I'm always talking about corner cases in the most hypothetical way. 


    And even for an online game.. I mean, just suppose a World of Warcraft expansion that has greater requirements than base game.


    Nobody of course.

    But obviously nobody is actively checking anything in any other game too.


    Iirc GOG galaxy can rollback patches btw. Also, cool third example.


    These two sentences immensely outrage me.

    1. It wouldn't be the first time we add something "just for the records of posterity"

    2. Claiming "dev says so, you must comply" is.. I dunno, crazy in a place like this.


    And I'm 3 times concerned given your status and given it's not like we hadn't even discussed in the past about lowendgaming or similar.

    I should backtrack a bit.


    If you want to add in a note about lost OS/hardware support just from an archival prospective, go ahead. I'm just highlighting that it wouldn't serve any purpose beyond that.


    As for mentioning unofficial OS/hardware support lower than what the minimum specs are, my reasoning is that it would complicate troubleshooting issues if we do. When a developer states minimum system requirements, they are saying "This is the general configuration we found that allows you to play the game at the bare minimum with no issues. We cannot guarantee stability with older configurations".


    Of course, you can try to run the game on older configurations. It might even work just fine, abit with heavy compromise in graphics. But any issues that do arise under such configurations would be difficult to nail down. Is it the person's configuration that's causing the issue or the game itself?


    The only reasonable fix I could give in such a situation is "Upgrade your hardware/software".


    I am advocating "dev says so, you must comply", but for good reason. Our fixes assume that at the very least the system the person is using is equal to or newer than the minimum specs. I don't want someone to look at our statements on such support, run the game on the "supported" OS/hardware, and come back to us reporting bizarre issues that may or may not be due to the configuration.


    Unofficial OS/hardware support equal to or newer than the minimum specs (but older than the recommended specs) is a different matter. If a particular OS/hardware works, but is not officially supported (and not specifically mentioned as an unsupported configuration), it can be listed. It would need some notice along the lines of "X OS/hardware works with the game, but is not officially supported. Stability is not guaranteed".

  3. Marioysikax has the right idea. Games that use digital distribution need to have the newest system requirements listed as games can drop support for outdated OSes and hardware (see Space Engineers).


    I don't think we should put a note regarding lost OS/hardware support because it wouldn't really matter for the latest build. Unless there is a way to use older builds of a game legally, there is no point in adding it to the page beyond historical purposes.


    Mentioning unofficial hardware/OS support also doesn't make sense. Even if a game still does work, there might have been a good reason why that hardware/software configuration was not listed (assuming hardware/OS is below minimum specs). Bringing it up may cause users to run the game on unsupported specs and find issues that are not present in officially supported specs.

  4. Generally, giving information regarding pirated and/or cracked versions of games is not allowed. Regardless of the progress made in copyright laws specific to software, it's still a legal grey area for the time being.


    That being said, there is one exception to this rule (that I personally see): If a game suffers from a game-breaking bug/crash and there is absolutely no other confirmed fix for it that is reliable (and legal), a No-CD crack/patch can be mentioned (but not directly linked). You don't need to mention the legality of said fix.


    In other words, No-CD cracks/patches are to be considered the absolute last ditch solution to get a game to function. 


    Considering games with SafeDisc are fundamentally broken on Windows 10, mentioning the No-CD crack solution would be appropriate in those cases (assuming that no other legal solutions are already available).


    As a sidenote, I removed the No-CD fix from the Max Payne 2 page as there are already other legal solutions given to the issue.

  5. Maybe we should add a tag named "Generic" (along with True, False, N/A, etc.) that links to relevant pages/page sections when clicked on?

    The only way I would see that working is if the Video Settings table had a dedicated field to enable showing generic instructions ("show_generic"). If the field is set to "true", then add a blurb to the relevant video settings along the lines of:


    "Generic instructions for forcing <VIDEO SETTING> can be found in <LINK TO GLOSSARY SECTION>"


    Even then, I don't like the idea of having a dedicated element in game articles for general fixes like that. I want to remove general solutions, not highlight them.


    I already mentioned the best approach to this: Add one set of generic instructions to the glossary pages (Anisotropic filteringAnti-aliasingVertical sync) and remove said instructions from specific game pages. All tables are already linked to these glossary pages. If someone absolutely wants to force a specific video setting for a game, they can look there.

  6. I'm going to weigh in on this issue as I've been thinking of adding something to the Editing guide to address this.


    Video settings that can be forced through a video card's drivers can be considered general fixes that are application-agnostic. It's the type of solution that can be applied to practically every 3D game the wiki covers.


    Based on that knowledge, I think we should not consider forcible video settings to be "hackable" in the context of any specific game. An article should be dedicated to game-exclusive fixes only. Allowing very general solutions tends to make an option field always "hackable", which I personally think does not add anything of value to the page.


    The only exception where adding a general fix would make sense is if in-game support for the setting is fundamentally broken with no other possible workaround (ex. game has broken V-sync support). Otherwise, I would add general steps to the relevant video setting glossary pages on how to force each setting.

  7. I think it's a good idea. It would definitely help cover all the bases on both wikis.


    It also has the potential to remove clutter on some pages (links to walkthroughs and gameplay-focused sites can be removed with StrategyWiki Infobox links as replacements).


    I don't see any reason why we shouldn't have it.

  8. So GameFront has recently announced that they are shutting down April 30, 2016. While games today don't require such dedicated filesharing services (normally opting for automated patching or uploading through a more general purpose service), much older games will be affected by the loss of this service. GameFront is almost on par with FilePlanet in terms of both files and reputation, and losing access to such a resource will make it significantly harder to find good patches for pre-Steam games. There is also the issue of permanently losing patches and mods that were uploaded exclusively to GameFront.


    Although we have practically nothing significant linking to GameFront at this time, it is recommended that any patches that can be found on the service for games we already cover should be mirrored on the wiki.

  9. MODS: Please remove the code from this post, I can't do it currently. The forum software can't apparently handle long strings of text, I should have use a plain text hosting service. My browser is prone to crashing on this page.

    Done. If you want to share huge chunks of text temporarily next time, use Pastebin.


    As for adding the tweaks to the article, I would recommend either using instructions to modify the required lines (assuming it's just a few) or upload to the Files section the modified config file.


    In any case, I'm looking forward to the full list of tweaks that come out of this.

  10. Having a specialized date for cancelled games is a great idea. But I'm not sure what would be the best way to highlight this detail. Would just having "Cancelled" along with the date of the last functioning version be enough? Or should we also have a "Cancelled" state tag added in?


    Example format:

    State tag: "This article documents a game that has been officially cancelled as of <DATE OF CANCELLATION> - information here is in context to the last functioning release of the game."

    I'm also liking having an "Unknown" state tag. However, an issue I see with it is with older articles. If there is a new development in the game's production and no one modifies the article to match this, it would look very inaccurate on our end. The only way I see it working is to add into the tag the date it was added in.


    Example format:

    "Although this game is under development, no new updates or releases have been made in over six months (as of <DATE OF ADDING TAG>) - information may change frequently and could be outdated or irrelevant."

    As for cancelled or discontinued games that are impossible to play, the Editing guide talks about this detail.

  11. Screenshots serve a couple of purposes:

    • They complement the tables in the articles by giving a visual reference to most of the options covered by the wiki. Like you said, articles tend to be very dry without them.
    • They give readers an idea where to find all the options in-game without having to dive into the actual menus themselves. They "flatten out" the menu hierarchy.
      • Ex. The subtitles toggle might be under "General", rather than "Audio".
    • They also show all the possible settings a user can modify (including features not covered by the wiki).
  12. Could someone help me with this? I don't know what to write for multiple screenshots of the same menu.


    I've decided to start using galleries seeing as I've seen some users actually using these keyboard images on Metal Gear Solid V.

    The guide already talks about how to handle this sort of thing:



    • If a menu cannot be completely captured in one screenshot and stitching them together is not an option, upload the screenshots of the menu as a "series". Add a number to each screenshot to distinguish the ordering
      • "(current #/total #)"

    So in your case the file caption format will be "In-game keyboard settings (#/3)"


    On a related note, for screenshots of remapping menus, just one picture for each input device is enough. The full list of remappable commands is not relevant for the wiki.

  13. Hmm so this is about expansions such as Call of Duty: United Offensive? But how do you determine whether the expansion is "worthy" of the prefix? Would Deus Ex Human Revolution: Missing Link count too? It'd make the name too long.

    It's quite simple: If a retail (i.e. physical) copy of the expansion was made available at some point, then it gets the prefix. Otherwise, it doesn't.


    Some examples:


    Retail expansions: Call of Duty: United Offensive, Quake Mission Pack 1: Scourge of Armagon, Command & Conquer 3: Kane's Wrath

    Digital expansions: Deus Ex: Human Revolution - Missing Link, Call of Duty: Advanced Warfare - Ascendance, The Witcher 3: Wild Hunt - Hearts of Stone



    There's a syntax error on this page.



    A { is missing.

    {DLC|--rows go here--}}

    It would be useful to state that, the DLC table needs to be placed under the availability table. (I can't really word it right now, just write something about the location of the DLC table)


    (Are tags broken for some reason?)


    Added in the fixes, thanks for pointing it out.

  14. When I started following the editing guide creating a new page and saw some inconsistencies between the sample article and editing guide, I saw some differences between the two and made a thread about it in sample article's page.


    However, I started seeing more differences and inaccuracies between the two, so I thought a forum may be a better place to discuss it.


    I'm going to list what caught my eye, but I'll also list the things that should be fixed in both of those places, since both of them are for view only:

    • "wikipedia" and "winehq" places are swapped in infobox; it's in different order in sample article's cheat sheet than it is in editing guide
    • "steam appid side" parameter is missing in the sample article's cheat sheet
    • square enix cloud syncying option is missing in save game cloud syncing table in sample article's cheat sheet
    • API and middleware tables are missing in the sample article's cheat sheet, seems it was already mentioned before, but not answered AFAIK. They are in the base article body though and editing guide does not say anything about the tables being optional
    • Sample article's cheat sheet for series pages uses {{SUBST:PAGENAME}} while the editing guide do not use it
    • Sample page's "genre information" links to the now-dead Style Policy page
    • links in "General information" in sample article does not match what the editing guide recommends (i.e. GOG links should be over Steam links). Editing guide does not mention nothing about the point: "If still relevant, state where bugs can be reported."
    • A small discrepancy in availability type, in example GOG.com is written as Gog.com (no uppercase)
    • The "Which is the 'best' version of the game to get?" under availability point is not present or explained in editing guide
    • I'm a bit puzzled about the patches section in essential improvements. Editing guide is really vague about it, only saying to place "Patches (both official and unofficial)", while sample article says [only?] "Include If There is a benefit in using an older patch". For example Brigade E5 is patched to latest 1.13 version on Steam, but my retail version is not. Following what the sample article says, I should not upload a link to patch 1.13? Or should I anyway? I'm confused x.x
    • Intro skip methods section is missing in sample article entirely
    • The order of utilities and modifications is swapped between sample article and editing guide (patches-utilities-mods in sample article vs patches-intro skip-mods-utilities in editing guide)
    • Configuration file(s) location table is missing in sample article body (not cheat sheet), and while we're at it, cheat sheet (and editing guide) says "Save game data location" while body simply "Save game location"
    • Some of the newly added table options are missing the appropriate "See <something>" section and matching headers. While we're at it, should we always use "See <something>" instead of just fill the notes, or only for really long explanations? Nor sample article or editing guide explains it
    • Sample article does not use the new way of treating fan translations for Spanish example
    • Creative Senz3D table features "class="generic-table-notes-cell" colspan="2"|"
    • "Other information" guidelines differ in sample article vs editing guide

    P.S. There are other minor differences between the two, especially when it comes to the formatting of missing data in cheat sheet - for example sample page's cheat sheet fills steam id with "000000" while they are blank in editing guide. Those are less of an issue, as they will get replaced anyway and will not reflect the final page's look in any way.

    Thank you very much for pointing out these inconsistencies. I've fixed most of them. When I can find the time, I'll fix the more complicated ones.


    Note that the Creative Senz3D problem is beyond my skillset right now. One of the admins will need to fix that.


    Speaking of inconsistency, in file upload page, there's link to PCGAmingWiki:Files article, which uses old formats and is slighlty differend overall from editing guides screenshots section


    Also it seems like AA is N/A for 2D games now, even though I have been setting them to false all this time because of this thread

    The Files article guide is very much in need of updating. I'll make that my next project.


    You should try to not rely on the editing guide too much, some things are not entirely clear and you should decide what to do on your own for the most part anyway.


    Could we stop doing this because it looks bad, and it makes things harder to read.


    And do this instead, tanks.



    The sole reason the Editing guide and the Sample guide exist is so that you don't "decide what to do on your own for the most part anyway". It is the standard by which all edits on the wiki are held against. Everyone from new contributors to admins must follow both documents. There should be absolutely no reason why we should be telling people to disregard the guide.


    If there is an issue regarding clarity in a particular section, just post it here. The guide is fairly malleable if given good reason to do so.


    As for the expansion naming, the reasoning behind it is that retail expansions are complete, separate products that just so happen to require the base game to function. Digital DLC are more along the lines of plugins for games (the best description I can give on this). The naming is to distinguish between both types of expansions.

  15. For screenshots, they can only be cropped in the following cases:

    1. The options menu is displayed as an in-game window, rather than a separate screen.
      •  Especially need to be done if said window is small compared to the rest of the screen.
    2. There is personal profile information that cannot be changed to an appropriate throwaway profile.
    3. All the settings for a menu do not fit in a single screenshot and must be stitched together.
    4. The screenshot is of an external menu/application.

    In these cases, it helps cut down on the clutter both on-screen and in the game article. Otherwise, provide a fullscreen screenshot.


    It should also be noted that when cropping, do not leave any unnecessary space outside of the in-game window.


    Good examples of properly cropped images can be found on any Company of Heroes page, Half-Life 2, and Splinter Cell: Blacklist.

  16. After nearly a full year working on it, the PCGamingWiki Editing guide is now officially done!


    It is currently in the process of being ported over to the redesigned site. No further changes to the guide will be made until after the relaunch (excluding spelling/grammar edits).


    I want to thank everyone that helped contribute to the project. Your input was of great help for me and all future editors that will use the guide.

  17. Editing: Regardless of if a browser has good crash recovery or not, it wouldn't serve any purpose to mention it. Some people will end up relying upon that functionality too heavily, rather than backup changes properly.


    References: I've added an exception for posts made by development team members or representatives if that helps.



    • It's always a good idea to mention backing up critical game files before they get modified. Even the best of computer users forget from time to time. I only mention the warning in fixes if the file is a DLL, EXE, or multi-line CFG/INI modification.
    • Yes, we need to add launching the game as a step. A fix covers everything right up to the start of the game.
    • If you want to create a page with a list of recommended programs to use, feel free. I wouldn't have the time to write such a thing up.
    • I keep going to a specific file path and opening a file separate for a reason. The first step ("go to <path>") establishes the context of all future steps in the fix in a clean manner. I might need to do more than just modify a file afterwards. Merging the two will make the steps look "sloppy".​

    What the wiki does not cover: Putting in pornographic games on the list is due to good business sense and decency, not "good old American dissonance towards nudity and sex". No console manufacturer or major retail store carries AO-rated games (most porn games fall under this rating) because they are very bad for their image. The same logic goes here.


    Regardless, porn games are seedy by nature and would cheapen the wiki if we started to allow them. They ultimately have no place here.


    Finally, I've already stated that the definitions are subjective in nature. Questionable games can be run by the mods/admins if there is confusion.


    Availability: I'm not dealing with that argument again. Like you said, the editor will need to make that determination.


    Video settings:

    • The Widescreen and Windowed notes have been added.
    • 4K: That is such a bizarre edge case, even if it is hypothetical. I have yet to encounter a 4K-ready game that does not support widescreen. It stays as is.

    Input settings:

    • Trying to come up with methods to disable acceleration for every game is nigh impossible. Not every game have an INI file that can be modified.
    • I've linked the toolkit in the table.
    • If controller support is false, we leave it as is. Adding the notice to every page would look messy. Anyways, the Glossary page already handles that.
    • The XInput preference is because most major controllers and modern games are designed with XInput in mind. I don't want editors to try testing for full controller support with non-standard controllers.

    Audio settings: I've added the note.


    Template documentation: That's not my responsibility. You're better off asking Soeb or Garrett.


    Anyways, I believe the guide is finished and ready for a full release. I have to start porting it over to the redesigned site at some point this week.

  18. Just noticed the WIP editing guide lacks any information on the disambig template nor when to use the two forms of the template. Definitely something to add in as it's not mentioned in the old guide and isn't on the editing GUI.

    Thanks for pointing this out. I've added in a basic overview of the tag in the Guide (not much to write on it honestly).

  19. Just encountered an issue not covered in the guide. I was adding an availability row for a game's official store, and the link contained equals signs in it, causing that row to be all messed up. After consulting with soeb on the IRC, I discovered the formatting should go like this:

    {{Availability/row|1=Official |2=http://www.official/store/url?action=product&id=555 |3=DRM |4=Notes |5=Key }}

    As the guide doesn't have this vital bit of information, it should be updated to include it; if it affects other availability row types as well, it should be noted for those rows as well.

    Thanks for bringing this up. I've added in the alternate syntax details.

  • Create New...