StarsMmd

It's cool. We all need help at some point.

When you compile the script in XSE a little window pop ups with the offset it placed the acript at. Make sure you copy that offset and assign it to the noc in advanced map.

Okay so I have a new problem with a script. When I try to compile it, it says "not enough free space found. Cannot complile." does anyone know how to fix this? here is the script

#dynamic 0xE3D176

#org @Star

lock

faceplayer

msgbox @1 0x6

setflag 0x273

setflag 0x828

setflag 0x829

setflag 0x1f3

fanfare 0x13E

msgbox @2 0x6

waitfanfare

setflag 0x82f

fanfare 0x13e

msgbox @3 0x6

waitfanfare

closeonkeypress

fadescreen 1

hidesprite 0x1

setflag 0x1208

fadescreen 0

release

end

#org @1

=STARVING TRAVELER: Ungh...\pthis is it... This is where my journey\nends....\pPlease, kid....do me...a favor...\pTake this Pokedex...and this\nPokeblock case.\pWith these you will...be able to become...\pcham...pion.....

#org @2

= \w\h01 received a Pokedex and the\nPokeblock Case! \pwait... what's that next to him?\pit seems like he just got a new\npair of RUNNING SHOES!

#org @3

=\w\h01 received a pair of RUNNING SHOES! \p"hold down B to run faster than the \nthe speed of sound!"\pWait.... hold what...?

try #dynamic 0x800000

You should be fine using 0x800000 every time. XSE should automatically find free space for you and will tell you the offset once it compiles.

That's interesting!

Though the image is really tiny and can't be scaled up for some reasons.

Yeah the image was just one of the snapshots you see when you select a map so the resolution is really low.

Okay so I have copied exactly one of the npc's scripts into new npc but when I click A on him, nothing happens.

The two main things you need to check are the "Talking level" and "Script offset". Make sure the talking level is at the same height as the movement permission for the map (you can probably just set it to 'Always') and set the script offset to the same offset.

I can't think of anything else that could be causing an issue unless maybe you didn't save properly or something.

I'd wager you're right about 0xFFFF08 changing the font color.

Just a little update. 0xFFFF08 does indeed change the font colour. The next bytes are in RGBA order but the Alpha channel doesn't appear to have any effect on the font.

0xFFFF38 also changes the font colour but it uses a small group of predefined colours based on the following 1byte. The colours are as follows:

0x00 white

0x01 yellow

0x02 green

0x03 dark blue

0x04 orange

0x05 black

The range of colours is small but it uses fewer bytes.

it's been a few years since I hacked gba but hopefully I still know what I'm talking about.

If you click on her sprite in route 103 you will see some details on the right hand side of the window. You want copy all of these to the a new sprite you create in petalburg woods. Sometimes the rival appears when you step on a script tile like on route 119. In that case you'd need a to copy that tile and it's values. Finally some scripts are activated by entering a map and there are some that will decide whether a sprite should appear or not.

This may require you to tweak some of the scripts depending on the map.

Honestly, I would recommend that you find a good advanced map tutorial and a scripting tutorial too since you sound like you're just starting out. I don't know of any personally but there are many and they should be pretty easy to find.

Good luck.

I've tried everything for pkhex.

Does it even work on 9.4 firmware cause i was told it does and that's what I have. I've even tried pcedit. I need a dummy guide for pkhex(like skip nothing, if you think I know it I probably don't, so please include every little baby step).

When you say it doesn't work, what exactly do you mean? It's hard to help if we don't know where the problem is coming from.

[quote name=Tiddlywinks;205678

A bunch of the "tables" are pretty indecipherable beyond maybe telling how big the entries are. I was able to identify string IDs in some of them' date=' though. Some of those were still hard to figure, though... But I did manage to figure out a few new tables pretty well, too.

First, let me just identify the ones that had string IDs but that were difficult to figure out otherwise, in case somebody might feel like taking a look at them...

[/quote]

My japanese is pretty good and as far as I can tell it's mostly debug text. Stuff from the debug menu and maybe some output logs. You also identified the strings that are very clearly related to the AI. They remain enigmas though. I can say that the table at 0xB9C is almost definitely not to do with music. It seems more like a list of milestones and events from the game. They probably come from a debug menu that the programmers could use to skip to certain parts of the game for testing.

[EDIT:] I don't know actually, maybe I'm wrong about it not having anything to do with music. It's pretty hard to ignore the fact that the names of all the sfx and music are listed right after it. Furthermore, I just counted the number of song names and I think it's the same as the number of entries in this table.

I found a list of pointers to tables in common_rel that includes all four of the ROM tables I described above. It starts at 0x478E58 in common_rel, and the addresses are all offset by 0x807628A0 (for the US ROM). There are some "empty" pointers, though, and I don't know if it might actually be multiple lists.

It wasn't very clear that you found the pointers in the RAM just spent a good few minutes searching common_rel itself. Also don't the pointers start at 0x478DF8 in RAM?

Also I've been wondering how the game decides if the opponents pokemon's HP is visible. It's definitely visible on mt.battle on battle mode but not in story mode. It's probably one of the unknown bytes somewhere in the tables you found. Or maybe it's just incorporated in the battle type values or something. Did you notice this?

I probably don't really care that much if it's some assembly. I've generally been having trouble reading the assmebly to any great extent, but I may see if I can find some simpler introductions than the very technical/jargony instruction set documentations I've been trying to reference.

When you say that a nice "feature" is you can see what functions are calling what you're looking at, you don't mean that Dolphin has some "feature" that will determine that automatically, do you? Did you just mean something like you can look for instructions that jump to the start of your function (though I think finding that may be a little complicated too)?

I did use one of the AR codes just like you describe already, but with my general trouble reading the assembly, I haven't been eager to try it a lot.

It really it is a feature that calculates it for you. I don't know how much you know about using debug mode so I'll start from the beginning. It also shows you the code in hex and in assembly and you can place breakpoints and all that.

When in debug mode, choose the 'Symbols' option in the top menu and then 'Generate Symbol Map'. This will get dolphin to name all the functions for you and they will come up in different colours making it easy to see where each one starts and ends.

If you look at the 'code' tab. You will see 4 boxes on the very left. The second one shows the names of the functions (Dolphin automatically names them based on their offset and you can change the name to whatever you like if you figure out what it does). The third box shows the functions the current function branches to and the 4th box shows which functions branch to the current function.

You can click on any of these and it'll take you straight to that function. Also if you're looking at the code itself you can right click on a branch instruction and there's an option to follow that branch and dolphin will take you to the instruction it branches to.

I had a lot of trouble finding a good ASM tutorial as well but then I stumbled across a really good one on the super smash bros melee forums. It uses melee and Sonic adventure 2 battle as examples but it is really easy to follow and should teach you everything you need to know. There aren't any prerequisites either, so I'm sure you'll get it. This one video is all I needed to get started. Here's the link:

I hope you give it a go. It's a few hours long but well worth the time. Good luck!

In response to the original question, I've found the ASM function which determines whether the pokemon's shiny model is used or not. This calls the function that calculates whether it is shiny or not. We can quite easily change this to decide whether it uses the shiny image based on if it's a shadow pokemon. The only thing stopping us from using shadow textures for all shadow pokemon is that the model formats aren't understood yet. It would be possible to do it on dolphin by dumping then replacing the textures for every shiny pokemon in the game. Of course, it goes without saying that there would be no shiny pokemon anymore. Personally I would happily make that trade. I haven't had any luck with extracting textures from the model files though...

It occurs to me I may have misunderstood your meaning a bit. If you just meant to zero out the whole table, then that wouldn't have any problems; the game doesn't generally have any trouble if given an invalid string ID, and the appeal/jam fields are certainly fine with 0. What I initially figured--and which I now realize would bring its own problems--was that you meant to delete the table, as in, all the data that used to be after the table would now appear that much earlier. At any rate, my main worry was that if you replaced the table with some new data and weren't careful about it and ended up with the "wrong" value in the description string field, you could get some pretty weird "descriptions". But aside from that, appeal/jam seem not to have any issue with random values.

It also just occurred to me that the Contest category (Smart/etc) has to be defined too, and that turns out to be offset 0x15. Oddly, it seems there may also be something that overrides the category in a move entry, because I tried changing the category for Shadow Rush and that ???? but they persisted with no-icon or the "???" icon. (Changing 0x15 worked just as expected for Bite, though.)

No worries. Sorry if I wasn't clear.

The game often checks for shadow moves in the ASM and probably determines whether it should display the icon or not in the code.

For I guessed how the game may check for a shadow move. I'd already tried copying the exact entry for a shadow move and putting it over a regular move and that didn't make it a shadow move so I knew it wasn't in the move data table. The next obvious answer was that the game simply compared the index with 0x164. So I searched Start.dol for the value 0x164 which led me to the instruction "0x2c000164" which is "cmpwi r0,356". I found the same instruction in the RAM on dolphin in debug mode and used break points to test it. A neat feature is that you can see which functions call the function you're looking at. Finding a similar function could be helpful to you. For example, the main part of my phsyical/special split implementation was finding the function that determined the category of a move. I knew it had to check if the move was a shadow move or not so I looked at each of the functions that called the function for checking. I found the function and simply ignored the check so that it always ran the code that checks the move data rather than the move's type.

Another helpful way to find ASM functions is to see which values in the RAM are being edited by Action Replay or Gecko codes. You can then begin to look into which functions branch to and from eachother. This helped me find the shiny calculation function. Seeing a bunch of XORs and a comparison to the value '8' were a dead give away.

Unfortunately it doesn't seem that displays the contest data. I thought of using it to display an image of the move's status rather than contest category.

I tried looking for pointers before, but like you said my start offsets were a bit off. I concluded that the pointers must have been somewhere else and never thought to look for them again. Very useful indeed. I usually just scroll through the file and adjust the bytes per row until the bytes all align and see if I can spot anything. The really great thing about the pointers though, is that this means we can potentially increase the size of tables. I'm really glad you spotted that!

I'm in the process of documenting some of my recent findings in . Maybe Some of it will be of use to you. May have figured out some of the tables you haven't.

Also you found some really interesting tables. Clears up a lot of things I'd been looking for.

Yeah that's true, although it is possible that the game is programmed well enough that it wouldn't crash without contest data. Have you tested this?

Even though it's not in the list of tables I -hacking-tutorial-part-7-Editing-Trainers-(Colosseum)&p=205678&viewfull=1#post205678'>found in Colosseum's common_rel, I noticed that the move table starts one entry earlier than you said it does above (at 0x11E010).

Sorry, my colosseum data is a bit unreliable at times since it's pretty old. Thanks for that.

This is certainly in the games. Shadow Pokemon can only use Shadow moves at first, so this "????" is a placeholder that just hides the other moves until the Pokemon has been purified enough. (I'm not exactly sure at what point that move ID gets substituted over the Pokemon's actual move, but it doesn't seem to be in the PKM at all (it always gives the Pokemon's "real" moves).)

That makes sense. I noticed the description and still didn't make the connection hahaha.

Contest stats (Colosseum):

• In: common.fsys\common_rel.fdat
  
• Start: 0x14BCA8
  
• Entry size: 0x08 (dec 8)
  
• Entry count: 51
  

Offsets...

• 0x00 -- 1 byte -- Appeal (hearts * 10)
  
• 0x01 -- 1 byte -- Jamming (hearts * 10)
  
• 0x02 -- 2 bytes -- 0
  
• 0x04 -- 4 bytes -- Description string (ID)
  

The contests stats aren't actually that 'useless' from a hacking point of view. Since this data is irrelevant it can all be replaced in order to optimise the lzss compression. Decreasing the file size is always nice.

I have a lot of information on which I'll be adding to this post. I've been writing an app to streamline the hacking process and I've pretty much completed the logic and just need to complete the UI now. As a result there is a lot of code that is quite useful as a reference. It's all in the swift programming language which I doubt many people here use but it should be simple enough to figure out what it all does.

Here's a link to the repository : -Code'>https://github.com/PekanMmd/Pokemon--Code

Part 1 of my tutorials: -hacking-tutorial-part-1-File-decompression-recompression'>http://projectpokemon.org/forums/showthread.php?46250-Stars-Pokemon-colosseum-and--hacking-tutorial-part-1-File-decompression-recompression

I'll be updating this post with more details.

Enumerations:

Constants:

Texture Editing:

Data Tables:

Gift and Trade Pokemon:

So I've been digging through the files in Pokemon XD and I stumbled across an image that is unused in the final version of the game. It shows the main character (Michael) at what looks like an early version of Gateon port. He has a very different design to the final design and it's sooo much cooler than the final version. I wish they'd kept the old design.

Usually these kinds of tables are in common_rel or, less often, in start.dol. However, we know that common_rel is loaded into ram in its entirety and I think almost all of start.dol is as well. You can figure out where these files start and end in ram and if any data in ram is between one of the two offsets you know it is in that file. However, these files are always at the same offset in ram and you say the start of the purification table varies in ram. This potentially means it's created at runtime.

I've had a little look myself and can't track it down so my best guess is that it is created by some ASM in start.dol.

No clue. I'd only know by seeing it happen (I haven't) or by reading a bunch of assembly that I don't even have the first clue where to find.

From looking at the values for the AI of the trainer I'm assuming that a higher value doesn't necessarily correspond to a more intelligent AI. It would make sense for the Mt.Battle masters on battle mode to have the highest AI value in the game but this is not the case. My best guess is that the game was programmed with predefined strategies. Like you said some of the more important characters would get unique values which are tailored to their team while the generic characters are just assigned the default strategies. For example, I believe that Justy's pokemon are all very likely to use double team and Evice's Slowking will use skill swap on his Slaking. I've found that sometimes, I'll give a trainer some really creative sets like baton pass sets but they just end up spamming their attacking move.

Ah so we were right about the priority, we just needed to factor in the AI as well! Do you happen to know if there are any AI values that actually switch pokemon during the battle?

Hahaha it's pretty funny that we both had the same idea! I'm sure it'll become obvious eventually.

The scripts definitely aren't assembly if you compare them to start.dol but yeah it's hard to figure them out. You can tell what they're doing you just can't tell how right now. The easiest way to test would be change values and see the results ingame but that process would be so tedious. Maybe one day...

And yeah the code for controlling your opponent is one of my favourites. Very useful indeed.

And, just because the Pokemon data uses Natures and I'm not sure of a "good" place to post this...

Nature data:

• In: common.fsys\common_rel.fdat
  
• Start: 0x122E60
  
• Entry size: 0x28 (dec 40)
  
• Entry count: 25
  

Offsets...

• 0x00 -- 1 byte -- Battle purification
  
• 0x01 -- 1 byte -- Walking purification
  
• 0x02 -- 1 byte -- Call purification (out of Hyper Mode/sleep)
  
• 0x03 -- 1 byte -- Day Care purification
  
• 0x04 -- 1 byte -- Cologne purification
  
• 0x05 -- 1 byte -- Attack modification
  
• 0x06 -- 1 byte -- Defense modification
  
• 0x07 -- 1 byte -- Sp Attack modification
  
• 0x08 -- 1 byte -- Sp Defense modification
  
• 0x09 -- 1 byte -- Speed modification
  
• 0x0A -- 1 byte -- 0x64
  
• 0x0B -- 8*1 byte -- Unknown...
  
• 0x13 -- 1 byte -- 0x00
  
• 0x14 -- 4 bytes -- Nature string (ID)
  
• 0x18 -- 7*1 byte -- Unknown...
  
• 0x1F -- 7 bytes -- 0x64 (each/all)
  
• 0x26 -- 2 bytes -- 0
  

These entries correspond to Nature indices (such as are used in the Trainer Pokemon data) with a 1-based index. That is, the first Nature/entry, Hardy, has index 1.

I've tentatively deciphered the first 5 bytes by taking what a FAQ claimed were the purification preferences of each Nature, and associating that with those bytes when they're sorted. I don't know exactly how the values influence purification (the short version is simply that higher numbers mean a larger effect), but I'm actually planning to spend some time on purification and try to put some hard numbers to it all, including these Nature effects.

The "modification" bytes have three possible values. 0x00 means the stat is increased, 0x01 means the stat is not affected, and 0x02 means the stat is decreased.

The 0x0B-0x12 and 0x18-0x1E bytes have a limited number of values, but I can't guess what they do. The interesting thing about both sets is that they tend to be in multiples of 5 and 10, like percents perhaps (the first 8 kind of tend low, and the latter 7 kind of tend higher). The only thing I can think up is that they could be AI parameters, sort of like the Emerald Battle Palace AI battles (though I don't actually have the first idea how the Battle Palace AIs were implemented). But Natures usually don't do much at all, so seeing all these values is kind of bewildering.

I also have no idea if any of the static bytes actually have some meaning. I can't help but harbor a bit of suspicion for the ones that are 0x64 (decimal 100) in particular, especially all the ones that come right after 0x1E.

Also I had a look on bulbapedia to see what else is affected by a pokemon's nature. The only other known effect is the effect on a pokemon's pokeblock flavour preferences. A lot of useless data like egg groups and egg cycles are carried over from the gba games so I wouldn't be surprised if most of the unknown values in the nature data were for the pokeblock data.

Also near the beginning of common_rel you will notice the ascii text for the names of all the sounds in the game from fanfares to background music. If you were to list these you could assume they're in the same order as the indexes used to reference them. You could figure out the index of miror b.s music from this and see if you can find it in those structures. There's no way to know that the songs are listed in order but it's quite likely.

This is really interesting stuff. I didn't even think about structures like the natures and trainer classes. I think I actually stumbled across the trainer class one in but didn't realise it's significance. I assumed the prize money was a value stored with each individual trainer like in the gba games iirc.

You said you think the trainer data probably starts an entry earlier and I think you're probably right. From what I've been seeing recently a lot of tables start with an empty row for index 0. e.g. the move data and pokemon stats tables both start with empty rows since there is no pokemon or move 0. However the type data (and I'm assuming natures too) don't have that empty row since 0 is a valid type value for the normal type. Where you said the data may start an index later at 1, I can't remember what you're referring to since it has been a while since I looked at colo but it probably does start at 0 even though it's unused because 0 is a possible value that could be assigned for that variable.

On my very first editing attempt, I was changing the hex for some trainers manually using my hex editor and I accidentally set the value for a trainer's pokemon to a value between celebi and treeko. It took me a while to notice because rather than crashing the game or anything, the game just ignored that pokemon. As you will know, arrays in programming start at index 0 so it is a valid index and the game just ignores empty entries.

oh and in case you were wondering, the indexes between celebi and treeko will work if you fill those entries with values first.

Also, I don't know if you noticed but most trainers send their pokemon out in the same order as they are specified in the data. However, on rare occasions they will send them out in a different order. Most shadow pokemon are last in their teams but a few are first in their teams and yet they are still sent out last. Sometimes a trainer will just send their pokemon out in random order which changes each time you battle them. I was wondering if you'd seen any values that could specify this. I thought it could be the value in the pokemon list that is always between 0-3 but this had no effect on their ordering.

As for where the game specifies which trainer is in which map, the second file in the .fsys for each map is the file with all the scripts for that map. In this file is very easy to piece together because it contains a lot of human readable text in it. However, the equivalent file in colosseum has no such text and so I don't know what any of it means but it probably serves a similar purpose. The 3rd file in the map .fsys files is a string table of the strings that appear in that map. In if you search for any if the string ids contaibed in the third file, in the second file they will appear. You could try searching for the trainer IDs in this file. The ID is most likely the same as the index in the trainer data

Finally, since you're clearly really into this research I recommend taking a look at gecko and ar codes for pokemon colosseum. There is so much that was figured out years ago from looking at the ram. Usually they just figured out the really obvious data but sometimes you may find something interesting. like One code for came with a list of all the values for the trainer models.

I'd wager you're right about 0xFFFF08 changing the font color.

I certainly did write some Java. It's in pieces and the output of one doesn't always feed right into the next... I guess I can, though. Here. (Lemme also disclaim that it's probably not written to a professional standard:tongue:.)

If you run any of it, it might be helpful to know that I like to use Excel (Calc, actually) to sort and prune my intermediate output files where it's necessary. That's the nice thing about using tabs as delimiters, super easy to put into and take out of a spreadsheet.:wink: In one program, I'm also throwing much more than is remotely useful to stderr, I just haven't felt like cutting it out... (You could in fact pretty well remove anything I'm printing to stderr at this point.)

FYI, it usually takes me about 20-30 minutes to search through every file extracted from any given ROM. The other programs don't even take a minute to run, though, I think. Also FYI, one of my intermediate steps sees me writing a file for every table, and I did this because (at the moment, at least), I have a notion of only opening the file(s) I need and reading strings from there. Pretty much the only reason I went beyond that stage was to make it into a convenient text dump.

Thanks for that. I just want to look through and make sure I haven't missed anything. You managed to parse every single file so your code can handle anything that the game contains. Mine currently only works perfectly for common_rel, tableres2 and start.dol but will crash on things I hadn't seen like 0xFFFF08. I haven't used java in a while but I think I can still understand it.

Hahaha that's a fair point! This is really cool though. I'm assuming you wrote a program of sorts to dump all text right? If so, could you upload the source code for that as well. Mine isn't complete yet and it would be great to see how you did it (if you don't mind of course). You don't seem to have mentioned any such code but you'd have to be pretty dedicated to do all of this manually .

Also, from the values I'm seeing, it looks like 0xFFFF08 almost definitely changes the font colour of the text. The next 4 values are RGBA values which determine the colour.

Yeah, I noticed they were 2 bytes each but I just ignored it since the maximum value for an EV is only 1byte. 0xFFFF does make sense for randomising the value as it is used as a randomiser value for a lot of variables. I didn't consider that since the game never randomises EVs. I lost interest in colosseum when I realised I could implement the phsyical/special class split in so I probably won't get around to testing your theory but if/when you do I'm curious to know.

And yeah sorry, I spent about a week typing up everything I knew on notepad and then copy and pasted it onto the forums at about 5am in the morning so I probably made a few mistakes along the way. I will correct that now, thanks for pointing it out.

I should probably post my discoveries as they come rather than piling them up... I think I'll post some updates soon.