Glitch City Laboratories Archives

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

Kyouki, you can access near all glitch pokemon with the ditto trick and you can see the others via Old Man glitch trainers and glitch HOF.  It's in the game code.

Yes, but not when it comes to glitch items. Then again, you could use glitch Pokemon to edit the items in your bag. But it doesn't seem to be well-known, and doesn't seem to exactly work well.

Uhh… yeah, they do edit your bag.

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

Kyouki, you can access near all glitch pokemon with the ditto trick and you can see the others via Old Man glitch trainers and glitch HOF.  It's in the game code.

Yes, but not when it comes to glitch items. Then again, you could use glitch Pokemon to edit the items in your bag. But it doesn't seem to be well-known, and doesn't seem to exactly work well.

Uhh… yeah, they do edit your bag.

I know, I know, but I meant it doesn't exactly work well because not a lot of glitch Pokemon actually edit the type of items in your bag. And you have to have a certain item in a specific place before encountering a glitch Pokemon, to edit it into what you want.

Also, are people going to enjoy such a strict definition? Is the purpose of Glitch City Laboratories to impress other people who contribute to similar sites like this? And if Gameshark code glitches, that can't be really accessible by a programming glitch working with an unhacked RAM, are not to be added to GCL, then the interest in glitching would be somewhat bleak, no? Besides, a lot of games today have protection against bad variables and bad RAM. So, you can say that it's a programming error that the game is allowed to interact with the bad variables one put in.

because if you could edit anything, you wouldn't get an error when you do something like "01XXFFFF" when imputting codes.

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

And yet, you act like a lot of effects caused by changing the RAM (or using a debug menu) aren't glitches.

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

You're saying Arceus actually exists in the R/B ROM?

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

And yet, you act like a lot of effects caused by changing the RAM (or using a debug menu) aren't glitches.

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects.

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

You're saying Arceus actually exists in the R/B ROM?

No. I don't think that stuff like Arceus being on R/B's screen, like Newo hacked the RAM to do that, as that's quite a cheap attempt for a "glitch find", should be put onto the site, but interesting and possibly useful effects from foreign savestate applying should be documented in a section called something like "Savestate Glitches".

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

And yet, you act like a lot of effects caused by changing the RAM (or using a debug menu) aren't glitches.

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects.

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code <– Wait, how do you know? Because I'm pretty sure that glitch Pokemon load their sprites from ROM. If they were loaded from RAM, then MissingNo's sprites would vary a lot. Same for a lot of other glitch Pokemon, whose sprites I'm pretty sure vary only a bit from stats screen, enemy sprite, back sprite, etc.

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects. <– RAM is a place to store memory to work with. It does not store all the game's text, graphics, algorithms, objects, etc. That's what ROM is used for.

---

I suggest we bring this to Debate Wars.

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

You're saying Arceus actually exists in the R/B ROM?

No. I don't think that stuff like Arceus being on R/B's screen, like Newo hacked the RAM to do that, as that's quite a cheap attempt for a "glitch find", should be put onto the site, but interesting and possibly useful effects from foreign savestate applying should be documented in a section called something like "Savestate Glitches".

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

And yet, you act like a lot of effects caused by changing the RAM (or using a debug menu) aren't glitches.

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects.

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code <– Wait, how do you know? Because I'm pretty sure that glitch Pokemon load their sprites from ROM. If they were loaded from RAM, then MissingNo's sprites would vary a lot. Same for a lot of other glitch Pokemon, whose sprites I'm pretty sure vary only a bit from stats screen, enemy sprite, back sprite, etc.

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects. <– RAM is a place to store memory to work with. It does not store all the game's text, graphics, algorithms, objects, etc. That's what ROM is used for.

---

I suggest we bring this to Debate Wars.

No. I don't think that stuff like Arceus being on R/B's screen, like Newo hacked the RAM to do that, as that's quite a cheap attempt for a "glitch find", should be put onto the site, but interesting and possibly useful effects from foreign savestate applying should be documented in a section called something like "Savestate Glitches". <– LET'S PUT ARZUZEUS IN THE GLITCH DEX 'CAUSE U CAN GET A SAVEZORZ STATE OF THE RAM HAXED ROM WHICH MAKES IT A GLITCH!!1 (Savestate = RAM)

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code <– Wait, how do you know? Because I'm pretty sure that glitch Pokemon load their sprites from ROM. If they were loaded from RAM, then MissingNo's sprites would vary a lot. Same for a lot of other glitch Pokemon, whose sprites I'm pretty sure vary only a bit from stats screen, enemy sprite, back sprite, etc.  <– (lol IRC arrow on forums) They load their sprites from the ROM yet you said that unusual effects are coded to act that way in the ROM and Graphics are RAM.  To unusual effects, the ROM is NOT coded to act like or have effects from RAM hacking.  From RAM hacking in R/B, you get get Super Glitch City (some youtube vid) which is a glitched to hell glitch city with fucked (or f**ked for barney mode people) sounds from RAM hacking.  most of those effects are not in the ROM (neither is glitch mansion warp or the dying Chameleon sound) nor the glitched credits with Oak "Walking around the world" with side by side warps in a glitch panel that lead to the Safari Zone or your house which leads to a normal Pallete Town with a Prof. Oak that never stops and crashes the game from going out of bounds.  Find me these scripts and places in the ROM without RAM hacking and you get a cookie with some gold too. To Graphics, they are stored in the ROM and are put on screen by Video exteral RAM not found in the ROM.

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects. <– RAM is a place to store memory to work with. It does not store all the game's text, graphics, algorithms, objects, etc. That's what ROM is used for. <– (still IRC arrow) In Sonic 2 when you beat the Death Egg boss, you get a script with Sonic running with explosions behind him that ends when he goes off screen.  When you use Debug to warp to "silver" sonic or whatever the thing is called, the explosions go and follow you and the script of the boss starts again.  The script is not supposed to let you move sonic at all to the left but when you use debug, you move to silver and refight him with explosions.  This occurence is not coded in the ROM because it disallows you to do this normally but since hack (debug) moved you to the script spot, you are fighting metal sonic with screwed up RAM because the RAM is saying you are in script and fighting silver sonic at the same time trying to make it work with the ROM which disallows this normally.

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

You're saying Arceus actually exists in the R/B ROM?

No. I don't think that stuff like Arceus being on R/B's screen, like Newo hacked the RAM to do that, as that's quite a cheap attempt for a "glitch find", should be put onto the site, but interesting and possibly useful effects from foreign savestate applying should be documented in a section called something like "Savestate Glitches".

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

And yet, you act like a lot of effects caused by changing the RAM (or using a debug menu) aren't glitches.

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects.

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code <– Wait, how do you know? Because I'm pretty sure that glitch Pokemon load their sprites from ROM. If they were loaded from RAM, then MissingNo's sprites would vary a lot. Same for a lot of other glitch Pokemon, whose sprites I'm pretty sure vary only a bit from stats screen, enemy sprite, back sprite, etc.

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects. <– RAM is a place to store memory to work with. It does not store all the game's text, graphics, algorithms, objects, etc. That's what ROM is used for.

---

I suggest we bring this to Debate Wars.

No. I don't think that stuff like Arceus being on R/B's screen, like Newo hacked the RAM to do that, as that's quite a cheap attempt for a "glitch find", should be put onto the site, but interesting and possibly useful effects from foreign savestate applying should be documented in a section called something like "Savestate Glitches". <– LET'S PUT ARZUZEUS IN THE GLITCH DEX 'CAUSE U CAN GET A SAVEZORZ STATE OF THE RAM HAXED ROM WHICH MAKES IT A GLITCH!!1 (Savestate = RAM)

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code <– Wait, how do you know? Because I'm pretty sure that glitch Pokemon load their sprites from ROM. If they were loaded from RAM, then MissingNo's sprites would vary a lot. Same for a lot of other glitch Pokemon, whose sprites I'm pretty sure vary only a bit from stats screen, enemy sprite, back sprite, etc.  <– (lol IRC arrow on forums) They load their sprites from the ROM yet you said that unusual effects are coded to act that way in the ROM and Graphics are RAM.  To unusual effects, the ROM is NOT coded to act like or have effects from RAM hacking.  From RAM hacking in R/B, you get get Super Glitch City (some youtube vid) which is a glitched to hell glitch city with fucked (or f**ked for barney mode people) sounds from RAM hacking.  most of those effects are not in the ROM (neither is glitch mansion warp or the dying Chameleon sound) nor the glitched credits with Oak "Walking around the world" with side by side warps in a glitch panel that lead to the Safari Zone or your house which leads to a normal Pallete Town with a Prof. Oak that never stops and crashes the game from going out of bounds.  Find me these scripts and places in the ROM without RAM hacking and you get a cookie with some gold too. To Graphics, they are stored in the ROM and are put on screen by Video exteral RAM not found in the ROM.

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects. <– RAM is a place to store memory to work with. It does not store all the game's text, graphics, algorithms, objects, etc. That's what ROM is used for. <– (still IRC arrow) In Sonic 2 when you beat the Death Egg boss, you get a script with Sonic running with explosions behind him that ends when he goes off screen.  When you use Debug to warp to "silver" sonic or whatever the thing is called, the explosions go and follow you and the script of the boss starts again.  The script is not supposed to let you move sonic at all to the left but when you use debug, you move to silver and refight him with explosions.  This occurence is not coded in the ROM because it disallows you to do this normally but since hack (debug) moved you to the script spot, you are fighting metal sonic with screwed up RAM because the RAM is saying you are in script and fighting silver sonic at the same time trying to make it work with the ROM which disallows this normally.

