Jump to content

PCGamingWiki will use a Single Sign On (SSO) system to bridge wiki and forum accounts which is ready for testing. You may login using the 'Login with PCGamingWiki' button on both the wiki and the forum, which will soon be the only option. If you have any issues please message Andytizer on Discord.

ThatOneReaper

Editing guide

Recommended Posts

Dude like, your posts are honestly unreadable, stop doing that tiny text thingy, it makes everything so much harder to understand. I can't even be bothered to read them because of that.

 

I know it's mean but I'm not asking for much. Is one of your links broken? Did you mean to link another page? http://pcgamingwiki.com/wiki/Assassin

 

I have no idea what you could possibly be referring to.

Share this post


Link to post
Share on other sites

I have no idea what you could possibly be referring to.

 

I really don't see why you had to do that, it really strains my eyes really badly, I had already asked him if he could stop doing that a while before, it really puts me off from reading anything he writes.

Share this post


Link to post
Share on other sites

Dude like, your posts are honestly unreadable, stop doing that tiny text thingy, it makes everything so much harder to understand. I can't even be bothered to read them because of that.

 

I know it's mean but I'm not asking for much. Is one of your links broken? Did you mean to link another page? http://pcgamingwiki.com/wiki/Assassin

For the tenth time, if it was important I wouldn't have miniaturized the thing in the first place.

Anyway, the second and third links were pointing to Assassin's Creed IV Black Flag and Assassin's Creed Liberation HD

 

Actually Mighty Switch Force! Hyper Drive Edition and Mighty Gunvolt vsync introduces so massive input lag people notice it (talking near one second) and indeed disabling or forcing vsync externally, did fix the issues not only for me but for others as well.

Yes, sorry. Such cases were indeed what I meant when referring to Dead Space.

 

 

 

 

Share this post


Link to post
Share on other sites

I've been reading a bunch of PMs I had gotten and Pridit had sent me this a while ago.

http://community.pcgamingwiki.com/topic/415-abandoning-title-case-in-general-information/

 

Is there a page related to the title case itself? The editing guide is really big right now and I didn't find anything related to it.

 

Also where should the 60 FPS lock note thing go? In the 60 FPS field or the 120 FPS field? To me it made more sense to place it inside the 60 FPS field seeing as it's less disconnected that way but I'm not sure.

9pK39lw.png

Share this post


Link to post
Share on other sites

I like it in the 120 FPS field personally, because as a 60 Hz user I don't care if the game is locked to 60 FPS.

I'll do that then, it doesn't matter too much to me but I asked just in case, seeing as I had seen another similar case.

Share this post


Link to post
Share on other sites

The |minOS = field should normally have only one entry. All other supported versions of the OS family should be placed in the |recOS = field

This is wrong in several ways.

 

Most importantly, when the you recommend different OS's for both Min and Recommended it creates the impression that it has different functionality and works better on the recommended OS.

EVEN though in those cases it is functionally 100% the same and is recommended just the same.

 

Key point. Raiden IV, on Steam, min and recommended are both listed as Windows 7 AND 8. On GOG 7/8/10 are all listed on both.

 

Why on earth would 8 or 10 be more recommended or important? They wouldn't be, because they aren't. But listing ONLY them as recommended will create potential confusion for people.

 

(EDITED: Whoops)

Share this post


Link to post
Share on other sites

Mhh I guess this distinction had a lot more sense 15 years ago when you could support 98, 2000 and XP, and indeed "prefer" just one of them, for whatever reason (going from different kernel, to different supported drivers).

And exactly in light of this, we shouldn't assume everything between two supported release is supported.

 

Last but not least another question arises in the end: if developer doesn't "respect" our minimum/recommended conventions.. should these "override" its decision?

Because I know the policy* is "just stick with what dev says", but I wonder if that might not just apply to "contents", rather than "syntax".

 

And I'd like a note stating that game readme has always priority, because too many times I find cover scans on mobygames from different publishers/distributors with different information.

 

