suloku

What would be the advantage? The final outcoome would be the same. They only thing multiboot would be interesting is to make a gba to gba program to distribute wondercards via link cable or the eon ticket without a cartflash to run the e-reader with custom savegames (which now I remember I did never upload...)

I don't know why my builds trigger some anti-virus, this happened too with a different program. It might be because I use sharpdevelop and I should really switch to visual studio, but I don't have the hard disk space to properly install it (I know disk space shouldn't be a problem nowadays, but my computer has been runing for almost 8 years now and I don't really have any need for upgrade it and disk cleaning is a tedious task after that much time). EDIT: I've just found out my antivirus (AVG) updated last week and now it also recognizes the program as malware, which is kind of anoying. Here's a shareable wondercard for the Eon Ticket (both japanese and non-japanese versions). I've checked and apparently the game clears that flag by itself after giving you the Eon ticket, but I scripted the wondercard so it will deliberately clear that flag if you speak to the man in blue after receiving the ticket (just in case you are worried). Check included readme for more detailed information, but as summary using this wondercard should yield the same results as record mixing, except that you are not record mixing, so if you never record mixed you could tell due to lacking any sort of record mixing data that the eon ticket wasn't obtained the standard way. The recommended way to obtain Eon Ticket in Emerald should be record mixing from R/S or a japanese emerald (jap R/S can't record mix with non-jap emerald), which can be done with VBA. This wondercard is just some proof of concept or for people who don't care about the savedata not having 100% legit data. Emerald_EON_ticket_wondercard (CUSTOM).zip EDIT: I finally went and uploaded the Eon Ticket savegames for e-reader, they are in the first post.

I'm not sure what is each file, are the 3 files mb roms? where the 3 inside coloseum bonus disc? I'm a little confused, but anyways I compiled one of FIX94's program for each of those bin files for anyone who'd like to test them out. If they work, maybe they can be swapped with the one in the 10ANNIV rom as a way to use them on emu/gba-gba @InsaneNutter jirachi_mb_test.zip ps: backup saves before testing, also, we don't know which rom these multiboot expect, but I would asume R/S either USA or JAP (if they are leftover prototypes maybe they are still for JAP). EDIT: It should be possible to put two of those bin files in the 10ANNIV rom, but the "sample0519.bin" is too big. In any case vba won't work with multiboot files on gba-gba apparently (but seems to work on dolphin-vbaM joybus emulation), so if they serve any purpose we could edit US colosseum bonus disk so it sends these multiboot roms instead of the one it is supposed to). Also, in client.bin there's text for R/S, and in sample0519.bin there's the gamecode for japanese Ruby.

If it needs to be sent as a multi boot rom, I can compile FIX94's wii/gc gba save dumper so it sends this rom instead of the dumper one. I don't have my wii set up right now, anyone wants to test? Also, anyone can get channel jirachi in any language with dolphin, there's a completed pal savegame at gamefaqs (thankfully no one needs to play that game just for the jirachi...) EDIT: and you can change the language setting to get any channel jirachi; you'll need the corresponding rom though.

This was comented in the first page but I have some thinga to say: - I've read reports stating that PCNY Celebi could be shiny, apparebtly at random. I'd love to know how the celebi machines worked... I read one that claimed not that he received a shiny one, but that the peraon before him did. Since the DV were random, it wouldn't surprise me it wasn't shiny locked. - For gen 1/2 events (mainly mew/celebi) some things can be checked for legality. Of course faking them is way easier than in gen 3. I'd love to see more of them, but having mew/celebi feels lucky enough, any gen 2 are probably dead and any japanese event is probably out of reach... About gen 2 VC: I don't think they'd do the gs ball event, they would just do a trade celebi if they ever do...unless they want to surprise everybody and rework the mobile function to work over wifi, even in non-jap games. That would be awesome.

@BlueBraviary you'll need to remove the ticket items foe the events to work after you inject them, they are coded in a way that if you have the item it thinks the event was already done even though the flags aren't set.

