Search the Community
Showing results for tags 'wii'.
Found 14 results
-
Version 1.0.0
1117 downloads
This is a mod of Pokemon Rumble (Wii) that was made for the shiny hunting community event Rumble Weekend! The original Pokemon Rumble contains only the 1st and 4th gen Pokemon, but this mod reintroduces the 2nd & 3rd gen Pokemon (and their shinies) to the game in a new terminal known as "GX"! The layer of fog on all stages has also been removed, and the collection screen has been updated to support all 493 available Pokemon! The original base game also remains fully intact in order to preserve the rarity of certain Pokemon. Included are 3 bps patches to be applied to a USA version of Pokemon Rumble to get you into GX! Due to slight differences in dumps of the games out there, there were 3 patches made to ensure it works. (details on how to obtain the original game obviously not provided) This is fully cross-compatible with save files from the original Pokemon Rumble (USA version), and it can be installed on actual hardware via homebrew. This patch currently ONLY works with the USA version of the game due to slight scripting/file structure differences that exist in the JP/PAL versions of the game, so if you want to play it on a Japanese or PAL Wii, make the resultant .wad region free after patching with a tool such as ShowMiiWads. (https://wiibrew.org/wiki/ShowMiiWads) This mod is still very much a work-in-progress, and for full details on what's available/what is planned for the future, read the readme file inside the zip folder! -"WindyPrairie"- 7 comments
- 3 reviews
-
- 1
-
-
- pokemon rumble
- wiiware
- (and 2 more)
-
Hello. I need a save file for the European version of Pokémon Battle Revolution (Wii) in Spanish with Pokémon Collection enabled in at least one profile. If the four profiles are open with the game unfinished, it's better. I need the save file to be in Spanish, I mean, if I randomly download any European save file from the Internet, when I try to load it, it won't let me load the game and the game will ask me to change the Wii language to english if I want to load the save file (look picture). Spanish Text: "To being able to use this save file, you must change your Wii console language to english." I obviously need to have the Pokémon Collection open to being able to edit Pokémon using PkHex. I don't really care about the progress in the save file, I only want it to be in Spanish (so I can load it without changing the language), with at least one profile with Pokémon Copy open so I can edit my own Pokémon. My idea is to play in Dolphin emulator. I don't have my Wii anymore. Thanks for your time. Edit: Thanks to javisoto99 for sending me his save file.
-
AT7 File Container Format Documentation for... Pokémon Mystery Dungeon: Keep Going! Blazing Adventure Squad Pokémon Mystery Dungeon: Let's Go! Stormy Adventure Squad Pokémon Mystery Dungeon: Go For It! Light Adventure Squad Or by it's other names... Pokémon Mystery Dungeon: Forward! Adventurers of Flame Pokémon Mystery Dungeon: Let's Go! Adventurers of Storm Pokémon Mystery Dungeon: Aspire! Adventurers of Light All on WiiWare~ Hello everyone, I've actually been making some progress with the research into the AT7 File Container format, here's what I have currently documented: As of now, I've done some huge research into the AT7 Container format and I have made some progress (finally). The AT7 format is split into multiple segments and sectors. Each segment has a 6-byte long header, both which indicate it's ID and size of the segment. AT7P counts the header, where as AT7X does not. Like AT4PX or PKDPX, the segment headers have control flags in it's header, but it is only determined within the first AT7P segment header .AT7P segments have only been examined with compressed data sizes of less than 49,158 bytes. It is unknown if the AT7P segments can go higher than 49,158 bytes AT7X segments have uncompressed data, but can only be 49,158 bytes long. Now here's some examples of where you can find the AT7 Segments for data2_WPAJ.bin: Address Type Segment Size 0x0 - 42F8 AT7P 42F9 bytes (Dec: 17,145 bytes) 0x42F9 - 87C1 AT7P 44C8 bytes (Dec: 17,608 bytes) 0x11589 - 1D58E AT7X C006 bytes (Dec: 49,158 bytes) 0x1D58F - 29594 AT7X C006 bytes (Dec: 49,158 bytes) 0x29595 - 3559A AT7X C006 bytes (Dec: 49,158 bytes) 0x3559B - 415A0 AT7X C006 bytes (Dec: 49,158 bytes) .. 0x14AAD78-14BFFF0 AT7E 15288 (Dec: 86,664 bytes) (This would keep going on and on, can't post all of the offsets since it would take too long, but I am posting about AT7E though) Segments AT7P segments can be any size! The size of the segment is always stated at offsets 0x4-5 in little endian. Where as AT7X is always at a fixed size and have uncompressed data, therefore meaning that offsets 0x4-5 will only count the uncompressed data, but not the header. The entire AT7 file container is split into sectors, containing 131,072 bytes (20000h) each. The AT7E segment always indicates the end of the archived files and then the free space comes after the AT7E header. Compressed data works as follows: After the compressed size bytes, it begins with each of the blocks. Each block starts with a flag byte. As it goes from MSB to LSB, if the bit is set, it reads, takes the next byte from the input and moves it to the output completely unchanged. If the bit is clear, it reads a 2-byte big-endian control code. The top nybble is a repeated string length of 3. The remaining bits are a 12-bit negative offset of the most recent occurrence of the string to repeat. AT7P Segment Info Offset Name Type Endianness Size 0x0-3 Text (AT7P) - Big Endian 4 bytes 0x4-5 AT7P Length* uint16 Little Endian 2 bytes 0x6 Compressed data begins - - - * - These bytes count both the header and compressed data As explained before, AT7X segments are a fixed size of 49,158 (C006) each, counting the header as well. Unlike with AT7P, AT7X segments have uncompressed data, which means that the data can be read without any need to decompress. Since AT7X can only hold data sizes of 49,152 bytes, any data contained has to be exactly 49,152 bytes. This can often be used for textures or certain images or any data that has no data that can be re-replicated in any way, but must be exactly 49,152 bytes within parts of large files. AT7X Segment Info** Offset Name Type Endianness Size 0x0-3 Text (AT7X) - Big Endian 4 bytes 0x4-5 Data size*** uint16 Little Endian 2 bytes 0x6-C006 Uncompressed data - - 49,152 bytes (fixed size) ** - It always has a fixed length of 49,158 bytes (C006h) each *** - The bytes are always 00 C0 (C000h), which means it is always 49,152 bytes long in decimal. Unlike AT7P, these bytes only count the compressed data, but not the header The AT7E segment marks the end of the container and will fill any remaining bytes within a sector with byte values of "45" (or "E" in ASCII). AT7E Segment Info**** Offset Name Type Endianness Size 0x0-3 Text (AT7E) - Big Endian 4 bytes 0x4 Free space***** - - - **** - This segment always indicates the end of the AT7 container, before the free space ***** - These bytes can be any size, the entire AT7 container is made of blocks that are 131,072 bytes (20000h) each, and all free space bytes have a value of "45". The size of the free space will depend on how much space the last block has left over. For example, the last block of data2_WPAJ.bin only has AD7C (44,412 bytes) of data left in it 20000h - AD7Ch = 15284h (86,660 bytes), which means data2_WPAJ.bin only has 86,660 bytes of free space with each byte value of "45" Sectors Sectors are sections of the container that make up the file, like how sectors work on a Hard Disk Drive. Each sector is 131,072 bytes long (20000h). There can be multiple sectors within an AT7 container, for example, data2_WPAJ.bin contains 166 sectors (A6 in hexadecimal). But some contain as little as just 1 sector (such as data1_WPAJ.bin). If the last sector of the AT7 container has free space, the end of the data will be flagged with the AT7E segment, beginning the start of the free space. Special thanks to: MegaMinerd - For discovering and explaining about how the compressed data works and explaining that AT7X data isn't compressed -
This doesn't count as save editing, does it? Can you please make it so that the Party Pokémon Box in PBR is accessible in PKHeX? I can't move them around in the game itself and I really want their data. I wonder if it's the same in Colosseum and XD...
-
Poking around in PKHeX with two PBR files, I clicked on Mail Box to find out what it does and this appeared: PbrSaveData 201-08 - UNOWN - 7DDB7394E875.bk4
-
AT7 File Container Format Documentation for... Pokémon Mystery Dungeon: Keep Going! Blazing Adventure Squad Pokémon Mystery Dungeon: Let's Go! Stormy Adventure Squad Pokémon Mystery Dungeon: Go For It! Light Adventure Squad Or by it's other names... Pokémon Mystery Dungeon: Forward! Adventurers of Flame Pokémon Mystery Dungeon: Let's Go! Adventurers of Storm Pokémon Mystery Dungeon: Aspire! Adventurers of Light All on WiiWare~ Hello everyone, I've actually been making some progress with the research into the AT7 File Container format, here's what I have currently documented: As of now, I've done some huge research into the AT7 Container format and I have made some progress (finally). The AT7 format is split into multiple segments and sectors. Each segment has a 6-byte long header, both which indicate it's ID and size of the segment. AT7P counts the header, where as AT7X does not. Like AT4PX or PKDPX, the segment headers have control flags in it's header, but it is only determined within the first AT7P segment header .AT7P segments have only been examined with compressed data sizes of less than 49,158 bytes. It is unknown if the AT7P segments can go higher than 49,158 bytes AT7X segments have uncompressed data, but can only be 49,158 bytes long. Now here's some examples of where you can find the AT7 Segments for data2_WPAJ.bin: Address Type Segment Size 0x0 - 42F8 AT7P 42F9 bytes (Dec: 17,145 bytes) 0x42F9 - 87C1 AT7P 44C8 bytes (Dec: 17,608 bytes) 0x11589 - 1D58E AT7X C006 bytes (Dec: 49,158 bytes) 0x1D58F - 29594 AT7X C006 bytes (Dec: 49,158 bytes) 0x29595 - 3559A AT7X C006 bytes (Dec: 49,158 bytes) 0x3559B - 415A0 AT7X C006 bytes (Dec: 49,158 bytes) .. 0x14AAD78-14BFFF0 AT7E 15288 (Dec: 86,664 bytes) (This would keep going on and on, can't post all of the offsets since it would take too long, but I am posting about AT7E though) Segments AT7P segments can be any size! The size of the segment is always stated at offsets 0x4-5 in little endian. Where as AT7X is always at a fixed size and have uncompressed data, therefore meaning that offsets 0x4-5 will only count the uncompressed data, but not the header. The entire AT7 file container is split into sectors, containing 131,072 bytes (20000h) each. The AT7E segment always indicates the end of the archived files and then the free space comes after the AT7E header. Compressed data works as follows: After the compressed size bytes, it begins with each of the blocks. Each block starts with a flag byte. As it goes from MSB to LSB, if the bit is set, it reads, takes the next byte from the input and moves it to the output completely unchanged. If the bit is clear, it reads a 2-byte big-endian control code. The top nybble is a repeated string length of 3. The remaining bits are a 12-bit negative offset of the most recent occurrence of the string to repeat. AT7P Segment Info Offset Name Type Endianness Size 0x0-3 Text (AT7P) - Big Endian 4 bytes 0x4-5 AT7P Length* uint16 Little Endian 2 bytes 0x6 Compressed data begins - - - * - These bytes count both the header and compressed data As explained before, AT7X segments are a fixed size of 49,158 (C006) each, counting the header as well. Unlike with AT7P, AT7X segments have uncompressed data, which means that the data can be read without any need to decompress. Since AT7X can only hold data sizes of 49,152 bytes, any data contained has to be exactly 49,152 bytes. This can often be used for textures or certain images or any data that has no data that can be re-replicated in any way, but must be exactly 49,152 bytes within parts of large files. AT7X Segment Info** Offset Name Type Endianness Size 0x0-3 Text (AT7X) - Big Endian 4 bytes 0x4-5 Data size*** uint16 Little Endian 2 bytes 0x6-C006 Uncompressed data - - 49,152 bytes (fixed size) ** - It always has a fixed length of 49,158 bytes (C006h) each *** - The bytes are always 00 C0 (C000h), which means it is always 49,152 bytes long in decimal. Unlike AT7P, these bytes only count the compressed data, but not the header The AT7E segment marks the end of the container and will fill any remaining bytes within a sector with byte values of "45" (or "E" in ASCII). AT7E Segment Info**** Offset Name Type Endianness Size 0x0-3 Text (AT7E) - Big Endian 4 bytes 0x4 Free space***** - - - **** - This segment always indicates the end of the AT7 container, before the free space ***** - These bytes can be any size, the entire AT7 container is made of blocks that are 131,072 bytes (20000h) each, and all free space bytes have a value of "45". The size of the free space will depend on how much space the last block has left over. For example, the last block of data2_WPAJ.bin only has AD7C (44,412 bytes) of data left in it 20000h - AD7Ch = 15284h (86,660 bytes), which means data2_WPAJ.bin only has 86,660 bytes of free space with each byte value of "45" Sectors Sectors are sections of the container that make up the file, like how sectors work on a Hard Disk Drive. Each sector is 131,072 bytes long (20000h). There can be multiple sectors within an AT7 container, for example, data2_WPAJ.bin contains 166 sectors (A6 in hexadecimal). But some contain as little as just 1 sector (such as data1_WPAJ.bin). If the last sector of the AT7 container has free space, the end of the data will be flagged with the AT7E segment, beginning the start of the free space. Special thanks to: MegaMinerd - For discovering and explaining about how the compressed data works and explaining that AT7X data isn't compressed
-
I'm not sure if requests should go here (if it isn't, sorry about that) but would it be possible to update PKHeX support so that it works well with PBR? So far, the only features I'm able to do is check the Pokemon stored in the PC. I'm unable to check Pokemon that are in my party, and am also unable to edit or even see Pokemon on my rental passes. I would love for this to be an option sometime, as there are many mons that I got through the Trade Battle format that I'd like to see in full detail and move to the main series games. Also, currently there is no way to edit any trainer passes, or customization in the passes. The rental passes have limited customization in the in-game editor, as you're not allowed to change skin tones there. I was hoping that a future PKHeX update would lift that restriction, if possible. I'd love it if these features were added to PKHeX, as the current PBR editor is rather barebones. In any case, thank you for taking the time to read this.
-
questions Official Help/Small questions thread for D/P/Plat!
randomspot555 posted a topic in Generation 4
Official Help/Small Questions Thread for DPP! In effort to help reduce clutter and the many threads asking small questions, this thread has been created. Forgot where to go next on Route 212? Lost on Mt. Coronet? Wondering why Shaymin won't change forms? Any of your small questions can be answered here. Well, almost. Threads that may answer your questions: EV Training Questions/Hep Here Team Building Questions/Help Here Smogon Rule Discussion Common Rules of Battling Basically, do you have a question that can inspire discussion? If so, post a thread (if one hasn't already been made). If it's game help or general questions about the 4th gen, then post here. Hopefully this will reduce clutter in the forum. -
http://wiibrew.org/wiki/GEMS_Wifi Why I can't make it: I wish I could code these things myself, but I'm not really much of a programmer myself and don't know how to use DevKitPro or any good at C++ for compiling homebrew apps. Also, I don't own any compatible Wireless devices (RT2500~60 Chipset) with for capturing things like DS and Wii Signals other than the devices their selves. What it would do (More to come): A Homebrew Application strictly for sending Generation IV & V (Even though there isn't anything yet, It'll probably be fairly easy to dump them from Saves with Hex Editor just like I've done for HG/SS before programs were able to do it for you in Saves. Generation V should and will have WCs like GIV despite opinions) Wonder Cards wirelessly to the DS through *.pcd files. Having a Folder and selecting which Wonder Card you want to Distribute. Things to be added later: Wonder Card Picture Previewer (like Pokémon Mystery Gift Editor and it's Show Card Preview feature) [Vertical and Horizontal for 16:9 and 4:3 TVs] Cry Sounds when in Distribution Mode PKMN Sprite (Could have detection for Wonder Card Distribution Value, if Platinum shared, Platinum Sprite and so forth. Maybe a Box above the Wonder Card display) Throbber (Could have the PKMN Sprite Animate once sending the Wonder Card, or a simple square throbber) Settings to restrict Wonder Card's Distribution Value for each Game Version (Distributions for certain versions / All Versions) Wonder Card Queuer (Press a button to move onto the next Wonder Card in a folder, or select which Cards to Distribute, and hit a button to move on to the next queued Wonder Card) Wonder Card Capture Mode (Capture a Wonder Card that's in hosting mode and saves it as a PCD file) [Thanks to trance for the idea!] Concept Layouts (Might change the BG to a Darker Blue Tiled one for less eye strain): [Wii] Before Distributing (Press A to Distribute w/Animate and Sound Cry): [DS](Animated GIF) Before Distributing (Press R for Card Switch, A to Distribute w/Animate and Sound Cry on Card): How it would be useful: Anything you could think of really. Not having a Flash Cart but a Homebrew Channel on the Wii with a Retail Copy and DS. I mainly use custom Distribution Roms with Patchers to send my Wonder Cards to my games. I'm quite tired of using these things even though it's basic as can be. Plus it would conserve space not having multiple files that are 8MB/1.5MB. Where as it would take up 856 Bytes times around how many files you have on your SD/microSD/microSDHC Card. Conclusion: In the end it's also just as legitimate (Legal, for people using that terminology) getting the Event as long as you had the Wonder Card straight from the Event. It's a steal, and as great as acquiring an Event legitimately like PBR Pikachu for instance. It's the perfect bargin and solution for people not wanting to fiddle around with their Networks for the GTS exploits, and want a generated Pokemon with a different Nature randomly. If developers didn't decide on it originally because of some single Event that was made up by a fan, then why not a Wii Version? It's not like anyone is going to take their Wii to an Event and distribute some derogatory thing. Besides, PP does have some programs that deal with Wonder Card files at least. Why not? If it hasn't been thought of before. This is something to keep in mind though. I have a contact that has knowledge of sending Wireless Signal activations through compiling his own custom applications to a few DS games of the Rockman (Megaman) Series of games. I'll ask him if nobody else knows much about Wonder Card signals. Either that or I'll purchase a PCI Card that has the Chipset itself eventually for reading the WC Signals and attempt to figure it all out on my own. Both ways will take a long time probably. Thanks for reading. -
I would like to see a pokemon on the Wii, not like BR but like the pokemon games on the hand helds but in 3D obviously lol. They proved it can be done by doing somthing similer on the Game Cube. I think that would be a very popular game, they could even make it so you could link up to the DS like with BR.
-
If anyone got a new Wii please pm me your wii code to get you on the internet so you and I can get free wii points.
-
On my wii i have a pokemon game and well this girl,Cindy. she wont stop beating me! I want her pokemons! Can we trade pokemons??? if not tell me how to beat her please! please?
-
I sort of thought it would be interesting to discuss the firmware updates the Wii receives every few months. At the time of writing, the Wii is at version 4.2 for most, if not all places. The newest update was added about a week ago. This update deleted many homebrew applications, along with updating some internal software. What are your thoughts on this? Do you think Nintendo should spend more time working on new applications and improving aspects of older software (such as the update to My Pokémon Ranch, or a better Internet Channel), or do you think it's justifiable for them to spend so much time working against the homebrew community? You can also talk about future updates (predictions, release dates, etc.), previous updates (your opinion, pros, cons, anything), basically anything about future and past Wii firmware and apps. PS - I do not support, nor go against the homebrew community, although I have been tempted *wink*. PPS - When my math teacher wants my class to move their desks farther away from each other for a test, he shouts "MEGATRON, ASSEMBLE!". Is that off-topic, or what?
-
I was just woundering what normal stats would look like and what id mave to put down for it to say it came from fire red.
