Jump to content

ajxpk

Innovator
  • Content Count

    739
  • Joined

  • Last visited

  • Days Won

    26

Posts posted by ajxpk


  1. @Purin is right. Distribution Count must have been stored on the Colosseum save file.

    The flag is indeed checked and set only by the Wishmaker Jirachi Multi Boot ROM, which does have FRLG support, it’s just locked by the function that calls the subroutine to check the GameCode. This check was exclusively added for the Wishmaker Multi Boot ROM, I think because of the Berry Program Update. The same Jirachi flag however is also used by the known earlier version of the software (client.2003_1112.bin/Meteor Jirachi) which uses the same Jirachi flag, there it only checks the language version and that’s why it always works with RSFRLG by default. Interesting to note: The Meteor Jirachi Multi Boot ROM doesn’t have any function of the SIIRTC library so this was added for Wishmaker. Also the Setup for the Origin Game is missing in the Meteor Jirachi version what I think could be leftover from the Alternate Negaiboshi Jirachi (distributed via GCN development system) where it was not needed as it was determined by the GameCode of the inserted cartridge, same as the OT Gender is missing which was based on the Trainer's OTG. I think that the Jirachi flag could be originating from it, because it looks the alternative Negaiboshi Jirachi was self-service and that's possibly why they added that restriction. However without an original save file we are unable to confirm it. Also I have read that some PCNY events were limited, not sure if it was about the GBC Events or GBA Events as it was a blog entry about PCNY Events in general.

    What’s interesting... client.bin and client.2003_1112.bin have Emerald support (which must have been in early phase) and there even is a check whether the cartridge inserted is inserted, although not working by default, but with some little tweaks these Multi Boot ROMs also work with Emerald. Why it works even Emerald was not finished yet is simple to explain because the Multi Boot ROM support as far as preparation of Offets goes for FRLG and E is identical. In these games close to the ROM header (starting at Offset 0x08000128) there is some information stored which is used by the Multi Boot ROMs to determine specific save file offsets universally. Obviously when they made the newer GBA Pokémon Games they added this for a better Multi Boot support, they didn't had to add much new code for new games and it also keeps the Multi Boot ROMs as light as possible.

    • Like 4

  2. 20 hours ago, InsaneNutter said:

    That's a very good point about Pokemon Stadium GS, certainly a needle in the haystack as you say. However with the recently Space World 97 it gives me hope such luck could happen.

    I've often thought their must be a Japanese equivalent to Project Pokemon, although it was never the most easy thing to do back in the day i'm pretty sure some people in the Japanese community would have had the foresight to back their saves up and are still active in the Pokemon community today.

    Ahiru’s Wonderland. This was before PPorg even existed,so we aren’t the first who had the idea of preserving Event Pokémon. Although that website was taken down early. They had Mews, Celebis and Odd Eggs which sadly weren’t available for download... you had to trade something rare in order to get one of those.

    https://web.archive.org/web/20070210151228/http://gbfan.web.infoseek.co.jp:80/pokemon_gold&silver&crystal/pokemon-251.html

    • Like 3

  3. So far there is no trash bytes documentation for Pokémon generated in-game, only a few tests I have done in the past.

    There definitely needs to be more tests to see what’s possible, but it could be that we will never have it fully analyzed. This year I have made a lot of progress to learn how data gets stacked in Gen 3, mostly for Event Pokémon analysis and for this I also studied many of the functions used by the Pokémon GBA games, because the official Pokémon distribution softwares make use of the same functions. With this I’m now able to pretty much predict what would appear as trash bytes. At least in a static environment it’s possible now, but I don’t know what happens in an in-game situation and I can imagine that it might be difficult because I expect trash bytes to be appearing more random depending on different situations like receiving a Pokémon as a gift, a static encounter or a wild Pokémon. Especially the last I would expect to be pretty noisy and who knows what will appear as trash bytes, it could be various things...

    If you want to make or edit your own Pokémon now with PKHeX I can only recommend what @Sabresite said. Zero trash is as if the Pokémon was traded to Colosseum or XD and back. Such a Pokémon can be considered as fishy but it’s still “legal”. As long as you don’t use it competitively or for trades it should be fine.

    I’m just not sure if catching a Pokémon in-game and just edit stuff like PID, Nature and IVs would be a good idea. At least as long as we don’t know what kind of data the trash is coming from, it might be unwise to do that. It could be data related for generating the stats of the Pokémon or at least something related and if that’s the case the Pokémon becomes illegal.

    • Like 2

  4. Not a leaked ROM, it would be a leaked disc since they were distributed using a Nintendo GameCube. There’s in fact a possibility that someone might have stolen one of these discs, I remember some comments on 2ch about that which was about ネガイボシ.

    The multi boot ROM is pretty much the one we have. The one from the Wishmaker Disc and it is the whole reason only why we have figured out the algorithm. I can’t imagine Ahiru or anyone else did the same long ago... It must be said that it’s a pretty complicated algorithm and not easy to make hacks without fully understanding it. So everyone who tries to hack a 5th Anniversary Egg will most likely fail.

    Trash bytes really tell us a lot about the software and in this case also the party slot it was generated into, kinda similar to the trash bytes of migrated Pokémon in Gen 4. The software builds the Pokémon’s substructure by stacking offset data to the substructure based on the party slot, this way the previously stacked leftover from the ReadFlash subroutine gets overwritten. Unlike in newer events starting with ネガイボシ2 were this was done in WRAM and the offset data is stored as global variables.

    Btw. I just noticed that we went Off-Topic. :D 

    • Like 1

  5. 12 hours ago, Purin said:

    From what I know the staff was able to edit the OT with the machine’s hidden options, so the OT is not really a fixed value per machine.
    In Europe they changed Mew’s OT in every city they visited, and for Celebi they had different staff member’s names as OT which I always found to be funny.

    I know about the Celebi software, just dunno how much it’s comparable... setting the OT Name up for it must have worked differently codewise, because there are Trash Bytes unlike in Mew's case. When it comes to Mew I didn’t said it’s necessarily fixed per machine/software. There was a fixed amount of days and units at Space World 1997 and apparently they distributed ヨッシー Mews at one system and then distributed ドンキー Mews at another time. So the names either changed randomly after reset, or they were set up by staff, or it was a combination of both, but I don’t know... would be interesting to know what kind of information you have about it if you know more.

    I still imagine that these were some kind of default OT Names, just because it’s too coincidental how they made use of the names YOSHI and LUIGI in different variations in America. Like YOSHIRA, YOSHIRB ect... + also if it’s true マクハリ (Same Software btw!) has been used quite a lot in Japan, for both WHF and Space World, most likely whenever they distributed at Makuhari. They used multiple systems as well and could have went with チバ for WHF because they used city names in other distributions, but always used マクハリ. So I believe it migh have been pre-set...

    The thing I’m interested the most though are the DVs. Apparently earlier Japanese Mews (before Space World 1997) had random DVs and weren't fix like the Mews we know and I believe that the reason they are fix is a bug and was not supposed to be like that. Wished we could get our hands on the software to disassemble it, maybe we could find out. :D 

    • Like 1

  6. Wow! Amazing! Great job guys.

    What’s really great about this is that this pretty much confirms that the existence of the マリオ OT Name among others must be true, which just btw. were distributed at Space World 1997. The software for distributing MARIO Mew obviously was a localized version of the one they used in Japan and that explains the same DVs and choice of OT Names. Other OT names I heard about are クッパ -, ピーチ and just recently I learned aboutドンキー.

    I haven’t seen a single living example of マリオ Mew until now...  But why would they distribute only  ヨッシー and ルイージ without the most important Nintendo name, especially considering they had 10~ distribution units being used.

    • Like 4
    • Speechless 1

  7. It looks like it has not been documented anywhere yet and it might be worth to share it.
    These are the locations where the Special Ribbon data is stored:


    Save File Section 4

    RS
    Offset 0x290

    FRLG
    Offset 0x21C

    E
    Offset 0x328


    Info:

    Spoiler
    
    Offset   Content
    0x0      MARINE RIBBON
    0x01     LAND RIBBON
    0x02     SKY RIBBON
    0x03     COUNTRY RIBBON
    0x04     NATIONAL RIBBON
    0x05     EARTH RIBBON
    0x06     WORLD RIBBON
    0x07     Unknown
    0x08     Unknown
    0x09     Unknown
    0x0A     Unknown
    
    0x0 =  
    0x1 = 2003 REGIONAL TOURNEY CHAMPION RIBBON
    0x2 = 2003 NATIONAL TOURNEY CHAMPION RIBBON
    0x3 = 2003 GLOBAL CUP CHAMPION RIBBON
    0x4 = 2003 REGIONAL TOURNEY Runner-up RIBBON
    0x5 = 2003 NATIONAL TOURNEY Runner-up RIBBON
    0x6 = 2003 GLOBAL CUP Runner-up RIBBON
    0x7 = 2003 REGIONAL TOURNEY Semifinalist RIBBON
    0x8 = 2003 NATIONAL TOURNEY Semifinalist RIBBON
    0x9 = 2003 GLOBAL CUP Semifinalist RIBBON
    0xA = 2004 REGIONAL TOURNEY CHAMPION RIBBON
    0xB = 2004 NATIONAL TOURNEY CHAMPION RIBBON
    0xC = 2004 GLOBAL CUP CHAMPION RIBBON
    0xD = 2004 REGIONAL TOURNEY Runner-up RIBBON
    0xE = 2004 NATIONAL TOURNEY Runner-up RIBBON
    0xF = 2004 GLOBAL CUP Runner-up RIBBON
    0x10 = 2004 REGIONAL TOURNEY Semifinalist RIBBON
    0x11 = 2004 NATIONAL TOURNEY Semifinalist RIBBON
    0x12 = 2004 GLOBAL CUP Semifinalist RIBBON
    0x13 = 2005 REGIONAL TOURNEY CHAMPION RIBBON
    0x14 = 2005 NATIONAL TOURNEY CHAMPION RIBBON
    0x15 = 2005 GLOBAL CUP CHAMPION RIBBON
    0x16 = 2005 REGIONAL TOURNEY Runner-up RIBBON
    0x17 = 2005 NATIONAL TOURNEY Runner-up RIBBON
    0x18 = 2005 GLOBAL CUP Runner-up RIBBON
    0x19 = 2005 REGIONAL TOURNEY Semifinalist RIBBON
    0x1A = 2005 NATIONAL TOURNEY Semifinalist RIBBON
    0x1B = 2005 GLOBAL CUP Semifinalist RIBBON
    0x1C = POKEMON BATTLE CUP CHAMPION RIBBON
    0x1D = POKEMON BATTLE CUP Runner-up RIBBON
    0x1E = POKEMON BATTLE CUP Semifinalist RIBBON
    0x1F = POKEMON BATTLE CUP Participation RIBBON
    0x20 = POKEMON LEAGUE CUP CHAMPION RIBBON
    0x21 = POKEMON LEAGUE CUP Runner-up RIBBON
    0x22 = POKEMON LEAGUE CUP Semifinalist RIBBON
    0x23 = POKEMON LEAGUE CUP Participation RIBBON
    0x24 = ADVANCE CUP CHAMPION RIBBON
    0x25 = ADVANCE CUP Runner-up RIBBON
    0x26 = ADVANCE CUP Semifinalist RIBBON
    0x27 = ADVANCE CUP Participation RIBBON
    0x28 = POKEMON Tournament Participation RIBBON
    0x29 = POKEMON Event Participation RIBBON
    0x2A = POKEMON Festival Participation RIBBON
    0x2B = Difficulty-clearing Commemorative RIBBON
    0x2C = RIBBON awarded for clearing all difficulties
    0x2D = 100-striaght Win Commemorative RIBBON
    0x2E = DARKNESS TOWER Clear Commemorative RIBBON
    0x2F = RED TOWER Clear Commemorative RIBBON
    0x30 = BLACKIRON TOWER Clear Commemorative RIBBON
    0x31 = FINAL TOWER Clear Commemorative RIBBON
    0x32 = Legend-making Commemorative RIBBON
    0x33 = POKEMON CENTER TOKYO Commemorative RIBBON
    0x34 = POKEMON CENTER OSAKA Commemorative RIBBON
    0x35 = POKEMON CENTER NAGOYA Commemorative RIBBON
    0x36 = POKEMON CENTER NY Commemorative RIBBON
    0x37 = Summer Holidays RIBBON
    0x38 = Winter Holidays RIBBON
    0x39 = Spring Holidays RIBBON
    0x3A = Evergreen RIBBON
    0x3B = Special Holidays RIBBON
    0x3C = Hard Worker RIBBON
    0x3D = Lots of Friends RIBBON
    0x3E = Full of Energy RIBBON
    0x3F = A Commemorative RIBBON for a loved POKEMON
    

     


    I already checked the assemblies on GitHub and it seems like this has not been disassembled yet... 
    The games have built in some kind of mechanic where when a Pokémon is traded (holding a Special Ribbon?) this data is apparently compared and exchanged. By default the slots are set to 0 but I noticed something strange in some save files I have examined. Some save files had slots filled with FFs and this is exchanged in case of a trade as well. That's how I confirmed that there 11 Slots even there are just 7 Special Ribbons in total. I have a feeling that the FF padding might be coming from COL & XD. Unfortunately the FF padding was also to be seen in the Festa Metang save files from Ahiru's Wonderland. So we can't be completely sure what kind of data was distributed with it.

    The German Debug Version of Pokémon Ruby has a Debug Menu including Mystery Event functions and one of them is for giving a Special Ribbon to all Pokémon inside the Team. Which is a Marine Ribbon with the assigned text "2003 REGIONAL TOURNEY CHAMPION RIBBON". In this case only the respective Slot of the Marine Ribbon changed while the other Slots remained untouched. I think for Festa Metang it was done the same way and the FF padding really just came from the GCN Games. If anyone has a relatively fresh Colosseum or XD save file which has never traded with a GBA game before we could figure out where this data came from.

    • Like 2

  8. @Deoxyz I can see this happening and that's what sucks about this.

    Even if you inject it into memory while playing it won't work. This is like in Gen 3 with the Mystery Event script that runs from memory automatically when you received an Event. We're doomed as far as preserving these Mystery Gifts goes and I wouldn't even be surprised if that's the future of Mystery Gifts.

    • Like 1
    • Teary-Eyed 1

  9. Mew is THE mythical Pokémon. Since when are mythical Pokémon worthless? Just because it doesn’t have a Special Move, Hidden Ability, isn’t Shiny? 😮

    People keep talking about the price (50$) which is not even for the Mew, it’s for the Poké Ball Plus itself. It was made for children and I believe children will love it. At least when I was a child I would have loved it. Considering the price for useless toys these days I consider this one at least being somewhat useful. You can use it as a controller for this game and it works with Pokémon Go, like it spins PokéStops for you which is convenience. And those who don’t like it that much and just got it for the Mew can sell it, so what’s the problem? ;)

    As a kid I started playing Pokémon with Gen 1 and in those days you were only able to get Mew locally, which means for most people that you had to travel. Also there have been many events over the time where you had to watch a movie or even fly somewhere with ANA, participate in some events, buy magazines to get a ticket to only have a chance to get an event, where you had to win drawings and contests. Sometimes you had to buy another game like an early version of Colosseum for Celebi in Japan or in the U.S. to get Jirachi... Pokémon Ranger for Manaphy is another example. Or how about the Virtual Console Mew were you had to buy a limited 2DS? (100$ Mew, lol)

    If the Poké Ball Plus is considered a paywall you might as well call all these things “paywalls”. But the thing is paying real life money in order to get an event is nothing new and it made events special since it was not so easy to obtain them. The real problem I feel is rather that there is no other way to get Mew. You have to communicate with their server which means getting Mew from the Poké Ball Plus might be in fact time limited as it has been previously stated. You can’t transfer Mew from Go or from Pokémon Bank, which really doesn’t make sense to me and I hope in the future there will be other ways to get Mew.

    • Like 4

  10. It's Lv. 1 actually and has Pound as Move. Poké Ball is a normal Poké Ball. OT Name and ID No. matches Trainer's. Oh yeah, 3 IVs seem to be MAX. That's all I figured out. An internet connection was required to redeem it, so the gift must have come from the Server... it's a real Mystery Gift with a Wonder Card with the text "You got Mew!" and "Mythical Pokémon Mew Gift" in the header line (which is now on the bottom) with a time stamp. The received Pokémon goes straight into the Pokémon Box.

    Edit: 
    Check @SciresM's Twitter for more information:

     


  11. 2 hours ago, theSLAYER said:

    @SabresiteBut do we treat these events as legit/legal since we can’t exactly check them against other copies?

    if it’s proved to be so, I could put em up on our gallery 

    They are legit.

    We have over hundreds of these Pikachu Event Pokémon, they are some of the most commonly collected events because they were distributed at every Pokémon Center in Japan.
    Most of the files were collected by Ahiru and can be traced to 2005 and then there are a few from Takasan who can be traced back to that time as well. Also there are indicators that they came from the distribution software, the seeds for example which were determined the same way as Meteor/Wishmaker Jirachi's. GW Pikachu in turn has an unknown incrementing seeding method which we think is time based and additionally a randomized OT Gender. So what is legal about these Events is pretty much known, the only Pikachu Event we are missing and we don't know about is Sapporo Pikachu.

    I'm kinda surprised that Ahiru's Wonderland files aren't already in the gallery. :D

    • Like 1

  12. Yes. Short Nicknames, actually an illegal Nickname with only a terminator would be best. In the first post you can find some dummy save files, those can be used. Regarding the question, sorry for the confusion. The structure can be seen in earlier posts in this thread.

    There are actually 2 different patterns of Trash Bytes, one is Japanese Diamond and Pearl and the other one is for anything else...

    Pattern 1 example:

    Spoiler

     

    Pocket Monsters Diamond/Pearl JPN:

    1st migrated Pokémon:
     

    
    FF FF 00 00 00 00 00 00 B4 C5 0C 02 E0 FF 7F 02 42 00 00 00 00 00

    2nd - 6th migrated Pokémon:

    
    FF FF 06 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    


    Completely static.

     


    Pattern 2 example:

    Spoiler

     

    Pokémon Platinum ENG:

    1st migrated Pokémon:

    
    2B 01 FF FF 00 00 00 00 42 00 00 00 00 00 00 00 C8 19 0C 02 E0 FF
    

    2nd - 6th migrated Pokemon:

    
    2B 01 FF FF XX 00 00 00 YY YY YY YY ZZ ZZ ZZ ZZ 4D 75 07 02 00 00

    XX: Level
    YY: Offset Pointer 1
    ZZ: Offset Pointer 2

     

     

    Basically the stuff that appears to be random in these Trash Bytes (marked with colors) are the level and some pointers and our problem is that the pointers change apparently because of the memory allocation, so we need to kill the memory allocation in order to determine the base offsets for these pointers. This is important to determine which Trash Bytes are legal. We will also have to determine the maximum possible offsets, but we can determine those mathematically so that's nothing we have to worry about right now... we just need the full 22 byte arrays with the base offsets...

    So in short... what needs to be done is we have to migrate Pokémon with short nicknames (0xFF in Gen 3), with the dynamic memory allocation being killed (aka Anti-DMA Code) during migration. And this with all games DP/Pl/HGSS in all different languages J/E/F/G/I/S/K

    • Like 2

  13. I haven’t worked on it for a while. But just in case someone would like to support this project, I want to give information about what has to be done next...

    We need migrated Pokémon on all different Game and language versions which means DP/Pl/HGSS in all different languages J/E/F/G/I/S/K. Can be done on Emulator...

    And most importantly we need to determine and document the lowest possible Offset/Base Offsets of the pointer inside the Trash Bytes of migrate Pokémon #2. For this we have to find a way to stop the Memory Allocation. Maybe there are cheat codes for that?

    • Like 1

  14. "I was told", "I heard"... This is an example of how rumors are being spread.

    Like I already said you will get different results from emulator to emulator, which we have learned from recent research and there is more research that needs to be done from here, we ain’t done yet. That's the only honest answer we can give to people. Besides that "emulator" is a generalized term in this context. Every emulator behaves different, especially if the core was programed independently and therefore would have to be seen as an individual "medium" as you called it.

    As for the Trash Bytes, no like I said the rumors are wrong. There are no different patterns and if they are as you say we would be good to document it and compare our data. According to my research it's not the case and it was done one both real hardware and emulator. Btw. the reason why they are identical is not even a surprise because memory and stacking are supposed to work exactly the same on emulators and real hardware. Otherwise it would cause serious issues like stacking issues and data being read from wrong memory locations. It would essentially mean things are out of control... so that should not happen. You have to keep in mind that this is all based on math and has not just to do with the emulation of the processor, this is just about the memory. That's why I was questioning these strange rumors from the beginning.

    I would also like to point out that the documentation was never completely finished... You're of course very welcomed to help with it. @Sabresite would be happy. Unfortunately I don't have time because I'm very busy working on some other research projects. It's not really my highest priority at the moment. ;)
     

     

    • Like 2

  15. It always depends on how the emulation is and I wished I could give answers but I have no experience with catching Pokémon on DeSmuMe. If it generates illegal Pokémon then another option would be melonDS and in the future there will be medusa. We have the same Topic in Gen 3 actually, when people talk about illegally generated Pokémon they usually talk about VBA, which is an very old Emulator. But there are other Emulators like mGBA and some of them have turned out giving better results. But we still have to do more research.

    Research is mandatory... There were rumors being spread in multiple forums and reddit that migrating Pokémon from Gen 3 to Gen 4 gives false Trash Bytes. It was seen as fact and when I wanted to take a look at it I was surprised that there was never a single case uploaded or any kind of documentation about what exactly was wrong with these Trash Bytes. So I had to start research on it on my own and then I asked people to upload migrated Pokémon from real hardware all just to figure out that the rumors were false, the Trash Bytes were identical.

    So my suggestion to everyone is just enjoy playing the games and report issues in the forum IF they occur. :)
    PKHeX should supports legality checking for it, so you can just catch Pokémon and see if they're legal like @theSLAYER suggested.

    • Like 1
×
×
  • Create New...