/v2/items returning Mastery Points
Invisiplous.6094:
Hi there!
/v2/items is currently returning Mastery Points as consumables. While this may be intended, their names being prepended with a space may not.
Note: The space is always there, no matter the language.
Also it looks like ids 6 and 46748 have been whitelisted prematurely since their names are currently like "((1234))". (1234 being the string id?)
Example: {"name":" Mastery Point","description":"Earn a Mastery poi
IDs I could find: 70497, 70773, 71564, 71567, 71784, 72093, 72455, 73185, 73842, 74128, 74160, 74546, 74577, 74633, 74908, 74910, 75016, 75182, 75964, 76026, 76171, 76206, 76215, 76227, 76426, 76877
Cheers,
~Invisi
Lawton Campbell.8517:
/v2/items is currently returning Mastery Points as consumables. While this may be intended, their names being prepended with a space may not.
Note: The space is always there, no matter the language.
So, mastery points are “Immediate” items which mean they’re consumed right before they’re inserted into your inventory. It’s kind of a weird system, but I hesitate to remove all Immediates from the API because they’ll likely be referenced by other endpoints (e.g., some of them are required by achievements).
Some item names have some context-sensitive parameters that go into them, e.g. the name is probably “{MasteryPointName} Mastery Point”. Since the API is (currently) just enumerating items, it doesn’t have the context to fill in those parameters (e.g., it would need the mastery point reference which points to that particular item; there’s no back-reference) so it just trims it out, which leaves the leading space.
It’s something that should probably be fixed in the long run, but there’s still quite a bit of lower-hanging fruit left :/
Also it looks like ids 6 and 46748 have been whitelisted prematurely since their names are currently like “((1234))”. (1234 being the string id?)
id 6, at least, predates the whitelist system. When we added the whitelist system, we talked internally about removing all of the broken-looking items from the API but the general feeling was that they were already indexed by third-party applications and we didn’t want to risk breaking anything.
46748 was probably a misclick >_>.