Jump to content


Editing guide

  • Please log in to reply
144 replies to this topic

#141 Mirh


  • Posts: 798

Posted 05 April 2017 - 09:18 PM

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?

#142 RaTcHeT302


Posted 05 April 2017 - 10:46 PM

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.

#143 Mirh


  • Posts: 798

Posted 11 April 2017 - 10:17 PM

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]


#144 Garrett


Posted 11 April 2017 - 11:28 PM

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.

#145 Mirh


  • Posts: 798

Posted 13 April 2017 - 05:13 PM

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.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users