Gen 2 have met information (only visible on crystal). In fact, for the leveled legendaries in this savefile, it is wrong, so if we assume they are totally legit, the employees at the PCNY forgot to change the data to reflect the met level. Also, there are some extra bytes that make them different from in-game catches (but don't have any in-game meaning).

@No.one 1) As theSLAYER said, it's the official US Eon ticket e-card (included for event completion and as another option to get it). 2) e-berry where (apparently) removed from FRLG and Emerald. No cards where released to my knowledge and there's no space in the savegame to hold the berry data due to WonderCards being stored there. There's the slim chance that they moved it to another portion of the savegame, but without e-cards we can't know without reverse enginering the rom (which I'm not capable of). 3) This one is tricky. In RS Eon Ticket event used Mystery Event option to get it. In those games, a script is stored in the savegame AND the data for record mixing it is also stored in the save. When you talk with your dad at petalburg it gets executed, giving you the Eon ticket item and enabling the flags for the events, then the script gets erased from the save (so everything returns to normal). Since emerald was released after RS and the Eon ticket for them was made, they put the Eon Ticket event script in-game. In japan, the oficial event was still carried out via Mystery Event, but instead of sending the script and record mixing data, it enabled the flag (only one!) in the save for the in-game event and stored the record mixing data. In the official emerald event, you get handed out the ticket by the man in blue at the pokémon center (this is the in-game event). The ticket events are scripted in a way that if one of the flags for the actual event or the item are already in the save they won't trigger again. This for example is what makes that if you hacked in (or used a glitch) to get the Eon Ticket item the event won't be enabled (if I recall properly). Enabling the unofficial Eon Ticket event would yield the same results as mixing records because that button won't inject the data needed for sharing an object via mix records (you can check this yourself via extracting the mystery event from the save and opening it in the editor). There will be one difference: a flag that should only be possible to be enabled in the japanese version of the game will be enabled. If you want an alternate method to get the eon ticket in emerald without mixing records that yields the same result, the easiest (and flashiest) way would be to get the rom script for the in-game eon ticket event and convert it into a wondercard, since wondercards can be tossed and shared, that would be the best way and would also feel like doing the event instead of just enabling the flags and giving the item via save editing. 4) For the TGC, we have the emerald counterpart and the WC text is different. For the Rocks america one we don't know if the text was different, it might have just been the standard "Mystic Ticket" we already have (the same card was distributed in Pokemon Center New York and Mexico, Rocks America might or might not have different text). The events themselves are the very same, so it doesn't really make a difference in-game. Would still be nice to have all the variants available though.

This seems very interesting, but I fail to comprenhend the use for this. From what I understood, the binary file colbtl.bin is what Colosseum sends to the GBA to allow trading, and it has been hacked/replaced with a different program that will write a savegame to the cartridge instead. What's that save so special for? Or is this just a proof of concept? But I find the one skipping region checking very interesting, I guess the point is to allow trade/combat from GBA games from a foreing region (i.e. jap games on US colosseum doing battles). This could be used into making the jap bonus disk work with all roms... maybe.

Savetype in vba for 128 KB saves is "1 Mbit flash" (1 mega bit = 128 kilobytes)

@Kirzi are your statements regarding only gen 7 or do these mechanics also apply to gen 6?

The source is there, I don't know what triggers avast, but you may check the code (or build by yourself). I used sharpdevelop 5.1.

Since this is a somewhat official statement and this site doesn't endorese piracy, I would add something like "if you modified your savegame and don't want to get banned". I'm just saying because I got the impression the statement was somewhat meant to prevent "cheaters" from being banned, but englsih isn't my mother language so maybe it was just my impression.

Ok, I did not understand the purpose of your questions. OT gender shouldn't matter for the in-game trash bytes. We could technically locate (via memory dumps) where the in-game trash bytes come from, then see what the memory address they come from is used for previous to the name generation and if it falls under a DMA address, but given that I recall in-game catches having apparently random trash the bytes probly depend on what you have done in-game prior to the catch, which shouldn't be much of a concern. In any case, the gender shouldn't affect them (or more like I personally can't think of a reason why it should).

