Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2016-11-11 13:33:11

bloodless
Member
From: Somewhere south of Never Land
Registered: 2016-05-06
Post 61/171

Pokemon Box/Bank

We're reaching an exciting time in Pokemon hacking. The dream of having all 802 Pokemon in one game is close thanks to the hard work of the members of this community as well as the hard work of everyone who contributed to the disassembly. One problem that I've seen people bring up though is box space. Expanding it so much to hold all those Pokemon is pretty much a waste of space in the game (as well as other issues I've seen mentioned) as people are likely to not use more than 100 Pokemon. I myself only use 6 in a play through but if one wants to complete the pokedex where do all these extra pokemon go after you've got their data and you're done with it?

As some of you may have guessed my eventual aim is to have all the games remade for the colour system aswell as some extra games exploring the other regions from sidegames/the anime, so this is something I've thought about a lot recently, I'd like some semblance of a Catch Em All challenge, something I feel official games have lost, I'm sure others would as well. So what's the answer?

With the advent of Gen III came Pokemon Box: Ruby and Sapphire, with Gen VI came the Pokemon Bank, allowing storage of 1500 & 3000 Pokemon, respectively, separate from one's cartridge. So here's my thought on this. What if we were to strip all the unneeded stuff from Red/Crystal leaving only the important data required for Pokemon and Pokemon storage? It would essentially operate in a trade style model without having to receive a Pokemon in return and with plenty of space to expand to store more than 1000 Pokemon.

I've created a mockup to acompany this post. Thoughts? Would something like this even be possible?

j7kcilU.png

OAQZTKf.png

Edit: Forgot to mention the second screenshot would be in RBGY/GSC, it would be accessed through the link club, with a BOX option when talking to the person at the link club.

Last edited by bloodless (2016-11-11 14:05:19)


The saddest thing is there's no such thing as an ex addict. Either you're fighting addiction or you're not and if you start fighting you never stop. That's the nature of the monster.

Offline

#2 2016-11-11 21:58:28

Rangi
Member
Registered: 2016-05-09
Post 306/870

Re: Pokemon Box/Bank

Sounds like a good idea!

Demakes of the newer games for Gen 1/2 is a nice long-term plan, but they don't exist yet, and as far as I know there aren't any actual games that use the under-development expand-dex project for pokered. (And the comparable structure rewrite for pokecrystal is still in early stages.)

On the other hand, there are some games that each have their own expansions to the data structures, or will soon: Red++, Polished Crystal, and Crystal 20xx. (Any others?) It would be nice if we could agree on a common data format, so that trading could mutually occur between all these hack games, and this Pokémon Box project could be used as a common storage box. (Or possibly two data formats, one for Gen 1, one for Gen 2, with the Gen 2 Time machine converting between them.)

Right now all of those games have their own limited selections of Pokémon, moves, and items, with incompatible indexes. If indexes were all 2 bytes, we could agree to use the official ones. Which wouldn't mean that every game has to support all Pokémon; they just need to agree on the Pokémon they do support. And Pokémon Box would support all of them, since it has the space to do so, and can act as a common denominator for trading.

We'd also have to agree on other data structure properties, like abilities, natures, stat exp and/or EVs, and so on. Again, not every game would have to support all of those things, they just should avoid collisions (like if one game thinks byte #15 is the held item and another thinks it's the HP EV).

This might be too ambitious to start with, but how about limiting it to pokered at first? Since that project's dex expansion has progressed the most, and Mateo plans to use it in Red++ anyway. I'd still suggest setting aside some bytes for properties that the games don't necessarily include, like abilities, just for future-proofing compatibility with other games.

(One concern: how much SRAM do you actually save by removing everything except the box and trade systems? Current map and coordinates, event flags, items in the bag, etc... but just how many more Pokémon would this let you keep, particularly after the data structures have become larger?)


Pokémon Polished Crystal (GitHub) — version 2.2.0 released
Pokémon Red★ and Blue★: Space World Edition (GitHub) — updated August 19!
Polished Map: pokered+pokecrystal map, tileset, and palette editor — version 3.5.1 released!

