ThatOneReaper

"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.

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".

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.

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.

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 filtering, Anti-aliasing, Vertical 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.

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.

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.

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.

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.

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: Date: Cancelled (<DATE OF LAST FUNCTIONING RELEASE>, <VERSION NUMBER>) 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.