Overhaul of the editing guide?

[Guest]

A long conversation between multiple PCGW staff members and PCGW community members on the official PCGW Discord brought up a good suggestion: overhaul the editing guide. I've taken the liberty of putting the chat log below, as it introduces the topic much more effectively than I ever could.

SirYuiJediYesterday at 7:31 PM
Actually, this game is 16:10 pillarboxed on a 16:9 display
that makes me think perhaps "limited" could be used for widescreen
SirYuiJediYesterday at 7:31 PM
Interesting idea. There's a couple other like that that I can edit if we follow that line of thought.
BaronSmokiYesterday at 7:32 PM
I guess the most important thing is mentioning the behavior in the notes
regardless of what the value is
SirYuiJediYesterday at 8:12 PM
Of course.
mastanYesterday at 8:18 PM
if it fills the whole screen area, then its good to go, even if it is vert-

Guide mentions that stretched(which fills the whole screen) is false for widescreen.
RoseYesterday at 8:43 PM
they probably meant vert- by that whole sentence though
mastanYesterday at 8:58 PM
Doubt that. Vert- does not distort picture. And if fov setting is available, vert- can be compensated.
If vert- does not break game then it's true for widescreen imo. But if it does and there's no other proper widescreen setting, then false.
Like in Broken Sword 5 for ultrawidescreen. Game offers next choices:
- Windowed
- Stretched 
- Vert- (breaks the game)
- Pillarboxed HD/FullHD
So I've put false to ultrawidescreen since no option allows to use full screen without stretching or breaking game.
GarrettYesterday at 9:06 PM
@BaronSmoki the ultrawide pillarbox grade handling seems to be a bug on WSGF's end (setting any of the other WSGF screen types to pillarbox gives an "unsupported" grade)
CptmoldYesterday at 9:09 PM
I think a Limited would be best.  For example Grim Fandango's widescreen support adds additional artwork to the sides to fit 16:9.
As long as notes can explain though anything should be fine.
RoseYesterday at 9:17 PM
I believe limited adds it to the list of games with uw support but it shouldn't be there
@mastan I was talking about the quote, not the wiki
mastanYesterday at 9:19 PM
Not sure about that. Word "even" suggests there is something besides vert-.
RoseYesterday at 9:21 PM
in any case, pillarboxing just means you resort to widescreen, zero benefits to a UW user. we have a row for widescreen. there's no need to claim pillarboxing is limited support
GarrettYesterday at 9:22 PM
yes, limited would be for things where it is truly supported, but has some noteworthy limitation
SirYuiJediYesterday at 9:36 PM
Yeah, because, for example, Vert- in a game with adjustable horiz FOV like… pretty much any 90s FPS, has no reason to be marked limited, because you can just change the FOV.

I really wish WSGF would stop labeling every game with adjustable FOV as hor+, though.
BaronSmokiYesterday at 9:37 PM
@Garrett, would you consider 16:10 pillarboxed on a 16:9 display to be "limited" enough for wide screen?
SirYuiJediYesterday at 9:38 PM
please say yes, please say yes
CptmoldYesterday at 9:47 PM
I think Limited would be good in Widescreen for any case where it's one or the other.  for example, I'd use Limited for Metal Gear Rising because it will stretch 16:9 no matter what resolution you pick, even 16:10 ones.  It distorts the image.
BaronSmokiYesterday at 9:49 PM
If it forces a stretch, that sucks. As a 16:10 gamer, I've gotten used to  letterboxing and it doesn't bother me.
SirYuiJediYesterday at 9:51 PM
I was never able to get 2.35:1 (or 1.33:1, 1.60:1, etc) resolutions to work in FFXV demo. It would always stretch it out to my desktop resolution (even though I set GPU scaling to maintain aspect ratio).
GarrettYesterday at 9:58 PM
some games get the aspect ratio from the current desktop resolution (not what you set for the game itself), so in those cases you'd need to change the desktop resolution as well
SirYuiJediYesterday at 10:00 PM
Which is obnoxious.
GarrettYesterday at 10:13 PM
also, GPU scaling only works for non-native resolutions; if the game is doing its own handling within the native resolution it won't have any effect
AemonyToday at 6:48 AM
Are you all saying that the parameters needs a thorough rethinking of how they’re applied? Noo, tell me it isn’t so! /s
As of right now, the widescreen etc parameters per the editing guide and abbreviations (mouse hover text) mostly only concerns itself with wether the game can output to a given type of resolution, and less with /how/ the actual support is handled
mastanToday at 7:26 AM
As of right now, the widescreen etc parameters per the editing guide and abbreviations (mouse hover text) mostly only concerns itself with wether the game can output to a given type of resolution, and less with /how/ the actual support is handled

So, ultrawidescreen should be true for this then? https://pcgamingwiki.com/wiki/File:Kaptain_Brawe_A_Brawe_New_World_21-9_stretched.png
PCGamingWiki
File:Kaptain Brawe A Brawe New World 21-9 stretched.png
PCGamingWiki - fixing PC games, one title at a time.
And wooden boards instead of black bars of pillarboxing https://pcgamingwiki.com/wiki/File:Kaptain_Brawe_A_Brawe_New_World_21-9_pillarboxed.png
PCGamingWiki
File:Kaptain Brawe A Brawe New World 21-9 pillarboxed.png
PCGamingWiki - fixing PC games, one title at a time.
AemonyToday at 8:17 AM
Hence why it needs a slight clarification/rework on all parameters
https://images.aemony.se/sharex/firefox_2019-05-12_14-17-04.png

Proper definition on what constitutes the various degrees of support is needed in the editing guide, with a better abbreviation text on the actual parameter
E.g.
True ==  Exposes ultra-widescreen resolutions and uses Hor+ (extending the visible area of the game in comparison to the reference view of the game).
Limited == Exposes ultra-widescreen resolutions, but with some sort of issue such as pillarboxed or stretched display or HUD elements, or Vert- (cropping the visible area of the game in comparison to the reference view of the game).
Hackable == Support can be improved why using hack/tweak of some sorts.
False == Does not expose ultra-widescreen resolutions through the settings of the game.
supports is a lose term that means different things for different people
Expack3Today at 8:37 AM
@Aemony I've never seen supports in this context mean anything other than "The game allows use of [x]". The degree of use determined by the game's implementation, which the guide - in the very example you provided - already goes into.
AemonyToday at 8:38 AM
Please define allows use of [x]
Because NieR:Automata allows the use of 21:9 resolutions without hacking ^^
Expack3Today at 8:39 AM
*allows use of [insert feature here]
AemonyToday at 8:39 AM
https://images.aemony.se/sharex/firefox_2019-05-12_14-39-23.png

Take that for example
It doesn't specify anything other than "Support does not count if the resolution is stretched."
So a 4:3 game that is pillarboxed on 16:9 resolutions is true, since it allows the use of 16:9 resolutions, arguably
Expack3Today at 8:41 AM
No, in that case it's Limited as which it technically supports 16:9, the full resolution is not used.
AemonyToday at 8:41 AM
Limited didn't exist when the parameters was created and the Editing Guide was written
Hence why I am for a rewrite with more in-depth details of each "level of support"
Expack3Today at 8:42 AM
That part I can agree on.
AemonyToday at 8:42 AM
Otherwise we're going to argue back and forth without having a clear definition to go by, because right now the reasoning I mentioned is as equal to yours since neither is actually covered by the Editing Guide
Anyway, it's something that requires a bit more work than your typical editing, hence why it haven't been made yet.
There's issues with most of the parameters that we might as well try and clear up whenever the ball starts to roll ^^
Expack3Today at 8:44 AM
This sounds like something which should be posted to the forums.
That way, all this won't get lost under the deluge of whatever else needs to be discussed on this channel.
AemonyToday at 8:45 AM
Definitely
It requires a discussion to be had around it to ensure that whatever end result ends up being good

 

[Aemony 142]

Overhauling the editing guide sounds too encompassing 🙂

What I think is needed is that we simply go into more detail about the various parameters that allows true/limited/hackable/false values, with the focus being on Video and Input sections primarily, with the Audio section secondarily.

 

A few example discussion points:

• 4K parameter seems heavily tied to 16:9 at the moment. Should preferably not be tied to any particular aspect ratio and more in general deal with whether a game can run at the 4K resolution of whatever aspect ratio the game is designed for (3840x2160 for 16:9-designed games, 3840x2400 for 16:10-designed games, 3840x2880 for 4:3-designed games).

 

• 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?

 

• Generally make it clearer whether a parameter means that a game have an option for toggling something vs. supports something. Right now the difference isn't always clear, which can cause new editors to interpret some parameters incorrect (e.g. should "mouse acceleration" be set to true or false if mouse acceleration is used, but no option is available to adjust it?)

 