Offline

#3 2016-11-11 23:02:36

Mateo
Member
From: The Sims 4
Registered: 2009-11-25
Post 3,426/3,580

Re: Pokemon Box/Bank

I agree, this would be a cool project to have, and I like the idea of a unified data structure. When the v3.0 rewrites get going with Red++, I was already thinking that the Gen 2 format with changes might be a good starting point, and I was thinking it might be handy to just make sure it matched Polished Crystal's struct. If Pokemon and Move IDs were both expanded, and the IDs matched, we wouldn't even need a Time Capsule feature to trade between the two I'd think. If we had a common structure and all the vanilla moves and 'mons had their canon IDs, then a universal bank like this would be infinitely handy I'd think.

Offline

#4 2016-11-12 01:14:19

bloodless
Member
From: Somewhere south of Never Land
Registered: 2016-05-06
Post 63/171

Re: Pokemon Box/Bank

As mentioned here the time capsule is an issue but with a 'unified ' 2byte format I see no reason the time capsule should even be in a 'unified' gen II game (other than in a regional/national dex format). I think if we can get a.2 byte complete red/crystal game going we could go from there and add things like nature's and IVs from there (presuming that's the way the community wants to go). We'd need a group chat with the major hackers to get the base started. I myself having never worked with the disassembly but being here since 05' think I understand enough to help out and others (no disrespect to yourselves) have worked with other V/VI/VII gem formats. It is most definitely a large task but I think starting with the bases would take a large amount of effort out of it.since we all have our own codes to add.

I'd  reply to the other points but my phone is about to die.

Last edited by bloodless (2016-11-12 01:22:06)


The saddest thing is there's no such thing as an ex addict. Either you're fighting addiction or you're not and if you start fighting you never stop. That's the nature of the monster.

Offline

#5 2016-11-12 01:39:13

ShantyTown
Member
Registered: 2013-12-04
Post 325/344

Re: Pokemon Box/Bank

I suppose I should probably start fixing those known 2-byte bugs in the expand-dex pokered project if people are wanting to make progress with this.  Not sure if it would be used by many people, but it's still a neat idea.

Offline

#6 2016-11-12 02:24:58

bloodless
Member
From: Somewhere south of Never Land
Registered: 2016-05-06
Post 64/171

Re: Pokemon Box/Bank

I think it would be used by at least the Skeetendo community.

Got my phone charging so I'll respond to some of the other things I missed.

It's great that we already have Rangi and Mateo already having some agreed upon stances (and games in the same 'universe', that's already a big starting point to work from, especially withMateos other planned games), plus the expanded pokedex project (upon completion) has a great starting point. The issue is having a base, which isn't thatdifficult (but still a massive task especially with the bugs to iron out, ie palletes and movesets working wrong) seeing as a few members of the community are already working on the expanded red, and a couple on the expanded Crystal.

As for the concern of stripping the base freeing up much space, as I say, I've not done a lot of work in red/gold but some (this was before the days of the disassembly) at the very least it would free up many flags which I could see having it's own uses, I.e. Separating boxes by gen/type/other uses.

The reason I posted this thread is to ask the opinion of members like (and especially) yourselves who have used the disassembly extensively. The idea is there but whilst I can do some you are the ones who can help me manage it.

Edit: I personally believe (having worked with hex in gold/red and some asm in FR) that the biggest issue is coordinating a unified 2byte Rom/disassembly in which moves and other important data is at least in a similar order with other things left alone that are agreed upon as bytes (whether used or not) for things like personalities. Which is exactly why I chose to post this here, other pokecommunities (not pointing any fingers) are not so much a community and there are very few jjoint projects.

Last edited by bloodless (2016-11-12 02:50:09)


The saddest thing is there's no such thing as an ex addict. Either you're fighting addiction or you're not and if you start fighting you never stop. That's the nature of the monster.

Offline

#7 2016-11-12 20:16:38

