Research & Development Quick Research/Development Thread

[sonic1]

Originally Posted by knizz

:O
Is this 0803FBE8?
Thanks!

Well, actually that's the routine that retrieves the pokemon data.

The one that i'm talking about is at 804037C, name's 'set_pokemon_data'

Pass adress at r0, pass index number r1, and the address which is located the data to set at r2. Thats why i was asking you about the stack. Game usually passes SP to R2, and the game uses the data present at the stack.

[knizz]

Originally Posted by sonic1

Well, actually that's the routine that retrieves the pokemon data.

The one that i'm talking about is at 804037C, name's 'set_pokemon_data'

Pass adress at r0, pass index number r1, and the address which is located the data to set at r2. Thats why i was asking you about the stack. Game usually passes SP to R2, and the game uses the data present at the stack.

I updated my DB to include this and an enumeration with all numbers get/set_pokemon_data uses and the pokemon-properties they represent.

Also smaller changes and fixes.

Download link in the signature.

[atomen]

Hi!

I thought this question might just fit in this thread. I've recently
developed a map editor for Red/Blue (out of pure curiousity) and now I've turned my sight for FR/LG. the difference compared to my
previous project though, is that I seem to be unable to find an
in-depth guide/format description of the map structure that LG/FR
uses. Now correct me if I'm wrong but does it not resemble the
format used in ruby/sapphire? At least that's what I've read.

