Replies: 1 comment 1 reply
-
|
I'd go with Go with 2 or 3 if you have time to spare |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
This is a follow-up on PR #1525 and our discussion to swap the
location_idfield inpokemon_evolution.csvwithlocation_area_id, to hopefully be more descriptive on the locations for the evolution.Unfortunately, digging into this further has shown it's not that simple. If we're doing this to be more descriptive with the "rock" evolutions (e.g. Leafeon with the Mossy Rock), it'll essentially be the same issue as before since we can't accurately describe the condition as "near the rock". Additionally, some evolutions are dependent on the entire location (e.g. Magneton can evolve in any location area within Mt. Coronet). Making an evolution entry for each of these location areas seems excessive.
I propose a few options for how to proceed:
near_special_rock, which would be a boolean set to true only for the relevant evolutions. This would only be needed for Leafeon and Glaceon, as the other location-based evolutions cover the entire location.eterna-forest-near-mossy-rocklocation area purely for the evolution condition. Similarly, we'd need to create a basemt-coronetlocation area (though a 'default' one of course does not exist in-game) which would be pointed to for the relevant evolutions.Any of these options would be reasonable, but each have their drawbacks. I'm torn between option 2 and 3, but I'd like to get some input from others to see what we'd think as far as upkeep and clarity before I make any changes. (I'll ping @notblisy @Naramsim @FreakMediaLP as well.)
Beta Was this translation helpful? Give feedback.
All reactions