To zeroth part: But Arceus isn't created by a variable. It's created by a hundred variables unrelated to the glitches in the GlitchDex that were created by a single variable.

To first part: Except, does Pokemon RBY generate random data during a RAM-hacked glitch? Where does it get all its ideas for effects from? If you make Oak walk around the world with a code that doesn't explicitly script him to do that, then why does the game do that? It probably made weird numbers with the script lying in the ROM for Oak to walk, or looked at some text or tiles, and thought they were the script or CPU opcodes for Oak, and used that.

To second part: Yes, the debug menu coded in the ROM commanded the RAM to move it over. The ROM, having reacted with it, sees nothing wrong with it because it looks like Sonic is back there again, and executes the script again as usual.

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

You're saying Arceus actually exists in the R/B ROM?

No. I don't think that stuff like Arceus being on R/B's screen, like Newo hacked the RAM to do that, as that's quite a cheap attempt for a "glitch find", should be put onto the site, but interesting and possibly useful effects from foreign savestate applying should be documented in a section called something like "Savestate Glitches".

I've always said that the term "glitch" strictly refers to programming errors in the actual game, and that fucking with the ROM, RAM or a savestate doesn't count because that isn't an error in the game (any program will react badly to corrupted data or code).

Well then, why did you work so hard on the Glitchdex, Itemdex, Attackdex, etc?

Because those are actually accessable though ways without gameshark and are in the ROM's coding.  Some need Gameshark but they are still there.

I don't really agree with that logic. So, you say that inaccessible variables that are alongside inaccessible unusual variables can be allowed to be called glitches. But I don't see a real reason to do so, if you're not allowing the calling of results from changing a byte in RAM, that cannot be changed using a programming glitch, to unusual variables a glitch.

You fail to understand the difference between something that actually does exist in the code and something that did not exist in the code and was actually created (not "accessed") by modifying code. Everything in the 'dexes exists in the game code (I can point out specific areas where the data for any given R/B glitch attack exists, for instance); something like, say, "Arceus in R/B" does not (it being a product of memory manipulation; I cannot point to a region of ROM code and say "This is the data for Arceus").

Almost all unusual reactions from editing the RAM exist in the ROM on games, although graphics are stored on RAM, so you CAN edit graphics and stuff just by hacking the RAM.

And yet, you act like a lot of effects caused by changing the RAM (or using a debug menu) aren't glitches.

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects.

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code <– Wait, how do you know? Because I'm pretty sure that glitch Pokemon load their sprites from ROM. If they were loaded from RAM, then MissingNo's sprites would vary a lot. Same for a lot of other glitch Pokemon, whose sprites I'm pretty sure vary only a bit from stats screen, enemy sprite, back sprite, etc.

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects. <– RAM is a place to store memory to work with. It does not store all the game's text, graphics, algorithms, objects, etc. That's what ROM is used for.

---

I suggest we bring this to Debate Wars.

No. I don't think that stuff like Arceus being on R/B's screen, like Newo hacked the RAM to do that, as that's quite a cheap attempt for a "glitch find", should be put onto the site, but interesting and possibly useful effects from foreign savestate applying should be documented in a section called something like "Savestate Glitches". <– LET'S PUT ARZUZEUS IN THE GLITCH DEX 'CAUSE U CAN GET A SAVEZORZ STATE OF THE RAM HAXED ROM WHICH MAKES IT A GLITCH!!1 (Savestate = RAM)

To first part:  it "lies in the ROM" because the ROM tries to use screwed up RAM. It isn't in the game's code <– Wait, how do you know? Because I'm pretty sure that glitch Pokemon load their sprites from ROM. If they were loaded from RAM, then MissingNo's sprites would vary a lot. Same for a lot of other glitch Pokemon, whose sprites I'm pretty sure vary only a bit from stats screen, enemy sprite, back sprite, etc.  <– (lol IRC arrow on forums) They load their sprites from the ROM yet you said that unusual effects are coded to act that way in the ROM and Graphics are RAM.  To unusual effects, the ROM is NOT coded to act like or have effects from RAM hacking.  From RAM hacking in R/B, you get get Super Glitch City (some youtube vid) which is a glitched to hell glitch city with fucked (or f**ked for barney mode people) sounds from RAM hacking.  most of those effects are not in the ROM (neither is glitch mansion warp or the dying Chameleon sound) nor the glitched credits with Oak "Walking around the world" with side by side warps in a glitch panel that lead to the Safari Zone or your house which leads to a normal Pallete Town with a Prof. Oak that never stops and crashes the game from going out of bounds.  Find me these scripts and places in the ROM without RAM hacking and you get a cookie with some gold too. To Graphics, they are stored in the ROM and are put on screen by Video exteral RAM not found in the ROM.

2nd part: Debug modes/menus are hacks on top of the game.  Hacking a game usually brings out RAM created objects. <– RAM is a place to store memory to work with. It does not store all the game's text, graphics, algorithms, objects, etc. That's what ROM is used for. <– (still IRC arrow) In Sonic 2 when you beat the Death Egg boss, you get a script with Sonic running with explosions behind him that ends when he goes off screen.  When you use Debug to warp to "silver" sonic or whatever the thing is called, the explosions go and follow you and the script of the boss starts again.  The script is not supposed to let you move sonic at all to the left but when you use debug, you move to silver and refight him with explosions.  This occurence is not coded in the ROM because it disallows you to do this normally but since hack (debug) moved you to the script spot, you are fighting metal sonic with screwed up RAM because the RAM is saying you are in script and fighting silver sonic at the same time trying to make it work with the ROM which disallows this normally.

To zeroth part: But Arceus isn't created by a variable. It's created by a hundred variables unrelated to the glitches in the GlitchDex that were created by a single variable.

To first part: Except, does Pokemon RBY generate random data during a RAM-hacked glitch? Where does it get all its ideas for effects from? If you make Oak walk around the world with a code that doesn't explicitly script him to do that, then why does the game do that? It probably made weird numbers with the script lying in the ROM for Oak to walk, or looked at some text or tiles, and thought they were the script or CPU opcodes for Oak, and used that.

To second part: Yes, the debug menu coded in the ROM commanded the RAM to move it over. The ROM, having reacted with it, sees nothing wrong with it because it looks like Sonic is back there again, and executes the script again as usual.

You said glitches created by savestates should be in site so Arceus Savestate is a site submission?

To first part: Except, does Pokemon RBY generate random data during a RAM-hacked glitch? Where does it get all its ideas for effects from? If you make Oak walk around the world with a code that doesn't explicitly script him to do that, then why does the game do that? It probably made weird numbers with the script lying in the ROM for Oak to walk, or looked at some text or tiles, and thought they were the script or CPU opcodes for Oak, and used that. <– The scroll down Oak fast then slow scroll up then warp down etc. script is not in the ROM.  The Super Glitch City tht made him do that was a wonder it DIDN'T make the game crash. It was warp music with varients while he was walking (and being controlled BY THE PLAYER.)  "It probably made weird numbers with the script lying in the ROM for Oak to walk, or looked at some text or tiles, and thought they were the script or CPU opcodes for Oak, and used that."  It's still not in the ROM.  To second part: "Yes, the debug menu coded in the ROM commanded the RAM to move it over. The ROM, having reacted with it, sees nothing wrong with it because it looks like Sonic is back there again, and executes the script again as usual." <– No, the screen still has explosions in the beginning created by the RAM.  Using Debug mode you can also make an offcolored sonic (Sonic uneducated people call him Ashura which is some bullshit) that screws up has pallete and makes the RAM change his pallete into a non-coded pallete in both the life indicator and his sprite. (Usually the life indicator pallete is different from the pallete swapped sprite)

OK, coding glitch or not, it's still a glitch!