Skeetendo

’Cause all games were better on the GBC

You are not logged in.

  • Index
  • → Help/Question
  • → [pokered] Proposal: advancing the Pokémon Data Structure step by step

#1 2018-11-03 21:20:00

Fotomac
Member
Registered: 2015-10-25
Post 329/332

[pokered] Proposal: advancing the Pokémon Data Structure step by step

For my pokered hack, I intend to advance the Pokémon Data Structure gradually, step by step, generation by generation.

Firstly, I want to eventually get the structure from this:

00: Index number
01: Current HP
02: Current HP
03: Level
04: Status condition
05: Type 1
06: Type 2
07: Catch rate
08: Move 1
09: Move 2
0A: Move 3
0B: Move 4
0C: Original trainer ID
0D: Original trainer ID
0E: Experience points
0F: Experience points
10: Experience points
11: HP EV data
12: HP EV data
13: Attack EV data
14: Attack EV data
15: Defense EV data
16: Defense EV data
17: Speed EV data
18: Speed EV data
19: Special EV data
1A: Special EV data
1B: IV data
1C: IV data
1D: PP of Move 1
1E: PP of Move 2
1F: PP of Move 3
20: PP of Move 4
21: Level
22: Maximum HP
23: Maximum HP
24: Attack
25: Attack
26: Defense
27: Defense
28: Speed
29: Speed
2A: Special
2B: Special

To this:

00: Index number
01: Held item
02: Move 1
03: Move 2
04: Move 3
05: Move 4
06: Original trainer ID
07: Original trainer ID
08: Experience points
09: Experience points
0A: Experience points
0B: HP EV data
0C: HP EV data
0D: Attack EV data
0E: Attack EV data
0F: Defense EV data
10: Defense EV data
11: Speed EV data
12: Speed EV data
13: Special EV data
14: Special EV data
15: IV data
16: IV data
17: PP of Move 1
18: PP of Move 2
19: PP of Move 3
1A: PP of Move 4
1B: Friendship
1C: Pokérus
1D: Caught data
1E: Caught data
1F: Level
20: Status condition
21: Unused byte
22: Current HP
23: Current HP
24: Maximum HP
25: Maximum HP
26: Attack
27: Attack
28: Defense
29: Defense
2A: Speed
2B: Speed
2C: Special Attack
2D: Special Attack
2E: Special Defense
2F: Special Defense

This would, of course, be Stage 1. Step 1, I propose, would be to move the catch rate byte to where it will be in Generation II, and to replace that with a byte for the held item, at the same time implementing the held item function. My first attempt to do so at this time will involve simply porting the code for the catch rate and held item functions from pokecrystal, but if anyone has any better ideas, I'm all ears.

Offline

#2 2018-11-08 02:15:07

KeiTaRo
Member
Registered: 2015-12-05
Post 52/56
Website

Re: [pokered] Proposal: advancing the Pokémon Data Structure step by step

Order of the bytes really wouldn't matter since you're using a label anyway, unless you have some sort of loop that is reading things in a specific order.

Offline

#3 2018-11-08 19:34:25

Fotomac
Member
Registered: 2015-10-25
Post 331/332

Re: [pokered] Proposal: advancing the Pokémon Data Structure step by step

That's the easy part. The hard part is actually finding the labels and where they're added to the data structure.

Offline

#4 2018-11-09 00:18:06

KeiTaRo
Member
Registered: 2015-12-05
Post 55/56
Website

Re: [pokered] Proposal: advancing the Pokémon Data Structure step by step

I mean, creating labels and designating memory is easy. You can do what you're wanting to do very simply, the complicated part is making all of those parts work for the Pokemon. AKA, in order for all those different values to DO something, you have to code functions to make use of them. Otherwise, they're just unused memory locations like any other. Your focus should probably be more on the scope of how you plan to use those things, and how you can integrate that in to your project.

Offline

#5 2018-11-10 20:27:47

Fotomac
Member
Registered: 2015-10-25
Post 332/332

Re: [pokered] Proposal: advancing the Pokémon Data Structure step by step

Well, at any rate I found the key place to look is in wram, which literally begins with the Pokémon Data Structure. At present, I'm porting the held item code from pokecrystal starting with the battle core. Here's what I came up with thus far:

LoadEnemyMonData:
    ld a, [wLinkState]
    cp LINK_STATE_BATTLING
    jp z, LoadEnemyMonFromParty
    ld a, [wEnemyMonSpecies2]
    ld [wEnemyMonSpecies], a
    ld [wd0b5], a
    call GetMonHeader
    ld a, [wIsInBattle]
    cp $2 ; is it a trainer battle?
    jr nz, .wildItem
; if it's a trainer mon, the item is in the party struct
    ld hl, wEnemyMon1Item
    ld a, [wWhichPokemon]
    ld bc, wEnemyMon2 - wEnemyMon1
    call AddNTimes
    ld a, [hl]
    jr .UpdateItem
.wildItem
; if it's a wild mon, we pull from the item slots in BaseData
; Force Item1
; Used for Ho-Oh, Lugia and Snorlax encounters
    ld a, [wBattleType]
    cp BATTLETYPE_FORCEITEM
    ld a, [wBaseItem1]
    jr z, .UpdateItem
; Failing that, it's all up to chance
;  Effective chances:
;    75% None
;    23% Item1
;     2% Item2
; 25% chance of getting an item
    call BattleRandom
    cp 75 percent + 1
    ld a, NO_ITEM
    jr c, .UpdateItem
; From there, an 8% chance for Item2
    call BattleRandom
    cp 8 percent ; 8% of 25% = 2% Item2
    ld a, [wBaseItem1]
    jr nc, .UpdateItem
    ld a, [wBaseItem2]
.UpdateItem:
    ld [wEnemyMonItem], a

Obviously, there's a quite bit more work to do on held items after this. I know for a fact at least part of it involves adding to the wram and constants, and perhaps even some more conversion from pokecrystal format to pokered format, but am I missing anything else?

EDIT REASON: Typo

Last edited by Fotomac (2018-11-10 20:28:18)

Offline

#6 2018-11-11 21:26:42

KeiTaRo
Member
Registered: 2015-12-05
Post 56/56
Website

Re: [pokered] Proposal: advancing the Pokémon Data Structure step by step

I mean...the comments alone pretty clearly tell you what you'll need to be doing: "; if it's a trainer mon, the item is in the party struct"

At the very least, you're going to need to update the way the game reads and processes trainer parties, particularly by adding a field to the trainer's 'mon data and passing that value to the appropriate field. You do realize that the held item in Gen 2 reads from the same value as the catch rate in Gen 1 -- this field actually serves no purpose for an already captured Pokemon, so you could just canibalize this section of the WRAM and save yourself a byte. not to mention, you're going to have to program in-battle effects for every type of held item you want ... it's going to be a lot more than merely "converting the code", although reading and thoroughly understanding pokecrystal's code is definitely going to help the picture become clear for you.

Offline

  • Index
  • → Help/Question
  • → [pokered] Proposal: advancing the Pokémon Data Structure step by step

Board footer

Powered by FluxBB