Jump to content

Welcome to the upgraded PCGamingWiki forums and files page. The current Wiki and Forum bridge is not functioning at the moment, therefore your Forum account currently has no password set. Please reset your Forum password via email check to generate a new password. If you have any issues please message Andytizer on Discord.

Garrett

Moderator
  • Content Count

    778
  • Joined

  • Last visited

  • Days Won

    108

Posts posted by Garrett


  1. 2 hours ago, Jinx said:

    Are the people who can't download or maybe can't update Metro not on 1903 Windows? Maybe you need that plus the Xbox app beta? Just throwing that out there. I'm going to keep waiting to try gamepass I guess.

    Yes, you'll need the May 2019 Update (1903) for this. If you're not getting it when checking for updates in Windows Update you can download it using the Update Assistant.


  2. Streaming services will be very popular in areas with good internet as long as it provides a "good enough" experience. Those wanting the best experience will still opt for native hardware as usual.

    Streaming is out of the question in many parts of the world due to data caps or poor internet speed. Microsoft's combination approach (streaming plus downloads) is much more accessible because it doesn't rely on internet speed or special server hardware. If your internet access is really slow you can buy the Xbox One disc and only download the latest patch. If Xbox Live (or your internet) goes down you can still play single player games just fine.

    Xbox Game Pass was available worldwide on day one whereas streaming services will be limited to specific countries. Microsoft's approach also opens up some appealing possibilities that can't exist with Stadia (start streaming a game instantly to see if you like it, then download the native version while you're away from your device).

    Project xCloud will probably be publicly available around the time Stadia launches, so Google will be facing immediate competition from a much more established rival.


  3. I'd be in favour of this for the reasons you've outlined.

    @Andytizer If this change happens it would probably make sense to add "settings" to the site tagline in some way to aid incoming searches using that specific keyword.

    On 6/9/2019 at 8:32 PM, Aemony said:

    Side question: should "support" be removed from the "VR support" header as well?

    Yes this would make sense as well for the same reasons (it would also be a good idea to revisit other aspects of the VR template, but that's a subject for a separate topic).

    On 6/9/2019 at 8:36 PM, Aemony said:

    Oh, this would also mean we can actually label our templates and cargo tables for "Audio", "Video", "Input" as well.

    Cargo table names do not have to match the associated templates (see Special:CargoTables for several examples).


  4. That looks good @Aemony, some of the descriptions may need to be reworded a bit but the concept is solid.

    21 hours ago, Aemony said:

    Going by Garrett's example for "always on" related to the surround sound row on the audio table, that would turn the potential tooltip into: "An option is available to adjust the number of speakers the game will make use of (e.g. mono, stereo, surround, 5.1, 7.1)" or something similar -- and if a game does not have an option, but supports surround sound up to e.g. 7.1, the state would be set to "always on".

    Tooltips could change based on the state that has been set (only explaining "always on" surround sound when set to that mode).


  5. On 6/4/2019 at 3:37 AM, Andytizer said:

    I think this Tickross change is a very a tidy solution for the 'Always On' issue. Garrett's colour is appropriately 'meh' as it's great if AA is on but we should be able to turn it off or change the AA type/quality etc. I would approve of this change @Garrett.

    The new "always on" state is implemented. I have revised the Section Table legend state definitions.

    This state only applies to specific features in the Video settings, Input settings, and Audio settings tables. I have added the new state to the instructions for the applicable fields.
     

    On 6/4/2019 at 3:37 AM, Andytizer said:

    @Aemony I agree with your points - multimonitor is more like a 'ultra-widescreen+' setting. But the term multimonitor is so ingrained as meaning Eyefinity/Surround especially in communities like WSGF, it'll be an uphill struggle to repurpose.

    In terms of a new name for a 'distinct' multimonitor support, how about... 'Second screen functionality'? This would include games like SupCom, World in Conflict, etc where minimap is used on 2nd screen. But it also opens up other types of 'outside the PC' functionality e.g. Fallout 4 Pip boy app. It could even include this guy's weird BF4 setup where he launches the game's minimap in the browser on a 2nd screen whilst gaming on the primary screen.

    This would be best implemented as two distinct rows since there is no similarity in implementation (a companion app involves a standalone device whereas a secondary display is connected directly to the computer).

    This could be part of a new "Technical information" sort of table (under Other information) with rows for any other advanced/obscure/obsolete features that don't really fit anywhere else.


  6. MobyGames is still being updated. If you go to the "Updates" menu at the top of MobyGames you'll find links for pages such as New Games and Game Updates.

    New games show up more quickly on PCGamingWiki because of a difference in approach: PCGamingWiki has VetleBot automatically adding anything released on Steam whereas on MobyGames any crawled game data has to be approved before it shows up for regular visitors.


  7. On 5/15/2019 at 6:40 AM, Aemony said:

    If so, the icon for the "always on" locked state should probably be changed to blue, to be more neutral.

    In the eye of the beholder, and all that.

    Having it "green" suggests that whatever it is that's locked "always on" is positive, which typically isn't the case, such as with these:

    - Mouse acceleration/smoothing being locked to always on.

    - Anti-aliasing being locked to always on.

    - Subtitles/Closed captions being locked to always on.

    etc.

    It might be best to avoid anything that resembles the hackable state color (since this is quite the opposite of hackable). I have changed the color to the greenish-brown shade Suicide machine used for limited ticks, see what you think of that one.

    On 5/15/2019 at 6:40 AM, Aemony said:

    Hmm... "features that can't be configured at all would be set to false as usual" vs."while the proposed "always on" state would be used for any features that are active but cannot be configured."

    Poor wording on my part. For example, a game's anti-aliasing (AA) state:

    True: This feature can be configured natively (in-game or through the game's launcher or configuration/setup tool). Game has AA setting, configurable quality: true.
    Limited: This feature can be configured natively, but support is limited (e.g. anti-aliasing i on/off rather than giving a choice of quality levels). Game has AA setting, but only On/Off etc.: limited.
    Always on: This feature is always active and cannot be configured natively. Game always has AA (and no option): always on.
    False: This feature is not present and cannot be configured natively. Game has no AA (and no option): false.
    Hackable: This feature cannot be configured natively, but can be added or configured via modifications or console commands. Game AA can be configured/improved/etc. with external/unofficial methods: hackable (replaces any of the above).
    N/A ("Not Applicable"): This feature does not apply for this type of game. AA concept does not apply to this game: n/a.

    An always off state would not be needed.


  8. 3 hours ago, Aemony said:

    I love the idea with a lock though, although it introduces the question of what warrants a green or red lock.

    I have made an example update of the Section Table legend with reworked definitions. There is no "always off" in this example (features that can't be configured at all would be set to false as usual).

    Currently, true has sometimes been used to mean "this is active natively" (e.g. forced Vsync); with a reworking such as this, true/limited would always mean "this can be configured natively" while the proposed "always on" state would be used for any features that are active but cannot be configured.

    This would require rethinking the implementation or presentation of a couple of settings for consistency, e.g. frame rate (@Mirh has previously suggested FPS support should be redesigned).


  9. Gamer Alex on Discord suggested having a separate setting state for features that exist but can't be toggled. I have made an example below of what an "always on" option might look like.

    Such a state would only be available for settings where an "always on" state can exist.

    on-off.png.818f4ec82603f6a600f75c40b5898867.png

    9 hours ago, Aemony said:
    • Repurpose multi-monitor parameter somehow, since right now it tends to mean "wider aspect ratio than ultra-widescreen".
      • The "main element" of multi-monitor gaming today is AMD Eyefinity and Nvidia Surround, which isn't really relevant to the game itself, as all of that logic is separate from the game.
      • Possibly repurpose to real multi-monitor support? As in games that allows the use of a secondary monitor for minimaps, view etc? Real native multi-monitor support, that is, without involving AMD Eyefinity or Nvidia Surround?

    I would have to disagree with this. Multi-monitor methods combine multiple physical displays into a single virtual display, so behavior beyond that is entirely handled by the game itself (just like ultra-widescreen) apart from a few games using the AMD/Nvidia APIs to determine HUD positioning.


  10. This is a great idea. Notes about VirtualStore redirection are now displayed for Windows paths pointing to HKEY_LOCAL_MACHINE, %WINDIR%, and <path-to-game>.

    Feel free to suggest any improvements to the wording or other path types that need notes.


  11. I would recommend referring to how MobyGames has determined genre naming/separation. A while ago they changed several terms that were ambiguous.

    2D/3D should probably be avoided because this could be confused with the art style or presentation (e.g. many games from the '90s used 3D modelling to make pre-rendered sprites for a purely 2D game).


  12. I tried, but it wouldn't let me manually add a "Linux (Proton)" path. The "System" column would stay empty, and adding a "Linux" one would be wrong.

     

    The note is still wrong. The save games aren't located beneath the <Steam-folder> but beneath the Steam settings folder in the user's home folder. That's where they all seem to be. The Steam binary isn't installed at ~/.steam/steam/[/size]

     

    I meant you can add it with "Steam" as the label for the path.

     

    I have reworded the path mention in the note.


  13. Do you remember what it was that you added? I'm not familiar with this game but it looks like most things that were added anonymously are still present except for a couple of alternate fixes such as launching the game with "/B /GDBShaders KKMaps.bf" to fix a "BigFile" error--maybe that is one of the fixes you're referring to?

     

    If you're not sure what your changes were you can click on the "History" tab at the top of the page to see the full revision history.

     

    Other users might have decided to remove a particular fix if they thought the instructions weren't clear enough or the fix didn't work on their end.


  14. What the community seems to desperately need is a resource to:

    • Report game compatibility, possibly with a WineDB type rating of Bronze/Silver/Gold/Platinum - right now all we have is a spreadsheet on Google Docs.
    • Present fixes and workarounds for games that don't work out of the box.
    • Provide clear delineation between Proton versions, a game might work properly on one Proton version but not another.
    • Possibly provide an overview page with statistics on the percentage of games working, with a table that lets you sort by criteria such as Proton version or compatibility rating.
    I know this is a lot of effort and not to be taken lightly, but I feel it fits right in with PCGamingWiki's objective of providing fixes and workarounds for every single PC game.

     

    Steam Play Compatibility Reports provides functionality along those lines (this seems to be the main community site for this purpose). Additionally, games are also being logged (in a less structured way) on the GitHub Issues page. As a result I would not expect to see a database like this on PCGamingWiki in the near future (but these other sites might be linked to).

     

     

    The automatically added save game location isn't always right. For example, my MGS5 savegames are not stored in the prefix but at:

    ~/.steam/steam/userdata/{{p|uid}}/311340/
    
    So in my Linux home folder below the Steam settings.

     

    Some games store data in a userdata path like that in addition to or instead of the Windows paths listed. I have reworded the note to make this clearer. If a "Steam" path such as this isn't listed for a game you can add it (this isn't automated because because use of this folder varies--even some games with Steam Cloud support actually store the files in the standard Windows locations and then upload to the cloud from there).

×