Link mega variety to it's respective item

[NicolasCunha]

We should have access for the mega stone required for a given mega variety.

For example, venusaur-mega , we could have a simple field specifying that the venusaurite is required for a Venusaur to mega evolve into a Mega Venusaur.

[FallenDeity]

perhaps we can take advantage of this existing field?

since when encountering a mega venusaur it can only be holding a venusaurite, should be doable with a new record for mega here https://github.com/PokeAPI/pokeapi/blob/master/data/v2/csv/pokemon_items.csv with version id matching the version/gen the mega was introduced in

[jemarq04]

The held_items is specifically for items a wild Pokemon will have during wild battles. If we wanted to do something like this, I think adding a needs_mega_stone field (or something similar) to pokemon_forms.csv would be the right move. Each Mega Pokemon has an entry as a form in the API, and we could have it just under the is_mega boolean.

I like the idea of tying the mega to its item, so we should definitely find a way to add that in!

[FallenDeity]

The held_items is specifically for items a wild Pokemon will have during wild battles. If we wanted to do something like this, I think adding a needs_mega_stone field (or something similar) to pokemon_forms.csv would be the right move. Each Mega Pokemon has an entry as a form in the API, and we could have it just under the is_mega boolean.

I like the idea of tying the mega to its item, so we should definitely find a way to add that in!

perhaps we could extend this idea a bit and add a required_item_present field of sorts in the pokemon form model since other than megas, some other mons too require some held items to change to another form for example giratina altered to origin form needs the griseous orb https://pokeapi.co/api/v2/pokemon-form/10063/ so rather than tying this to megas we can make it a form specific item requirement?

[jemarq04]

That's a good point – maybe trigger_item to match similar requirements in evolution? It would need to be nullable of course since not all forms would require one. Maybe a separate file to be read instead of adding a field to pokemon_forms.csv

[DanielMJansen]

I like the trigger_item idea for Megas and other item-based forms such as Giratina, Arceus, Silvally, and Genesect.

One thing worth keeping in mind is that not all form changes are item-based. For example, Meloetta changes form through Relic Song, while Palafin and Minior (and others) change forms through their abilities.

These cases probably don't need a solution right now, but if we go with a separate file/model rather than a dedicated field in pokemon_forms.csv, it could give us some flexibility if support for other form-changing mechanics is ever needed in the future. Maybe the field could even be called 'form_requirement' or something like that to be more generic rather than specifically an item?

[FallenDeity]

that sounds good yeah we could have something similar to evolution trigger in evolution chain but as form trigger where we could have an enum with different triggers such as items, moves, conditions etc this should serve as more versatile solution

[jemarq04]

One thing worth keeping in mind is that not all form changes are item-based. For example, Meloetta changes form through Relic Song, while Palafin and Minior (and others) change forms through their abilities.

Yes, the item trigger should be a nullable field to consider that.

These cases probably don't need a solution right now, but if we go with a separate file/model rather than a dedicated field in pokemon_forms.csv, it could give us some flexibility if support for other form-changing mechanics is ever needed in the future. Maybe the field could even be called 'form_requirement' or something like that to be more generic rather than specifically an item?

Great point! Those can definitely be additional fields in that file if we go this route.

I’m working on some SWSH encounters at the moment so I don’t have time to work on this just yet, so if anyone wants to give it a try go for it! You can use something like encounter conditions as a basis, I believe.

[dyp1109]

Hi, I'd love to take this on! I plan to add new generic form_methods table for activation types (e.g. items/moves), and linked up with tables like form_condition_items.csv , form_condition_moves.csv etc. to connect to existing items/moves.