Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - bbbbbbbbba

Pages: [1]
Western localizations of Generation I games are pretty similar to each other, much more so than compared to the original Japanese game. As a result, glitch items usually have similar names and/or behaviors. For example, Spanish P8 is equivalent to English 9F both in name and in function. Differences can mostly be explained by text pointers being different. For example, 3F takes the high byte of its effect pointer from a low byte of a text pointer, which means that its effect is likely to be different on all Western versions, as exemplified by French 2eme Etage.

Given this, how about we merge all the other Western ItemDexes (which are likely to remain incomplete forever otherwise) into the English ItemDex? The advantages would be:
  • Reducing duplicate information in pages, which may make maintaining the ItemDex easier.
  • As an extension of the above point, reducing incorrect information from copy-pasting (e.g. the 2eme Etage page was in the "ACE glitch items" category, which it does not belong to).
  • Eliminating red links from the ItemDex index, which (together with the straight up lack of entries) may otherwise confuse people with a foreign game.
  • Highlighting the items that are actually different between languages, encouraging glitch researchers to study them on language versions other than the ones where we already know their behaviors.

We can still add a section below the ItemDex pages to note the language versions where the item is confirmed to have the same behavior, although it should be understood that all items can be assumed to have the same behavior unless noted otherwise. And I guess if a language-specific glitch item is really notable in a non-English game, they can still have their own page, although I doubt there would be a need for such a special case. (ItemDex pages are generally not very long.)
Wiki Discussion / Slot machine behaviors
« on: October 09, 2019, 06:40:29 pm »
The behaviors of slot machines in the Game corners are so much more complicated than meets the eye (Gen I, Gen II), and with many oddities that may be considered as glitches. However, our wiki's documentation of them is woefully incomplete. Presumably this is because: (1) It is difficult to argue whether any specific oddity should be a glitch, given that those behaviors are intended to be obscure, and (2) it is difficult to even describe any particular glitch about the slot machines without first explaining their behaviors in normal cases.

Given this, should we just have pages titled "Slot machine behaviors (Generation N)", with a section named "Oddities" or "Potential glitches", and let the readers decide for themselves whether they should count?
Wiki Discussion / On the definition of "glitch"
« 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?
Wiki Discussion / Organization discussion thread (everyone please weigh in)
« on: September 02, 2019, 02:10:33 am »
The wiki needs better organization, and we need as much input as possible (especially "oldbies" who are more familiar with the site). Any form of discussion (reply, Discord, PM, wiki talk pages, etc.) is welcome. Below, I have outlined the main problem I see with the wiki (disagreement between "scientists", "artists", "technologists", and maybe "historians"), and I want your input on how we might solve this problem, or why this might not be a problem.

I have also proposed some solutions of my own, in the section titled "Proposals" (with four subsections, although now I think about it, only the first subsection is a direct answer to my own problem, and the other three are just organization ideas in general...), so if you want to see concrete proposals (instead of some abstract analysis), feel free to skip ahead.

After a long PM thread with Sherkel, I decided to make this public in the form of a forum thread. We both agree that the wiki is currently lacking in proper organization, a discussion is needed to decide what we should do to fix that, and that discussion should involve as many people as possible. Lack of organization is a serious problem, as it frustrates users and (potential) contributors alike. A new user --- indeed, probably any single user --- is powerless to fix a systematic problem, and that is why we need a public discussion, in order to come up with something most people would agree with.

One of the reasons that deterred me from doing this earlier is that I am not very comfortable with the GCL forum. Maybe the UI is not as friendly as could be, and maybe it is just me. But I suppose I might not be the only one who don't want to post on the forum for one reason or another. If you have anything to say, I encourage you to join the discussion in whatever form you are comfortable with. Ping me on the GCL Discord (I am suggesting a new channel for wiki discussion, but until then, #glitch-general should do), private message me, edit my user talk page, or any other talk page if appropriate.

The problem with being a "catch-all" site
As Sherkel has said in a PM, GCL "has always been a 'catch all' for all forms of glitchology, much as Bulbapedia is to Pokémon." I think this is an ambitious goal. This approach surely has its advantage: We don't exactly have a large user base, so we want to retain as much of it as possible. However, I believe this approach also has an apparent problem. To quote myself:
Quote from: bbbbbbbbba
The way I see it, there are at least three, maybe four, approaches to Pokémon glitching: as a science, as an art, as a technology, and maybe as a history. (In case you didn't notice, I'm firmly in the "science" camp.) Those approaches pull the site in different directions.
(To be clear, Sherkel's statement above is in response to my statement above, instead of vice versa.)

This is another reason why we want to hear as many different voices as possible!

This clash might show on multiple levels. I have analyzed this on the individual page level, specifically regarding the glitch pages (pages that document individual glitches) because I believe that is the most important component for a glitch site.
Quote from: bbbbbbbbba
I think the first thing should be to figure out what we want our "Project Glitch" pages (pages that document individual glitches) to look like. And here we can already feel the tension. Even though everyone would agree that a glitch page needs an introduction, a procedure, and a result:
  • The glitch scientist wants the procedure to be as general as possible, covering all the examples and exceptions to our best knowledge. There should usually be an explanation section --- or explanations should accompany each step of the procedure, in the case of particularly complex glitches. If the desire for generality means that the result could only be stated in technical terms, so be it.
  • The glitch artist wants to document all the cool results observed. That sometimes means documenting a lot of slightly different procedures individually. It doesn't matter if the results cannot be reproduced --- it might be preferable if they cannot be reproduced.
  • The glitch technologist wants it to be as easy as possible to use the glitch. That means concrete and detailed procedures that even a newbie can follow, preferably also optimized for simplicity (a 5-Pokémon setup should obsolete a 20-Pokémon one). Useful results are prioritized.
(My portrayal of the latter two attitudes are not necessarily accurate.)

My point is that those goals clash with each other on how to write the procedure and the result. It would be one thing, e.g., if I only wanted a separate section for explanation. But in an article describing a glitch, all the sections are related to the others. It's not like Bulbapedia Pokémon pages, where the "game data" section could be completed without even knowing what the rest of the page is going to look like.

And so this is a puzzle that needs to be solved.
Quote from: bbbbbbbbba
To put it another way, the clash is between concrete and optimized procedure / general all-encompassing procedure / all the individual procedures.
(I.e. it's not simply that technologists want procedures, scientists want explanations, and artists want results.)

Collapsibles ("folders")
The reason I wrote about the "clash" is because I felt it. There are long stretches of contents on the wiki that I don't want to see. Conversely, when I write about technical details, I often worry that they are long stretches of contents that other users might not want to see. Those long stretches of unwanted contents disrupt the flow of reading.

Maybe the problem can be solved by hiding them away, but only one click away. A link to another page can do that, but some things don't warrant creating a separate page, and having to click links is disruptive in its own way. I think collapsibles ("folders") is a better way of doing the same.

Collapsibles are boxes you can "expand" and "collapse". Template:Major glitches is an example. Apparently, they are a MediaWiki feature, but the wiki code for them is kind of difficult to understand. To make collapsibles something everyone can use, we need to make a template for them.

After we have the template, we need to begin editing existing pages to include them. This would sets up examples on how to use them, so that new contributors might be able to finish the job, and new pages would be able to catch on. Trainer escape glitch might be a good first page to try. It is a complex glitch with many moving parts, and as a result many sections that might benefit from being collapsible.

Wiki templates are great. They make what would have been a complex mess of HTML code (or just a lot of text) easy to use, and easy to maintain, too. I believe if we use them correctly, they can make the wiki more friendly to new contributors, which is exactly what we want.

I'm not familiar with the MediaWiki framework, so I don't really know what can be templated. I do feel that it is difficult to make a table that looks good (like The Big HEX List), so if a template can help with that, that would be awesome. There might be things I am forgetting for now...

Edit: Let me just begin listing things I might want.
  • "PK" and "MN" symbols that render like how they look in-game, and copy as something relatively unambiguous (e.g. "<PK>").
  • A "glitch infobox" template.
  • The existing YouTube template should allow an optional parameter for a timestamp. Furthermore, the visibility of that template could be improved (it can be difficult to see a small strip of text centered in a page, especially when it is the only thing in a section).

But more importantly, to make templates really work, we need to advertise them. I believe the MediaWiki allows a message to be displayed on the "edit page" UI. We should put some commonly used templates there so that new contributors would know to use them. That also saves contributors the trouble of finding them from other pages. That can also include things that are not strictly templates, but people might need to copy-paste from somewhere else anyway, like the word "Pokémon". (I got the idea from another wiki site (in Chinese). And yes, the idea of using collapsibles extensively also came from that site.)

Style guide
We have a manual of style, but I feel that it can use some additions.

One problem that concerns me the most, the formatting of hexadecimals, has been brought up before (although I also want to unify the capitalization, and that thread didn't mention that "hex:E9" and "hex E9" are also used ). I disagree with the resolution:

Wow...such evenly spread votes all the way across the board. Ironically, after having starting this poll I'm leaning toward it not being important enough. A few reasons:

1. The opinions from what we can see of the userbase are so divided that a unilateral change would be disliked by most users, no matter what it ended up being.

2. There are a lot of articles on the wiki. Originally I thought it would be best to catch this and set a standard on it before the page count grew even higher, but for about 3,400 pages at the time of posting this, there'd need to be a very pressing reason. Speaking of standards...

3. The wiki doesn't have strict style standards and never has. We have the manual of style, but that's just enough to prevent it from looking like articles were thrown together by elementary schoolers in seconds. I haven't seen any violations of that thanks to the QC team, but pages are written in all manners of different writing and organizational styles. This includes aspects like notation. Information is our first priority; if we had an editor base of hundreds, we could strictly look over every page and edit even the slightest deviations from what we consider the most proper style, but that's not the case right now.

Oh well, maybe this was a bit needless. Or was it not? More input  about the wiki is always welcome, in this thread or elsewhere.

My counterpoints:

1. The poll didn't have an option "anything, as long as it is consistent". I think it is rather likely that most people who voted on any of the first four options would be more OK with any of the other three than with the status quo.

2. Well, I am already proposing across-the-board changes. And we don't actually need to go over 3,400 pages. Simply put something in the manual of guide, and edit some major pages to establish the rule, maybe mass edit Dex pages with robots --- I believe the rest will be brought in line in time.

3. We might not be able to look over every page, but we are able to look over every future edit. In this regard, our lack of wiki activity (especially new contributors) could actually be an advantage. We can put something above the edit area to the effect of: "We are serious about our style guide, but don't worry about it if you are new to the site. Our staff will review any edits and gladly fix any style problems for you!" I don't think that would be a deterrent to any new contributor.

Actually, I believe the status quo of inconsistency may be a deterrent to some new contributors. How so? Editing the wiki is mostly thankless work. I think most people do that because they believe they are creating something good. And inconsistency does not look good --- at least to the conformists it doesn't. So those inconsistencies may be enough to make them think again about contributing.

It might be argued that there are more non-conformists out there than conformists. But even then, I don't think the approach of "feel free to edit, staff will catch problems" would alienate non-conformists. It might alienate anti-conformists, but I don't believe anti-conformists would be a significant portion of the crowd. Maybe we can also mention that we are open to exceptions, as long as there is a good reason --- that can be determined on a case-by-case basis.

As a bonus, if we can make it a wiki task to fix the pages to adhere to a more strict style guide, it might well incentivize some lurkers to contribute! It isn't unthinkable that, having gotten comfortable with wiki editing, they go on to contribute in other ways, like bringing new information to the site, right?

Some other things that might be unified with a more strict style guide:
  • Capitalization of X and Y (as in coordinates).
  • Capitalization and formatting of register names. In particular, the register a needs something to distinguish it from the English word "a".
  • Really, capitalization of everything.
  • Whether to use spaces around operators (+, =, <=, etc.).
  • ... Suggestions are welcome!
Those are not exactly priorities, but I think we can begin by implementing some items where there are no strong arguments for inconsistency, and there are no strong arguments against every option. Those can be discussed in separate threads if necessary.


I've brought up one problem with the CSS before, and I have since decided that other problems are also in need of fixing. The reason I decided to bring it up here is that I feel that CSS problems cause organization headaches:
  • Bulleted lists are a useful tool for organization, but editors may be discouraged from using them because nested/multiline bulleted lists are ugly.
    • Numbered lists are even more ugly (I've never seen a number followed by a bullet anywhere else).
  • Different section headings are of the same size, making it hard to see the structure of a page from a glance.
  • The color of links are almost indistinguishable from normal text. This discourages intelligent potholes and encourages cramming all the information in one page.
Currently, I use the Stylish plugin for Chrome to give myself a better viewing experience. But I would surely prefer those changes to be incorporated to the site's CSS. I am no expert of CSS, and I don't know whether those settings would look as good on mobile, or if they would break something else (as I mentioned, I don't use the forum often), so I would appreciate it if someone with experience in CSS could help to implement it.

P.S. I've already realized one potential problem: My bulleted list fix didn't take into account the font size, making bullet points in e.g. forum quotes slightly off. If anyone knows a more correct way to do this, please let me know.

Code: [Select]
/* Bulleted lists */
li {
    background-position: left 5px;

/* Numbered lists */
ol > li {
    background-image: none;
    padding-left: 0;

/* Numbered lists on the forum */
ul[style="list-style-type: decimal;"] {
    padding-left: 1.5em;
ul[style="list-style-type: decimal;"] > li {
    background-image: none;
    padding-left: 0;

/* Bulleted lists in the "Categories" line on the bottom of wiki pages */
.catlinks li:first-child {
    padding-left: 0.6em;
.catlinks li {
    padding-left: 0.6em;

/* Link color.
Not sure if this color works for everyone, but it is more distinguishable and also doesn't look out of place to me. */
a:not(.new) {
    color: #778899;

/* Some links on other parts of the site shouldn't have the above applied */
.dropmenu a {
    color: #000000;
.catbg a {
    color: #FFFFFF;
.table_list .header td.catbg a {
    color: #515151;

/* Section headings */
h2 {
    font-size: 1.5em;
    margin-top: 0.5em;
h3 {
    font-size: 1.17em;
    margin-top: 0.5em;
h1, h4, h5, h6 {
    margin-top: 0.5em;

/* Code */
pre {
    font-size: 130%;

code {
    font-size: 130%;

Beyond page-level
My above proposals are mainly about how to let users easily find information they need, and contribute information they have, on an individual page. They don't address the issue of how to let users find an interesting page in the first place. Part of the problem, again, is that different users find different pages interesting.

The problem of categorization has been brought up, too. That thread died down without a real conclusion, and I guess that was at least partly my fault. At that time, I already had some vague idea of the problem:
I think the advantage of your system is that it singles out the most interesting glitches to the average player (1B and 2A); however, the most interesting glitches to the average glitcher are probably different.
I didn't have the "science/art/technology/history" idea then, though. Now that I have a better idea of the problem, I want to ask for suggestions again. Maybe more than one categorization system co-existing is the way to go.

Actually, it doesn't seem like a bad idea to explicitly mention this "division" on the front page or the sidebar, and portray it in a positive light. It would help everyone find what they need, and also reinforce the idea that we are indeed a "catch-all" site for all aspects of glitching.

Other random ideas:
  • A navigation bar on Dex pages, like the one Bulbapedia has on Pokémon pages, would be nice.
  • The "Random page" button can be split into "Random (major) glitch", "Random glitch Pokémon", etc.
  • Related to the above suggestion, I want to cut down on the number of uninteresting pages, even Dex pages. Would it be fine to, for example, make ItemDexES/RB:094 a redirect to ItemDex/RB:094? I believe they act identically except for the name, which can easily be acknowledged on the latter page. And yes, I don't see any problem with a page with multiple navigation bars either, as long as they are thin enough.

I will keep this section short, not because the problem of page visibility is not important, but only because I haven't been thinking about this part of the problem too much, and this post is getting long enough. Maybe I will expand on this section later, factoring in whatever input I get.

To reorganize the wiki is going to be a huge project no matter what. I am willing to help, but only if I believe it would make more people here happy than not. Again, we need as much input as possible. Please let me know whether you agree or disagree with my interpretation of the problem and my proposals, and if you have different proposals. I hope that we can get to a consensus before taking any large-scale actions, which I believe is needed now.
In my opinion, the purpose of bullet points is to clearly delineate the points. And it utterly fails to do that when it can appear right in the middle of a point.

I just grew bored of looking at ugly bullet lists, so I tried to fix the problem with the Stylish plugin for Chrome. I found out that on my computer, the following setting is perfect:

Code: [Select]
li {
background-position: left 5px;

(The default is "left center".)

However I didn't try it on my phone, so I don't know if this works well on different display sizes.

What do you think? Have any of you tried to modify the behavior of those bullet points?
Today I was scanning through the Generation I natural glitches list when I realized something fishy about this one. The attached GIF begins at the exact point the NPC starts to move, not a moment earlier. Then I opened the YouTube video and saw that the glitch was reproduced from a specific save file.

After some failed attempts to reproduce this glitch, I realized that this glitch may only work from a save file.

From here it's easy to guess what really happened. The game was saved exactly at the frame when the walking NPC was ready to move, but hadn't decided in which direction yet. When the save file is loaded, both NPCs are loaded, but they are not correctly marked as visible. Since the walking NPC is updated first, if it decides to move up, the collision check isn't going to stop it.

I then found a way to semi-reliably reproduce this in an emulator. With the two NPCs adjacent to each other, begin frame advancing, watching the RAM address $C2x8 ("time until next step") of the walking NPC. When it becomes 0x01, begin holding Start. There is a one-frame delay for the Start menu, so when it pops up, the countdown will go to 0x00 exactly. Saving from this Start menu gives a save file from where this glitch may happen.

Of course, this doesn't only work in the Cerulean Pokémon Center, but in almost any place where two NPCs may go to the same square, and the NPC with lower ID (i.e. that is updated first) can walk. See attachment for an example in Pallet Town.

There is one more small question to ask. Why are the NPCs marked as invisible in the save file? Of course, because they are hidden by the Start menu. At this point I realized that it may not be necessary to have a save file after all. Sure enough, further testing showed that the glitch can also be triggered simply by bringing up the Start menu at the same exact frame to hide the NPCs, and then just closing it.

Presumably, if the "stationary" NPC is not hidden when the game is saved, then this glitch won't work. And this glitch may work in other situations where multiple NPCs are loaded at the same time; I haven't checked yet.

If everyone agrees that this is the same glitch as the current "NPC and Cable Club lady glitch", I'll probably edit the wiki and rename the page in a few days. Of course, if someone else would help me do it, I will be thankful. Further research is also welcome.
Well, I'm pretty sure I'm not the first one to discover it (see, but since it is nowhere to be found on this site (to my best knowledge), here is it:


When you defeat a trainer, the amount of money you win depends on the trainer class and the level of their party; namely, your winnings is the level of the last pokemon times a fixed amount depending on the trainer class. This fixed amount is always <= 99 for normal trainers, but is written in 2-byte (4-digit) BCD for the ease of computation. I will copy-paste some code from (I added some comments)

.FinishUp ; XXX this needs documenting
   xor a       ; clear D079-D07B
   ld de,$D079
   ld [de],a
   inc de
   ld [de],a
   inc de
   ld [de],a ; de is now D07B
   ld a,[W_CURENEMYLVL] ; the level of the last pokemon
   ld b,a
   ld hl,$D047 ; the address of the trainer-class specific multiplicand
   ld c,2 ; do 2-byte BCD arithmetic
   push bc
   ld a,$B
   call Predef ; indirect jump to BCDAdd; reads operands from [de] and [hl], saves result in [de]
   pop bc
   inc de
   inc de
   dec b
   jr nz,.LastLoop

The intention of this loop is to add the multiplicand into address D07A-D07B for b times, where b is the level of the last pokemon. The two instructions in red is meant to restore the value of de, assuming that it is decreased exactly twice in the function BCDAdd. But is this the case?

Well, it is, as long as the BCD addition did not overflow. When it does overflow, the function sets the result to 9999 (in BCD; hex 99 = dec 153) (like how your money won't increase beyond 999999), and in this process also increase the value of de - the address to write to - by 3.

Does this pattern sound familiar?

Of course, the addition never overflows in normal play, because the multiplicand is <= 99 and the level is <= 100. Of course, glitch trainers abide by neither limitation. In fact, most ZZAZZ trainers takes the multiplicand from the names of real trainers, which is an ocean of uppercase letters, meaning that the multiplicand can easily be things like 8X8X, overflowing the content of any address in 1 or 2 additions. Seriously.

By the way, being ZZAZZ trainers doesn't mean they don't have stupidly long names. There is a good chance that some of the mysteries of the ZZAZZ glitch actually stem from the long name...
Generation I Glitch Discussion / Explanation of the surfing glitch?
« on: March 01, 2014, 01:28:08 pm »
The surfing glitch page says:

"However, if START is pressed mid-step, the START menu pops up without giving the game time to change the player's direction if the game is saved. "

This sounds plausible at first, but when I really think about it, it doesn't make much sense. After all, it is not saving but loading that resets the player's direction, so how is it possible that the game "has no time" to change that direction because START is pressed too fast?

I think I need a more accurate explanation for this...
Pages: [1]