*= which is a bit misleading for end user, considering he might expect we "verify/check" them

 

------

 

On another news, I take advantage of this post to note down a discussion we had on IRC on the formal definition of "different game" (rather than different "editions of the same release") when coping with discerning cases like this from this.

We ruled off "title" and "publisher decisions" since they are just extrinsic (same rose but different names)

And we ruled out "if old fixes applies" given things like for example Omikron digital version. Where, for as much as you suffer of ~95% less problem than original release, it's nothing more than a simple dll that handles everything (not dissimilarly from being considered just a "vendor specific" patch)

 

So in the end the point should be "having an [enough] different codebase".

Which isn't still a definitive answer (when enough is enough? and what count as difference?) but at least seems the "most comprehensive" description.

I hope we'll be able to further refine it in the future, perhaps by analyzing corner cases like this, this or this.

 

EDIT: or this, lol.

Edited by Mirh

Share this post


Link to post
Share on other sites

Why are we allowing these people to get away with "well.. there are problems when cap is disabled.. but whatever" claims?

I mean, why there's no clear criteria about issues for status ?

 

And why are we directly mentioning fraps and bandicam?

 

 

 

EDIT: What's the point of references?

Giving credits, helping the "future editor" understand when that may apply or just prove that there's a person on Earth believing that fixes something?

 

Seriously, this last link is the symbol of everything stupid I might be against

 

What's the value? Who is this value in? The editor? Or the average user?

A noob definitively gives no care. What's then?

Who might click them? Who might be interested in?

And I just see people that wants to deepen their knowing. Credits to first finder or official statements being kind of incidental cause.

But if even developer has no sound clue.. That's still not a reason.

 

Edited by Mirh
Add references thought here, so not to spam the world

Share this post


Link to post
Share on other sites

What do we do if sys req change over time?
 
For example, I noticed Overwatch dropped Vista from supported OS (although it should still work in the end, but this is another matter)
What if we were talking about a game requiring greater specs after an update or for an expansion?

 

EDIT: what about mentioning hardware/OS still working but not officially supported/mentioned?

 

P.S. we should tell editor to check for possible ways to decouple dubbing/interface/subtitles when possible.

Share this post


Link to post
Share on other sites

What do we do if sys req change over time?

 

For example, I noticed Overwatch dropped Vista from supported OS (although it should still work in the end, but this is another matter)

What if we were talking about a game requiring greater specs after an update or for an expansion?

 

EDIT: what about mentioning hardware/OS still working but not officially supported/mentioned?

With modern games getting automatic updates - especially in case of online multiplayer games where latest patches are actually required to even be able to play, newest system requirements are the ones that are kept and if they change to drop some significant support over time, like old OS or intel HD graphics, then put it as note. 

 

And I think similar method of thinkig should be applied to game working on OS that is not supported, who are going to check the game every time it's updated? Of course I do not see any issue of having note that "worked on Windows 2000 with version 1.01".

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

With modern games getting automatic updates - especially in case of online multiplayer games where latest patches are actually required to even be able to play, newest system requirements are the ones that are kept and if they change to drop some significant support over time, like old OS or intel HD graphics, then put it as note.

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.

 

And I think similar method of thinkig should be applied to game working on OS that is not supported, who are going to check the game every time it's updated? Of course I do not see any issue of having note that "worked on Windows 2000 with version 1.01".

Nobody of course.

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

 

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

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

 

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.

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Cool.

For as much as I feel like you are pretending nobody on earth will ever need that, which imo is a big underestimation of the diverse people "needs".

 

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.

I'd hardly see somebody with unsupported software cause troubles. trivia: technically even newer (and not only older!) Windows versions count for some developers

I mean, you just politely need to ask him "try the supported XYZ version" and see if things improve.

 

As for hardware.. Really, I haven't all that distrust in humanity to believe one would complain because his Pentium 4 doesn't run smoothly arma 3.

 

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

Ok, that's how an ideal world would work.

But of course we aren't, and that's why even we need a wiki for fixes in the first place.

 

Said this, we aren't devs so we don't have to care for "formalities". 

Also, as I was saying here (and probably in other rants here or there) there's simply NO criteria devs use to establish them.

 

Given we bring up this argument then, I'd link to the relevant thread.

 

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?

I think you are a bit too much dramatizing the story.

I mean, it seems like we are talking about sorcery or something.

 

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

If that's not something you can workaround, obviously.

 

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

Once we manage to find a wording for which words "work", "run", "support", "start" can't be misunderstood for something they aren't (e.g.: you can never figure out if "we are not supporting" simply refers to "bug reports & complaints" or literally "exe crashes straightaway") I don't believe all that pedantry will be needed.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Mhh, yes I know the general story. That's why I asked this in the first place.

 

This feels worse than simple commands/parameters on many different of the aspects I always thought native/hackable distinction to be expected to answer,

E.g: time wise it's very long.

Difficulty and explanation-length wise? Games with consoles enabled by default (or simply toggleable in-menu) look way easier to handle.

What other parameters are there then?

Share this post


Link to post
Share on other sites

What do you need to enable on Tomb Raider? I can't picture what you are asking.

 

Anyway it should be kept simple, Hackable for anything outside, Native for anything inside. Most editors are going to be confused if we add too many exceptions.

 

If things get a bit too overly specific it might lead to more convoluted edits, along with edit wars as to why "this thing should be like this because I said so" which can go on forever.

 

I have no idea what your actual problem is with Tomb Raider anyway.

Share this post


Link to post
Share on other sites

Most editors are going to be confused if we add too many exceptions.

And indeed I wanted to make clearer the criteria in the first place?

 

"Hackable for anything outside, Native for anything inside". Yeah, so easy!

Then, do in-game console count as native? Oh, and what about those games where you can write commands in normal chat by just putting a slash before?

 

My personal take on the matter has always been "simplicity" (or difficulty if you want to see the question from the other side of the coin).

I mean.. why else should the user care about the status otherwise? Curiosity for its own sake?

It has to serve a practical need first of all, and whatever "I shouldn't worry" about the feature, or *effort* is needed seems it.

But this "native" TR madness really pushes the boundaries of the examples-based rule.

Not only it is tedious, but also counterintuitive (command line switches seems arguably a cakewalk).

 

Now, IMO the only way out seems redefining the goalposts of "effort":

  • either we take a hard stance on the matter [aka, everything that isn't blatantly overwatch-settings-levels easy, showy and self-explanatory is hackable(but imo, this would fit a hypothetical PCGWKids, if any)]
  • or we relax a bit the norms, say either (or a combination?) of:
    • "no external tools needed" (no notepad; but game icons, and so parameters, should considered as "parts" of the game, and thus count as native)
    • "shouldn't take more than 10 seconds" [to do]
    • "shouldn't take more than 5 seconds" [to read how-to]

Cheers.

Share this post


Link to post
Share on other sites

Currently, the native/true state is not based on the complexity of the process, so it applies even when it involves using a specific combination of options/hotkeys (e.g. AA in Thief: Deadly Shadows requires disabling bloom). It also applies when native support is available but limited (e.g. Gothic only lists low-end widescreen resolutions).

 

Hackable applies to results that can only be achieved though console commands, command line arguments, configuration files, mods, or other manual methods.

Share this post


Link to post
Share on other sites

Yes, I do know (it's not the first time I edit the wiki :*)

 

My more profound question was: what would be the point of this distinction in the first place?

Then I just went on trying to make up for an answer.

Share this post


Link to post
Share on other sites

  • Who's Online   1 Member, 0 Anonymous, 76 Guests (See full list)

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Forum Statistics

    1,197
    Total Topics
    6,724
    Total Posts
×