Using variant forms for different species

[Rangi42]

Considering how feasible this would be, and which engine features still rely on one-byte Pokémon IDs with no awareness of variant forms.

• cries: would complicate OBJECTTYPE_POKEMON; maybe treat that one specially as a high bit mask along with the form? and still use a jumptable for the rest
• names: GetPokemonName is called in many places, including pokenamemem
• Pokédex entries: also complicated by some forms not needing their own entries, like variant Magikarps
• maybe others

[FredrIQ]

The form byte already has a bit whose purpose is to give a different set of 254 mons (for a total of 508). Why reuse the form bits for it? It's even part of the same byte.

The byte also includes gender, for similar reasons, although Polished does not have gender differences in sprites.

[Rangi42]

There are already tables and routines that take the form into account, and I've thought before about giving Alolan/Galarian forms their own Pokédex entries, so I was just considering what features are still limited to a species byte. All of these would also need dealing with if we use the 9th species bit too. Of course the advantage of the 9th bit is making species and form independent. Overall it doesn't look like there's a cheap hacky solution to adding extra species, but I might at least add form support to pokepic and loadwildmon. (Also curious if there's any major thing left besides cries, names, and dex entries that isn't yet listed.)

[FredrIQ]

I've started tentatively implementing 9bit on a branch. This is what I have in mind for implementation:

• Use the unused extspecies bit (currently IsDead in master) to refer to a second "bank" of species
• Implement a 3rd set of variant "forms" as a supergroup of the 2 other tables, for specifying even more differences (names, for instance).
• In various tables that currently specify a species (grass, trainers, etc), create a new parameter format, "dp", which takes 1-2 arguments. Argument 1 is a 9bit species. This is converted into a 8bit species byte and a byte with the extspecies bit set if the species is >255 (unset if species <=255). The 2nd argument is optional and also allows specifying form. This allows us to also make form 0 mean "form not specified", i.e. for wild encounters that should allow a random form such as Magikarps or cases like Unown which needs special handling.
• The new format could be combined as necessary with regular bytes. For example, grass encounters, instead of being in the format "db 5, RATTATA", it is "dbp 5, AMBIPOM" or "dbp 5, VULPIX, ALOLAN_FORM".

The first 2 parts are easy enough to add, what takes time is to change various places in the source that currently only specifies a 8bit species, into handling a 9bit one, such as wild encounters, trainers, etc. Trainers actually take a form byte already, but while you could for example claim that a trainer uses a Bulbasaur and then manually set the extspecies flag as part of a pokémon's form for species $100, it would be clearer if it took a dp-format argument.

Does this seem sensible? Or is there a better way of doing it?

[Rangi42]

I'd call it mon_id, like map_id being 2 bytes for the group+map, but otherwise that sounds okay. You could refer to pokecrystal16 for the things which would need updating that PC didn't add itself.

[FredrIQ]

The reason I wanted to add it as a "a/b/w"-style datatype is because it's very common to combine pokémon with other stuff. For example, wildmons care about level, BT cares about items, and so on. I think this:

db 10 ; level
mon_id DITTO
db 10
mon_id ABRA
db 10
mon_id MUDKIP
db 10
mon_id VULPIX, ALOLAN_FORM
...

would be less readable than this:

dbp 10, DITTO
dbp 10, ABRA
dbp 10, MUDKIP
dbp 10, VULPIX, ALOLAN_FORM

But maybe you disagree? I think the ideal here would be a PKM(x) macro or similar, but I don't think you can create those.

[Rangi42]

Sure, dbp then.

[itsdarsh]

This issue will be resolved as part of 9bit.