Glitch City Laboratories Forums

Lab α: The Lobby => Wiki Discussion => Topic started by: bbbbbbbbba on September 29, 2019, 06:52:23 pm

Title: On the definition of "glitch"
Post by: bbbbbbbbba on September 29, 2019, 06:52:23 pm
Recently there has been some heated debate on the Discord, which was apparently hated by everyone not in it. Even though I dislike the forum with passion, I have to admit that it might be a better medium for level-headed discussion. Therefore here I am:

How should we define, or at least try to define the word "glitch" on this site? Should it be...
I know I am missing some options.

Now, the advantages of a more extensive definition is probably obvious: We become more inclusive, and we can retain more information. However, a more specific definition would help with categorization, and would increase the average quality of our pages. Furthermore, a less extensive definition doesn't mean we have to exclude everything not defined as "glitches": Glitch-related things can have pages too, and focusing on how they are related to glitches would help a lot with the organization.

So... what do you think?
Title: Re: On the definition of "glitch"
Post by: Parzival on October 01, 2019, 08:55:00 am
Glitch: Unintended "features" working in (obv) ways unintended, such as ACE.

Bug: Intended features working in ways unintended, such as the 99 item bug or the Map FF crash seen when exiting a map in an undefined direction.
Title: Re: On the definition of "glitch"
Post by: RETIRE on October 01, 2019, 09:00:52 am
Any unintended phenomenon that can be observed without external modification ("A Pong game written with ACE is a glitch")?

This is what is what is the closest to my thought process.
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 01, 2019, 10:51:50 am
Glitch: Unintended "features" working in (obv) ways unintended, such as ACE.

Bug: Intended features working in ways unintended, such as the 99 item bug or the Map FF crash seen when exiting a map in an undefined direction.

Hmm... how many of you would support a split between "bug" and "glitch"? On the Discord discussion other participants were against it on the ground of K.I.S.S., but I think the point of terms is to categorize things, and the word "glitch" is not doing that now.
Title: Re: On the definition of "glitch"
Post by: Parzival on October 01, 2019, 11:32:15 am
Glitch: Unintended "features" working in (obv) ways unintended, such as ACE.

Bug: Intended features working in ways unintended, such as the 99 item bug or the Map FF crash seen when exiting a map in an undefined direction.

Hmm... how many of you would support a split between "bug" and "glitch"? On the Discord discussion other participants were against it on the ground of K.I.S.S., but I think the point of terms is to categorize things, and the word "glitch" is not doing that now.
In most facets of computing and technology, these two terms are distinct, so I'm all for it here.
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 01, 2019, 02:15:39 pm
Well, the thing is that in the English-speaking video game community, the word "glitch" is used in a sense that does not at all overlap its usual definition, and closer to what "bug" is supposed to be. On the other hand, since "bug" is less used in this community, maybe that's the word we can define better.

I think your definition for "bug" may still be too broad, as almost every subroutine can be made to go berserk with malformed input data (which we can almost always force to happen, with ACE and whatnot). In a sense, the map FF crash may well be "intended", seeing as the developer probably intentionally chose the value 0xFF and decided that it won't matter, because the map design would never allow the player to exit in that direction.
Title: Re: On the definition of "glitch"
Post by: Parzival on October 02, 2019, 10:18:50 am
Well, the thing is that in the English-speaking video game community, the word "glitch" is used in a sense that does not at all overlap its usual definition, and closer to what "bug" is supposed to be. On the other hand, since "bug" is less used in this community, maybe that's the word we can define better.

I think your definition for "bug" may still be too broad, as almost every subroutine can be made to go berserk with malformed input data (which we can almost always force to happen, with ACE and whatnot). In a sense, the map FF crash may well be "intended", seeing as the developer probably intentionally chose the value 0xFF and decided that it won't matter, because the map design would never allow the player to exit in that direction.
technically ACE would be classified under "glitch" as ACE isn't (usually) the result of something intended going nuts, so things unachievable without ACE would be glitches and not bugs as you're not using a feature written into the game on purpose to do weird s**t, you're writing your own code.
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 02, 2019, 01:21:10 pm
technically ACE would be classified under "glitch" as ACE isn't (usually) the result of something intended going nuts, so things unachievable without ACE would be glitches and not bugs as you're not using a feature written into the game on purpose to do weird s**t, you're writing your own code.

Well, using an item is an intended feature, but with invalid item IDs, that can cause ACE. Of course you can say the functionality of an item is a "feature" in itself, but then the problem is how to slice a playthrough into different (intended and/or unintended) "features".
Title: Re: On the definition of "glitch"
Post by: Parzival on October 03, 2019, 10:56:04 am
technically ACE would be classified under "glitch" as ACE isn't (usually) the result of something intended going nuts, so things unachievable without ACE would be glitches and not bugs as you're not using a feature written into the game on purpose to do weird s**t, you're writing your own code.

Well, using an item is an intended feature, but with invalid item IDs, that can cause ACE. Of course you can say the functionality of an item is a "feature" in itself, but then the problem is how to slice a playthrough into different (intended and/or unintended) "features".
isn't defining unclear boundaries fun? xD

I would agree, however I'd say individual mechanics would be "features", including item functions (as, with ACE, we're not executing, say, a dev tool that jumps to RAM, we're just abusing a badly-made table lookup function to look up a bad item index, which jumps to an area it expects to contain a "feature")
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 03, 2019, 11:46:37 am
isn't defining unclear boundaries fun? xD

It is! And I'm happy that you think the same.

I would agree, however I'd say individual mechanics would be "features", including item functions (as, with ACE, we're not executing, say, a dev tool that jumps to RAM, we're just abusing a badly-made table lookup function to look up a bad item index, which jumps to an area it expects to contain a "feature")

What do you say about memory manipulation by expanded item pack (and expanded other things)? Switching items around and tossing them are both intended features, but they can change so much of the RAM that it almost works like a cheating device.

