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 - Háčky

Pages: 1 [2] 3 4 ... 9
Generation II Glitch Discussion / Re: Nightmare glitch and more
« on: February 03, 2017, 05:51:37 pm »
That code is only called when the player uses an item, not the AI. AI item usage is controlled by the code in battle/ai/items.asm. The equivalent function AI_HealStatus cures the AI’s active Pokémon of the effect of Toxic but not the effect of Nightmare. EnemyUsedFullRestore additionally cures the AI’s active Pokémon of confusion, but EnemyUsedFullHeal does not cure confusion. These bugs seem to be holdovers from Generation I, when Nightmare didn’t exist and neither Full Heal nor Full Restore cured confusion.
Pokémon Discussion / Re: Safari Zone: Mysterious hidden texts
« on: December 23, 2016, 02:58:22 pm »
TCRF says that there is an untranslated data corruption error used by the Cable Club in Red and Green.

Does it even exist in the English versions and, if so, is it returned as mojibake?
That message and its associated code only exist in the original Red/Green ROMs, not in Rev. A or any later games.

That's really interesting Háčky. I didn't know there were differences in text between rev 1.0 and rev A. Is the message used in any way (possibly by trading an unstable hybrid glitch Pokémon)? I think probably not if it only exists in one revision but I'm curious.
It looks like the message is shown if either player’s name starts with $60 (bold A). I don’t know why that would be the case, and I guess Game Freak didn’t either :P

Code: [Select]
ld a, [wPlayerName]
cp $60
jr nz, .playerDataNotCorrupted
ld de, OneselfString
jr .corrupted
ld a, [wLinkEnemyTrainerName]
cp $60
jr nz, .parterDataNotCorrupted
ld de, PartnerString
call CopyStringToCF4B
ld hl, DataCorruptedString
call PrintText
jr @ ; spin
Pokémon Discussion / Re: Safari Zone: Mysterious hidden texts
« on: December 23, 2016, 02:50:52 pm »
TCRF says that there is an untranslated data corruption error used by the Cable Club in Red and Green.

Does it even exist in the English versions and, if so, is it returned as mojibake?
That message and its associated code only exist in the original Red/Green ROMs, not in Rev. A or any later games.
You’d need some way of activating the mobile features in Viet Crystal. Simply plugging in a Mobile Adapter GB doesn’t work.

The reason is that Viet Crystal altered a byte at 01:6594, changing the call to function 5B:4000 (which is used to check for the Mobile Adapter GB on startup) into a call to 01:4000 (which displays the string “Waiting…!” during a link cable connection?).
Pokémon Discussion / Re: Trades between RBY and Pokémon Sun and Moon
« on: September 09, 2016, 12:06:05 am »
Also, we saw how rigorous and rigid the validity check is for pokebank, will any mews in gen 1 be able to be transferred at all, considering theyre solely available in VC through a glitch?

There was a Mew distribution event for the VC games in Japan, so they’ll at least have to accept those. It’s possible they could reject any Mew from a non-Japanese version.
Emulation & ROM Hacking / Re: Text dumping 'Pokemon Vietnamese Crystal'
« on: August 25, 2016, 09:18:58 pm »
There’s an existing text dump, but if you’re interested in poking around yourself, the character map starting from $80 is:


Everything from $B5 to $E2 is question marks (which is why most untranslated text is shown as mostly question marks, because that range covers most of the hiragana in the original character set); everything from $E3 to $FF is left as it was in the original game.

If you look through the text, you’ll see that a lot of strings were translated more than once; I was trying to catalogue these a while back until I stumbled into something more exciting.

Personally, my favorite piece of translation work is the text for Mobile Stadium Moveable Sport Field:

They also acknowledged and fixed the Berry glitch in Ruby and Sapphire, and the Lumiose City save glitch in X and Y.
A while back, I noticed that echo RAM doesn’t work in GB Tower (in either Pokémon Stadium or Stadium 2). There seemed to be other data at those addresses but I couldn’t tell anything about what it was.

I tried running these tests in Stadium 2:

UnknownOpcodes: Fail (“The saved data has been corrupted, so it is impossible to CONTINUE. Please reset the game and choose NEW GAME.” No, it didn’t actually corrupt my save file.)
InvalidBanks: Pass (124)
VRAMAccess: ? (always 255)
EchoRAM: Fail (30)
InvalidStop: Fail
Pokémon Discussion / Re: 2nd Gen Roaming Mechanics
« on: June 30, 2016, 08:00:05 am »
Thank you! I was tempted to look into this the last time I was trying to track down the beasts, but never did.

