Options for substat breakdown and roll quality

[FichteFoll]

I generally always enable these two options when sharing an enka card because they provide a lot more insight at a glance than just the numbers of each substat.

According to the readme, there is currently no way to enable these for the embedded card.

[LumiFae]

This is true, we have no implementation for this due to how enka works. Also sorry for the late response, apparently I don't get messages about stuff being said here. I will work on a method to allow this to happen and maybe also include the option on my latest project enka.discord.

Will get back to this asap!

[FichteFoll]

2 days is a perfectly fine response time. Don't stress yourself. 😉

[LumiFae]

I like to respond within 5 minutes usually unless you catch me when driving or sleeping haha

[LumiFae]

Ok so I've had a thought. How enka.cards work is specifically that every image is cached for 24 hours after it is generated from enka itself, this is to stop constant hits to enka.network whenever cards is hit (which for some reason is a lot). Right now we do have the option to switch language which ignores the cache and re-caches but in that language but if we were to include 2 options to change the image further, that means more requests to enka and more caching, storage ain't the issue though but the total load on enka could be a lot and gives people multiple ways to overload enka and me with requests, and cloudflare will just block my IP address if I send too many hits which is not what I want. If I can figure out a method in the future for fixing something like this, I will, but for right now, I probably won't implement this until the future.

[FichteFoll]

I don't really follow your argument.

First of all, you mention that enka.cards caches the generated cards (which makes sense), but then you mention that each request with special options would cause further cards to be generated, which I don't agree with. If I'm sharing a card for my account with my chosen options (substat breakdown, roll quality, english language) then that should still only cause one card to be generated and cached for each URL, not num languages * 2 * 2.

Secondly, you mentioned a DoS type attack, which I also don't really agree with because

1. you can implement a rate limit on the enka.network side on a cache miss
2. if someone wanted to attack enka.cards, I'm positive they could already do it with various different fabricated accounts/UIDs regardless of whether they exist and regardless of whether there are multiple variants for each card. Unless you somehow have a way to verify the validity of a request before forwarding it to enka.network.
3. And finally, you could add a rate limit per account if that is still a concern.

[LumiFae]

You have a valid point. I'll reopen this but it probably won't be done next week unless I get some serious motivation. I'll also include some sort of check to see if there is 3 cached responses and if there is, it won't fetch enka even if it's different and I think that would be good, or maybe if I think of another one when I am more awake.