character ids

[xannem]

fixes #110
fixes #149

[man90es]

Those ids look like what Mihoyo uses officially. This approach has its advantages but IMO there's a few problems with their numbering system.

• Integers are better than strings because you've got less room for error when adding new JSONs
• Starting at 10000002 instead of 0 serves no purpose, it just introduces complexity and more room for error
• There are gaps in numbering, e.g. 10000004 does not belong to any released character. So if you do something programmaticaly with a for loop then you may need to implement something to handle those gaps
• Travellers of all elements have the same ID, even though in most apps they are treated as different characters
• When adding new characters, we are limited to waiting until Mihoyo exposes their ID instead of adding them immediately after we get to know about them

[xannem]

Good points, I thought about using IDs separate from Mihoyo originally but it felt more potentially confusing to make up a system from scratch - wouldn't that be even more confusing for future users figuring out what ids have and have not been used/which order to implement ids with unreleased characters?

A bit confused about your third point, say if we don't have gaps in numbering so 1 = Albedo 2 = Alhaitham etc. like the current existing folder structure that might make it easier for when writing a for loop if you do like a simple incremental range but you'd still need to know what numbers belonged to each character and the folder structure changes from naming so alphabetical wouldn't make a lot of sense. Wouldn't a new reasoning be even more arbitrary and another thing we'd have to keep track of? I don't think it would be that much trouble to just loop through a list of ids, I'd be open to ideas on a unique system but I thought using Mihoyos would just standardize and make it easier for people to add ids rather than reinventing the wheel.

• Integer instead of string makes sense though and that'd be a simple change
• Yea for travelers since its separated by elements I didn't see that there was a differentiation between Lumine and Aether 10000007 and 10000005 respectively so I just picked the one for Lumine since both protagonists can be canon :D

[man90es]

The question is, how well-known Mihoyo's IDs are? I encountered them while reverse-engineering their website, but does anyone in the community also use them? Do Mihoyo themselves use them consistently across their whole website and in the game itself?

As for reinventing the wheel, I used to have an ID system like this in genshin.hemlo.cc/partybuilder: characters are sorted by release date, and alphabetically for characters that were released simultaneously. I'm not using it anymore for reasons, but that was a rather convenient system if I do say so myself. Here's an example:

Name	Release date	ID
Shikanoin Heizou	2022-07-13	52
Collei	2022-08-24	53
Tighnari	2022-08-24	54
Traveller (Dendro)	2022-08-24	55
Dori	2022-09-09	56

[xannem]

Actually by release date/alphabetically also sounds pretty good to me, people can find that information for characters more quickly (I also got just the Mihoyo IDs through what previous poster had made and from various sources) but release date would be more easily accessible and shouldn't be too hard for users to continue. I'll update PR to have that option sometime, thanks for the idea it does sound convenient :)

[JMPJNS]

if you can find an official source for those IDs they would be a great addition

[man90es]

@JMPJNS if you send a GET request to https://sg-public-api.hoyolab.com/event/simulatoros/config it will return characters with IDs like those in this PR, but they have problems that I outlined earlier

[man90es]

Ignore what I said earlier in this thread, I didn't read the linked issues properly back then. This PR isn't really related to the issues — adding numeric IDs wouldn't have solved them. But they are some kind of in-game data — I believe you can find those IDs in Dimbreath's datamines too, not just Hoyolab API. I'm not sure how valuable it is