Construct "order" for forms from Pokédex No. & form index by SnorlaxMonster · Pull Request #1571 · PokeAPI/pokeapi

SnorlaxMonster · 2026-06-25T16:14:24Z

Change description

Addresses #1569. This constructs the order column of pokemon_forms.csv by concatenating a three-digit form number with the Pokédex number. This should facilitate inserting new forms in the future, without needing to reorder every subsequent Pokémon.

Note that because I wanted the base forms to be form ID 0, I have also shifted all of the form_order values by -1. Additionally, some of the form_order values also weren't unique previously, so those have been modified to be unique.

AI coding assistance disclosure

No AI used.

Contributor check list

I have written a description of the contribution and explained its motivation.
[N/A] I have written tests for my code changes (if applicable).
I have read and understood the AI Assisted Contribution guidelines.
I will own this change in production, and I am prepared to fix any bugs caused by my code change.

jemarq04 · 2026-07-01T17:59:30Z

This is great! Did you do this with a script? If so, it would be great to have this in the API when new forms are added. You can add it into Resources/scripts/data.

Naramsim · 2026-07-02T08:05:21Z

-10552,frillish-female,female,592,11,0,0,0,2,794
-10553,jellicent-female,female,593,11,0,0,0,2,795
-10554,meowstic-female-mega,mega-female,10326,31,1,1,1,4,984
+1,bulbasaur,,1,28,1,0,0,0,1000


Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
I also don't like the order starting at 1000, it's seems like a sort of a quick hack. If this is done by a script maybe we could simply keep the order as it is now and run the script each time we update this file, what do you think about it?
Secondly, if this is done by a script we could even integrate it in the build logic and have the order column created at build-time. This is of course more difficult to implement and needs some code knowledge.
I'm not entirely opposed to the 1000 id system I'd just want to express my ideas.
My bad for not having participated to the #1569 issue.

