Gen 9

[Someon1e]

accidentally closed #225

fixes #209

TODO

• update pokeapi_db.json- COMPLETED: worked around by using existing files which already contained gen 9 info
• update sprites
• test encounters
• test new starters - this PR implements gen 9 starters and fixes gen 8 starters (off by one error)
• test fossils (none were added, but code relating to fossils was changed so should be tested)
• test trading works with gen 9

[Koconnor03]

Thank you for doing this! There was some db updates I did, maybe one or two files, but there were minimal code changes, maybe just a few lines. You should be able to look through my sprite files to save you time if you haven't done that already. I had every sprite, some that weren't already there. I had the sources updated in the credits if you want to find where I got them. My downfall on my attempt was fixing a ton of bugs without telling anyone and then putting it all into the same pull request. I wish you luck and I can't wait to test this out when I'm done with my travels!

[h0tp-ftw]

sorry for being late, why is there so many changes here? is it out of date? my potato pc couldn't even load differences for me to review 😭

[Someon1e]

sorry for being late, why is there so many changes here? is it out of date? my potato pc couldn't even load differences for me to review 😭

98% of the total code changes (by line count) is from pokedex.json, maybe you could exclude it from diff and view it separately?

Alternatively, you could review in codespace

[Unlucky-Life]

best to delete this file because there already is a new github action building the folder_structure.json

[Someon1e]

Do you mean to delete the file, or remove changes to it from the PR?

[h0tp-ftw]

as the maintainer i'm unsure of how to deal with this and #244 , if i merge one the other would have merge conflicts and/or go out of date by overwriting changes. and so many changes at once in both PRs. what's the best way to approach this?

[Someon1e]

as the maintainer i'm unsure of how to deal with this and #244 , if i merge one the other would have merge conflicts and/or go out of date by overwriting changes. and so many changes at once in both PRs. what's the best way to approach this?

It'll be easier to merge this PR first. #244 modifies a lot more things and should really be split into multiple PRs.

[Unlucky-Life]

We would need zo edit the pr 's first and add back the fallback values - it seemed that me and @h0tp-ftw agrred on this to minimize game breaking issues

[Someon1e]

Just to clarify on the settings fallback values change:

1. The modification from settings_obj.get(name, fallback) to settings_obj.get(name) does not remove the fallback behaviour.
2. Instead, default values are written directly into the settings object (sourced from DEFAULT_CONFIG) upon its initialisation.
3. Importantly, this means that .get() will always be correct as long as the name is inside DEFAULT_CONFIG).

If we revert to the old version:

1. The fallback would have to be provided with every use of .get(). This only moves the point of failure from defining the fallback just once in DEFAULT_CONFIG to instead defining it in every single .get(). Therefore, this would be arguably easier to make a mistake with because a valid value has to be provided in each call.
2. If the default value of a setting needed to be changed, it would require modifying all .get() calls for that setting instead of only once in DEFAULT_CONFIG.

[h0tp-ftw]

I'm at a complete roadblock because of the two big PRs with so many conflicting changes within, I think your implementations are excellently done and just after @Unlucky-Life 's resolutions are considered (as you noted there's major restructures and file changes) it could be good to merge. But this will wreck his PR probably which has a ton of changes in many different files.

I would also try to consolidate all constants to resources.py perhaps/ That is some minor cleanup.

I also realize how badly I have documented our logging features, I will try and implement them and also make some dev guide soon.

This PR will inevitably lead to some things breaking because of how many changes there are, but I feel positive about the implementation.

[h0tp-ftw]

Awaiting Unlucky's changes, but green light from me.

[Unlucky-Life]

@h0tp-ftw From me its fine if we reck my pr - i will need to split up the features anyway and try to read the changes to a new pr and branches each. It just important we hook the functions with fallback values. Currently alot of users anki becomes unusable due to our addon, and i would like that we become more known for a "stable" addon

@Someon1e Please just fix the pr with adding fallback_values for the functions (basically if a value is missing or none_type) and the comments i have added (please comment on them so i know that they have been fixed or how). The functions currently reworked should have a fallback if they break - We need to minimize the bugs at the cost of perhaps missing bugs. But instead log them if the fallback_value is needed to be used. I was not talking about the settings_obj fallback, but instead about the fallback statement in the functions - it would be important to declare these so nothing brakes / Anki is not becoming unusable due to our Addon. Your work is much appreciated !

[h0tp-ftw]

Question @Someon1e i notice a missing_back folder, is that for sprites that do not have a gif available? i noticed some don't have gif available

will try to check on behalf of unlucky and get fixes/merge asap

[Someon1e]

Question @Someon1e i notice a missing_back folder, is that for sprites that do not have a gif available? i noticed some don't have gif available

Yes, it's for sprites that do not have an official GIF version. Although, some new GIFs have already been made since this PR was created - should they be added in this PR now or a future PR?