• New parameter(s) in Audio settings detailing spatial audio support and possible tech required to enable it.
  • Either replacing the existing EAX support field, or supplementing it somehow.

 

The above is just a few examples that can be discussed. Past that, we should add abbreviations (hover explanations) to all of the parameters in the tables with a short and concise description of what the parameter tracks to make it easier editing without having to visit the Editing Guide. Some parameters already have this, and it simply needs to be extended to the rest after the discussions about what the parameters should actually mean have finalized.

[Garrett 214]

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.

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.

[Aemony 142]

31 minutes ago, Garrett said:

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.

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.

The fact that the methods does the heavy lifting and sets up a virtual display is the reason why its current use is wasted.

The parameter is basically relegated right now to a “wider-than-ultra-widescreen” field, a ”hyper-widescreen”. I believe we looked it up a few weeks ago and found that in most instances that the parameter mirrors the ultra-widescreen parameter, since it’s effectively just a subparameter of that.

Meanwhile we’re losing out on tracking actual games with native multi-monitor support, since those are basically combined with every other title that can “spoof support” through Eyefinity or Surround.

 

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

[Garrett 214]

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

[Guest]

@Garrett I can't help but think @Aemony was also referring to multi-monitor games such as Supreme Commander, where a secondary monitor can be independently used (e.g. no Eyefinity/Surround needed) as a full-size viewport. I'd add, as a much more obscure example, MechWarrior 2, whereby users who had both a supported color video card and a Hercules Graphics Array (HGA) discovered that while the monitor hooked up to their color video card showed things as normal, the monitor attached to the HGA would show developer debugging information.

I know the latter example is barely related to multi-monitor support, but I feel it's the purest example of "multi-monitor as independent monitors" rather than the Nvidia/AMD "multi-monitor as wider-than-widescreen". As of right now, the multi-monitor setting covers both, which can potentially cause confusion since "multi-monitor as wider-than-widescreen" is so common.

[Aemony 142]

On 5/13/2019 at 12:25 PM, Garrett said:

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

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.

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

 

On 5/13/2019 at 1:40 PM, Expack3 said:

@Garrett I can't help but think @Aemony was also referring to multi-monitor games such as Supreme Commander, where a secondary monitor can be independently used (e.g. no Eyefinity/Surround needed) as a full-size viewport. I'd add, as a much more obscure example, MechWarrior 2, whereby users who had both a supported color video card and a Hercules Graphics Array (HGA) discovered that while the monitor hooked up to their color video card showed things as normal, the monitor attached to the HGA would show developer debugging information.

I know the latter example is barely related to multi-monitor support, but I feel it's the purest example of "multi-monitor as independent monitors" rather than the Nvidia/AMD "multi-monitor as wider-than-widescreen". As of right now, the multi-monitor setting covers both, which can potentially cause confusion since "multi-monitor as wider-than-widescreen" is so common.

This is correct, and was what I was going for. There's not a lot of games with native multi-monitor support, but they exist and typically allows the use of the secondary monitors in some special way. For example some of the Battlefield games allows the use of a second monitor to show the minimap of the game, and some racing games have allows for native extended view across multiple monitors without involving AMD/Nvidia specific features.

The current multi-monitor parameter could almost entirely be worked into the existing ultra-widescreen parameter with the minor difference (if one exists) noted in the Notes field.

In my opinion, the multi-monitor parameter should be an highly obscured parameter, hidden by default, that properly categorizes games that allows the use of one or more secondary monitors for unique features independent of GPU features. Not be used as an "additional-ultra-widescreen" parameter.

[Garrett 214]

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:

 Game has AA setting, configurable quality: true.
 Game has AA setting, but only On/Off etc.: limited.
 Game always has AA (and no option): always on.
 Game has no AA (and no option): false.
 Game AA can be configured/improved/etc. with external/unofficial methods: hackable (replaces any of the above).
 AA concept does not apply to this game: n/a.

An always off state would not be needed.

[Andytizer 269]

On 5/30/2019 at 4:49 AM, Garrett said:

 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.

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

 Game has AA setting, configurable quality: true.
 Game has AA setting, but only On/Off etc.: limited.
 Game always has AA (and no option😞 always on.
 Game has no AA (and no option😞false.
 Game AA can be configured/improved/etc. with external/unofficial methods: hackable (replaces any of the above).
 AA concept does not apply to this game: n/a.

An always off state would not be needed.

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.

 

 

On 5/12/2019 at 8:53 PM, 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?

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

[Garrett 214]

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.

[Aemony 142]

I've created an initial version of the current input settings table with tooltips for all settings that tries to use standardized language to describe what the row is about: https://pcgamingwiki.com/wiki/User:Aemony/Sandbox

You can compare it to the original table in the Editing Guide: https://pcgamingwiki.com/wiki/PCGamingWiki:Editing_guide/Input_settings

It's possible it might be tweaked a bit when implemented for Video/Audio tables, but so for far it works fine, I think.

 

The key terminology that separate the rows are as follows:

• The game support XXXX - On these rows the state dictates whether something is supported or not, such as mouse input in menus, or native Steam Input API support.
• An option is available XXXX - On these rows the state dictates whether an option is available to tweak something. The new "always on" state should only be relevant on these rows, and never on the "the game support XXXX" rows.
  • 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".

 

I've tried to limit myself within the two above as much as possible, although some other minor variations are also used:

• The game has XXXX - This is currently only used for controller button prompts -related rows, as I found it slightly weird to type "The game support DualShock-stylized button prompts in-game" etc. although on second thought that might work as well.
• An extension of the previous field, XXXX - Self-explanatory, showcases that a row is related to the row above it.

 

Then there's two unique Steam Input related rows I couldn't get working under these restrictions:

• Official controller preset(s) - The developer of the game supplies official controller configurations for various types of controllers through Steam Input.
• Cursor detection - Indicates whatever Steam properly detects when mouse cursor is visible in game, allowing for automatic switching between controller layouts.

 

Please tell me what you think, and whether I should try to fill out the Video/Audio tables with similar tooltips on each row.

[Rose 273]

RoseToday at 7:26 PM
https://pcgamingwiki.com/w/index.php?title=Warhammer:_Chaosbane&diff=788235&oldid=788229
had to undo these by SirYodaJedi
PCGamingWiki
Index.php?title=Warhammer: Chaosbane&diff=788235&oldid=788229
Warhammer: Chaosbane at PCGamingWiki - bugs, fixes, crashes, mods, guides and improvements for every PC game.
I don't see how setting surround sound to always on just because it's there is of help
there are no clear disadvantages to how most games do surround sound - simply by using all the speakers, with no toggle
AemonyToday at 7:41 PM
@Rose always on is the proper value to use when the game supports surround sound but does not expose an option to configure it manually
The color is simply because it's neither true nor false, and should not be either
Blue was thrown around as another color, but was discarded because of hackable already using it
RoseToday at 7:43 PM
has any surround sound user ever complained about not being able to switch to 2.0 through the game UI?
AemonyToday at 7:44 PM
That's not the point. It's to separate games between those that require manual configuration to enable it, or those that automatically configures themselves, basically
The use of always on on AA parameter is for a similar purpose
RoseToday at 7:45 PM
wasn't it created to suggest something is limiting? for surround sound it's not
AemonyToday at 7:45 PM
No
It was created to suggest that something is always on
We already have limited for rows with limited support etc
RoseToday at 7:46 PM
was surround sound specifically discussed?
AemonyToday at 7:46 PM
This is separate from that
It was one of the parameters @Garrett added support for and mentioned in another channel
https://discordapp.com/channels/165183350913499136/326048443040530432/586102001679597578
The editing guide have been updated to reflect its use in the case of surround sound as well
RoseToday at 7:50 PM
alright, I see the new description and I don't generally disagree on it. then the issue would lie in the unified color that looks like it's for something limiting or for a half-measure, while I'd bet for surround users it's the desired behavior
AemonyToday at 7:50 PM
@SirYodaJedi's edits to the Warhammer article seems in line with the new always on state if there is no built-in toggle for that game for either AA, surround sound, or subtitles
The color is easily changed, and will probably be changed. It was taken because it was easily available after SuicideMachine used it for his limited icon for the platform features overview
RoseToday at 7:51 PM
no wonder it looks limiting!
Yoda's change to the subs row is not correct at all, per the reason I stated in the edit description
AemonyToday at 7:53 PM
Always enabled at the cutscenes and dialogue.[5]
I assume there's no option to disable subs?
RoseToday at 7:53 PM
the characters speak beyond dialogue
when they're out of energy and such
no subs for it
AemonyToday at 7:53 PM
If so, then set it to always on and make a note about how some phrases don't have subs
Games typically includes random phrases and stuff here and there that might not have subtitles
What's important is whether the important stuff have subs or not
https://community.pcgamingwiki.com/topic/4103-overhaul-of-the-editing-guide/?tab=comments
PCGamingWiki PCGW Community
Overhaul of the editing guide?
A long conversation between multiple PCGW staff members and PCGW community members on the official PCGW Discord brought up a good suggestion: overhaul the editing guide. Ive taken the liberty of putting the chat log below, as it introduces the topic much more effectively than...
There's the thread that touches upon clarifying a lot of what the rows actually meant and how users are supposed to approach them, etc
My last reply from 3 hours ago introduced a first draft of trying to (as much as possible) separate parameters into "The game support XXXX" and "An option is available XXXX" to make it clearer whether it's supposed to be set based on whether a game supports the use of something  or has a toggle to configure something
The subtitles row would basically become An option is available to toggle subtitles for dialogue and conversations in the game or something similar, which would mean always on would dictate that subs are available, but can't be disabled
RoseToday at 8:06 PM
the icon really needs to be changed urgently if it's to be used so widely, because most of the time it will not point at limits or half-measures associated with the color yellow and further confounded by the lock icon
AemonyToday at 8:16 PM
Any suggestions for an alternative color scheme?
RoseToday at 8:18 PM
why was it decided against green?
AemonyToday at 8:19 PM

 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. 

always on should be neutral, as it can be either "positive" or "negative" depending on the scenario
RoseToday at 8:23 PM
for surround sound it's predominately if not always positive. for subtitles it's neutral indeed but not limiting. I don't think you had games like Chaosbane in mind when that example was used. it's not a movie or text always appearing on the screen. it's very situational. for AA and smoothing that may be the case, but for AA it depends on the implementation - whether it makes the game look blurrier
AemonyToday at 8:24 PM
We can't use separate colors for the setting based on the parameter involved, hence we are going for a generic color that can be applied across all
The current "green-brownish" color have the benefit of being partially based in brown, which apparently is the color you get if you mix green + red together
RoseToday at 8:26 PM
most games support surround sound, and something visibly different would needlessly highlight the row
AemonyToday at 8:26 PM
And it's appropriately lame
Any color change would have that effect
It's a minor threshold in the long run that only exist when a new state is introduced
RoseToday at 8:27 PM
so keeping it green wouldn't. the lock would say enough to those interested
AemonyToday at 8:27 PM
There's more issues with keeping it green (it's not neutral as it needs to be) than not
Keeping it green is not an option
It would end up with more OMG PCGW THINKS FORCED MOUSE ACCELERATION IS A GOOD THING!!! than having it the current color
I'd prefer blue myself, but as mentioned it clashes somewhat with the hackable state
The opposite of the color blue is apparently orange, but having it orange separates it even more than its current green-brownish color
RoseToday at 8:35 PM
it shouldn't be at the cost of implying surround sound or subtitles are bad things. you can poll surround sound users and I don't think they'll ever say it's a bad / limiting / questionable thing to have a game use all their speakers and offer no toggle
yellow is commonly seen as a warning color, across the world
there's nothing warning about surround sound being that way
AemonyToday at 8:36 PM
It's neither yellow, orange, or red though
It's green-brownish
RoseToday at 8:36 PM
let me get that color picker :smile:
AemonyToday at 8:36 PM
Anyway, you can't merely focus on a single parameter and argue the semantics of the use of said color for that particular parameter
We use general colors applied across multiple parameters, and needs something that encompasses all possiblities as much as possible
I can bring up that we shouldn't use RED for the color FALSE since No Mouse Acceleration option available or present IS NOT NEGATIVE all day, but we're not going to change the color of all FALSE values to green simply because having no mouse acceleration present in a game is generally considered a good thing among PC gamers
RoseToday at 8:38 PM
https://cdn.discordapp.com/attachments/327384491343478784/586217373736894479/unknown.png
AemonyToday at 8:39 PM
63.1 green vs. 62.7 red
Almost properly balanced
https://tenor.com/view/perfectly-balanced-thanos-gif-13078930
RoseToday at 8:40 PM
https://en.wikipedia.org/wiki/Yellow#Visibility_and_caution
Yellow
Yellow is the color between orange and green on the spectrum of visible light. It is evoked by light with a dominant wavelength of roughly 570–590 nm. It is a primary color in subtractive color systems, used in painting or color printing. In the RGB color model, used to cre...
poll the surround sound users though :smile:
AemonyToday at 8:41 PM
I am one, I am well aware that it's not seen as a negative thing
But again, general application is of importance here
Unless you have better alternative colors than green to to suggest then the current color will most likely stand for now since Andy also gave its approval in the forum thread
It's appropriately "meh" and balanced between green and red that it can serve well enough for now
RoseToday at 8:46 PM
the wiki really needs global RfCs for this type of stuff so that a decision of this scope doesn't revolve around just one or two people
RoseToday at 8:53 PM
I get the need for it and the color for AA and mouse acceleration but the rest seems like an afterthought affecting hundreds of pages and viewers
AemonyToday at 8:56 PM
There's too many scenarios and edge cases to account for every single thing. At one point or another you'll just have to jump in and tidy up the minor issues that might arise after. As it stands, the color of the icon is hardly an issue beyond the initial notice that it will cause readers before they get used to it
AndytizerToday at 8:57 PM
I think the yellow colour is good
MarioysikaxToday at 8:59 PM
wait, does the template insertion now insert current date automagically?
AemonyToday at 8:59 PM
Yes
MarioysikaxToday at 9:01 PM
I love this
AemonyToday at 9:03 PM
You're welcome :smile:
RoseToday at 9:03 PM
where Aemony sees people angry about mouse acceleration being green and surround sound users being edge cases, I see that most people don't even notice the blur of AA, they don't know what mouse acceleration is, but if they're surround sound users, I can imagine them being angry at the notion of something cautionary or neutral about games automatically adjusting to their setup
AemonyToday at 9:03 PM
Even inserts your username for refuser templates

something cautionary

 >_<
RoseToday at 9:04 PM
I demonstrated it with the wiki link
AemonyToday at 9:04 PM
Tell them to read the legend for the icon then, and they would understand its purpose
RoseToday at 9:07 PM
the same could be said for it being green and applied to AA, and you'd have even more success because you'd argue with the lock icon in hand
AemonyToday at 9:08 PM

Guys? You see that green lock? Well, that means you can't disable AA! Isn't that GOOD!

Again though, these sorts of changes aren't implemented to cater to certain use cases or scenarios or groups of people
RoseToday at 9:16 PM
a cautionary color and a lock and "no native option" for eventually hundreds of pages where the option is universally seen as positive and good is just not right and much larger in scope than "some edge cases". I'll conclude with that, since you're quite set against the idea of green!
AemonyToday at 9:17 PM
It's not a cautionary color
It just isn't green
As for no native option, that can be rephrased better
But it is accurate in that the game includes no native option built-in to adjust the feature
I'm also open to suggests of other alternative colors
As I've mentioned repeatedly
If you think the current color is to "cautionary", then suggest another color (not green, red, or blue) that can be used instead
AemonyToday at 9:22 PM
The thread that touched on this matter is also still ongoing, and we're looking to implement various changes to clear up confusion and make it clearer for users (as I mentioned at the start somewhere I think), and part of those changes are almost certainly a rephrasing of the tooltips for these various states, as they don't properly account for the various scenarios they're used for.

 

[Garrett 214]

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

[Satsun 7]

I agree that the audio section should be broken out more for the spatial audio options, going as far as having separate boxes for EAX, A3D, and just "Spatial" or "Windows Spatial". My primary justification is because I really like how this list of HDR games is able to be generated based on that box being checked in a game's page. Since EAX, A3D, and Windows Spatial are all different enough, I think it would be a bit frustrating to be looking for a modern game with spatial options based on the 'EAX' box and have tech that hasn't been relevant for over a decade mixed in with the results. I've been noticing that spatial notes are being put in the EAX field, so I'm guessing a decision regarding this hasn't been made within the past year. 😄

[Aemony 142]

1 hour ago, Satsun said:

I agree that the audio section should be broken out more for the spatial audio options, going as far as having separate boxes for EAX, A3D, and just "Spatial" or "Windows Spatial". My primary justification is because I really like how this list of HDR games is able to be generated based on that box being checked in a game's page. Since EAX, A3D, and Windows Spatial are all different enough, I think it would be a bit frustrating to be looking for a modern game with spatial options based on the 'EAX' box and have tech that hasn't been relevant for over a decade mixed in with the results. I've been noticing that spatial notes are being put in the EAX field, so I'm guessing a decision regarding this hasn't been made within the past year. 😄

After extensive discussion, I think we're close to finalize the details of how we would cover it best. The way I see right now is a multi-parameter approach like the DualShock 4 parameters under input, where we both track support (native, hackable, etc) separately from the mode supported itself (DirectSound3D, Windows Spatial, etc).

 

Inputting e.g. "EAX" into the mode field would interpret it as DirectSound3D and show it as such.