Re: On the definition of "glitch"
Posted by: bbbbbbbbba
Date: 2019-10-03 15:16:08
Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.
You can join Glitch City Research Institute to ask questions or discuss current developments.
You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.
Ah, I see what you mean. This is a good point, and is somewhat prevalent here, so i'll explain it like this:
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.
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.
isn't Rule 1 of software development literally "assume all user input is hostile and malformed"?
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"?
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?
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.
This does help, yes, but again, termage in most other facets of an entire industry mean something too.
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.
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.
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?
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.
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
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.
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.
I do want to note that most ways of underflowing the bag or PC also require a parent glitch
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…
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.
Map script pointer manipulation is a glitch in Pokémon Red, Blue, and Yellow. It can be abused via the expanded items pack and is the parent glitch of map script arbitrary code execution and 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.