PCGamingWiki will soon migrate to a Single Sign On (SSO) system to bridge Wiki and Forum accounts, please read our FAQ.
This seems like an important setting, especially with the prominence of high-PPI UHD monitors.
True: Has option to change scaling settings. May or may not automatically scale based on selected resolution. Example: SWTOR
Always on: Is automatically scaled based on resolution, but has no manual setting. Example: Lego Star Wars: The Complete Saga
Limited: Only scales certain elements (ex: graphics but not text), or cannot be scaled beyond a certain percentage of the base resolution. Example: Half-Life 2
False: Is not scaled and does not have an option to scale. Can't think of an example off the top of my head.
Hackable: Hackable. Example: Quake
This could go in the video settings table, or it could go in a potential accessibility table. I think probably wait until a dedicated accessibility table is made and put any info in 4K for now.
In the beginning, PCGamingWiki shied away from including classification of games because we were focused only on fixes - we weren't interested if a game was a 'third person shooter' or a 'first person shooter' - we just wanted FOV fixes, widescreen fixes, etc. However I think things could be improved - taking a queue from Wikipedia: Modes: Firstly with the way the tables work, some genres don't require 'FOV' fixes for example 2D games. Or an 90s adventure game doesn't need an 'Inverted Y-Axis' option etc. A mode property would allow us to restrict certain tables so that this makes more sense. This would include things like: VR, 2D, 3D, 1st person, 3rd person, touchscreen, VR etc. Furthermore, in the future we could use this to categorise other features like microtransactions, lootboxes etc. Genres: Genres are a great way of listing games. We could make lists of Puzzle games on Uplay, RPGs fan translated into Russian, etc. How great would it be to see all the Local co-op games that are 2D rather than 3D (my wife can't play 3D games as she gets motion sick!). In terms of implementation, this could sit in the proposed Overview section as well as the Infobox itself.
Reviews are a very important part of 'discovery' of what game to play. How much more useful would our lists be if we could filter or sort by Metacritic score?
Metacritic includes the Critic score which tends to be fairly static after release.
There is also the User Score which tends to fluctuate a lot, even years after release, or is subject to review bombing.
I would be happy to include both.
Potentially, Metacritic scores would sit inside the Infobox, with a link directly to the relevant Metacritic page.
The values themselves could be gleaned from Wikidata, or another automated method, or could be entered manually.
I am also open to alternative review aggregators and am open to suggestions.
Proposal to remove wikis from General information and the Editing guide.
Wikis were included because generally speaking there was 'the one' wiki everyone used. However with the advent of massive wikifarms, a single game could have several wikis associated with it.
Inconsistencies with 'community wiki' / 'official wiki' terminology - meaningless as all wikis are community wikis Wikis don't offer technical information If a wiki contains a good technical page, this could be linked to separately Proposed solution:
Remove any game wikis from General information Time limit: 7 days (14th June 2019)
Support for batch uploads could improve the speed of which users upload multiple screenshots for use in the articles. This seems at first glance as a relative easy feature to implement, as the functionality is already provided through extensions to MediaWiki: https://www.mediawiki.org/wiki/Category:Bulk_upload
How does this relate to the new backend for images and thumbnails? Does the extension need to have support to make use of the DigitalOcean Space? A few months ago when I tried to do something similar using multiple tabs I would often hit an error similar to a 429, Too many requests, and have a few of the uploads cancelled until I let the current ones finish. Is this something that would occur, and if so, do we need to increase the number of allowed connections per user on the backend?
Who's Online 4 Members, 0 Anonymous, 213 Guests (See full list)
Recently Browsing 0 members
No registered users viewing this page.