Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Species that do not count towards the Pokédex should have a flag in SpeciesInfo instead of using a static array #3932

Closed
pkmnsnfrn opened this issue Jan 5, 2024 · 4 comments · Fixed by #3937
Assignees
Labels
feature-request Requests a new feature
Milestone

Comments

@pkmnsnfrn
Copy link
Collaborator

Description

Context: #3900 (comment)

ideally this would deprecate sRegionalNotCountedList .

Discord contact info

pkmnsnfrn

@pkmnsnfrn pkmnsnfrn added the feature-request Requests a new feature label Jan 5, 2024
@LOuroboros
Copy link
Collaborator

Why add a flag to the Pokemon struct though? Is there a reason not to add it to SpeciesInfo instead?

Space in the Pokemon struct is super valuable imo, and that doesn't really feel like the right place for this anyway because it's not really a flag that you'd apply to each individual Pokémon, but a flag that should encompass the entire species.

@pkmnsnfrn pkmnsnfrn changed the title Species that do not count towards the Pokédex should have a flag in the Pokémon struct instead of using a static array Species that do not count towards the Pokédex should have a flag in SpeciesInfo instead of using a static array Jan 5, 2024
@pkmnsnfrn
Copy link
Collaborator Author

Why add a flag to the Pokemon struct though? Is there a reason not to add it to SpeciesInfo instead?

Space in the Pokemon struct is super valuable imo, and that doesn't really feel like the right place for this anyway because it's not really a flag that you'd apply to each individual Pokémon, but a flag that should encompass the entire species.

I misspoke, you're 100% right

@Bassoonian
Copy link
Collaborator

I'll figure this out tomorrow. Not a bugfix, so I assume that means it'd target upcoming? Or should we just push it to master so it can be in 1.7.2 since it deprecates something not currently in 1.7.1?

@Bassoonian Bassoonian self-assigned this Jan 6, 2024
@AlexOn1ine
Copy link
Collaborator

I'll figure this out tomorrow. Not a bugfix, so I assume that means it'd target upcoming? Or should we just push it to master so it can be in 1.7.2 since it deprecates something not currently in 1.7.1?

I would say master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Requests a new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants