Research & Development Quick Research/Development Thread - Page 3

shiny quagsire · #51 September 2nd, 2010, 02:25 PM

Alright, this question is mostly directed to JPAN, but anyone can answer.
In your berry system, you said htis:

Quote:

Originally Posted by JPAN

There is a limit of 256 different berry slots, each identified in the person id by the table number 0xfe.

What exactly does that mean? I've tried everything I could to understand, but the sentence is kinda smeared out in my mind. :\

JPAN · #52 September 2nd, 2010, 04:44 PM

Quote:

Originally Posted by shiny quagsire

Alright, this question is mostly directed to JPAN, but anyone can answer.
In your berry system, you said htis:

There is a limit of 256 different berry slots, each identified in the person id by the table number 0xfe.

What exactly does that mean? I've tried everything I could to understand, but the sentence is kinda smeared out in my mind. :\

This means that each of the variables is linked to a specific OW number (person ID wasn't the best choice of words in this one, here it means the Sprite OW) And as OW sprite numbers are limited to a byte (0xfe, the table number, indicating that it is a berry tree), you only have 256 slots where you can have berries.

shiny quagsire · #53 September 3rd, 2010, 01:39 AM

Quote:

Originally Posted by JPAN

This means that each of the variables is linked to a specific OW number (person ID wasn't the best choice of words in this one, here it means the Sprite OW) And as OW sprite numbers are limited to a byte (0xfe, the table number, indicating that it is a berry tree), you only have 256 slots where you can have berries.

So to turn the overworld into a berry tree, I'd use your OW hack, set the table # to 0xFE. But where does the variable come in? I'm not quite sure what you mean by the OW number. (Sorry if I'm frustrating you, it's just harder to understand when there's just text :p)

Wait, do you mean set the sprite to the desired variable index?

diegoisawesome · #54 September 4th, 2010, 07:57 PM

JPAN, what about the flags? Is there a way to fix the flags above 0x900 or something?

HackMew · #55 September 5th, 2010, 09:45 AM

Quote:

Originally Posted by JPAN

You can use this routine to clear 0x1000 bytes. Just replace the last pointer for the one you will be using.

Code:

.align 2
.thumb
Fill_memory: push {r4-r7, lr}
    mov r4, #0x10
    lsl r4, r4, #0x8 /*value = 0x1000*/
    ldr r5, start_addr
    add r4, r5, r4
    mov r0, #0x0
    mov r1, #0x0
    mov r2, #0x0
    mov r3, #0x0
fill_loop:  stmia r5!, {r0-r3}
    cmp r4, r5
    bgt fill_loop
    pop {r4-r7,pc}
.hword 0x0000    
start_addr:  .word 0x0203f000 /*change as needed*/

I really don't understand why would you push r6 and r7 when they're not even used, and not pushing r0-r3 instead, which might be needed depending from where the routine is called. Either way, there are better and faster ways to do that:

Code:

.text
.align 2
.thumb
.thumb_func
.global EraseMemory

main:
	push {r0-r3, lr}
	ldr r0, .START_ADDRESS
	mov r1, #0x0
	str r1, [r0]
	add r1, r0, #0x0
	ldr r2, .LENGTH
	swi #0xC
	pop {r0-r3, pc}
	
.align 2
.START_ADDRESS:
	.word 0x0203F000
.LENGTH:
	.word 0x01000400

In the code above, 0x01000400 stands for 0x400 words, and the 1 is for memory filling, rather then copying (the default behavior). Note that due to the way the SWI 0xC works, the word count (total amount of bytes / 4) must be a multiple of 8.

Quote:

Originally Posted by diegoisawesome

JPAN, what about the flags? Is there a way to fix the flags above 0x900 or something?

FYI, the address of the hypotetical flag 0x900 overlaps the one used by variable 0x4000. I guess I'll be able to tell you more when I implement the safe variables myself (sorry JPAN, but your code is just too messy).

EDIT: I did some research, and I think I found some safe areas to store the new variables in. For FR/LG, the whole area between 0x0203C000 - 0x0203EFFF appears to be totally unused. I somewhat confirmed it by putting a breakpoint on read/write on the whole area. I wasn't able to get the debugger to break yet. Also, here's a list I made, which clearly shows my theory:

Code:

As for Emerald, the whole 0x0203XXXX area is mostly used by the game already. So my suggestion is to try the 0x0202XXXX area, in particular anything between 0x02027000 - 0x02027FFF, or 0x0202A000 - 0x0202AFFF, or 0x0202D000 - 0x0202DFFF, or 0x0202F000 - 0x0202FFFF.

Code:

As for R/S, the whole are between 0x0203B000 - 0x0x0203DFFF should be safe.

Code:

Although I made those lists as accurate as possible, please note that they're only approximative; testing is always a must. Especially if you're using R/S/E, because I didn't test them.

Wichu · #56 September 6th, 2010, 10:08 AM

Not really that advanced compared to what you guys have been up to, but I was asked whether I knew where Steven's double battle team in Emerald was located. A bit of digging later, and I found it. It's not quite in the same format as normal trainers.

Metang: 0x5dd6d0
Skarmory: 0x5dd6e4
Aggron: 0x5dd6f8

Format:
Species (2 bytes)
IVs (1 byte)
Level (1 byte)
Nature? (1 byte) - unconfirmed; check this (Metang should be Lonely, Skarmory Impish, and Aggron Adamant)?
EVs? (6 bytes) - unconfirmed; check this?
Padding (1 byte)
Moves (8 bytes)

Unlike ordinary trainers (as far as I can remember), Steven's data appears to include nature and EVs. I bet this could be used to add opposing trainers with stronger Pokémon somehow.

Anyway, a question: this isn't really useful for ROM hacking, but it's related. Could somebody find the formula used to calculate the PIDs of eggs in Emerald if the mother is holding an Everstone? I know the formula without the Everstone already, but I'm stumped as to what happens when one is used.

colcolstyles · #57 October 9th, 2010, 04:59 AM

If anyone's interested, here's a tiny little morsel of information that I found recently. At the address '0x3A72A0' in Fire Red, you will find two bytes: '0xCD' and '0xFF'. These two bytes are used whenever the player is given two or more of some item using the 'giveitem' construct. The '0xCD' corresponds to an uppercase 'S' while the '0xFF' is the terminator byte, signifying the end of the string. If you change the byte from '0xCD' to '0xE7', the 'S' will become a lowercase 's'. I figure this might come in handy for those de-capitalization patches because it's really annoying to see "Player received the Poké BallS!" every time the player receives more than one of an item.

slawter666 · #58 October 11th, 2010, 05:01 PM

Realistically, how much work would be needed to change the 64x64 pixel limit in the 3rd generation games to the 80x80 pixel limit used in the 4th generation games? Please don't tell me it's hard or a lot of work. I'm genuinely interested in what would have to be done to increase the limit as it would be extremely beneficial to lots of people, especially as it would allow much higher quality sprites to be used as well as being able to import the 4th and 5th generation pokémon without (too much) resizing.

diegoisawesome · #59 October 11th, 2010, 11:51 PM

It appears that the offsets Hackmew posted a while back that were safe (for Emerald) are wrong..

shiny quagsire · #60 October 12th, 2010, 01:48 AM

Quote:

Originally Posted by slawter666

Realistically, how much work would be needed to change the 64x64 pixel limit in the 3rd generation games to the 80x80 pixel limit used in the 4th generation games? Please don't tell me it's hard or a lot of work. I'm genuinely interested in what would have to be done to increase the limit as it would be extremely beneficial to lots of people, especially as it would allow much higher quality sprites to be used as well as being able to import the 4th and 5th generation pokémon without (too much) resizing.

You would need to modify the games ASM code, which would be a pain and would be way too hard. And, the sprites would go outside the picture box in the status screen. In other words, it's really hard, and it's just not worth it.

Gamer2020 · #61 October 12th, 2010, 01:52 AM

Quote:

Originally Posted by diegoisawesome

It appears that the offsets Hackmew posted a while back that were safe (for Emerald) are wrong..

How's about putting a reason as to why you believe that?

HackMew · #62 October 12th, 2010, 09:55 AM

Quote:

Originally Posted by diegoisawesome

It appears that the offsets Hackmew posted a while back that were safe (for Emerald) are wrong..

That's right, but like I said, I did not test them. What about 0x0203D800?

slawter666 · #63 October 12th, 2010, 03:59 PM

Quote:

Originally Posted by shiny quagsire

You would need to modify the games ASM code, which would be a pain and would be way too hard. And, the sprites would go outside the picture box in the status screen. In other words, it's really hard, and it's just not worth it.

Ok, I thought it would involve ASM and it wouldn't be a case of just changing a few values. I never even thought about the box in the status screen though. It's just irritating having to resize sprites and them losing their quality because of it.

Anyway, thanks for the swift reply.

The 100 Mega Shock · #64 October 12th, 2010, 08:28 PM

The GBA hardware will only draw sprites up to 64 x 64 pixels.

Go any bigger and you'll have to work with tiles and tilemaps, which would be an absolute nightmare to both code in the first place and then implement for each Pokémon.

diegoisawesome · #65 October 12th, 2010, 09:39 PM

Quote:

Originally Posted by HackMew

That's right, but like I said, I did not test them. What about 0x0203D800?

That address appears to function properly, but only time will tell... hopefully.

HackMew · #66 October 12th, 2010, 10:06 PM

Quote:

Originally Posted by The 100 Mega Shock

Go any bigger and you'll have to work with tiles and tilemaps, which would be an absolute nightmare to both code in the first place and then implement for each Pokémon.

No doubt it would be painful, but... you would only need a single tilemap for all the Pokémon. However, even if you succeeded, there would still be problems in the Pokédex etc. because the sprites weren't supposed to be bigger than 64x64 pixels.

slawter666 · #67 October 14th, 2010, 08:11 PM

Quote:

Originally Posted by The 100 Mega Shock

The GBA hardware will only draw sprites up to 64 x 64 pixels.

Go any bigger and you'll have to work with tiles and tilemaps, which would be an absolute nightmare to both code in the first place and then implement for each Pokémon.

Quote:

Originally Posted by HackMew

No doubt it would be painful, but... you would only need a single tilemap for all the Pokémon. However, even if you succeeded, there would still be problems in the Pokédex etc. because the sprites weren't supposed to be bigger than 64x64 pixels.

Ah I see why it's hard then...Could the pokédex problem be fixed by a gfx hack to make the box where they're shown bigger or do you mean they wouldn't show up properly? I take it that it would it be the same for the trainer sprites?

I'll probably just leave it then and just resize any sprites I need to, but anyway, thank you all for the help, it's appreciated.

knizz · #68 October 21st, 2010, 04:27 PM

In Pokemon Firered 825E074 contains the ping-pong animation for the arrows in the bag. Open in VBA Memory Viewer and play around.

Team Fail · #69 October 22nd, 2010, 02:12 AM

Quote:

Originally Posted by knizz

In Pokemon Firered 825E074 contains the ping-pong animation for the arrows in the bag. Open in VBA Memory Viewer and play around.

Pretty cute little find.

Both arrows run off the same script, I believe. I made it really twitchy. I also may try to make a custom animation for them when I have some time on my hands.

knizz · #70 October 27th, 2010, 12:27 PM

Controlling other characters on a map: Just write their id to 0x02037078+5. As always this is for Firered.

sonic1 · #71 October 27th, 2010, 05:49 PM

If you want to always run without using button B, like in HG/SS, set 0x02037078 to 02. Warning: If you open 1 of the menu options, or have a battle or warp, the effect fades off and you have to set it again.
VERSION: FIRERED

Credits to you knizz, for the offset! Can you tell us what really that offset is?

Quote:

Originally Posted by knizz

Controlling other characters on a map: Just write their id to 0x02037078+5. As always this is for Firered.

Neat trick, i had this bug once in emerald and it only happened in a certain house opening the pokedex and always wondered how to do it.

But controlling other persons in A-Map has some limitations in-game like the camera not moving, and the limits the person can go,etc.

altariaking · #72 October 27th, 2010, 05:57 PM

Quote:

Originally Posted by sonic1

If you want to always run without using button B, like in HG/SS, set 0x02037078 to 02. Warning: If you open 1 of the menu options, or have a battle or warp, the effect fades off and you have to set it again.

Credits to you knizz, for the offset! Can you tell us what really that offset is?

Neat trick, i had this bug once in emerald and it only happened in a certain house opening the pokedex and always wondered how to do it.

But controlling other persons in A-Map has some limitations in-game like the camera not moving, and the limits the person can go,etc.

Interesting find 0_0
This is or FireRed? I'll try and find the offset for Ruby after I finish my English essay xD

sonic1 · #73 October 27th, 2010, 06:06 PM

Quote:

Originally Posted by altariaking

Interesting find 0_0
This is or FireRed? I'll try and find the offset for Ruby after I finish my English essay xD

Sorry, i forgot to put the version. Yes, it is for firered, i work only with firered.

Also, do you know why that happens? Check what happens to that value when you put the bike.
Sidenote: Because it simulates the speed of a bike, its a bit faster than running.

knizz · #74 October 27th, 2010, 06:19 PM

02037078 is a structure that controls the movement of, and only of, the player. However it can be associated to any NPC on screen.

The first two bits (0x03) of 02037078+0 determine the speed. 1 is normal. 2 is bike speed. 3 gives you a bike and changes itself to 2.

No matter what you write to 02037078+1 it is set to 0 again. If the value was 2 before the reset you get a bike. If you change the bike-byte the NPC turns into the hero.

02037078+2 and 02037078+3 behave like this:
0 0 Nothing pressed
0 0 Nothing pressed
1 1 Pressed forward
2 1 Pressed forward
2 1 Pressed forward
2 1 Pressed forward
0 0 Nothing pressed
2 1 Pressed forward
2 1 Pressed forward
0 0 Nothing pressed
0 0 Nothing pressed
1 1 Pressed forward
2 1 Pressed forward
2 1 Pressed forward

I don't know about 02037078+4.
02037078+5 sets the npc-id that is controlled by the keypad. (I wonder which numbers the npcs from connected maps have)
02037078+6 locks all movement when set to 1

More info about the NPCs is stored at 02036E38 in 16 0x24-byte long structures (Does that mean that there can't be more than 16 npcs in the overworld at the same time?!)
0x00 bits 7 and 6 are set when this npc is talking
0x01-0x0A unknown
0x0B height
0x0C-0x0F unknown
0x10 from (coords)
0x14 to (coords)
0x18 unknown
0x19 direction (in which the character actually looks)
0x1A unknown
0x1C direction (set when talked to but not always copied to 0x19)
0x1E unknown
0x20 direction (set after talk)
0x21-0x23 unknown

UPDATE: http://www.pokecommunity.com/showpos...80&postcount=2

coordinates are saved as two halfwords (x and y)

The code for moving uses a table to convert the direction to relative coordinates.
Table: 083A64C8
Function that uses the table above: 08063A20
Function that uses the function above to move npcs: 0805C4F4

Note that the table contains 9 and not 5 directions. Yes. Game Freak planned to have diagonally moving npcs.

colcolstyles · #75 November 2nd, 2010, 01:23 AM

In a Fire Red ROM, there is a table of data located at the address '0x452c4c'. Each entry in this table contains two pieces of information. One is a pointer and the other is a 32-bit number (I assume this is to keep the alignment consistent). The pointer points to another table and the number specifies the size of that table. In one of these secondary tables, there are a number of entries (the exact number is specified by the number mentioned earlier), each of which are also composed of a pointer and a 32-bit number. These pointers point instead to a list of pokémon and the number dictates the length of that list.

After a bit of research, I determined that the first table of pointers controls the classification of pokémon habitats (e.g., Grassland, Mountain, Rough-Terrain, etc.) as displayed in the PokéDex. The secondary tables specify which pokémon are in each Habitat and which pokémon appear on each "page" of the PokéDex (see the screenshots if you don't know what I mean). Let's look at an example. The first pointer at '0x452c4c' points to '0x4527d4' and is followed by the number '0x1b'. Thus, if you have a complete PokéDex, then there will be 27 ('0x1b' in decimal) pages of pokémon in the Grassland Habitat (the pointers are arranged in the order that they appear in-game, so Grassland comes first). The first pointer at '0x4527d4' points to '0x4524d0' and is followed by the number '0x4'. This means that the first four pokémon at that address are grouped onto one "PokéDex page". In this case, the numbers at that address (after reversing them) are '0x0013', '0x0014', '0x00a1', and '0x00a2', which correspond to Rattata, Raticate, Sentret, and Furret. So, if on the main PokéDex screen you select "Grassland Pokémon", you'll get a screen like this:

Spoiler:

But if we edit that data, we could get something like this:

Spoiler:

So let's say you replaced Machop (a Mountain Habitat pokémon) with a fakemon that you want to go in the Urban Habitat. You should first subtract one from the number of Mountain pokémon (Mountain is the sixth Habitat so the number would be found at '0x452c78') and add one to the number of Urban pokémon (Urban is the eigth Habitat so the number would be found at '0x452c88'). Then you would have to remove the entry for Machop's evolutionary family's page in the Mountain Habitat table and add it somewhere in the table for Urban Habitat pokémon.

Blogs
Recent Entries	Best Entries
Best Blogs	Blog List
Search Blogs

Tag Search
Advanced Search