Roar has −1 priority. If fleeing has the same priority as the selected move, that would explain why slower Pokémon can sometimes attack before the beast flees.
Pokémon Discussion / Re: Debug menus in Japanese Crystal
« on: June 15, 2016, 08:50:02 pm »
I see. Thanks for that. :)

Regarding the sound test, may I ask how would we go about activating it with arbitrary code execution (with a trick such as TM15 ACE)? Would it be as simple as bringing up the menu, or are there pointers within the menu code that were changed in the final game?

The sound test makes several calls to functions in the upper part of bank 0 that are offset by $3D bytes, including important ones like PlayMusic and PlaySFX ;)

In order to run it with ACE, you’d have to copy the code (from 3F:72C3–73B1) into RAM and patch those calls. And once the code is moved into RAM, you’d also need to patch calls to the sound test’s own subroutines so they point to the new addresses in RAM. Probably the simplest patching method would be to loop through the code looking for the bytes $CD (call) and $C3 (jp) and checking the high byte of the address that follows. If it’s ≥ $40, then it’s pointing to its own code in bank $3F and needs to be offset to wherever you’ve put the patched code in RAM. If it’s ≥ $2B, then it’s pointing to the upper part of bank 0 and you need to subtract $003D. If it’s < $2B, then the address is fine. (This might not work properly if the bytes $CD or $C3 appeared as an operand rather than an instruction, but luckily they don’t in the sound test code.)
Pokémon Discussion / Re: Debug menus in Japanese Crystal
« on: June 15, 2016, 02:26:36 pm »
Displays the Mobile Adapter connection prompt with an incorrect palette. Maybe it would do more than that if a connection could be made.

This script initiates a Colosseum mobile battle using the first three Pokémon in the party. It can be either a time-limited battle or an unlimited one depending on the “unlimited battle mobile adapter” flag.

The palette of the Mobile Adapter prompt depends on the location where it’s accessed. In an area such as the first floor of the PokéCom Center, the prompt will be the usual dark blue.

Also, I realize I never mentioned how to access those unreferenced scripts. The Game Genie codes ??4-819-D58 · ??4-829-7FB will replace the pointer to テスト1 Test 1.

Quick-start (3F:5983)
Function 3F:5983 seems to be intended as some sort of accelerated start for debugging purposes. It does a bewildering variety of peculiar things:

  • Sets bit 7 of $D83F (StatusFlags). (Pokecrystal identifies this as ENGINE_BUG_CONTEST_ON, but I don’t think it’s related to the Bug-Catching Contest at all. The only place I see that it’s used is in MainMenu_GetWhichMenu, which checks this flag but then does the same thing whether it’s set or not. The flag is set in-game when the Mystery Egg is given to Prof. Elm.)

There’s dummied-out code for the main menu in the English version of Pokémon Crystal? When I say it like that, the reason for it becomes a lot more obvious :P

That flag is used in the Japanese version to hide the Mobile and Mobile Stadium options from the main menu until the Mystery Egg is delivered to Prof. Elm.

These are incredible finds! Well done Háčky! There are a number of sound effects in the sound test I don't recognize, such as 45, 146, 175, 176-178, 205, 206. Are any of those used?

175–178 are used for the moves Moonlight, Encore, Beat Up, and Baton Pass.

206 is used when unlocking the Card Folder. 205 is probably also used for some mobile feature, but I don’t know which one.

045 and 146 don’t seem to be used. Notably, 045 (called SFX_FANFARE in pokecrystal) can be played by a text script, but there don’t appear to be any text scripts that use that command.
Emulation & ROM Hacking / Re: Emulating the Mobile Adapter GB
« on: June 14, 2016, 11:48:49 am »
This is something I meant to do myself, by the way: I just tried to go about it a different way, via static analysis, and I'm not sure how the GB serial hardware works.

That sounds painful ;D I started by setting a read breakpoint on $FF01 (serial data) and trying to find what bytes I could put there to make something different happen.

OK. I modified the emulator to dump to file the data of any unknown packet.

I then went into the Cable Trade Center, and canceled, and now I have several files to look through.

Haven't discovered much yet, naturally, however, it seems to use specifically 0x15 packets.

Seems the "byte of unknown significance" is the length of the sent/received data.