Also how about arbitrary script execution (in later gens)? Every line of arbitrary script executed would be an "intended feature". (I would have mentioned return-to-libc attack (https://en.wikipedia.org/wiki/Return-to-libc_attack), but I don't think that's known to be possible in any of the Pokémon games.)
Title: Re: On the definition of "glitch"
Post by: Parzival on October 03, 2019, 12:28:09 pm
isn't defining unclear boundaries fun? xD

It is! And I'm happy that you think the same.

I would agree, however I'd say individual mechanics would be "features", including item functions (as, with ACE, we're not executing, say, a dev tool that jumps to RAM, we're just abusing a badly-made table lookup function to look up a bad item index, which jumps to an area it expects to contain a "feature")

What do you say about memory manipulation by expanded item pack (and expanded other things)? Switching items around and tossing them are both intended features, but they can change so much of the RAM that it almost works like a cheating device.

Also how about arbitrary script execution (in later gens)? Every line of arbitrary script executed would be an "intended feature". (I would have mentioned return-to-libc attack (https://en.wikipedia.org/wiki/Return-to-libc_attack), but I don't think that's known to be possible in any of the Pokémon games.)
Expanded item pack is an intended feature running out of bounds (it is the EXPANDED pack after all) to the point it reaches something like 40% of RAM. Memory manipulation via expanded pack would be used either for setting up ACE payloads or manipulating things to do other things, whether classifiable as "bug" or "glitch".
Since we're doing things to accomplish other things here, we need to box things into individual items: expanded pack being its own concept and anything you do with it being another.
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 03, 2019, 01:20:21 pm
... so things unachievable without ACE would be glitches and not bugs...
Since we're doing things to accomplish other things here, we need to box things into individual items: expanded pack being its own concept and anything you do with it being another.
OK, we might have had a misunderstanding here. When I talked about forcing subroutines to go berserk with ACE, I was implying using ACE to change the data they refer to (usually beforehand, but might be during their execution if we can find a way to "inject" ACE), not using ACE to directly do things like playing pong.

Let me put it this way: If a game has no known ACE or mass memory manipulation exploit, does everything glitchy that can happen when you alter the RAM through an external device still count as "bugs"?
Title: Re: On the definition of "glitch"
Post by: Parzival on October 03, 2019, 01:32:28 pm
... so things unachievable without ACE would be glitches and not bugs...
Since we're doing things to accomplish other things here, we need to box things into individual items: expanded pack being its own concept and anything you do with it being another.
OK, we might have had a misunderstanding here. When I talked about forcing subroutines to go berserk with ACE, I was implying using ACE to change the data they refer to (usually beforehand, but might be during their execution if we can find a way to "inject" ACE), not using ACE to directly do things like playing pong.

Let me put it this way: If a game has no known ACE or mass memory manipulation exploit, does everything glitchy that can happen when you alter the RAM through an external device still count as "bugs"?
Not really, as you're using external equipment. ACE isn't external, however...
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 03, 2019, 01:41:49 pm
That would mean that, a game could otherwise be programmed very well and have almost no flaw, but once an ACE exploit is found, it
would suddenly have thousands of bugs. That strikes me as weird, but maybe it's OK.
Title: Re: On the definition of "glitch"
Post by: Parzival on October 03, 2019, 02:11:11 pm
Custom code, I feel, shouldn't count; following what is and isn't bug or glitch stops at getting to hijack execution. ACE? Categorize. After that? Stop.
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 03, 2019, 02:16:08 pm
Again, in the "glitches accessible by ACE", the custom code is only used for setup, and the actual glitchy part is entirely intended code doing unintended things. Using Gameshark as an example, it is what can happen in the game after you remove the Gameshark.
Title: Re: On the definition of "glitch"
Post by: Parzival on October 03, 2019, 02:37:35 pm
Again, in the "glitches accessible by ACE", the custom code is only used for setup, and the actual glitchy part is entirely intended code doing unintended things. Using Gameshark as an example, it is what can happen in the game after you remove the Gameshark.
Ah, I see what you mean. This is a good point, and is somewhat prevalent here, so i'll explain it like this:

If you're using ACE to set up a situation that otherwise can't be attained, it's definable as a "glitch" due to being something you can't achieve without total control. This may even exclude memory editing through, say, expanded pack as even with EP you'd still have to trigger whatever you wish to accomplish with the proper function and said function would have to not sanitize its workspace first.

nuance is great
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 03, 2019, 04:51:37 pm
If you're using ACE to set up a situation that otherwise can't be attained, it's definable as a "glitch" due to being something you can't achieve without total control. This may even exclude memory editing through, say, expanded pack as even with EP you'd still have to trigger whatever you wish to accomplish with the proper function and said function would have to not sanitize its workspace first.

In the end, the question is to what extent can the failure to sanitize a workspace (i.e. input data) be considered a bug. In the map FF case, the programmers (presumably intentionally) decided that the map connection does not need to be sanitized, since the map design shouldn't allow an invalid connection to be taken. However, it is plausible that it could have been done. In other cases, like meta-map script IDs, it might be impractical to sanitize the input (since the meta-map IDs themselves are supposed to be the most reliable indicator of the state of the map).

Also, in the end, it can be argued that many proposals for sanitizing inputs are based on 20/20 hindsight. Sure, this specific glitch could have been avoided by doing this specific sanitization, but how are the developers supposed to know that this kind of malformed input could happen in the first place? (If they had known, they would have been able to just fix the parent glitch/bug.)
Title: Re: On the definition of "glitch"
Post by: Parzival on October 04, 2019, 04:01:06 pm
If you're using ACE to set up a situation that otherwise can't be attained, it's definable as a "glitch" due to being something you can't achieve without total control. This may even exclude memory editing through, say, expanded pack as even with EP you'd still have to trigger whatever you wish to accomplish with the proper function and said function would have to not sanitize its workspace first.

In the end, the question is to what extent can the failure to sanitize a workspace (i.e. input data) be considered a bug. In the map FF case, the programmers (presumably intentionally) decided that the map connection does not need to be sanitized, since the map design shouldn't allow an invalid connection to be taken. However, it is plausible that it could have been done. In other cases, like meta-map script IDs, it might be impractical to sanitize the input (since the meta-map IDs themselves are supposed to be the most reliable indicator of the state of the map).

Also, in the end, it can be argued that many proposals for sanitizing inputs are based on 20/20 hindsight. Sure, this specific glitch could have been avoided by doing this specific sanitization, but how are the developers supposed to know that this kind of malformed input could happen in the first place? (If they had known, they would have been able to just fix the parent glitch/bug.)
isn't Rule 1 of software development literally "assume all user input is hostile and malformed"?
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 04, 2019, 06:45:39 pm
isn't Rule 1 of software development literally "assume all user input is hostile and malformed"?

The tricky part is that they are not supposed to be user inputs. Those data are supposed to come from other subroutines in the game's code, and it is only because of an earlier bug that the user gains the ability to manipulate them.
Title: Re: On the definition of "glitch"
Post by: Sherkel on October 04, 2019, 07:41:51 pm
Overall I think game state after the fact compared to beforehand should take priority when defining this. Off the top of my head, item underflow is a glitch, the Celadon looping map thing is a trick, Trainer escape is a glitch, Wally defeating Ralts is an oversight, and using Cute Charm for tons of shinies is an exploit.

I hope to articulate this better in addition to what degree it's necessary to delineate them later. Article names should at least be consistent.
Title: Re: On the definition of "glitch"
Post by: Parzival on October 05, 2019, 12:51:03 am
isn't Rule 1 of software development literally "assume all user input is hostile and malformed"?

The tricky part is that they are not supposed to be user inputs. Those data are supposed to come from other subroutines in the game's code, and it is only because of an earlier bug that the user gains the ability to manipulate them.
Considering the user is not intended to have direct hardware access, this earlier bug would have to be triggered by user input, wouldn't it?
Overall I think game state after the fact compared to beforehand should take priority when defining this. Off the top of my head, item underflow is a glitch, the Celadon looping map thing is a trick, Trainer escape is a glitch, Wally defeating Ralts is an oversight, and using Cute Charm for tons of shinies is an exploit.

I hope to articulate this better in addition to what degree it's necessary to delineate them later. Article names should at least be consistent.
This does help, yes, but again, termage in most other facets of an entire industry mean something too.
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 05, 2019, 12:56:53 am
Overall I think game state after the fact compared to beforehand should take priority when defining this. Off the top of my head, item underflow is a glitch, the Celadon looping map thing is a trick, Trainer escape is a glitch, Wally defeating Ralts is an oversight, and using Cute Charm for tons of shinies is an exploit.

I hope to articulate this better in addition to what degree it's necessary to delineate them later. Article names should at least be consistent.

For article names things are a bit different, because an article can only have one "standard" name, but it is surely related. In particular, it has been noted that "oversight" in the article name usually implies an inconsequential glitch, but we also use "due to an oversight" to describe the causes of glitches (even major ones), where it is the polar opposite of inconsequential.

Anyway, my thoughts on the words themselves:

Considering the user is not intended to have direct hardware access, this earlier bug would have to be triggered by user input, wouldn't it?
Of course, but the problem is that whether the consequential glitch should be considered another bug. Like you've said, we need to box things into individual items.
Title: Re: On the definition of "glitch"
Post by: Parzival on October 05, 2019, 08:23:17 am
Considering the user is not intended to have direct hardware access, this earlier bug would have to be triggered by user input, wouldn't it?
Of course, but the problem is that whether the consequential glitch should be considered another bug. Like you've said, we need to box things into individual items.
I feel unqualified to define these and i'm surprised I made it this far, but anyways, this is true and is in itself hard to classify. How would one classify issues resulting from other issues? Different trigger methods for the same issue may even technically change the classification in rare cases.
Title: Re: On the definition of "glitch"
Post by: Sherkel on October 05, 2019, 03:44:02 pm
I feel unqualified to define these and i'm surprised I made it this far
This after making almost half the posts in the thread? :P However b9a's tone comes across, what he and all of us want is just to help the site and the community surrounding it, in part by opening discussions available for any member to give their two cents to. I don't want this to fall on just a few, especially with how much it's confusing even me where to draw the lines.

Anyway, about the five terms I threw out as a possibility, what I was trying to get at but didn't know the words for was that a "trick" requires a parent glitch, and such an entrypoint is what should formally be regarded as a glitch. I'd put all ways of underflowing the bag or PC under the latter. An "oversight" to me is, in short, an inconsequential glitch. They don't deserve the same degree of intrigue as something like negative HP through Pomeg berries. An exploit is an instance of normal gameplay that doesn't create an invalid game state but seems like something not intended to be done in a particular way. X Accuracy's effect on Gen I OHKOs is the ideal example.

Phrases like "due to an oversight" and "is a glitch" should just be removed from articles in general. I might add this to the manual of style (or just do it, uh, manually :p ).

In terms of categorization, I think glitches and the tricks they allow for should be shown alongside each other, as the average user will be curious about a particular end state ("Mew's on my screen!") rather than which bytes are set to what after flying from a long-range trainer, even if they allow for meta-map script activation as well. Similar to what I said in the other thread, I'm for notability-based categorization.
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 06, 2019, 11:44:16 am
I feel unqualified to define these and i'm surprised I made it this far
This after making almost half the posts in the thread? :P However b9a's tone comes across, what he and all of us want is just to help the site and the community surrounding it, in part by opening discussions available for any member to give their two cents to. I don't want this to fall on just a few, especially with how much it's confusing even me where to draw the lines.
To be honest, even I myself have no real motivation to participate in this discussion now. I just don't want to leave anyone who does want to discuss in the same position that I have often felt that I am in --- finding that nobody else cares. I guess I at least care a little, but I really don't know what is good for this site now.

Maybe I'd just been waiting for you to come back. You are the one who has always been pushing for better categorization, so maybe you have more insight than I do.

Anyway, about the five terms I threw out as a possibility, what I was trying to get at but didn't know the words for was that a "trick" requires a parent glitch, and such an entrypoint is what should formally be regarded as a glitch. I'd put all ways of underflowing the bag or PC under the latter. An "oversight" to me is, in short, an inconsequential glitch. They don't deserve the same degree of intrigue as something like negative HP through Pomeg berries. An exploit is an instance of normal gameplay that doesn't create an invalid game state but seems like something not intended to be done in a particular way. X Accuracy's effect on Gen I OHKOs is the ideal example.
I largely think those definitions are OK. I would usually want more support before being comfortable implementing them, but it seems that there is no one to support or oppose, so maybe we should just go ahead and deal with the fallout, if any, later.

I do want to note that most ways of underflowing the bag or PC also require a parent glitch (of course game-altering device is another option, and Gen I SRAM glitch might also be able to do it, although I don't really know how Gen I SRAM glitch bypasses the checksum, and it may result in a game so broken as to render the expanded item pack/box irrelevant anyway).

Phrases like "due to an oversight" and "is a glitch" should just be removed from articles in general. I might add this to the manual of style (or just do it, uh, manually :p ).
I think guessing what the developers were thinking is a necessary thing for a glitch site (after all, the definition of glitches always has "unintended" in it, which requires inferring the intention in the first place), and "due to an oversight" is a good way to communicate that after analyzing the code, it seems likely that the developers just forgot. I recognize that the terminology might be confusing, though, and maybe we don't need to communicate this piece of information after all.

In terms of categorization, I think glitches and the tricks they allow for should be shown alongside each other, as the average user will be curious about a particular end state ("Mew's on my screen!") rather than which bytes are set to what after flying from a long-range trainer, even if they allow for meta-map script activation as well. Similar to what I said in the other thread, I'm for notability-based categorization.
Well, I guess that surely does not mean putting them in the same category, right? Maybe a table like what is currently in the "major glitches" template (https://glitchcity.info/wiki/Template:Major_glitches) would be a good way to do that.

On a page level, though, I understand the need for concrete and comprehensive procedures for a particular trick (having to go through 3~4 pages to understand how to do dry underflow would be too overwhelming for a new glitcher), but I am always worried that those procedures would be perceived as "magic spells" that could never be understood and must be followed exactly. Maybe for some people that's exactly what they want to achieve, but I personally hate that.
Title: Re: On the definition of "glitch"
Post by: Sherkel on October 11, 2019, 08:30:23 pm
Quote
To be honest, even I myself have no real motivation to participate in this discussion now. I just don't want to leave anyone who does want to discuss in the same position that I have often felt that I am in --- finding that nobody else cares. I guess I at least care a little, but I really don't know what is good for this site now.
Same for me, honestly. Maybe when I next go on Discord I'll push the links to this and related threads to whoever's online. Having been here (and also not here) for a while, though, I'd take the current state of the wiki less as "nobody else cares" and more as "nobody else currently cares". Heck, I could have done a lot more by now than I have, and I was hoping that giving potential editors a clearer direction to go in through these threads would help them do so. Documenting stuff isn't the most motivating task for anyone and I'm not an exception, but I think you've done some real good for the site with your insights and proposals about what its direction should be (not to mention all your articles). It's been a slow process, but it hasn't been in vain. In short, I think it's alright that nobody's in a hurry.

Quote
I do want to note that most ways of underflowing the bag or PC also require a parent glitch
I literally forgot quantities above 99 weren't intended. :P Oh, golly...

I've said all I can think of to add at this point, but I'll sticky it now (you can too, by the way). Clarifying "trick/oversight/glitch/exploit" was the goal here and I'd say it's been done successfully now.
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on October 12, 2019, 08:40:09 pm
Documenting stuff isn't the most motivating task for anyone and I'm not an exception, but I think you've done some real good...
Well... some people think documenting glitches (especially root causes of glitches) is just killing the fun, and they might have a point. Other people don't want to change how they have been using the words, and that's reasonable too. Maybe I have been misinterpreting lack of support as presence of opposition, but sometimes I do feel actively discouraged from doing what I do.
Title: Re: On the definition of "glitch"
Post by: Evie the Bird Mother 🌸 ☽ on October 16, 2019, 02:29:46 am
Documenting stuff isn't the most motivating task for anyone and I'm not an exception, but I think you've done some real good...
Well... some people think documenting glitches (especially root causes of glitches) is just killing the fun, and they might have a point. Other people don't want to change how they have been using the words, and that's reasonable too. Maybe I have been misinterpreting lack of support as presence of opposition, but sometimes I do feel actively discouraged from doing what I do.

Don't worry, I'm with you I feel technical explanations and knowledge behind the glitches are fascinating (even though I'm not as skilled as you in analysing them so intricately); this and the pursuit of documenting them. I remember a discussion about whether glitches should be 'for fun' or 'for application', by extension whether should they not necessarily be for one or the other. So keep up the good work we need more documentation. :) But also, it may be important to balance the hobby and work dynamic so don't push yourself too hard either if it bugs you. (thumbs up) - at the same time I want to encourage you to do what you enjoy; it seems like your the person who loves the pursuit of knowledge like me.
Title: Re: On the definition of "glitch"
Post by: bbbbbbbbba on November 26, 2019, 10:20:35 am
OK, today I am reminded of why I think this question is important by this page (https://glitchcity.info/w/index.php?title=Map_script_pointer_manipulation&oldid=11050).

The page is a short stub with only three paragraphs, and it is the first two paragraphs that I have a problem with:
Quote
Map script pointer manipulation is a glitch in Pokémon Red, Blue, and Yellow. It can be abused via the expanded items pack (https://glitchcity.info/wiki/Expanded_items_pack) and is the parent glitch of map script arbitrary code execution (https://glitchcity.info/wiki/Arbitrary_code_execution) and map script pointer item ball manipulation (https://glitchcity.info/wiki/Map_script_pointer_item_ball_manipulation).

The glitch can be activated by modifying the location of the map script pointer by altering item 41 and item 41's quantity.
The logic here is incredibly twisted, and that's because it tries to frame something that is entirely an application of the extended item pack (i.e. a trick) as something that "naturally" exists in the game (i.e. a glitch). "The glitch can be activated by modifying the location of the map script pointer"? What glitch? To be honest, that might be a correct statement under certain definitions of words, but it is not a good way to think about this. The trick is to modify the location of the map script pointer (by altering item 41 and item 41's quantity in the expanded item pack).

My point is that confusing definitions makes it difficult to think about things. As such, they encourage readers not to think, and just to follow instructions. And that is how we keep our readers from becoming future glitch researchers.
Title: Re: On the definition of "glitch"
Post by: Sherkel on November 26, 2019, 02:36:07 pm
Use of terms was pretty confusing there. Don't think I'd go as far as saying it encourages viewers not to think, but I changed that part of the page.
Title: Re: On the definition of "glitch"
Post by: Evie the Bird Mother 🌸 ☽ on January 05, 2020, 08:13:40 am
Following the poll; which came out for clarifying definition -

(https://i.imgur.com/MN4E9cc.png)

Discuss what to do with this if you like. :)
Title: Re: On the definition of "glitch"
Post by: moose on January 16, 2020, 08:51:56 am
I don't do much here anymore, but I personally consider bug and glitch to be the same, and will probably not remember all of these obscure rules. The longer winded these guidelines are, the more new members will just be tempted to not bother remembering anything and consider them all the same.
Title: Re: On the definition of "glitch"
Post by: Ganix on January 16, 2020, 05:40:15 pm
I don't really have any stake in this, but a "bug" is effectively the programmatic error that results in unintended behavior, whereas a "glitch" is the direct æffect of a bug being triggered. Just use terms that fit the situation or subject.
Title: Re: On the definition of "glitch"
Post by: Sherkel on January 17, 2020, 02:46:10 am
I think it was pretty clear "bug" and "glitch" would be treated the same regarding page names, with a preference for "glitch" for fairly obvious reasons. Clarifying whether or not a given observation is a direct effect was the main question if I recall correctly.

Also, everyone has a stake in site-related matters unless it's said otherwise, regardless of their permissions.
Title: Re: On the definition of "glitch"
Post by: Ganix on January 17, 2020, 07:20:36 am
Ohh gotcha, definitely treat them the same in regards to page names, otherwise that'd probably cause confusion -- I was mostly referring to their usages in technical descriptions and wiki article text.

For example, I personally love seeing why a certain glitch occurs (the "bug") as well as how to make that glitch occur in a controllable manner (the "trick" or "exploit"), but those can easily be added in the wiki article itself without needing to be part of the title, especially since the most important part of the glitch is...well, the glitch. =P

One excellent example of this is the ZZAZZ glitch article (https://glitchcity.info/wiki/ZZAZZ_glitch (https://glitchcity.info/wiki/ZZAZZ_glitch)), which not only explains the method of obtaining the glitch, but also the details on what's going on behind the scenes and how the game mechanics work to produce that effect, which is heckin' awesome to me. <3

And ye I totally agree, I deffo misspoke on the whole stake thing, sorry about that! I mostly meant my post as a "keep this in mind when writing an article" rather than a "these are the rules that should be followed when writing an article", which wasn't really apparent from the way I worded it. ^^;;
Title: Re: On the definition of "glitch"
Post by: Evie the Bird Mother 🌸 ☽ on March 06, 2020, 09:14:23 am
For Yuzihax, Photon-Phoenix, Abwayax. I started these in January (there may be a few more) but want input if that's OK. Thanks. https://glitchcity.info/wiki/Template:Glitch https://glitchcity.info/wiki/Template:Exploit https://glitchcity.info/wiki/Template:Exvuln
Title: Re: On the definition of "glitch"
Post by: Evie the Bird Mother 🌸 ☽ on May 11, 2020, 05:04:26 pm
Due to the subjectivity on which term to use, should we remove the suffixes like "glitch", "oversight" from titles altogether? Like this article currently https://glitchcity.info/wiki/Friendship_underflow ?  (Note it's currently not "friendship underflow glitch")

Or leave it like https://glitchcity.info/wiki/Trainer_escape_glitch https://glitchcity.info/wiki/Battle_transition_oversight https://glitchcity.info/wiki/Time_Capsule_exploit etc.

A concern I have though is that it's also a way to distinguish from articles not about glitching methods, like https://glitchcity.info/wiki/RAM which is about what the term RAM means, so in that respect from the title you'd no longer necessarily know what is a glitch and what is a terminology article (other than through places like the category pages). In that respect we could maybe just keep using one term, (that could be glitch or for a more general term exploit - yet that could open a complication where (on a relatively greater scale) intended exploits like using a Repel to encounter Pokémon only above your level are covered, which we wouldn't call glitches.

Maybe we could dub another project name: So something like "Project (anything based on what we and Abwayax wants)"; so like how Project Caspar is for non-Pokémon glitches (and glitchy/buggy/unintended exploits), Project (something) could identify it, and articles moved to things like "Project Pokémon exploits:Old man", "Project Caspar:Super Mario Bros." etc. On the project name we could state something like "all glitches, bugs, oversights and unintended exploits are included".

I agree with moose's post personally, and it seems people's definitions of 'glitch', 'oversight', 'exploit' etc. can vary from person to person:

I don't do much here anymore, but I personally consider bug and glitch to be the same, and will probably not remember all of these obscure rules. The longer winded these guidelines are, the more new members will just be tempted to not bother remembering anything and consider them all the same.

A long time ago we also had a distinction between glitch and trick (old man trick etc.). In the past I think we used it to describe 'something' that requires another base glitch(but I'm unsure?) (base glitch/natural glitch as in something that requires no other glitches; in this case, old man trick requires the left-facing shore tile glitch that allows the previous grass Pokémon buffer combined with the old man's ability to change it).  Not everywhere accept this type of title, namely Celebi Egg Trick was created on Bulbapedia (maybe based on our naming; at one point we called it Celebi Egg trick too) and was moved to Celebi egg glitch later. https://bulbapedia.bulbagarden.net/w/index.php?title=Celebi_egg_trick&action=history