canyon/ranking/solo/player/playername problem

[sylario]

I work directly with the web service without using the PHP library.
When i ask for a player in multi (canyon/ranking/multi/player/sylario/) i have the following data in the field ranks :

World
34739
World|France
7971
World|France|Provence-Alpes-Côte d'Azur
576
World|France|Provence-Alpes-Côte d'Azur|Alpes-Maritimes
132

But for solo (canyon/ranking/solo/player/sylario/) i only have the following data:

World
5251

Without the ranking for each subzone.

Is it a bug, or does it work as intended ?

[gouxim]

It's the the intended behaviour ; internaly, our database has less details for the Solo Rankings than it has for the Multi Rankings

[sylario]

:/ Ok, thanks for the info.

[Xymph]

It's the the intended behaviour ; internaly, our database has less details for the Solo Rankings than it has for the Multi Rankings

Strange... does that mean the database used by the API is separate from the one used by the game client?
As observed before, the client shows Solo rankings for subzones, so why can't those be made available via the API too? Will they be added later?

[gouxim]

We use the same DB on the API (or, to be precise, an aggregate/replica of the master server's DBs).

There are less information in the DB for Solo rankings than for Multi rankings. The MP client displays solo rankings info for subzones from a extrapolation calculated from data from archives downloaded by the client.

Given the complexity, it's not reasonable to implement that on API, so it will unfortunately have to remain a limitation of the API for now.

[Xymph]

We use the same DB on the API (or, to be precise, an aggregate/replica of the master server's DBs).

That's what I expected indeed.

There are less information in the DB for Solo rankings than for Multi rankings. The MP client displays solo rankings info for subzones from a extrapolation calculated from data from archives downloaded by the client.

Given the complexity, it's not reasonable to implement that on API, so it will unfortunately have to remain a limitation of the API for now.

Ahh, now I understand. Thanks for the explanation.

Still, it's a pity for the API.