If this statement is true, how close does this format description
match the FR/LG one (since it describes ruby's):
pokecommunity.com/showthread.php?p=6646782

Any hint or help would be greatly appreciated!
(sorry for the feeble reply, written on my cellphone...)

Note: I have tried to search for answers but without succes.

[redriders180]

I'm happy to be posting here something that might help someone, actually! But then again, someone probably already posted this somewhere else. v.v

Anyways, in Diego's tutorial, it discusses applymovement, and lists many commands that can be used. It lists from 0x0 up to 0x66, skipping 0x45 and everything from 0x5A to 0x5F. I decided to try every possible byte as an applymovement command, to see if there's anything else besides the listed commands...and there was! I found almost 67 unmentioned movements, and a fair majority of them actually work. Most of these are useful, because they access frames besides the first eight. I'll list the ones not mentioned in the tutorial here...These are for Firered/Leafgreen:

Spoiler:

#raw 0x45 = Walk in place. Direction of walking depends on which way you were facing at time of activation. Loops forever
#raw 0x5A = Look Down
#raw 0x5B = Run in place, downwards. Loops forever. Uses running frames, as opposed to walking frames.
#raw 0x5C = Seemingly Absolutely nothing
#raw 0x5D = Also absolutely nothing
#raw 0x5E = Again, Nothing
#raw 0x5F = Nothing once more.
#raw 0x67 = Nothing.
#raw 0x68 = Face up, and locks movement.
#raw 0x69 = Face up, and locks movement. When used for cut trees and smash rocks, it plays the destruction animation.
#raw 0x6A = Nothing.
#raw 0x6B = Nothing.
#raw 0x6C = Causes person not to flip while moving right, aka Moonwalking.
#raw 0x6D = Nothing.
#raw 0x6E = Walks one tile down, but takes two steps.
#raw 0x6F = Walks one tile down, but takes two steps.
#raw 0x70 = Faces right, then down, very fast.
#raw 0x71 = Faces down, then up, very fast.
#raw 0x72 = Faces up, then left, very fast.
#raw 0x73 = Faces left, then right, very fast.
#raw 0x74 = Runs in place downward, uses running frames, as opposed to normal
walking frames. Loops forever.
#raw 0x75 = Runs in place upward, uses running frames, as opposed to normal
walking frames. Loops forever.
#raw 0x76 = Runs in place left, uses running frames, as opposed to normal
walking frames. Loops forever.
#raw 0x77 = Runs in place right, uses running frames, as opposed to normal walking frames. Loops forever.
#raw 0x78 = Player looks diagonally left and right, twice.
#raw 0x79 = Faces down, Locks movement.
#raw 0x7A = Faces up, and locks movement.
#raw 0x7B = Faces left, locks movement.
#raw 0x7C = Runs and jumps in place, facing down. Uses running frames.
#raw 0x7D = Runs and jumps in place, facing up. Uses running frames
#raw 0x7E = Runs and jumps in place, facing left. Uses running frames.
#raw 0x7F = Runs and jumps in place, facing right. Uses running frames.
#raw 0x80 = Runs and jumps down. Uses running frames.
#raw 0x81 = Runs and jumps up. Uses running frames.
#raw 0x82 = Runs and jumps left. Uses running frames.
#raw 0x83 = Runs and jumps right. Uses running frames.
#raw 0x84 = Runs and jumps down two tiles. Uses running frames.
#raw 0x85 = Runs and jumps up two tiles. Uses running frames.
#raw 0x86 = Runs and jumps left two tiles. Uses running frames.
#raw 0x87 = Runs and jumps right two tiles. uses running frames.
#raw 0x88 = Step on the spot right, then face down.
#raw 0x89 = Step on the spot down, then face up.
#raw 0x8A = Step on the spot up, then face left
#raw 0x8B = Step on the spot left, then face right
#raw 0x8C = Run down. Uses running frames
#raw 0x8D = Run up. Uses running frames
#raw 0x8E = Run left. Uses running frames
#raw 0x8F = Run right. Uses running frames
#raw 0x90 = Slide down, facing right, then faces down.
#raw 0x91 = Slide up, facing down, then faces up.
#raw 0x92 = Slides left, facing up, then faces left.
#raw 0x93 = Slides right, facing left, then faces right.
#raw 0x94 = Spins down. Faces down when completed.
#raw 0x95 = Spins up. Faces up when completed.
#raw 0x96 = Spins left. Faces left when completed.
#raw 0x97 = Spins right. Faces left when completed.
#raw 0x98 = Runs downward, using running frames. Loops forever.
#raw 0x99 = Runs downward in place, and jumps. Repeats once.
#raw 0x9A = Runs downward in place, swaying from side to side slighty. Uses running frames.
#raw 0x9B = Walks downward VERY slowly, taking ten steps to move one tile.
#raw 0x9C = Walks upward VERY slowly.
#raw 0x9D = Walks left VERY slowly.
#raw 0x9E = Walks right VERY slowly.
#raw 0x9F = Looks diagonaly left and right, twice, then faces the same way you started facing.
#raw 0xA0 = Slides down one tile.
#raw 0xA1 = Slides up one tile.
#raw 0xA2 = Slides left one tile.
#raw 0xA3 = Slides right one tile.
#raw 0xA4 = Flies up off the screen, and disappears.
#raw 0xA5 = Flies down from top of screen, and reappears.
#raw 0xA6 = Runs very fast, and jumps down one tile
#raw 0xA7 = Runs very fast, and jumps up one tile
#raw 0xA8 = Runs very fast, and jumps left one tile
#raw 0xA9 = Runs very fast, and jumps right one tile
#raw 0xAA through #raw 0xFD either lock or crash the game.

A note: The ones that say "loop forever" can be un-looped, of course. The commands in question simply won't trigger the "waitmovement" command, so the script is waiting for a movement to end, causing the loop. I'll leave it up to you to figure it out

[Jambo51]

I've decided to post a couple of useful hacks on here today, both related to battle scripting.

First, here's my "callasm" scripting command. It does exactly what its namesake in overworld scripting does.

Spoiler:

.text
.align 2
.thumb
.thumb_func
.global battlescriptcallasm
main:
push {lr}
push {r1-r7}
ldr r0, scriptlocation
ldr r0, [r0, #0x0]
ldrb r1, [r0, #0x1]
ldrb r2, [r0, #0x2]
lsl r2, r2, #0x8
orr r1, r2
ldrb r2, [r0, #0x3]
lsl r2, r2, #0x10
orr r1, r2
ldrb r2, [r0, #0x4]
lsl r2, r2, #0x18
orr r1, r2
bl bx_r1
ldr r0, scriptlocation
ldr r1, [r0, #0x0]
add r1, #0x5
str r1, [r0, #0x0]
pop {r1-r7}
pop {r0}
bx r0
bx_r1: bx r1
.align
scriptlocation: .word 0x02023D74

In order to insert this command, you need to repoint and extend the battle script command table which is at 0x0825011C and add a new entry pointing to the routine I just gave you. If you insert it directly after the end of the table, it will become command 0xF8.

Usage is thus:

F8 XX XX XX 08

Where XX XX XX 08 is the pointer to the ASM to call + 1 for THUMB mode, or not incremented for ARM mode.

Second up, this is the battle string loader hack I made. It intercepts the "failed" part of the loader. That is, it branches out from what the loader would otherwise consider to be a bad number to load from and skip.

Spoiler:

.text
.align 2
.thumb
.thumb_func
.global battlestringloaderhack
main:
mov r0, #0xC2
lsl r0, r0, #0x1
cmp r0, r6
bne normalcode
ldr r0, ramlocation
ldr r7, [r0, #0x0]
cmp r7, #0x0
beq alternative
mov r0, #0xA
lsl r0, r0, #0x18
cmp r7, r0
bge alternative
mov r0, #0x8
lsl r0, r0, #0x18
cmp r7, r0
blt alternative
b continue
alternative: mov r6, #0xC
ldr r1, returntwo
bx r1
continue: ldr r0, returnone
bx r0
normalcode: ldr r1, otherramloc
mov r0, #0xFF
strb r0, [r1, #0x0]
pop {r3-r5}
mov r8, r3
mov r9, r4
mov r10, r5
pop {r4-r7}
pop {r0}
bx r0
.align
ramlocation: .word 0x0203C020
returntwo: .word 0x080D77D1
returnone: .word 0x080D77DD
otherramloc: .word 0x0202298C

As you can see, it has checks to try and catch a "bad" location given in the RAM location I set aside for the new functionality. All it can catch, sadly, is if you leave the RAM location empty, or if you try to use an invalid ROM location. The rest, I have to leave to the user.

I've written the routine such that it supports 32MB ROMs as well, so you don't have to worry about that either.

To insert the actual routine, navigate to 0xD77BE and change the code to 03 49 08 47, then go to 0xD77CC and change the pointer to the insert location of the routine, plus 1 for THUMB mode of course.

Now, using it. It's as easy as this: Using the storebyte command of the battle script functionality (0x2E), store the bytes of the ROM pointer in little endian ordering, into the RAM address 0x0203C020. Then, you call the battle string printer as such:

10 84 01 39 40 00

The routines will take care of the rest!

[knizz]

I wrote a bit about the scripting system at this new wiki http://pkmnhackersonline.com/wiki/in...Firered_Engine. Stuff that is in my DB already, but that isn't available online.

[Agastya]

I think I've found the Battle Pike wilds. I say think, because despite the fact I have edited them in a hex editor (and multiple hex editors showing the changes), I personally can't get any changes to show up in-game. I'm only really posting these because they make sense compared to what's shown on the Bulbapedia page, and maybe somebody else can help out with this to say if they get results, if this is somehow completely wrong, or if it's just VBA getting tired of allowing me to have nice things.

Spoiler:

Pike wilds start at 0x6121D4 for (Level 50?) and 0x612274 for (Open Level?). There are twelve entries followed by four pointers on the first one splitting them into four blocks of three, and then twelve entries followed by six pointers on the second one, the first four pointers splitting the previous twelve entries into four blocks of three and the final two pointing towards the first and second sets of pointers. The format for the wilds itself is a 12 byte data structure:

7B 01 | 04 00 | 5C 00 89 00 22 00 BC 00

1) Species, 2 bytes
2) ???, 2 bytes
3) Movepool, 8 bytes

Displayed is the generic Seviper entry. Its movepool is Toxic, Glare, Body Slam, and Sludge Bomb. I'm not sure what the ??? is, but it's either 04 00 or 05 00, and has been noted in the spawn listing alongside what Bulbapedia states is its spawn rate.


Set one (Rooms 0~280)
Seviper 04 00 26%
Milotic 04 00 26%
Dusclops 05 00 48%

Set two (Rooms 281~560)
Seviper 04 00 26%
Milotic 04 00 26%
Electrode 05 00 48%

Set three (Rooms 561~840)
Seviper 04 00 26%
Milotic 04 00 26%
Breloom 05 00 48%

Set four (Rooms 840+)
Seviper 04 00 26%
Milotic 04 00 26%
Wobbuffet 05 00 48%

Each instance of Seviper and Milotic is its own entry, so they should be customizable to the hacker's whims. The entries in Open Level are the same, but have slightly different movepools.

It'd be nice if these actually were the offsets though, because then after that it's figuring out what determines the Pokemon selected by each facility. Outside of the list being a in a "general sliding scale of difficulty" there's not really much other leads on selection.

[redriders180]

Hi there! I was designing a berry tree system for my game (Firered), and while I figured out a way to make a tree give a berry a day, I realized that there was something else in the game that does pretty much the same thing; the regenerating berries in Berry Forest, and regenerating trinkets on treasure beach. Does anyone have any info on these regenerating items, and how I might be able to expand the list to cover all my berry trees? Additionally, does anyone know where I might find the offsets for the flags/variables for hidden items?

[ipatix]

Hey guys,

I have some questions about the SSEQ file format:

I read in the SDAT specs of kiwi.ds that the delay and note length parameters are expressed with a variable anmount of bytes.
But these parameters aren't described and I want to know how these work.

What I noticed so far is that if you have more than one byte, the last byte is positive and the others are negative.
But what do I have to do with these values?
Do I have to read them out in Little Endian or do I have to add all these values?

Hope you can help me out with this ;-)

[looper]

I guess here you find, what you're looking for: http://kiwi.ds.googlepages.com/sdat.html

[sonic1]

Originally Posted by redriders180

Hi there! I was designing a berry tree system for my game (Firered), and while I figured out a way to make a tree give a berry a day, I realized that there was something else in the game that does pretty much the same thing; the regenerating berries in Berry Forest, and regenerating trinkets on treasure beach. Does anyone have any info on these regenerating items, and how I might be able to expand the list to cover all my berry trees? Additionally, does anyone know where I might find the offsets for the flags/variables for hidden items?

Well, i only took a quick look into this issue (3 minutes) because i'm very busy now, and i don't want to discourage you, but there's a limit for those items.
The routine at 080CC44C is the one who gets the flag associated with the hidden item, based on Hidden ID + 0x3e8. This means no repoint+add items without overwriting other game flags.

Thats the only thing i found out by now.

Props

[redriders180]

Originally Posted by sonic1

Well, i only took a quick look into this issue (3 minutes) because i'm very busy now, and i don't want to discourage you, but there's a limit for those items.
The routine at 080CC44C is the one who gets the flag associated with the hidden item, based on Hidden ID + 0x3e8. This means no repoint+add items without overwriting other game flags.

Thats the only thing i found out by now.

Props

Well, plan B is to make a script that just clears all the hidden item flags to zero at midnight, which is simple enough. I assume the hidden item flags are stored somewhere in memory, so I'd just have to write 0 to all the bytes I need to clear it out. Does anyone have the offset for this location in the memory?

[sonic1]

Originally Posted by redriders180

Well, plan B is to make a script that just clears all the hidden item flags to zero at midnight, which is simple enough. I assume the hidden item flags are stored somewhere in memory, so I'd just have to write 0 to all the bytes I need to clear it out. Does anyone have the offset for this location in the memory?

Well, actually, they are normal flags, like 0x800 etc..., but are Hidden ID + Flag 0x3E8. (E.g: Hidden item 0x10 would be flag 0x3F8. Clear the flag to be able to get the item again)

The script is somewhat easy. There are 0xBE hidden items. Here's a script made now for the purpose:

#dynamic 0x800000
'----------------
#org @start
setvar 0x8000 0x3E8 'Base flag
setvar 0x8001 0x0   'Counter
goto @loop

#org @loop
compare 0x8001 0xBE
if B_> goto @end
addvar 0x8001 0x1
clearflag 0x8000    ' Clear flag in var 8000
addvar 0x8000 0x1
goto @loop

#org @end
setvar 0x8000 0
setvar 0x8001 0     'Reset vars
release
end

I made this in 5 minutes and didn't test it. Test it and please warn me if there's an inconvenience with this.

(to @redriders180: I saw your PM, i just hadn't the time to answer it because its a little complex for my current time available)

[redriders180]

Originally Posted by sonic1

Well, actually, they are normal flags, like 0x800 etc..., but are Hidden ID + Flag 0x3E8. (E.g: Hidden item 0x10 would be flag 0x3F8. Clear the flag to be able to get the item again)

The script is somewhat easy. There are 0xBE hidden items. Here's a script made now for the purpose:

#dynamic 0x800000
'----------------
#org @start
setvar 0x8000 0x3E8 'Base flag
setvar 0x8001 0x0   'Counter
goto @loop

#org @loop
compare 0x8001 0xBE
if B_> goto @end
addvar 0x8001 0x1
clearflag 0x8000    ' Clear flag in var 8000
addvar 0x8000 0x1
goto @loop

#org @end
setvar 0x8000 0
setvar 0x8001 0     'Reset vars
release
end

I made this in 5 minutes and didn't test it. Test it and please warn me if there's an inconvenience with this.

(to @redriders180: I saw your PM, i just hadn't the time to answer it because its a little complex for my current time available)

I just tested this, and for some odd reason, it's not working. I activated a hidden item in the usual way, obtained it, and then ran this script via signpost, but I couldn't get the item again. I even expanded it to clear every flag from 0x1 to 0xFFF, but nothing. Am I doing something wrong?

[sonic1]

Ok, sorry, my bad, the script doesn't work, and i don't know why. In the past months i only worked with ASM, so i'm a but rusty with scripts. Here's a routine.
Try callingasm this routine:

.align 2
.thumb

main:
	push {r0-r4, lr}
	ldr r0, =0x3E8 			@flag base
	ldr r1, =0x0			@counter
loop:
	cmp r1, #0xBE
	bhi end
	add r1, r1, #0x1
	bl clearflag
	add r0, r0, #0x0		@next flag
	b loop
end:
	pop {r0-r4, pc}
	
clearflag:
	ldr r4, =0x0806E6A8+1          @clearflag routine offset
	bx r4

Hope this helps.

[Light_of_Aether]

I looked at the list of identified flags posted by DavidJCobb and it isn't very clear which ranges of flags can be used safely. It looks like the range between 0AE and 154 doesn't have any flags. Does anyone know if new flags can be created in that range?

[Chaos Rush]

I figured out how to edit the Hoenn Dex order in Ruby, without editing the National Dex. The offset is at 0x1FC84C. It does not list by Pokemon index number, it lists by dex entry index number. Treecko's index number is 277, but Treecko's dex entry number is 252. Which is why the byte at the offset I listed is FC. Changing the bytes here will change the Hoenn Dex while keeping the National Dex intact.

I suspect the same table exists in Emerald, and the bytes should be exactly the same.

EDIT: Hacked the Hoenn Dex to something similar (but not exactly the same) to a listing I'm planning on using in a future hack:

[sonic1]

Originally Posted by Chaos Rush

I figured out how to edit the Hoenn Dex order in Ruby, without editing the National Dex. The offset is at 0x1FC84C. It does not list by Pokemon index number, it lists by dex entry index number. Treecko's index number is 277, but Treecko's dex entry number is 252. Which is why the byte at the offset I listed is FC. Changing the bytes here will change the Hoenn Dex while keeping the National Dex intact.

I suspect the same table exists in Emerald, and the bytes should be exactly the same.

EDIT: Hacked the Hoenn Dex to something similar (but not exactly the same) to a listing I'm planning on using in a future hack:

Yup, that table exists in Emerald, it's located at 0x31DFB8
For any ruby/firered to emerald equivalents, you can ask me, as i'm a emerald hacker.

[Chaos Rush]

Originally Posted by sonic1

Yup, that table exists in Emerald, it's located at 0x31DFB8
For any ruby/firered to emerald equivalents, you can ask me, as i'm a emerald hacker.

Do you know where the limiter that limits the Hoenn Dex to 202 entries is though? It would be nice if we could expand it. It shouldn't require any ram repointing because the maximum amount of entries that the ram allows is 386.

[Jambo51]

For anyone interested, in FR US 1.0 (aka BPRE 1.0), to change your Pokédex "mode" to the style which DPPt used (That is, to have the seen amount displayed in the continue screen and the save screen instead of the caught numbers), change:

0800CF56: 00 20
0800CF64: 00 20
080F803C: 00 20
080F8044: 00 20

It really is that simple.

[Haru~]

Hello guys!

Does anyone know the RAM location for the player's current money, if any?
I've been messing with the memory viewer but I can't see it unless I access the trainer card, 0x02000490. But I want to know where the data is when you're not viewing the card.

EDIT: Oh, it's for BPRE. Silly me!

[Spherical Ice]

Well the offset 0x054B80 contains bytes that can be edited to change the amount of money you start off with in FireRed, but I don't know which ROM you're referring to.

[Chaos Rush]

Originally Posted by Jambo51

stuff

So glad I found this, thank you! I've been thinking of figuring out how to make my own callasm command for battle scripting, but you've just saved me some work!

[aar2697]

For the setmapfooter command/script in XSE, you're required to know the map footer for the map. Some people suggest subtracting the map footer table from the pointer to map footer offset, but there's a much easier way. I also think that method only works with Emerald, because since no one has posted the map footer table for Fire Red on these forums, I had to reverse find the "table," but using that number did not work with other maps than the map that I used to reverse find it. I probably checked my math, offsets, and pointers countless times, and I'm positive that method doesn't work with Fire Red.

This, however DOES work with Fire Red, along with Leaf Green, Ruby, Sapphire, and Emerald.
1. Go into Advance Map.
2. Choose a map you want the setmapfooter command to work with.
3. Go to header.
4. CTRL+H for professional settings.
5. Find the 19th byte in the Map Header (long strand of bytes under Map Settings)
6. That 19th byte is what you will use.

[Haru~]

After a long battle with cancer trying to find the RAM location of the player's money, I had a feeling that it is encrypted somewhere in the RAM and that's why I can't find it. So after going to my local POKeMART, I found a little routine that seems to decrypt something. After doing further testing, I made this routine to get the player's current money using the game's own code.

The routine:

Spoiler:

.align 2
.thumb

/*This routine does all the hard work in retrieving your current
money and stores it in vars 0x8000 and 0x8001.
	0x8000 - Lower half
	0x8001 - Upper half
*/

main:	push {r4-r6, lr}
	ldr r6, .DMA_MAP
	ldr r0, [r6, #0x0]
	mov r5, #0xA4
	lsl r5, r5, #0x2
	add r0, r0, r5
	ldr r1, .OTHER_RAMLOC
	ldr r1, [r1, #0x8]
	bl get_amount		/*Does the actual decrypting*/
	ldr r1, .VAR_8000
	str r0, [r1]
	pop {r4-r6, pc}

get_amount:	ldr r4, .DO_CALC
		bx r4

.hword 0x0000
.DMA_MAP:	.word 0x03005008
.OTHER_RAMLOC:	.word 0x02039934
.VAR_8000:	.word 0x020370B8 /*Var 0x8000-0x8001*/
.DO_CALC:	.word 0x0809FD59

I slept after that...