The first byte of a $15 packet is, as far as I’ve seen, always $FF (though my implementation sends $00 and it doesn’t seem to matter). Your dumps are starting from the second byte, which is the first byte of the actual data sent by the Trade Center/Colosseum. These features apparently have their own redundant packet structure, which starts with the length and ends with a little-endian checksum.

There's a similar string near both of them, "\x19\x67\x10\x01free__crystal". Guessing this one is used with the Unlimited Battle Adapter, given this code?

Yes, "free__crystal" is sent in “unlimited battle” mode.
Emulation & ROM Hacking / Emulating the Mobile Adapter GB
« on: June 13, 2016, 11:46:06 pm »
It’s been over fifteen years and no one has done this yet?

(This post is necessarily going to be filled with technical minutiae, so if that’s not your thing, you may want to skip the entire first half of it and skim through the rest. If that is your thing, then you don’t need me to tell you what to do.)

I’ve documented most of the protocol that Game Boy Color games use to communicate with the Mobile Adapter GB, and written a proof-of-concept implementation that links with BGB and enables Mobile Trainer’s initial setup and Pokémon Crystal’s Trade Corner to work. Because I’ve been working with BGB, I’ve not yet tested anything with Game Boy Advance games, but I would expect that the protocol is the same and it should be possible to create an implementation compatible with VBA-M in the future.

As all of this information has been determined solely from analysis of Mobile Trainer and Pokémon Crystal, I can’t say whether this documentation represents how the Mobile Adapter GB hardware actually behaves, but it at least represents how these games seem to expect it to behave.

Protocol description
The Game Boy Color communicates with the Mobile Adapter GB at a clock speed of 512 KiHz (bits 0 and 1 of the SC register are set and the GBC is in double-speed mode). The protocol closely resembles the one used by the Game Boy Printer, but it has been modified for two-way communication.

A communication session consists of a series of commands sent by the Game Boy Color, each followed by a response from the Mobile Adapter GB, generally using the same command ID as the command it is responding to. A session begins with the Game Boy Color sending command $10 with the body "NINTENDO", and the Mobile Adapter GB replying with the same. The session ends when the Game Boy Color sends command $11, and the Mobile Adapter GB responds in kind.

When either device sends a packet, it begins by sending the preamble bytes $99 $66, followed by the packet data. After the packet is finished, both the sender and receiver transmit a byte containing their device ID xor $80. (The Game Boy Color’s device ID is $00. Any device ID from $08 to $0F is recognized as a Mobile Adapter GB: $08 is the PDC model, $09 is the CDMA model, $0A is the unreleased DoCoMo PHS model, and $0B is the DDI PHS model. $0C–0F were presumably reserved for future use.)

After the device ID, the sender sends $00 while the receiver confirms successful receipt of the packet by sending the packet’s command ID xor $80. If the packet checksum fails, the recipient sends $F1 instead, which instructs the other device to resend the packet. ($EE, $F0, and $F2 also appear to be error codes, but I don’t know how they’re used.)

The packet itself consists of a four-byte header, followed by the body, followed by a two-byte big-endian checksum, which is the sum of each preceding byte (not including the $99 $66 preamble). The first byte of the header is the command ID, and the fourth is the length of the packet body. The second and third bytes are unused, as far as I know, and are set to $00. While a packet is being received, the recipient continuously transmits the byte $4B.

Command listing
This list covers all of the commands supported by the standard library found in Pokémon Crystal. There is also at least one command, $1A (write configuration data), that is exclusively used by Mobile Trainer. It’s possible that some of the missing numbers are commands that exist in the hardware but were never used by any software; for instance, I would expect that there are commands for opening and closing UDP connections.

The command numbers appear to be organized such that commands numbered $1x relate to the basic operation of the Mobile Adapter GB and its attached telephone, while commands numbered $2x are network operations.

$10: Begin session
Sent to the adapter at the start of a session. The packet body is the ASCII string "NINTENDO". The adapter replies with an identical packet.

$11: End session
Sent to the adapter at the end of a session. The packet body is empty. The adapter replies with an identical empty packet.

$12: Dial telephone
Instructs the adapter to dial a telephone number. The packet body contains one byte of unknown significance, followed by the telephone number written in ASCII. The adapter’s response has an empty body.

$13: Hang up telephone
Instructs the adapter to hang up a telephone connection. The packet body is empty. The adapter replies with an identical empty packet.