This was originally brought up in a different PR (#1532) by the author:
(IMO, this would be better handled similarly to what Champions does internally, where they just allocate the last 3 digits to the form ID and the first 4 to the National Pokédex number, so that inserting a new form doesn't require incrementing all of the others; e.g. Mega Venusaur is 0006001. However, changing that structure would belong in a separate PR, so I've just stuck to what is already there.)
Of course, I think we can make use of some nice scripts to do it for us in any format we'd like, so it really goes to preference.
This is something that Champions implemented, and personally I think it's more readable and easier to maintain manually. A script could be used to help maintain it, but if a new Mega Bibarel were introduced tomorrow we could simply go in and say "easy, that's order 400001 for national pokedex number 400 and form 001" without having to run a script.
I do like the idea of doing it at build-time as well, avoiding the need to write them manually into the CSV file. Whichever format we choose this would be a nice next step.

Having the order be generated at build time, rather than specified in the input CSV files, sounds like a good idea. Although it's a much more involved change than in this PR.
Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
Are you trying to say that you would prefer that form_order starts from 1 instead of 0? I had deliberately changed it to be 0-indexed so that the default forms were all form 0 (and thus Bulbasaur is 0001000, etc.), which aligns with the internal numbering of Champions as well. But I can change it back to being 1-indexed if you prefer. (Especially if order is just generated at build time instead, it doesn't really make much difference whether this field is 0-indexed or 1-index.)

Yes, I don't think we need to support pokemon champions ordering system. I'd prefer to keep consistency across the API. So let's revert back to 1-index.
Can you investigate a bit if it's feasible building the order at runtime? If it's relatively easy we can go that way. If not, I would like the order to be subsequent as it is now. I don't know if your script is easy to modify in this regard. Last option is to have big spaced numbers.

Hey @SnorlaxMonster are you still there? Sorry for the ping

SnorlaxMonster · 2026-06-25T16:14:24Z

Change description

Addresses #1569. This constructs the order column of pokemon_forms.csv by concatenating a three-digit form number with the Pokédex number. This should facilitate inserting new forms in the future, without needing to reorder every subsequent Pokémon.

Note that because I wanted the base forms to be form ID 0, I have also shifted all of the form_order values by -1. Additionally, some of the form_order values also weren't unique previously, so those have been modified to be unique.

AI coding assistance disclosure

No AI used.

Contributor check list

I have written a description of the contribution and explained its motivation.
[N/A] I have written tests for my code changes (if applicable).
I have read and understood the AI Assisted Contribution guidelines.
I will own this change in production, and I am prepared to fix any bugs caused by my code change.

jemarq04 · 2026-07-01T17:59:30Z

This is great! Did you do this with a script? If so, it would be great to have this in the API when new forms are added. You can add it into Resources/scripts/data.

Naramsim · 2026-07-02T08:05:21Z

-10552,frillish-female,female,592,11,0,0,0,2,794
-10553,jellicent-female,female,593,11,0,0,0,2,795
-10554,meowstic-female-mega,mega-female,10326,31,1,1,1,4,984
+1,bulbasaur,,1,28,1,0,0,0,1000


Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
I also don't like the order starting at 1000, it's seems like a sort of a quick hack. If this is done by a script maybe we could simply keep the order as it is now and run the script each time we update this file, what do you think about it?
Secondly, if this is done by a script we could even integrate it in the build logic and have the order column created at build-time. This is of course more difficult to implement and needs some code knowledge.
I'm not entirely opposed to the 1000 id system I'd just want to express my ideas.
My bad for not having participated to the #1569 issue.

This was originally brought up in a different PR (#1532) by the author:
(IMO, this would be better handled similarly to what Champions does internally, where they just allocate the last 3 digits to the form ID and the first 4 to the National Pokédex number, so that inserting a new form doesn't require incrementing all of the others; e.g. Mega Venusaur is 0006001. However, changing that structure would belong in a separate PR, so I've just stuck to what is already there.)
Of course, I think we can make use of some nice scripts to do it for us in any format we'd like, so it really goes to preference.
This is something that Champions implemented, and personally I think it's more readable and easier to maintain manually. A script could be used to help maintain it, but if a new Mega Bibarel were introduced tomorrow we could simply go in and say "easy, that's order 400001 for national pokedex number 400 and form 001" without having to run a script.
I do like the idea of doing it at build-time as well, avoiding the need to write them manually into the CSV file. Whichever format we choose this would be a nice next step.

Having the order be generated at build time, rather than specified in the input CSV files, sounds like a good idea. Although it's a much more involved change than in this PR.
Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
Are you trying to say that you would prefer that form_order starts from 1 instead of 0? I had deliberately changed it to be 0-indexed so that the default forms were all form 0 (and thus Bulbasaur is 0001000, etc.), which aligns with the internal numbering of Champions as well. But I can change it back to being 1-indexed if you prefer. (Especially if order is just generated at build time instead, it doesn't really make much difference whether this field is 0-indexed or 1-index.)

Yes, I don't think we need to support pokemon champions ordering system. I'd prefer to keep consistency across the API. So let's revert back to 1-index.
Can you investigate a bit if it's feasible building the order at runtime? If it's relatively easy we can go that way. If not, I would like the order to be subsequent as it is now. I don't know if your script is easy to modify in this regard. Last option is to have big spaced numbers.

Hey @SnorlaxMonster are you still there? Sorry for the ping

SnorlaxMonster · 2026-06-25T16:14:24Z

Change description

Addresses #1569. This constructs the order column of pokemon_forms.csv by concatenating a three-digit form number with the Pokédex number. This should facilitate inserting new forms in the future, without needing to reorder every subsequent Pokémon.

Note that because I wanted the base forms to be form ID 0, I have also shifted all of the form_order values by -1. Additionally, some of the form_order values also weren't unique previously, so those have been modified to be unique.

AI coding assistance disclosure

No AI used.

Contributor check list

I have written a description of the contribution and explained its motivation.
[N/A] I have written tests for my code changes (if applicable).
I have read and understood the AI Assisted Contribution guidelines.
I will own this change in production, and I am prepared to fix any bugs caused by my code change.

jemarq04 · 2026-07-01T17:59:30Z

This is great! Did you do this with a script? If so, it would be great to have this in the API when new forms are added. You can add it into Resources/scripts/data.

Naramsim · 2026-07-02T08:05:21Z

-10552,frillish-female,female,592,11,0,0,0,2,794
-10553,jellicent-female,female,593,11,0,0,0,2,795
-10554,meowstic-female-mega,mega-female,10326,31,1,1,1,4,984
+1,bulbasaur,,1,28,1,0,0,0,1000


Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
I also don't like the order starting at 1000, it's seems like a sort of a quick hack. If this is done by a script maybe we could simply keep the order as it is now and run the script each time we update this file, what do you think about it?
Secondly, if this is done by a script we could even integrate it in the build logic and have the order column created at build-time. This is of course more difficult to implement and needs some code knowledge.
I'm not entirely opposed to the 1000 id system I'd just want to express my ideas.
My bad for not having participated to the #1569 issue.

This was originally brought up in a different PR (#1532) by the author:
(IMO, this would be better handled similarly to what Champions does internally, where they just allocate the last 3 digits to the form ID and the first 4 to the National Pokédex number, so that inserting a new form doesn't require incrementing all of the others; e.g. Mega Venusaur is 0006001. However, changing that structure would belong in a separate PR, so I've just stuck to what is already there.)
Of course, I think we can make use of some nice scripts to do it for us in any format we'd like, so it really goes to preference.
This is something that Champions implemented, and personally I think it's more readable and easier to maintain manually. A script could be used to help maintain it, but if a new Mega Bibarel were introduced tomorrow we could simply go in and say "easy, that's order 400001 for national pokedex number 400 and form 001" without having to run a script.
I do like the idea of doing it at build-time as well, avoiding the need to write them manually into the CSV file. Whichever format we choose this would be a nice next step.

Having the order be generated at build time, rather than specified in the input CSV files, sounds like a good idea. Although it's a much more involved change than in this PR.
Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
Are you trying to say that you would prefer that form_order starts from 1 instead of 0? I had deliberately changed it to be 0-indexed so that the default forms were all form 0 (and thus Bulbasaur is 0001000, etc.), which aligns with the internal numbering of Champions as well. But I can change it back to being 1-indexed if you prefer. (Especially if order is just generated at build time instead, it doesn't really make much difference whether this field is 0-indexed or 1-index.)

Yes, I don't think we need to support pokemon champions ordering system. I'd prefer to keep consistency across the API. So let's revert back to 1-index.
Can you investigate a bit if it's feasible building the order at runtime? If it's relatively easy we can go that way. If not, I would like the order to be subsequent as it is now. I don't know if your script is easy to modify in this regard. Last option is to have big spaced numbers.

Hey @SnorlaxMonster are you still there? Sorry for the ping

SnorlaxMonster · 2026-06-25T16:14:24Z

Change description

Addresses #1569. This constructs the order column of pokemon_forms.csv by concatenating a three-digit form number with the Pokédex number. This should facilitate inserting new forms in the future, without needing to reorder every subsequent Pokémon.

Note that because I wanted the base forms to be form ID 0, I have also shifted all of the form_order values by -1. Additionally, some of the form_order values also weren't unique previously, so those have been modified to be unique.

AI coding assistance disclosure

No AI used.

Contributor check list

I have written a description of the contribution and explained its motivation.
[N/A] I have written tests for my code changes (if applicable).
I have read and understood the AI Assisted Contribution guidelines.
I will own this change in production, and I am prepared to fix any bugs caused by my code change.

jemarq04 · 2026-07-01T17:59:30Z

This is great! Did you do this with a script? If so, it would be great to have this in the API when new forms are added. You can add it into Resources/scripts/data.

Naramsim · 2026-07-02T08:05:21Z

-10552,frillish-female,female,592,11,0,0,0,2,794
-10553,jellicent-female,female,593,11,0,0,0,2,795
-10554,meowstic-female-mega,mega-female,10326,31,1,1,1,4,984
+1,bulbasaur,,1,28,1,0,0,0,1000


Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
I also don't like the order starting at 1000, it's seems like a sort of a quick hack. If this is done by a script maybe we could simply keep the order as it is now and run the script each time we update this file, what do you think about it?
Secondly, if this is done by a script we could even integrate it in the build logic and have the order column created at build-time. This is of course more difficult to implement and needs some code knowledge.
I'm not entirely opposed to the 1000 id system I'd just want to express my ideas.
My bad for not having participated to the #1569 issue.

This was originally brought up in a different PR (#1532) by the author:
(IMO, this would be better handled similarly to what Champions does internally, where they just allocate the last 3 digits to the form ID and the first 4 to the National Pokédex number, so that inserting a new form doesn't require incrementing all of the others; e.g. Mega Venusaur is 0006001. However, changing that structure would belong in a separate PR, so I've just stuck to what is already there.)
Of course, I think we can make use of some nice scripts to do it for us in any format we'd like, so it really goes to preference.
This is something that Champions implemented, and personally I think it's more readable and easier to maintain manually. A script could be used to help maintain it, but if a new Mega Bibarel were introduced tomorrow we could simply go in and say "easy, that's order 400001 for national pokedex number 400 and form 001" without having to run a script.
I do like the idea of doing it at build-time as well, avoiding the need to write them manually into the CSV file. Whichever format we choose this would be a nice next step.

Having the order be generated at build time, rather than specified in the input CSV files, sounds like a good idea. Although it's a much more involved change than in this PR.
Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
Are you trying to say that you would prefer that form_order starts from 1 instead of 0? I had deliberately changed it to be 0-indexed so that the default forms were all form 0 (and thus Bulbasaur is 0001000, etc.), which aligns with the internal numbering of Champions as well. But I can change it back to being 1-indexed if you prefer. (Especially if order is just generated at build time instead, it doesn't really make much difference whether this field is 0-indexed or 1-index.)

Yes, I don't think we need to support pokemon champions ordering system. I'd prefer to keep consistency across the API. So let's revert back to 1-index.
Can you investigate a bit if it's feasible building the order at runtime? If it's relatively easy we can go that way. If not, I would like the order to be subsequent as it is now. I don't know if your script is easy to modify in this regard. Last option is to have big spaced numbers.

Hey @SnorlaxMonster are you still there? Sorry for the ping

SnorlaxMonster · 2026-06-25T16:14:24Z

Change description

Addresses #1569. This constructs the order column of pokemon_forms.csv by concatenating a three-digit form number with the Pokédex number. This should facilitate inserting new forms in the future, without needing to reorder every subsequent Pokémon.

Note that because I wanted the base forms to be form ID 0, I have also shifted all of the form_order values by -1. Additionally, some of the form_order values also weren't unique previously, so those have been modified to be unique.

AI coding assistance disclosure

No AI used.

Contributor check list

I have written a description of the contribution and explained its motivation.
[N/A] I have written tests for my code changes (if applicable).
I have read and understood the AI Assisted Contribution guidelines.
I will own this change in production, and I am prepared to fix any bugs caused by my code change.

jemarq04 · 2026-07-01T17:59:30Z

This is great! Did you do this with a script? If so, it would be great to have this in the API when new forms are added. You can add it into Resources/scripts/data.

Naramsim · 2026-07-02T08:05:21Z

-10552,frillish-female,female,592,11,0,0,0,2,794
-10553,jellicent-female,female,593,11,0,0,0,2,795
-10554,meowstic-female-mega,mega-female,10326,31,1,1,1,4,984
+1,bulbasaur,,1,28,1,0,0,0,1000


Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
I also don't like the order starting at 1000, it's seems like a sort of a quick hack. If this is done by a script maybe we could simply keep the order as it is now and run the script each time we update this file, what do you think about it?
Secondly, if this is done by a script we could even integrate it in the build logic and have the order column created at build-time. This is of course more difficult to implement and needs some code knowledge.
I'm not entirely opposed to the 1000 id system I'd just want to express my ideas.
My bad for not having participated to the #1569 issue.

This was originally brought up in a different PR (#1532) by the author:
(IMO, this would be better handled similarly to what Champions does internally, where they just allocate the last 3 digits to the form ID and the first 4 to the National Pokédex number, so that inserting a new form doesn't require incrementing all of the others; e.g. Mega Venusaur is 0006001. However, changing that structure would belong in a separate PR, so I've just stuck to what is already there.)
Of course, I think we can make use of some nice scripts to do it for us in any format we'd like, so it really goes to preference.
This is something that Champions implemented, and personally I think it's more readable and easier to maintain manually. A script could be used to help maintain it, but if a new Mega Bibarel were introduced tomorrow we could simply go in and say "easy, that's order 400001 for national pokedex number 400 and form 001" without having to run a script.
I do like the idea of doing it at build-time as well, avoiding the need to write them manually into the CSV file. Whichever format we choose this would be a nice next step.

Having the order be generated at build time, rather than specified in the input CSV files, sounds like a good idea. Although it's a much more involved change than in this PR.
Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
Are you trying to say that you would prefer that form_order starts from 1 instead of 0? I had deliberately changed it to be 0-indexed so that the default forms were all form 0 (and thus Bulbasaur is 0001000, etc.), which aligns with the internal numbering of Champions as well. But I can change it back to being 1-indexed if you prefer. (Especially if order is just generated at build time instead, it doesn't really make much difference whether this field is 0-indexed or 1-index.)

Yes, I don't think we need to support pokemon champions ordering system. I'd prefer to keep consistency across the API. So let's revert back to 1-index.
Can you investigate a bit if it's feasible building the order at runtime? If it's relatively easy we can go that way. If not, I would like the order to be subsequent as it is now. I don't know if your script is easy to modify in this regard. Last option is to have big spaced numbers.

Hey @SnorlaxMonster are you still there? Sorry for the ping

SnorlaxMonster · 2026-06-25T16:14:24Z

Change description

Addresses #1569. This constructs the order column of pokemon_forms.csv by concatenating a three-digit form number with the Pokédex number. This should facilitate inserting new forms in the future, without needing to reorder every subsequent Pokémon.

Note that because I wanted the base forms to be form ID 0, I have also shifted all of the form_order values by -1. Additionally, some of the form_order values also weren't unique previously, so those have been modified to be unique.

AI coding assistance disclosure

No AI used.

Contributor check list

I have written a description of the contribution and explained its motivation.
[N/A] I have written tests for my code changes (if applicable).
I have read and understood the AI Assisted Contribution guidelines.
I will own this change in production, and I am prepared to fix any bugs caused by my code change.

jemarq04 · 2026-07-01T17:59:30Z

This is great! Did you do this with a script? If so, it would be great to have this in the API when new forms are added. You can add it into Resources/scripts/data.

Naramsim · 2026-07-02T08:05:21Z

-10552,frillish-female,female,592,11,0,0,0,2,794
-10553,jellicent-female,female,593,11,0,0,0,2,795
-10554,meowstic-female-mega,mega-female,10326,31,1,1,1,4,984
+1,bulbasaur,,1,28,1,0,0,0,1000


Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
I also don't like the order starting at 1000, it's seems like a sort of a quick hack. If this is done by a script maybe we could simply keep the order as it is now and run the script each time we update this file, what do you think about it?
Secondly, if this is done by a script we could even integrate it in the build logic and have the order column created at build-time. This is of course more difficult to implement and needs some code knowledge.
I'm not entirely opposed to the 1000 id system I'd just want to express my ideas.
My bad for not having participated to the #1569 issue.

This was originally brought up in a different PR (#1532) by the author:
(IMO, this would be better handled similarly to what Champions does internally, where they just allocate the last 3 digits to the form ID and the first 4 to the National Pokédex number, so that inserting a new form doesn't require incrementing all of the others; e.g. Mega Venusaur is 0006001. However, changing that structure would belong in a separate PR, so I've just stuck to what is already there.)
Of course, I think we can make use of some nice scripts to do it for us in any format we'd like, so it really goes to preference.
This is something that Champions implemented, and personally I think it's more readable and easier to maintain manually. A script could be used to help maintain it, but if a new Mega Bibarel were introduced tomorrow we could simply go in and say "easy, that's order 400001 for national pokedex number 400 and form 001" without having to run a script.
I do like the idea of doing it at build-time as well, avoiding the need to write them manually into the CSV file. Whichever format we choose this would be a nice next step.

Having the order be generated at build time, rather than specified in the input CSV files, sounds like a good idea. Although it's a much more involved change than in this PR.
Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
Are you trying to say that you would prefer that form_order starts from 1 instead of 0? I had deliberately changed it to be 0-indexed so that the default forms were all form 0 (and thus Bulbasaur is 0001000, etc.), which aligns with the internal numbering of Champions as well. But I can change it back to being 1-indexed if you prefer. (Especially if order is just generated at build time instead, it doesn't really make much difference whether this field is 0-indexed or 1-index.)

Yes, I don't think we need to support pokemon champions ordering system. I'd prefer to keep consistency across the API. So let's revert back to 1-index.
Can you investigate a bit if it's feasible building the order at runtime? If it's relatively easy we can go that way. If not, I would like the order to be subsequent as it is now. I don't know if your script is easy to modify in this regard. Last option is to have big spaced numbers.

Hey @SnorlaxMonster are you still there? Sorry for the ping

SnorlaxMonster · 2026-06-25T16:14:24Z

Change description

Addresses #1569. This constructs the order column of pokemon_forms.csv by concatenating a three-digit form number with the Pokédex number. This should facilitate inserting new forms in the future, without needing to reorder every subsequent Pokémon.

Note that because I wanted the base forms to be form ID 0, I have also shifted all of the form_order values by -1. Additionally, some of the form_order values also weren't unique previously, so those have been modified to be unique.

AI coding assistance disclosure

No AI used.

Contributor check list

I have written a description of the contribution and explained its motivation.
[N/A] I have written tests for my code changes (if applicable).
I have read and understood the AI Assisted Contribution guidelines.
I will own this change in production, and I am prepared to fix any bugs caused by my code change.

jemarq04 · 2026-07-01T17:59:30Z

This is great! Did you do this with a script? If so, it would be great to have this in the API when new forms are added. You can add it into Resources/scripts/data.

Naramsim · 2026-07-02T08:05:21Z

-10552,frillish-female,female,592,11,0,0,0,2,794
-10553,jellicent-female,female,593,11,0,0,0,2,795
-10554,meowstic-female-mega,mega-female,10326,31,1,1,1,4,984
+1,bulbasaur,,1,28,1,0,0,0,1000


Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
I also don't like the order starting at 1000, it's seems like a sort of a quick hack. If this is done by a script maybe we could simply keep the order as it is now and run the script each time we update this file, what do you think about it?
Secondly, if this is done by a script we could even integrate it in the build logic and have the order column created at build-time. This is of course more difficult to implement and needs some code knowledge.
I'm not entirely opposed to the 1000 id system I'd just want to express my ideas.
My bad for not having participated to the #1569 issue.

This was originally brought up in a different PR (#1532) by the author:
(IMO, this would be better handled similarly to what Champions does internally, where they just allocate the last 3 digits to the form ID and the first 4 to the National Pokédex number, so that inserting a new form doesn't require incrementing all of the others; e.g. Mega Venusaur is 0006001. However, changing that structure would belong in a separate PR, so I've just stuck to what is already there.)
Of course, I think we can make use of some nice scripts to do it for us in any format we'd like, so it really goes to preference.
This is something that Champions implemented, and personally I think it's more readable and easier to maintain manually. A script could be used to help maintain it, but if a new Mega Bibarel were introduced tomorrow we could simply go in and say "easy, that's order 400001 for national pokedex number 400 and form 001" without having to run a script.
I do like the idea of doing it at build-time as well, avoiding the need to write them manually into the CSV file. Whichever format we choose this would be a nice next step.

Having the order be generated at build time, rather than specified in the input CSV files, sounds like a good idea. Although it's a much more involved change than in this PR.
Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
Are you trying to say that you would prefer that form_order starts from 1 instead of 0? I had deliberately changed it to be 0-indexed so that the default forms were all form 0 (and thus Bulbasaur is 0001000, etc.), which aligns with the internal numbering of Champions as well. But I can change it back to being 1-indexed if you prefer. (Especially if order is just generated at build time instead, it doesn't really make much difference whether this field is 0-indexed or 1-index.)

Yes, I don't think we need to support pokemon champions ordering system. I'd prefer to keep consistency across the API. So let's revert back to 1-index.
Can you investigate a bit if it's feasible building the order at runtime? If it's relatively easy we can go that way. If not, I would like the order to be subsequent as it is now. I don't know if your script is easy to modify in this regard. Last option is to have big spaced numbers.

Hey @SnorlaxMonster are you still there? Sorry for the ping

SnorlaxMonster · 2026-06-25T16:14:24Z

Change description

Addresses #1569. This constructs the order column of pokemon_forms.csv by concatenating a three-digit form number with the Pokédex number. This should facilitate inserting new forms in the future, without needing to reorder every subsequent Pokémon.

Note that because I wanted the base forms to be form ID 0, I have also shifted all of the form_order values by -1. Additionally, some of the form_order values also weren't unique previously, so those have been modified to be unique.

AI coding assistance disclosure

No AI used.

Contributor check list

I have written a description of the contribution and explained its motivation.
[N/A] I have written tests for my code changes (if applicable).
I have read and understood the AI Assisted Contribution guidelines.
I will own this change in production, and I am prepared to fix any bugs caused by my code change.

jemarq04 · 2026-07-01T17:59:30Z

This is great! Did you do this with a script? If so, it would be great to have this in the API when new forms are added. You can add it into Resources/scripts/data.

Naramsim · 2026-07-02T08:05:21Z

-10552,frillish-female,female,592,11,0,0,0,2,794
-10553,jellicent-female,female,593,11,0,0,0,2,795
-10554,meowstic-female-mega,mega-female,10326,31,1,1,1,4,984
+1,bulbasaur,,1,28,1,0,0,0,1000


Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
I also don't like the order starting at 1000, it's seems like a sort of a quick hack. If this is done by a script maybe we could simply keep the order as it is now and run the script each time we update this file, what do you think about it?
Secondly, if this is done by a script we could even integrate it in the build logic and have the order column created at build-time. This is of course more difficult to implement and needs some code knowledge.
I'm not entirely opposed to the 1000 id system I'd just want to express my ideas.
My bad for not having participated to the #1569 issue.

This was originally brought up in a different PR (#1532) by the author:
(IMO, this would be better handled similarly to what Champions does internally, where they just allocate the last 3 digits to the form ID and the first 4 to the National Pokédex number, so that inserting a new form doesn't require incrementing all of the others; e.g. Mega Venusaur is 0006001. However, changing that structure would belong in a separate PR, so I've just stuck to what is already there.)
Of course, I think we can make use of some nice scripts to do it for us in any format we'd like, so it really goes to preference.
This is something that Champions implemented, and personally I think it's more readable and easier to maintain manually. A script could be used to help maintain it, but if a new Mega Bibarel were introduced tomorrow we could simply go in and say "easy, that's order 400001 for national pokedex number 400 and form 001" without having to run a script.
I do like the idea of doing it at build-time as well, avoiding the need to write them manually into the CSV file. Whichever format we choose this would be a nice next step.

Having the order be generated at build time, rather than specified in the input CSV files, sounds like a good idea. Although it's a much more involved change than in this PR.
Hi, I saw your comment for the start-at-0 but I think we should leave the order starting from 0. In all the other CSVs we have it so.
Are you trying to say that you would prefer that form_order starts from 1 instead of 0? I had deliberately changed it to be 0-indexed so that the default forms were all form 0 (and thus Bulbasaur is 0001000, etc.), which aligns with the internal numbering of Champions as well. But I can change it back to being 1-indexed if you prefer. (Especially if order is just generated at build time instead, it doesn't really make much difference whether this field is 0-indexed or 1-index.)

Yes, I don't think we need to support pokemon champions ordering system. I'd prefer to keep consistency across the API. So let's revert back to 1-index.
Can you investigate a bit if it's feasible building the order at runtime? If it's relatively easy we can go that way. If not, I would like the order to be subsequent as it is now. I don't know if your script is easy to modify in this regard. Last option is to have big spaced numbers.

Hey @SnorlaxMonster are you still there? Sorry for the ping