Mmmmmm
Member
From: West Virginia
Registered: 2015-05-17
Post 157/261

Re: Pokemon Box/Bank

Regarding moves, I think index numbers stay the same between generations, with more being tacked on over time. You could just include every move ever made in order (take Crystal's move order, then make index slot 252 Fake Out, 253 is Uproar, etc.), and dummy out the ones that aren't actually in your game, giving them a useless effect like Splash. Same for abilities if those are planned.

Offline

#8 2016-11-13 15:31:05

FIQ
Member
Registered: 2016-09-17
Post 18/79

Re: Pokemon Box/Bank

http://bulbapedia.bulbagarden.net/wiki/List_of_moves has a nice list for reference.
There is also http://bulbapedia.bulbagarden.net/wiki/ … ration_VI) for items (which has been by index order in the same order across generations since IV). Strangely, the old HM07 index wasn't recycled in ORAS, so there are 2 of these with the placeholder.

Last edited by FIQ (2016-11-13 15:37:56)

Offline

#9 2016-11-13 22:42:06

Rangi
Member
Registered: 2016-05-09
Post 314/870

Re: Pokemon Box/Bank

the biggest issue is coordinating a unified 2byte Rom/disassembly in which moves and other important data is at least in a similar order with other things left alone that are agreed upon as bytes (whether used or not) for things like personalities.

Agreed. Changing the size of a data structure introduces even more problems than just rearranging its contents, and making them larger also eats into the finite space available. Each project's incentive is to pack data as small as possible, so if e.g. Red++ has >255 Pokémon and Polished Crystal has abilities and Crystal 20xx has 5-bit DVs (which are all technically the "correct", most up-to-date formats), they have little reason to each set aside unused bytes in the right places.

On the other hand, if Pokémon Box works out a good structure format and is clearly shaping up to be an actual game that will work for storage and trading, then that's an incentive to be compatible with it.

Compare the Gen 2 and Gen 6 data structures. There have been a lot of new Pokémon attributes introduced, and while a fan game probably won't implement ribbons or markings, one might want contest stats. Replacing stat experience with EVs (which actually take fewer bytes) could be another issue.

One solution might be to keep the main data structure relatively small, containing only the "least common denominator" attributes, and then set aside a few bytes to refer to a secondary structure. If two games both implement contest stats, they could detect each others' game ID and that way know to trade secondary structures as well as primary ones.

Last edited by Rangi (2016-11-13 22:45:29)


Pokémon Polished Crystal (GitHub) — version 2.2.0 released
Pokémon Red★ and Blue★: Space World Edition (GitHub) — updated August 19!
Polished Map: pokered+pokecrystal map, tileset, and palette editor — version 3.5.1 released!

Offline

#10 2016-11-14 00:39:54

bloodless
Member
From: Somewhere south of Never Land
Registered: 2016-05-06
Post 68/171

Re: Pokemon Box/Bank

Mmmmmm wrote:

Regarding moves, I think index numbers stay the same between generations, with more being tacked on over time. You could just include every move ever made in order (take Crystal's move order, then make index slot 252 Fake Out, 253 is Uproar, etc.), and dummy out the ones that aren't actually in your game, giving them a useless effect like Splash. Same for abilities if those are planned.

Those were my thoughts with a similar thing in place for pokemon and tms as well.

FIQ wrote:

http://bulbapedia.bulbagarden.net/wiki/List_of_moves has a nice list for reference.
There is also http://bulbapedia.bulbagarden.net/wiki/ … ration_VI) for items (which has been by index order in the same order across generations since IV). Strangely, the old HM07 index wasn't recycled in ORAS, so there are 2 of these with the placeholder.

That's something I've been meaning to look up so thanks for the handy reference!

@Rangi one thought that does occur to me is obviously not every game will have 255+ pokemon, so if someone where to say box a pokemon with index 256 from, for example, red++ but also be using the box in conjunction with Polished Crystal (I believe those two games are planned to match in the end but for the example let's say red++ has more pokemon than PC) I could see that causing all kinds of glitches right there. Would the game ID detection also be a good way to handle that issue? I've never looked into how the first 2 gens recognise each other but I would assume something like that in place would be the way to go?


The saddest thing is there's no such thing as an ex addict. Either you're fighting addiction or you're not and if you start fighting you never stop. That's the nature of the monster.

Offline

#11 2016-11-14 00:49:27

Rangi
Member
Registered: 2016-05-09
Post 315/870

Re: Pokemon Box/Bank

bloodless wrote:

@Rangi one thought that does occur to me is obviously not every game will have 255+ pokemon, so if someone where to say box a pokemon with index 256 from, for example, red++ but also be using the box in conjunction with Polished Crystal (I believe those two games are planned to match in the end but for the example let's say red++ has more pokemon than PC) I could see that causing all kinds of glitches right there. Would the game ID detection also be a good way to handle that issue? I've never looked into how the first 2 gens recognise each other but I would assume something like that in place would be the way to go?

I mean, you could technically let each game use a completely different data structure, program Box to use a large structure that can handle all their data, and convert the game formats to/from Box's format when trading depending on the game idea. Basically like the Gen 2 Time Capsule, but more powerful.

(Analogy: graphic image formats can be black and white, grayscale, N-bit color, RGB, HSL, etc, but programs like Photoshop convert all of those to an internal format during editing and convert back when saving.)

The primary/secondary structure idea would just make this conversion process less of a headache for Box, and also help with letting the different games trade directly.

The question is which pieces of data should go in a mutually-agreed-on primary structure and which can go in "proprietary"/"private-use" secondary ones; Pokémon IDs seem like a fundamental thing that should go in primary, but that means we should agree to all use 2-byte IDs.

Last edited by Rangi (2016-11-14 00:50:43)


Pokémon Polished Crystal (GitHub) — version 2.2.0 released
Pokémon Red★ and Blue★: Space World Edition (GitHub) — updated August 19!
Polished Map: pokered+pokecrystal map, tileset, and palette editor — version 3.5.1 released!

Offline

#12 2016-11-14 01:05:00

FIQ
Member
Registered: 2016-09-17
Post 19/79

Re: Pokemon Box/Bank

I ended up making this proposal for Polished Crystal, but I think 0x00-0x1F would make for a good starting point as "primary" structure:

0x00:2 Species
0x02:2 Item
0x04:1 Move extension byte
    bit 7:2 Move1
    bit 5:2 Move2
    bit 3:2 Move3
    bit 1:2 Move4
0x05:1 Move1
0x06:1 Move2
0x07:1 Move3
0x08:1 Move4
0x09:2 ID
0x0B:3 EXP
0x0E:1 HP  EV
0x0F:1 Atk EV
0x10:1 Def EV
0x11:1 Spe EV
0x12:1 SpA EV
0x13:1 SpD EV
0x14:1 HP +Atk DV
0x15:1 Def+Spe DV
0x16:1 SpA+SpD DV
0x17:2 Personality
    bit 15:1 Shiny
    bit 14:2 Ability
    bit 12:5 Nature
    bit  7:1 IsEgg
    bit  6:2 Gender
    bit  4:5 Form data
0x19:1 PP Up data
0x1A:1 Happiness/Egg cycles
0x1B:1 Pokérus
0x1C:1 Caught data
    bit 7:2 Time
    bit 5:1 OT Gender
    bit 4:5 Ball
0x1D:1 Caught level
0x1E:1 Caught location
0x1F:1 Level

I think the only big thing this is missing that would be desirable in a primary struct is 5bit IVs. Some work-arounds:
* Make capture data "secondary"
* Make Species + Item byte 2 reuse the same byte with lower 4 for one of them and upper 4 for the other
* Make EXP part of the Party struct

Last edited by FIQ (2016-11-14 08:34:38)

Offline

#13 2016-11-14 02:49:52

Mmmmmm
Member
From: West Virginia
Registered: 2015-05-17
Post 160/261

Re: Pokemon Box/Bank

I think making moves 2 bytes would be a higher priority than making items 2 bytes, but then you'd have to remove some other things to make it fit.

Offline

#14 2016-11-14 08:30:10

FIQ
Member
Registered: 2016-09-17
Post 20/79

Re: Pokemon Box/Bank

Mmmmmm wrote:

I think making moves 2 bytes would be a higher priority than making items 2 bytes, but then you'd have to remove some other things to make it fit.

For moves in particular, I think it's better to use a single byte for all 4 moves' "second byte". This gives you 1022 move slots (excluding move index 0x000 and 0x.3FF). While this complicates implementation slightly, it means you avoid using up *three* aditional bytes just for moves where you only use the 2 lowest significant bits anyway. That is the "move extension byte" in my proposal.

Offline

#15 2016-11-17 13:45:13

Rangi
Member
Registered: 2016-05-09
Post 334/870

Re: Pokemon Box/Bank

To free up a byte for the five-bit IVs, the second bytes of the species and item could be combined. This gives you 4,078 Pokémon and 4,078 items.

0x00:1 Species
0x01:1 Species+item extension byte
    bit 7:4 Species
    bit 3:4 Item
0x02:1 Item
0x03:1 Move extension byte
    bit 7:2 Move1
    bit 5:2 Move2
    bit 3:2 Move3
    bit 1:2 Move4
0x04:1 Move1
0x05:1 Move2
0x06:1 Move3
0x07:1 Move4
0x08:2 ID
0x0A:3 EXP
0x0D:1 HP  EV
0x0E:1 Atk EV
0x0F:1 Def EV
0x10:1 Spe EV
0x11:1 SpA EV
0x12:1 SpD EV
0x13:4 IVs
    bit 32:5 HP IV
    bit 27:5 Atk IV
    bit 22:5 Def IV
    bit 17:5 Spe IV
    bit 12:5 SpA IV
    bit  7:5 SpD IV
    bit  2:3 unused
0x17:2 Personality
    bit 15:1 Shiny
    bit 14:2 Ability
    bit 12:5 Nature
    bit  7:1 IsEgg
    bit  6:2 Gender
    bit  4:5 Form data
0x19:1 PP Up data
0x1A:1 Happiness/Egg cycles
0x1B:1 Pokérus
0x1C:1 Caught data
    bit 7:2 Time
    bit 5:1 OT Gender
    bit 4:5 Ball
0x1D:1 Caught level
0x1E:1 Caught location
0x1F:1 Level

This box_struct structure freed up three bytes by only storing PP Up data, not actual PP counts. Those could be moved to party_struct like this:

0x00:1 Status
0x01:1 Move1 PP
0x02:1 Move2 PP
0x03:1 Move3 PP
0x04:1 Move4 PP
0x05:2 HP
0x07:2 MaxHP
0x09:2 Atk
0x0B:2 Def
0x0D:2 Spe
0x0F:2 SpA
0x11:2 SpD

That keeps box_struct the same size (32 bytes) adds 3 bytes to the party_struct's size (32+19 instead of 32+16), but there appear to be enough unused bytes in wram.asm that this wouldn't be a problem. If space is really an issue the PP can be packed into three bytes: 24 bits, 6 bits per move, max 64 PP per move.

The only required feature with this structure is replacing 2-byte stat experience with 1-byte EVs (which also means that Pokémon base data will have to replace some unused bytes with EV gain amounts). Any game that doesn't implement abilities, natures, >255 IDs, etc can ignore those bytes.

Last edited by Rangi (2016-11-17 14:00:42)


Pokémon Polished Crystal (GitHub) — version 2.2.0 released
Pokémon Red★ and Blue★: Space World Edition (GitHub) — updated August 19!
Polished Map: pokered+pokecrystal map, tileset, and palette editor — version 3.5.1 released!

Offline

#16 2016-11-17 18:43:13

FIQ
Member
Registered: 2016-09-17
Post 25/79

Re: Pokemon Box/Bank

How about this?

0x00:1 Species+Item extension byte
    bit 7:4 Species
    bit 3:4 Item
0x01:1 Species
0x02:1 Item
0x03:1 Move extension byte
    bit 7:2 Move1
    bit 5:2 Move2
    bit 3:2 Move3
    bit 1:2 Move4
0x04:1 Move1
0x05:1 Move2
0x06:1 Move3
0x07:1 Move4
0x08:2 ID
0x0A:3 EXP
0x0D:1 HP  EV
0x0E:1 Atk EV
0x0F:1 Def EV
0x10:1 Spe EV
0x11:1 SpA EV
0x12:1 SpD EV
0x13:4 IVs
    bit 31:1 Nicknamed
    bit 30:1 Is an Egg
    bit 29:5 SpD IV
    bit 24:5 SpA IV
    bit 19:5 Spe IV
    bit 14:5 Def IV
    bit  9:5 Atk IV
    bit  4:5 HP  IV
0x17:2 Personality
    bit 15:1 Shiny
    bit 14:2 Ability
    bit 12:5 Nature
    bit  7:1 Unused
    bit  6:2 Gender
    bit  4:5 Form data
0x19:1 PP Up data
0x1A:1 Happiness/Egg cycles
0x1B:1 Pokérus
0x1C:1 Caught data
    bit 7:2 Time
    bit 5:1 OT Gender
    bit 4:5 Ball
0x1D:1 Caught level (0 means hatched from Egg)
0x1E:1 Caught location
0x1F:1 Level

I think this is a minor improvement. I tweaked IV and PV storage. Mostly to make IVs have the same structure as in Generation IV (no pun intended) and onwards, to reduce potential for confusion. I also made the "extension byte" be stored before both Species and Item to be more consistent with how moves are handled.

Last edited by FIQ (2016-11-17 18:54:45)

Offline

#17 2016-11-17 18:47:56

Mmmmmm
Member
From: West Virginia
Registered: 2015-05-17
Post 172/261

Re: Pokemon Box/Bank

Using a bit to signal that something is nicknamed seems silly for a hack on the Game Boy. The reason they have that in Gen IV and beyond is because you can trade between multiple languages, but to my knowledge attempting that in Gen 1 and 2 can supremely break your game and possibly corrupt your save data, due to not every character of every language being in the game for space-saving reasons. I suppose you could use it for hacks that have multiple European-language translations, but it still seems silly.

Offline

#18 2016-11-17 18:51:10

FIQ
Member
Registered: 2016-09-17
Post 26/79

Re: Pokemon Box/Bank

Mmmmmm wrote:

Using a bit to signal that something is nicknamed seems silly for a hack on the Game Boy. The reason they have that in Gen IV and beyond is because you can trade between multiple languages, but to my knowledge attempting that in Gen 1 and 2 can supremely break your game and possibly corrupt your save data, due to not every character of every language being in the game for space-saving reasons. I suppose you could use it for hacks that have multiple European-language translations, but it still seems silly.

Well, the alternative would mean to have the bit be unused outright (Having Ability be stored there like in III would make handling hidden ones awkward), so I figured there was no harm in including it, just in case someone does find an use for it. After all, I have seen non-English hacks before.

Last edited by FIQ (2016-11-17 18:53:25)

Offline

#19 2016-11-17 19:15:01

Rangi
Member
Registered: 2016-05-09
Post 338/870

Re: Pokemon Box/Bank

Since the Gen 2 implementation of nicknames doesn't need a bit in the box_struct, it could just be left unused i.e. implementation-defined. Maybe use it to toggle which of two Egg sprites gets shown; or use it as a "fateful encounter" flag for distribution codes; or use it as a "permanently fainted" flag for Nuzlocke runs (since depositing a Pokémon heals its HP, PP, and status condition, with all of those items kept in the party_struct).

Features from official structures that are still missing:

• Any Pokémon can have any ability, even though wild Pokémon abilities are initially chosen from two or three valid ones (replace 2 bit ability index with 1 byte ability ID)
• Contest stats: Cool, Beauty, Cute, Smart, Tough (5 bytes)
• PC markings: circle, triangle, square, heart, star, diamond (6 bits)
• Hyper Training (6 bits) (if a bit is set for a stat, that stat is calculated as if it had a perfect IV, although Hidden Power and breeding still use the real IV)
• Ribbons (1 bit per ribbon)
• Fateful encounter (1 bit)
• Shiny Leaves (5 bits) and Leaf Crown (1 bit)

Contest stats take up a lot of space and would require a whole new minigame implementation, with effects for every move, and AFAIK nobody is planning to do that. On the other hand, storing a whole ability ID would be more flexible than a base-data-lookup-index; and a Hyper Training byte would also be useful. How feasible is it to make the box_struct a few bytes bigger?

Edit: Also, if this gets to the point where there's a collaboratively-edited pokecrystal fork which implements the new data structure as a ROM base for actual games to be built upon, what other semi-essential feature should go in it? Suggestions:

• Fix Gen 2's bugs and glitches
• Up-to-date Pokémon stats, move attributes, and item attributes
• Fairy type
• New evolution methods (location, knowing a move, etc)
• Physical/Special split (share moves' type byte)
• Remove the code for Mystery Gift, GameBoy Printer, and Mobile Adapter (I've done this for Polished Crystal; the Mobile Adapter code in particular was wasting a lot of space)

(I see the Fairy type and Physical/Special split as essential because they're the reason for certain new Pokémon and moves being added at all. There's no point extending the Pokémon table to fit Sylveon if it's not Fairy-type; there's no point extending the move table to fit Giga Impact if it's not distinguished from Hyper Beam; and so on.)

Last edited by Rangi (2016-11-17 19:27:13)


Pokémon Polished Crystal (GitHub) — version 2.2.0 released
Pokémon Red★ and Blue★: Space World Edition (GitHub) — updated August 19!
Polished Map: pokered+pokecrystal map, tileset, and palette editor — version 3.5.1 released!

Offline

#20 2016-11-17 19:21:11

FIQ
Member
Registered: 2016-09-17
Post 28/79

Re: Pokemon Box/Bank

It is worth pointing out that the GSC box struct (not sure with the RBY one) has 4-6 redundant bytes: species (1 byte) and 3 Trainer name string termination bytes (Trainer names can only be 7 characters, but there is space for 10 + terminator). You could also -- allthough this complicates logic -- also get rid of 2 additional string terminator bytes (one for Pokémon nickname and one for Trainer name) if you add one yourself when displaying their names. Species is technically not entirely redundant since it's used when figuring out what to make an Egg into, but with the IsEgg bit, this is entirely redundant.

Rangi wrote:

Since the Gen 2 implementation of nicknames doesn't need a bit in the box_struct, it could just be left unused i.e. implementation-defined. Maybe use it to toggle which of two Egg sprites gets shown; or use it as a "fateful encounter" flag for distribution codes; or use it as a "permanently fainted" flag for Nuzlocke runs (since depositing a Pokémon heals its HP, PP, and status condition, with all of those items kept in the party_struct).

Features from official structures that are still missing:

• Any Pokémon can have any ability, even though wild Pokémon abilities are initially chosen from two or three valid ones (replace 2 bit ability index with 1 byte ability ID)
• Contest stats: Cool, Beauty, Cute, Smart, Tough (5 bytes)
• PC markings: circle, triangle, square, heart, star, diamond (6 bits)
• Hyper Training (6 bits) (if a bit is set for a stat, that stat is calculated as if it had a perfect IV, although Hidden Power and breeding still use the real IV)
• Ribbons (1 bit per ribbon)
• Fateful encounter (1 bit)
• Shiny Leaves (5 bits) and Leaf Crown (1 bit)

For Fateful encounter, I'd personally reserve location ID 255 for it.

Ability index is something I'd store in the party struct, not the box struct.

Last edited by FIQ (2016-11-17 19:27:40)

Offline

Board footer

Powered by FluxBB