$14: Wait for telephone call
Instructs the adapter to wait for a telephone call to be received. The packet body is empty. The adapter replies with an identical empty packet (only when the call is received?).

$15: Transfer data
This command is used either to send data over a TCP connection opened with command $23, or directly to another Mobile Adapter GB. While a connection is open, the Game Boy sends this packet containing one byte of unknown significance followed by zero or more bytes of data to be transmitted. The adapter replies with one byte of unknown significance followed by zero or more bytes that it has received from the other end. This is repeated until the connection is closed. The adapter sets bit 7 of the command ID while it is connected to a server, so the reply’s command ID appears as $95. When the remote server has closed the connection (e.g., at the end of an HTTP response), the reply sets the command ID byte to $9F instead.

$17: Telephone status
Sent to the adapter before attempting to dial. The packet body is empty. The adapter’s reply has one byte: $00 means that the telephone is ready to make a call, $04 or $05 means that the line is busy (I’m not sure what the difference between these values is?), and any other value seems to be an error. Some features of Mobile Trainer actually check this after dialing to make sure the line is active, but Pokémon Crystal doesn’t bother.

$19: Read configuration data
Requests a portion of the adapter’s 192-byte configuration memory. The packet body consists of two bytes; the first is an offset and the second is the number of bytes to be read. The adapter replies with a body containing one byte of unknown significance (possibly the offset, although that would be redundant?) followed by the requested data. In practice, the configuration data is read in two chunks of 96 bytes; it should be technically possible to read the full 192 bytes at once, but reading in smaller chunks is probably more reliable.

$1A: Write configuration data
Writes to a portion of the adapter’s 192-byte configuration memory. The packet body consists of one byte, which is an offset, followed by the bytes to be written. The adapter’s reply has an empty body (or, at least, Mobile Trainer doesn’t seem to care what the response is). As with the read command, Mobile Trainer chooses to write the data in two separate chunks (of 128 and 64 bytes).

$21: ISP login
Logs in to the DION service (which will then be used to connect to an Internet server). The packet body begins with the login ID and password, each prefixed by a byte denoting its length. The last eight bytes are the IPv4 addresses of two DNS servers. The adapter’s reply has a four-byte body, which might be an IPv4 address assigned to the adapter, although that doesn’t seem to be needed for anything in-game.

$22: ISP logout
Logs out of the DION service. The packet body is empty. The adapter replies with an identical packet.

$23: Open TCP connection
Opens a TCP connection to an Internet server. The packet body consists of an IPv4 address (four bytes) and a port number (two bytes, big-endian). The adapter replies with one byte of unknown significance. The adapter sets bit 7 of the command ID while it is connected to a server, so the reply’s command ID appears as $A3.

$24: Close TCP connection
Closes a TCP connection to an Internet server. The packet body contains one byte of unknown significance. The adapter replies with one byte of unknown significance.

$28: DNS query
Looks up the IP address for a domain name, presumably using the DNS server addresses sent in command $21. The packet body is the domain name. The adapter’s reply has a four-byte body containing the corresponding IPv4 address.

Configuration memory
The Mobile Adapter GB has 192 bytes of memory in which to store configuration data. This memory can be read with command $19 and written with command $1A. It is structured as follows:

Code: [Select]
$00  "MA"
$02  Set to $01 during Mobile Trainer registration
     Set to $81 when registration is successfully completed
