Mirh 103 Share Posted November 24, 2016 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. Link to comment Share on other sites More sharing options...
Mirh 103 Share Posted March 8, 2017 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. Link to comment Share on other sites More sharing options...
ThatOneReaper 51 Author Share Posted April 4, 2017 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. Blackbird 1 Link to comment Share on other sites More sharing options...
Mirh 103 Share Posted April 5, 2017 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? Link to comment Share on other sites More sharing options...
Guest Share Posted April 5, 2017 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. Link to comment Share on other sites More sharing options...
Mirh 103 Share Posted April 11, 2017 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. Link to comment Share on other sites More sharing options...
Garrett 214 Share Posted April 11, 2017 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. Link to comment Share on other sites More sharing options...
Mirh 103 Share Posted April 13, 2017 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. Link to comment Share on other sites More sharing options...
Recommended Posts