StarsMmd

Yeah, someone else requested a version without the moves randomised a while ago. Here you go: http://www.mediafire.com/download/25c5nxlokqa21x8/Randomised+Pokemon.zip The hack will still take a little bit of time. It's actually quite a lot of work but it's still on the way

I appreciate the kind words. Thanks ! Hope you enjoy the randomiser ???✌?️

Thanks Happy new year to you too! tbh it's slowed down a bit but it's still in progress. There isn't too much work left, just haven't been able to dedicate much time to just sit down and work on it. Shouldn't be too much longer though. The support is much appreciated.

I just reused the animations which are already in the game. I spent a lot of time shuffling them around to match up nicely. There are a few repeats but most of them are unique. For example, grass knot had the animation of vine whip, while vine whip has been removed since the pokemon you encounter won't ever need it in their movesets.

Yes it does! I've been able to run it on my wii u in vWii mode. it's very convenient ??

I know what you mean. They have a few die hard fans like us but were mostly slept on. Easily my favourite games in the series!

Thanks G! I appreciate the encouragement. It's nice that there are still fans out there. I have my fingers crossed that the shadow mewtwo in pokken tournament is alluding to an XD/Colo sequel

yeah unfortunately there isn't really an easy way to do it right now but I'll aim to release some patches eventually.

Afaik, I was the first person to successfully reverse engineer the game files to the point that hacks could be possible. I doubt you'll find any thing else right now. However, since I released my research online a couple of people have contacted me saying they were going to work on some hacks of their own. Since I've been working on the gamecube games for a while now, I think XG will be the first major hack of to be released but maybe someone might release something a bit less extensive before then. We'll just have to wait and see.

I'm glad you're interested. I'll be sure to get it done as soon as possible ??

Uni's good thanks. Haven't had as much free time as I'd like though. I made a nice GUI for my hacking which has been really useful but I recently switched over to doing everything programmatically. It required a little bit of set up but it should speed things up considerably.

Was wondering how I didn't notice, but I've got it down as 0xB8 in my source code so I guess it was a typo. It's great to have you double checking ??

Oh yeah... I made a presumption based on the file name but the data in that file is completely useless and was probably just for the developers to test stuff. At the time I thought there might have been some gimmick to the file like how DeckData_DarkPokemon is unique. However, that data is not used in the game at all. I think DeckData_Sample is also an old file just for testing. All the battle bingo data is in common_rel. I think I made a post about it. If not, I'll write one up today. ? I should probably update some of my posts now that I've actually tried more stuff out. Edit: yeah I posted it in this thread -Info-dump'>http://projectpokemon.org/forums/showthread.php?46590-Pokemon--Info-dump although I really did just 'dump' the info. Most of it doesn't look very pretty but the battle bingo data is explained in the 'data tables' spoiler.

Ahh and I thought I finally had it figured out. I guess it's still a little bit of a mystery. It's possible that shadow pokemon are randomised by default but the option is still available for all pokemon. If you look at the way DeckData_DarkPokemon works, you see that the pokemon in DeckData_Story are completely independent from their shadow data. The additional shadow data just holds a reference to the pokemon. This means that the process of changing any shadow pokemon is trivial as it only requires changing the reference. The pokemon being referenced doesn't need any modification and will be automatically randomised. Maybe the programmers originally randomised the data manually like they did in colosseum and then later decided to do it automatically and we're just seeing leftovers that weren't removed since they don't make a difference anymore. It is also possible that the castform and exploud were meant to be shadow pokemon (or at least the pokemon that were in those slots at the time) at a very early stage in development and they forgot to take off the randomisation value. Of course, this is just speculation though.

Whoops, thanks will fix that now. First, at the end here, you've said the PID starts at 0x1C but that it's only 1 byte long; either it's actually 4 bytes, or it starts at 0x1E However, I'm really not sure those 4 bytes at 0x1C would be the PID anyway. Yeah I called it the pid because I didn't have a better name but it definitely isn't the pid. I used the name because it is used to calculate the ability, gender and nature and I think this will affect the pid that is generated at the end of the day because it will need to match these values. I read somewhere that the game literally just keeps trying new values until they match. All shadow pokemon have random genders. There is even footage of Zook's zangoose having different genders between the 3 times you see it because it's final value isn't set until you battle him yourself. That's interesting actually. I noticed all the shadow pokemon either had 0x40 or 0x80 in the byte just before what I called the "pid" but couldn't figure out what it meant. I think it makes sense that it randomises the values. That's like how the values in colosseum worked where the high bit randomised the value. There are two possibilities. The "pid" field is 2 bytes long and the high bit for those 16bits is what randomises that value and the IVs are randomised by default. However there is no high bit set for the IVs of shadow pokemon so the second possibility is that the 0x40/0x80 byte itself randomises all the fields that need randomising. Just by the way, I often document fields as being fewer bytes than they actually are because the game never used all the bytes. For example, string ids are all 4 bytes but there aren't any ids longer than 2. I documented them as 2 bytes because when I was editing values by hand it was easier to find the values by eye if I skipped the extra 00s. Also, when I moved to writing programs, I used the smaller sizes to speed up the programs. My sizes are usually based on convenience rather than accuracy, so if you do have any doubts about the size you're probably right . In a similar manner, I have barely tested any of my research. It's all based on presumptions. With all the information I have from people hacking other games and my brief spell hacking pokemon colosseum, a lot of it was pretty obvious. I have played what I've got so far of my hack though and everything seems to be working as intended so I know it's mostly accurate. There are a couple of things I wasn't able to deduce though: 1. I fought the first trainer in the game when I started with 2 starters but it was still a single battle. I haven't looked into it yet but there is something that determines whether a battle is a single battle or not, as opposed to being a result of having 1 pokemon each. 2. I know how to give shadow pokemon to trainers that wouldn't usually have them. However, what happens if you catch/defeat them? Do they automatically go to miror b.? Also what determines which trainers keep their shadow pokemon? (e.g. greevil) 3. If one was to increase the total number of shadow pokemon by adding one to DeckData_DarkPokemon.bin, would miror b.'s final battle adjust to be after you've caught all shadow pokemon in the file or is he hard coded to battle you after you catch exactly 82/83 (I forget the number)

thanks I'll have a look

Is the display code offsets option live on github?

sweet, thanks. Gonna come in handy

Hey, do you think you could add to the script disassembler so that each instruction has it's offset in the script file next to it? It will make it a bit easier to figure out where to go to manually change instructions. Thanks

Yeah I'm looking through your code now. Impressive work .

Sounds good. So I've been looking at some of the disassembled scripts and I think I'm starting to get a feel for how it all works. For class methods like Party::recieveGiftOrEventPkm(id) or Character::setVisibility did you find out what they do by trial and error and did you name them yourself?

hahaha I'm always surprised by how much is in common_rel. When I look for things I find them there like 80% of the time. btw, have you managed to do anything cool by editing the scripts?

I'm not sure how I never noticed this before but the "common" script is in common_rel from common.fsys starting at offset 0x5BEE4.

Did you manage to figure out what the sections at the bottom are for, i.e. GVAR, STRG, VECT, GIRI, ARRY. Also do you know any ways to decrease the compressed file sizes? For example, redundant data or unnecessary data.

So excited to play around with this! Can it reassemble the scripts as well?