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.

Messages - bbbbbbbbba

Pages: 1 2 [3] 4 5 6
Wiki Discussion / Re: On the definition of "glitch"
« 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.
Wiki Discussion / Re: On the definition of "glitch"
« 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"?
Wiki Discussion / Re: On the definition of "glitch"
« 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, but I don't think that's known to be possible in any of the Pokémon games.)
Wiki Discussion / Re: On the definition of "glitch"
« 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".
Wiki Discussion / Re: On the definition of "glitch"
« 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.
Wiki Discussion / Re: On the definition of "glitch"
« 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.
Generation I Glitch Discussion / Re: PP (not) Up
« on: September 30, 2019, 11:12:43 am »
I suggest that, after a few basic checks (like making sure the max PP is still 7), you should get ACE and read the RAM directly to see what it going on. You can find the relevant memory addresses by looking up Gameshark codes.
Generation I Glitch Discussion / Re: PP (not) Up
« on: September 29, 2019, 07:40:50 pm »
We have discussed about this on the Discord the other day, and we agree that TM01 doesn't get increased PP because its base PP is 3, and 3/5 rounded down is 0. However, we all believe that TM13, a 7 PP move, should be able to take PP Ups as normal. Can you post more details about your experiments?
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?
Well, I'd guess it's the quickest manipless way. The method in the current "catch 'em all" route is faster for hardcore runners, but death-warp methods without manipulation are obviously miserable on a real console. And even the "F8FF" route might be able to be adapted to give you a x255 item stack and dump you somewhere safe (avoid the Forest until you can fix it). In the end, there is a trade-off between speed, complexity and reliability, and the Machop guy method probably hits the right balance for the average casual player.
We got an example very quickly with the Defense Up 1 glitch

Just to clarify, please don't use this name for the wiki page (even a redirection would be unnecessary IMO). I would suggest "0 damage reported as miss (glitch)", with some variations of "doubly resisted move missing glitch" being the redirections. It can also encompass one of the effects of dual-type damage misinformation.

Further on topic, bringing back the "natural glitches" category and displaying it prominently is a good suggestion, though I might want to put more emphasis on what...well, cuts to the core of the game, basically. Not just something that happens to be doable from a new file. "Essential glitches", or something? In my case, if it wasn't for the techniques in 151 and RBA, I might not have ever come back here, for instance.

Well, I am going to disagree a little, because glitches don't "happen" to be doable from a new file. If they are, that's because they are manifestations of true bugs, rather than one broken assumption causing a chain reaction. Regardless, a focus on "essential glitches" is certainly warranted. I would tentatively define them as "the first glitchy step of a fastest way, starting from a reasonable game state, to achieve a sequence break (or some other appropriate goal)", although, seeing that there should not be too many of them, having them decided on a case-by-case basis by the community might be OK too.

A first step might be to put at least one of the Gen I essential glitches (probably either trainer escape or old man glitch) back onto the sidebar. I also think ACE really doesn't belong in the "glitches" section of the sidebar, as it is too wide a category when regarded as a collection of glitches, and it is much better to think of it as a goal.

Another category that might warrant some focus is "glitches that can happen in normal gameplay". Some glitches doesn't need contrived setups, or out-of-the-box thinking: Looking at the price tag of the bike (and exiting the menu using B) is completely normal behavior for a casual player. Gen I misses are just a fact of life. And I believe every kid who played the game on a non-SGB platform had at some point noticed the escape sprite handling glitch and wondered "what the heck is that?!"

About collapsible sections, by the way, I looked at a page here on my phone a couple days ago and instantly realized what you were talking about, so in short I'm on board in theory with using them for longer pages. There is still the question of practicality for those using a bigger screen, as I don't know if enough pages need entire sections hidden to look cleaner.

It might be because those sections don't exist yet! I think many pages might benefit from a more in-depth analysis or some screenshots, but they haven't been added at least partly because they would break the flow of reading.

Incidentally, Legendary Star Blob has text explanations beside the screenshot (example), instead of vertically between them, and I think that might be a better approach for procedures with screenshots. What do you think? Maybe we can add a template for this.
Hmm... I think just your presence would help us a lot. Maybe just hang out in our discord, explaining things you are familiar with if someone asks. Maybe look up the relevant glitches here when you are working on a route, noting if there is something missing, incorrect, or difficult to read. (If you don't want to fix something yourself, you can just inform us. I'm sure if you bug us enough, some of us would do it. ;D)

I am not really familiar with the speedrunning community, so I'm not sure about my suggestions. (I've tried to join the Pokémon speedrunning discord, but I left when the server asked me which game I ran. Obviously I didn't run any, and I took that as an evidence of the speedrunning community being unfriendly towards non-runners. I was probably thinking too much...)
Generation I Glitch Discussion / Re: The aftereffects of Glitch Trainer 0xFD
« on: September 14, 2019, 03:10:59 am »
I think I've found out the culprit. After a battle, the game copies the enemy trainer's name in a weird way (disassembly). According to this table, the 0xFD trainer's name should come from $9481, which is in the VRAM. Since this copy is until a 0x50 terminator, mass corruption happens.

Edit: I think I've found out why the game does this, too. In the Japanese version, some trainer names actually have an abbreviated version that is used as dialog tags (video). Presumably the entries in TrainerNamePointers that aren't wTrainerName were originally those abbreviations in the Japanese version.
A Pokédex entry is a relatively complicated object. A valid Pokédex entry looks like this:
Code: [Select]
; string: species name
; height in feet, inches
; weight in pounds
; text entry

db "DRILL@"
db 6,3
dw 2650
TX_FAR _RhydonDexEntry
db "@"
Here "DRILL" means Rhydon is the Drill Pokémon. This string is the first to be printed to the screen, and with good reason: The game need to know where that string ends in order to find all the other data.

Consider a Pokédex entry at $AA00. Contrary to what I initially believed, the SRAM is actually unlocked during the battle. It is locked when the game finished loading the player's back sprite, but is then unlocked when the game loaded the back sprite of my first Pokémon and never locked again. I can't tell if this is intentional.

Well, on my save file for testing, SRA0:AA00 is a bunch of 0xFF anyway. (Probably because I have cleared the save file some time in the past.) Which is an awfully long string of "9". More "9"s than healthy for the game. For example, at some point it overwrites wOptions and then wLetterPrintingDelayFlags, which causes the game to wait 15 frames between characters. And that's terrible.

For some reason, beginning at SRA0:BBB7, my save data is no longer 0xFF. It begins with some bytes I don't understand ("E4 35 70 01 67 3E 8C 00 00 39 C3 BB 94 20 20 D3 01 8C 8C 8C 20 D3 38"), and then (starting at $BBCE) becomes "00 39 00 39 00 39 ...". I guess old crashes don't die that easily.

Anyway, the game mercy kills the PlaceString subroutine when it sees 0x00 at $BBBE. But it puts the pointer de at $19F3, which is... here. Starting from $19F4, the bytes "17 96 66 22" are interpreted as the height and weight data (23'150"/880.6 lb; the 150 displayed as " 0" when forced to be printed in two digits). Right after there happens to be a 0x50 terminator. Everything is fine!

Except that wJoyIgnore has also been overwritten to 0xFF, so I softlock. Oh well. At least I can soft reset.

It should be clear by now why this Pokédex entry behaves differently depending on the save file, especially after looking at glitch Pokémon sprites (which are known to trash SRAM Bank 0, also known as HOF data). Anyway... why don't you set a breakpoint at 10:435E and see for yourself?
On the categorization problem, I think maybe the best solution is still to revive the "natural glitch" category. The thing is, in theory any glitch could be reached by only following "consequence" links starting from natural glitches (except cheating/ACE only glitches, which can have their own category). For giving newcomers a tour of the site, they are as good a category as any. And they have a rather well-defined boundary, which, in my opinion, is important for a categorization system to work, especially if we don't want it to be maintained by a single person.

One problem with natural glitches I see is that there are still too many of them, especially for Generation I (see list of natural glitches in Generation I). It might still be necessary to have a notion of "major glitches" based on their perceived usefulness/destructiveness. I currently don't have a satisfactory idea, but I hope we can come up with a definition that, while probably not completely clear-cut, is at least objective and logical, so that people can argue for a page's inclusion or exclusion.

If the "major glitch" category turns out to be too broad in the other direction (ACE programs tend to be useful, after all), we can always focus just on natural major glitches (of course, necessary precursors of major glitches would all be major glitches). I don't want to argue that something like item underflow is not major, but they don't need to be exposed through a "public-facing" category.

About the definition of "major glitches", we can open another thread if people feel it's worth it.

Another idea: Maybe we can have a "glitch infobox" template, similar to our Template:ItemInfoGenI or Bulbapedia's Template:Pokémon Infobox, and put there some basic information like affected version(s), variations, consequences, precursors (for non-natural glitches), etc. It can serve the dual purpose of helping people decide if they are interested enough to read the text, and facilitating navigation. It can also contain a good screenshot (gif if necessary) that showcases the glitch, which would be nice too.
Pages: 1 2 [3] 4 5 6