$04  Primary DNS server (
$08  Secondary DNS server (
$0C  Login ID ("g_________")
$2C  E-mail address ("")
$4A  SMTP server ("")
$5E  POP server ("")
$76  Configuration slot 1
$8E  Configuration slot 2
$A6  Configuration slot 3
$BE  Checksum (big-endian)

Strings are null-terminated if shorter than the fields which contain them.

Each configuration slot may contain a telephone number to be used to connect to the ISP (eight bytes) and an identifying string (sixteen bytes). The telephone number is stored in a variant of binary-coded decimal, where $A represents the # key, $B represents the * key, and $F marks the end of the telephone number.

If the device ID is $08 (PDC) or $09 (CDMA), Mobile Trainer will configure it to use the telephone number #9677 and identifying string "DION PDC/CDMAONE". If the device ID is $0A (DoCoMo PHS) or $0B (DDI PHS), it will be configured with the telephone number 0077487751 and identifying string "DION DDI-POCKET".

These are always written to the first configuration slot; the other two slots are always empty (filled with $FF and $00), and it’s unclear how they would have been used. (I’m guessing they’re there in case Nintendo wanted to support an ISP other than DION in the future?) Pokémon Crystal has an option within the Mobile menu, titled 「モバイルセンターを えらぶ」 Choose a Mobile Center, for selecting which of these three configuration slots it will use.

If the device ID is one of the unused values $0C–0F, Mobile Trainer will fill the entire configuration memory with garbage data, because bounds checking is for sissies.

The checksum, like the packet checksum, is simply the sum of the preceding 190 bytes.

Mobile Trainer
Initial setup
When the Mobile Trainer cartridge is first loaded with the Mobile Adapter GB connected, a setup wizard prompts the user to enter their DION login ID, e-mail address, and password. (According to instructions published by the Nintendo Online Magazine, these credentials were provided on the 「DIONモバイルGBコース登録書」 DION Mobile GB Plan Registration Form included in the Mobile Adapter GB box. The account would expire after 15 days unless the Registration Form was filled out and mailed to KDDI.)

(Straying further from the topic, this site has some photographs of the printed matter supplied with the Mobile Adapter GB, which bizarrely includes a promotion offering baseballs signed by Kazuhiro Sasaki, then a pitcher for the Nintendo of America–owned Seattle Mariners.)

The login ID and e-mail address are stored in the adapter’s configuration memory, and the user is asked to choose whether or not the password will be saved on the Mobile Trainer cartridge. After that, Mobile Trainer attempts to log in to the DION POP e-mail server (, where the subdomain is filled in from the entered e-mail address). If the login is successful, then a welcome message is displayed, followed by the Mobile Trainer title screen.

After setup has been completed, Mobile Trainer will boot to the title screen even when the Mobile Adapter GB is not connected. (If an adapter is connected, Mobile Trainer will still check whether it has been configured, and launch the setup wizard if needed.)


Other features
I haven’t put much effort into getting any other features of Mobile Trainer working, but they all appear to be fairly straightforward: the e-mail uses DION’s POP and SMTP servers, the account management options use a simple HTTP interface, and Nintendo’s mobile homepage would have used some subset of HTML (though there probably aren’t any complete surviving copies of the pages, there are a few screenshots in this Nintendo Online Magazine article).

However, there may be significant unused content in the Mobile Trainer ROM. The most obvious instance is some text for a debug menu that’s helpfully titled 「== DEBUG MODE ==」. I also found this peculiar run of text:



GAMER's Life



To my knowledge, Bowser didn’t play baseball until 2005 on the GameCube, and I still haven’t heard any news about this Pocket Monsters Moss

One more thing I noticed is that after completing the initial setup, there are four options in the 「モバイルせってい」 Mobile Settings menu, but when Torchickens used a GameShark code to skip the initial setup, a fifth option, 「電話番号の変更」 Change telephone number, appeared. By erasing my Mobile Trainer save file and using that GameShark code, I was able to replicate this and attempted to use this option. It read the configuration data from the adapter, then started executing from WRAM and choked on opcode $FD. I’m guessing that’s not the intended behavior.

Pokémon Crystal
Initial connection
On startup, before the copyright screen, Pokémon Crystal tries to connect to the Mobile Adapter GB and check the telephone status with command $17. If this connection is successful (which does not require that the adapter even be configured), all of the game’s mobile features are unlocked except for Mobile Stadium.

(The telephone status check has no purpose: the game will recognize the adapter as connected regardless of what value it sends in response to command $17. It appears that the result of this check is used to set or clear the “unlimited battle mobile adapter” flag, but the flag is always cleared regardless of what value is sent by the adapter. I’m guessing the debug build behaved differently.)

After the successful connection, the 「モバイル プロフィール」 “Mobile Profile” screen will be presented the first time Continue is selected from the main menu, or whenever a new game is started.

Egg Ticket
When the Egg Ticket is redeemed at the PokéCom Center Trade Corner, the game makes an HTTP GET request for ("CGB-BXTJ" is the product code for the Japanese version of Pokémon Crystal; "01" denotes the game’s publisher, Nintendo.) This text file should have two lines, with CRLF line endings.

The first line is the HTTP URI that will be used to download the Odd Egg data. This URI contains a sequence of up to four capital "X"s, which the game will replace with a hexadecimal value.

(If the filename—i.e., the part of the URI after the last "/", even if it’s part of the query string—starts with a decimal digit, the game reads up to three digits from the start of the filename, interprets this as the service fee [in yen] charged for downloading this file, and prompts the user to confirm before downloading it. Since it is known that there was no service fee for the Egg Ticket event, the filename should not start with a digit, or an "X" that will be replaced by a digit.)

The second line is a series of 16-bit values written in hexadecimal (with lowercase "a""f"). These represent the cumulative probabilities of each Odd Egg being obtained. The game generates a random 16-bit number, compares it to each of these values, and downloads the Odd Egg corresponding to the first value that is greater than or equal to the random number, by filling in the "X"s in the URI with "0000" for the first Odd Egg, "0001" for the second, and so on in hexadecimal. Leading digits will be omitted if there are fewer than four "X"s to replace.

If the second line of the file is blank, the Trade Corner attendant will say 「もうしわけ ございません! ただいま タマゴけんの サービスは ちゅうし しています」 “I’m awfully sorry. The EGG TICKET exchange service isn’t running now.” Reportedly the Egg Ticket exchange service ran for the entire time that the Mobile System GB was in operation, so this text would never have been used. If the Egg Ticket service was shut down, it would have made it impossible for someone who had the Egg Ticket in their Bag to use the Trade Corner until they deposited it in their PC, which could have been confusing.

The downloaded Odd Egg file is 54 bytes, containing the 48-byte Pokémon data structure followed by the nickname, which should be 「タマゴ」 “EGG”. The OT name 「なぞ」 “ODD” is added by the game, though it goes unseen since an Egg’s OT is always shown as “?????” until it hatches.

For my implementation, I’ve copied the Odd Egg data from the English version. But according to legend, the Odd Egg received from the mobile event had a 50% chance to be Shiny, higher than the 14% chance for the in-game event in the Western versions. Does anyone know where this information came from? The only way to verify it would have been to download index.txt and read the probability values, and I’ve seen no evidence that anyone would have known how to do that at the time.


PokéCom Center Trade Corner
When a Pokémon is deposited at the Trade Corner, the game sends an HTTP GET request for The first line of this file is a URI that will be used to log in before uploading the Pokémon data. Since the service fee for the Trade Corner was ¥10, the filename in that URI should start with "10".

As far as I can tell, the server is supposed to send an HTTP 401 Unauthorized response with a WWW-Authenticate header, to which the game will respond by retrying with an Authorization header. Then the server will respond with a Gb-Auth-ID header. I can’t seem to get this process to work, so instead I’ve bypassed it by having the server send the Gb-Auth-ID on the first try.

The game POSTs a 143-byte file with the following contents:

Code: [Select]
$00  DION e-mail address (null-terminated ASCII)
$1E  Trainer ID
$20  Secret ID
$22  Offered Pokémon’s gender
$23  Offered Pokémon’s species
$24  Requested Pokémon’s gender
$25  Requested Pokémon’s species
$26  Trainer name
$2B  Offered Pokémon’s 48-byte data structure
$5B  Offered Pokémon’s OT name
$60  Offered Pokémon’s nickname
$65  Mail data (filled with 00 if not holding Mail):
$65    Message
$86    Sender’s name
$8B    Sender’s Trainer ID
$8D    Pokémon species
$8E    Item index

The genders of the offered and requested Pokémon are encoded as: $00 = gender unknown, $01 = male, $02 = female, and (for the requested Pokémon) $03 = either male or female.

After a Pokémon is deposited in the Trade Corner, the game enforces a two-hour waiting period before the status of the trade may be checked. To check if a trade has been made, the game logs in to the DION POP e-mail server and searches for an e-mail with the header X-Game-code: CGB-BXTJ-00. If it finds one, it will read the X-Game-result header, which is in the format 1 ttttssss oooo rrrr x, where tttt and ssss are the Trainer ID and Secret ID, oooo is the gender and species of the offered Pokémon, and rrrr is the gender and species of the requested Pokémon, all written in lowercase hexadecimal. The last character x is either "1" or "2", with "1" indicating that a trade partner has been found and "2" indicating that the server has given up on finding one. If a trade partner has been found, the body of the e-mail will contain the last 105 bytes of the above data structure (starting from the Trainer name) for the received Pokémon, encoded in Base64.

If no e-mail with a matching X-Game-code and X-Game-result is found, the Trade Corner attendant will give you the option to retrieve your Pokémon. If you choose to retrieve it, the game reads a URI from the second line of exchange/index.txt and POSTs a 38-byte file to it, which contains the first 38 bytes of the above data structure (up to the requested Pokémon’s species). This cancels the trade.


Cable Trade Center
I wasn’t planning to work on the multiplayer features at this point; I just wanted to see what commands they use so I could add them to the command listing.

I wrote my program so that when it received a command it didn’t recognize, it would echo that command verbatim in response. This turned out to be entirely sufficient to make the Mobile Trade screen open and let me trade with myself!


One notable feature of the mobile trade animations is that the Mobile Adapter GB is depicted using a palette chosen according to the device ID—the PDC adapter is shown as blue, the CDMA adapter is shown as yellow, the unreleased DoCoMo PHS adapter is shown as green, and the DDI PHS adapter is shown as red. There are also assigned palettes for the unused device IDs $0C–0F: purple for $0C, black for $0D, pink for $0E, and gray/violet for $0F.

Cable Club Colosseum
I was also able to get into a battle with myself in the Colosseum, though it inevitably unraveled when the opposing Pokémon fainted and it tried to send out the fainted Pokémon as a replacement for itself (since it wasn’t “my” Pokémon that fainted, I hadn’t made a selection).

I did, however, find out what an “unlimited battle mobile adapter” does: it removes the 10 minute per day limit on Colosseum battles. When entering the Colosseum without the “unlimited battle” flag, the attendant will ask: 「きょうの のこり じかんは あと 10 ふんです[。] たいせん しますか?」 “Today’s remaining time is 10 min. Would you like to battle?” (or one of a few other messages if less time is left). With the “unlimited battle” flag, she asks instead: 「モバイル たいせん では ポケモンを 3たい えらんで たいせん します[。] よろしいですか?」 “To enter a mobile battle, you must pick a team of three POKéMON. Is that OK?”


I pilfered the BGB linking code from TheZZAZZGlitch’s implementation of the Game Boy Printer protocol and wrote a script that does just enough to make these features work. Rather than connecting to a proper server, it fabricates the responses that the server should give for a limited set of commands. It completely ignores the DION login ID and password, so you can enter whatever you want in Mobile Trainer’s setup. The e-mail server is hard-coded to contain an e-mail matching the Pidgey-for-Pidgey trade that I made in the video; if you want to use the Trade Corner, you’ll have to edit that e-mail to match your Trainer ID, Secret ID, and the trade you’ve made.

I think the next step will be to set up a server that can run a fully functioning Trade Corner, and write a client that can connect to that server or make direct “calls” to other clients. There’s still the matter of getting Pokémon Crystal’s Pokémon News, Battle Tower, and Mobile Stadium features running, and after that, it might be interesting to get a couple of the other Mobile Adapter GB compatible games working. Eventually, it would be fun to build a ROM hack of the English version of Pokémon Crystal that restores all of its mobile functionality.
The 182/800 figure is the probability of Zigzagoon having 11 or 12 Attack. It’s based on the same figures you came up with, but the correct calculation for the probability of Zigzagoon having an Attack-enhancing nature and 12–31 IVs, or an Attack-neutral nature and 26–31 IVs, is (4/25 × 20/32) + (17/25 × 6/32) = 182/800.

The next three figures are the probabilities of Ralts having a Defense-reducing nature, 0–3 HP IVs, and 0–5 Defense IVs. But by my calculations, Ralts can actually have up to 9 Defense IVs and still end up with a Defense stat of 6, so the probability of Ralts being vulnerable to a two-hit KO should be 4/25 × 4/32 × 10/32 = 1/160.

The last two figures are apparently meant to be the probability that the 85%–100% random damage multiplier will be high enough to deal 10 damage on the first attack and 7 on the second. Assuming that Pokémon Showdown’s damage calculator is accurate (is it?), those figures are also wrong: if the damage roll is anything less than 100%, the damage will be rounded down and Zigzagoon will be unable to KO Ralts. The probability of a 100% roll is 1/16, so the probability of two in a row is (1/16)2 = 1/256.

The probability of all these things happening at once would thus be 182/800 × 1/160 × 1/256 = 182/32768000, or about 1 in 180 044.
Generation I Glitch Discussion / Re: Anything about glitch types?
« on: March 24, 2016, 11:41:00 am »
Type effectiveness is defined by a list of the pairings that are super effective, not very effective, or ineffective. Any pairing not in the list results in neutral damage.
Pages: 1 [2] 3 4 ... 9