Help talk:Style guide/Bugs

Two potential changes

I'll just get right into it:

1. Adjust the "Bugs should be able to happen while playing a regular, non-modified game/server." guideline to exclude game-sided bugs. E.g., a bug with sv_pure 1 is that having a custom taunt sound causes the default sound of the taunt to slow down and play for the duration of the modified file. This is an issue with sv_pure not properly handling the custom files, rather than a bug caused by the custom files itself. An example of a bug with custom files is that things will lose their team colour if you select the RED/BLU buttons on the Loadout menu on custom HUDs, because they change the materials, but if this is kept that way on sv_cheats 1 servers it will keep the modified materials meaning everyone is on the same team.
   The difference here is that this bug was created by custom files, while the custom taunt sound bug is created by an in-game command not working properly but it merely involves custom files.

1. Bugs produced by setting values of certain console commands higher than intended should not be covered. This sounds very broad, but it really isn't. A good example is that the Shortstop's viewmodel shows a bunch of bullets at higher values, but at 70 (which is what the intended limit is as indicated by the game's slider in the options menu) these are not visible. People putting the viewmodel_fov to a higher range than it's meant to is obviously going to produce artifacts like that, so we'd have to put an artificial limit on these kinds of things (e.g. do we count up to values of 90? Or 110? Or the max the command allows?), or just altogether agree it's a bit silly to document a bug like this.

I hope it was all clear.
| s | GrampaSwood (talk) (contribs) 02:07, 6 June 2024 (UTC)

  For your first example, they require custom files/modification to materialize so they shouldn't be included in my opinion. The sound bug wouldn't happen without the custom file. So by definition it is a bug caused by the custom file. At least that's how I see it. No custom file, no bug. I guess you could maybe argue that it's sorta like a "Schrödinger's bug" kind of thing where the bug technically exists but also doesn't and you can only really prove it by using the custom file......But I just don't really see why something like what you're describing should be covered. I don't see the benefit.

  For the second example involving console commands I agree. Seems silly to cover bugs that are only achievable via console commands. As for actually enforcing that, I'm not really sure what the best approach would be. But either way I don't think the wiki should be covering stuff like that.
Mediarch ♥ Talk ♥ My Edits 02:51, 6 June 2024 (UTC)

  +1 for Mediarch's opinion, exactly what I want to say

Profiteer the tryhard (talk|contribute) 03:04, 6 June 2024 (UTC)

  Completely agree with Mediarch, that's exactly how this should be handled. Just leaving my opinion

jestie. Talk 04:00, 6 June 2024 (UTC)

The main difference in the first example is that the cause of the bug lies within Team Fortress 2 rather than within the custom files. What actually produces this bug is setting sv_pure to 1, the files themselves are working entirely fine, which means the issue doesn't lie with having custom files but rather with how the command handles these files thus not making it a bug with the custom files. As for "I don't see the benefit", it's the same for why we document any bug and people can know if their custom files are the issue or if it's a game issue.
| s | GrampaSwood (talk) (contribs) 13:07, 6 June 2024 (UTC)