They are just what was in that memory region before it was used to store (then copy to the pokemon) the nickname. It will most likely never be the same, and more given emerald has DMA. In any case there's almost no chance that any in-game generated pokémon will have trash bytes of any event distribution, and if one has, it's mere (extreme) coincidence. Trash bytes for ingame pokemon should be random, and if you are worried about them, you are better off clearing them via colosseum/xd. Besides being obtaines in emulator and rng manipulation, the mew should be totally legitimate either way. I don't get why you want it to look like an event pokemon though, the generation algorythm might have been different from the one used in-game, so any pid/dv combos for in-game mew wouldn't (most likely) apply.

Source: bulbapedia I seem to understand males will only pass HA with ditto. I'm not sure about the same species "Male HA + female no HA", or if "male HA+female HA" has a 100% HA offspring... but if the "male/genderless can only pass ability via ditto" applies, then "Male HA + female no HA" can't output HA and "male HA+female HA" is the same as ""male no HA+female HA".

I forgot to mention that if you are using savestates you'll need a way advance the RNG, otherwise you'll allways get the same PID. Or you could just change OT and SID before generation if you don't care about those so the pokemon is shiny (you can read the rng seed with lua and probably know the pid beforehand, or get the pid, store it and load the savestate). Not sure how much you can acomplish with lua though.

Source: bulbapedia There's no shiny flag.

I will probably try adapting it to stadium 1 jap, since they seem to also have tournament pokemon. I hope they used the same encoding table...

Set 0xA083 to 0x0B to enable the Celebi event. The flag is out of the checksumed regions. For non-japanese, the offset is 0x3E44 (didn't really know where to post this information, this seems the most correct place)

The trash bytes are unique to the device/rom that generates the pokémon, since they are just what lied in memory when the pokémon was generated (from my point of view I don't see a reason why they didn't clear those bytes, but at the same time, I also don't see a reason why they should have cared). What I said about Colo/XD removing them is from this point: OK, we know we can't never do 1:1 replication (since that needs the actual distro device, or a copy of it), but if we throw trash aside and just concentrate on what makes the pokémon unique to that event (PID, TID, OT, OTgender, IV, level, met place...etc) and we can replicate that 1:1 that would still be awesome. If you are using a homebrew app to get them I'd personally still prefer single pk3 files from people who actually got the event. But for personal use? Fun? Gen 4 onwards (since that clears the trash too)? I'd really like to have something like that, albeit I understand the concerns collectors may have, but faking some gen 3 event on gen 4 onwards is really difficult to discern (and many are available anyways). That's just my personal opinion, actually I think the fact that we can't replicate trash is good, because A) Doesn't matter for gameplay/gen 4 onwards B) It's a good way to quickly know if the pk3 file was just generated C) There's a legit way to get rid of the trash bytes so even generated pokémon can be claimed to be fully legal without having trash bytes. ps: I think I finally found a way to tell legal from legit appart (I always confuse the correct word), hope I didn't mix them up. ps2: yes, GF switching to an in-game generation for most events is really nice, gen 1-3 are a nightmare for events....and gen 3 is actually better than those.

Oh, so only that one skin was affected, I understood from the thread that more skins might be affected, sorry for the confusion.

This is a simple program to view the teams in Pocket Monsters Stadium (JAP) and all data relative to the pokémon. It can also export individual pokémon as jpk1 files to use with pkhex. It is worth noting that the teams and trainers from Level 50-55 Tournament are (in theory) copies of the participants and winners of a real tournament that was held in japan. jpk1 code is heavily based on pkhex. Download: https://github.com/suloku/PMStadium_Viewer/releases/tag/0.1 Source code: https://github.com/suloku/PMStadium_Viewer/ ps: this needs a z64/v64 rom, you can find a converter here: https://www.zophar.net/utilities/n64aud/tool-n64.html ps2: this is for the japanese only game, not the international Pokémon Stadium 1, you can find an editor for it here: https://github.com/Guernouille/Stadium_Editor

So, does the gallery currently hold original data? I think it would be somewhat important to make sure all original data is in preserved, but I did not play any of the games at the time so it's not like I can contribute. I did download all what was uploaded to the old gallery, but for what I've read some of those might be "wrong" too.

Does someone have the PokeSkinED v2.1 english version? I just realized the package I uploaded doesn't have it in english and it's the only application that allows to create custom skins for BW/BW2. EDIT: the correct link was just some posts above by BlackShark: