There are experiences that just count total numbers of badges owned over the entirety of roblox; is there any plans for an api that just gives you the number of badges owned without having to fetch information on every badge you own.
3 Likes
The addition of this API is fine but I feel like it’s just promoting bad practices to developers.
These games should not be using badges as a data system. When you award the badge to a player you should save the badge id in a datastore. This would mean you aren’t making a bunch of UserHasBadgeAsync requests and can load everything in a single request.
For your example, if your game has already shipped to production I would perform the inefficient badge ownership requests and then save the badge ids the player owns to a datastore. Next time they join in you can use the data fetched from the datastore and immediately load the badge ids they own.
7 Likes
Please do not do this as your only line of defence for checking badge ownership, especially for logic which denies getting the badge a second time:
- BadgeService / DatastoreService can go down. If this happens, you’ll be left with stale data.
- Players can delete badges from their inventory. Ideally, you should be able to react to this and allow the player to re-earn the badge if they so wish.
Using a hybrid system of DatastoreService for the fast badge list and BadgeService to update stale data should suffice.
I only say this because I once fell for this case of ‘stale data’. An experience’s datastore thought I had earned the badge when, in reality, I was never awarded the badge at all. This meant that I was unable to earn the badge entirely as the experience had logic to stop awarding badges it thought players had already earned. Now I don’t blame the developer for this, I can only assume that they did call AwardBadge and Roblox simply internally failed to award it; before this whole scenario too, the only thing that I would have done differently if I were them is account for player badge deletions. I do think we can, however, all learn from this case and remember that both BadgeService and DatastoreService can error, whether that be because of Roblox outages or bugged developer-defined code, we need to account for stale data (and assume it can happen) and ensure we handle those cases effectively.
Also, I do have to ask staff: Is there any chance that AwardBadge can internally fail without triggering a pcall? I’ve been wondering about this since I can only assume a pcall was probably used in the case above, given that they were most likely using best practices. Now I do understand if maybe it was an experience bug instead since I have no proof of it being either case but I’ve still been worrying that it could be a BadgeService issue. 
13 Likes
great update, can we also get specialmesh’s vertexcolor rework? right now it takes vertexcolor as Vector3 instead of Color3?
2 Likes
omg i never thought of a feature like this being made; itll be really useful for the entire platform 
3 Likes
Most devs that utilize CheckUserBadgeAsync() have way more than 10 badges that they are checking for each player on join.
Hope to see limit increase soon 
would be cool to add more badges to my group’s games for rewards but too many limitations
6 Likes
Having 10 as the hard limit doesn’t really harmonize with the ease of badge creation nowadays.
One thing that has always been missing from this service is the fact that you can’t listen to an event which would allow for detecting badge awards.
3 Likes
This brings a happy tear into my eye. I like to have quite a few badges and checking them was taking way more network requests than I would’ve liked to use for something trivial.
Edit: Okay why is there a 10 limit? 
2 Likes
They definitely only made this so their events would be easier to organize, I respect it though
3 Likes
Great addition. Can we get a similar method for gamepasses, products etc? 
5 Likes
I’d love this for player display names too!
3 Likes
Ooo, I absolutely will be using this. And given I plan certain badges to be prerequisites for others, I can make badge checks very efficient!
2 Likes
i could be wrong but 10 in this case im pretty sure does equal 100
in the old api your rate limit was 50 but you can only request 1 single badges info for each one so that would accomedates 50 badges
the new api the rate limit is 10 but each one of those requests can get data on 10 badges at once which means if you use all 10 requests gets you 100 badges right?
or am i understanding this wrong?
5 Likes
allows you to get the displaynames of up to 250 users at once, i use this in my leaderboards
4 Likes
No need to use SpecialMesh anymore, since MeshParts support SurfaceAppearance, which can now be tinted.
They’re not deprecated as such but they might as well be ngl.
2 Likes
I do agree that more events for things like this are long overdue, but I think an event for badges being awarded would be useless, since you have to award the badge from your own live game. Just use a BindableEvent or a Signal at the same time as you award it.
As I’ve seen others suggest here, it’s common practice to handle badges using both DataStoreService and BadgeService. If you assign your badges unique keys saved into a dictionary you’ll be able to pull these much faster, and you can award any badges that the player should have (but are missing from their inventory) in the background whilst they play.
1 Like
This is basically a workaround (which is useful) so my players don’t have to wait as long to view their badges, but it still does come with the issue in situations where badges may internally error, as well as players still having the ability to delete badges out of their inventory.
You’d have to practically use what I’m doing now, but with extra requests, and nothing really changes the fact that these requests that will still be made, just less efficiently.
I was more so anticipating that the request/data limits would be more generous. If badges are continued to be supported, I would hope the API could be expanded to include more use cases like these, just like multi-get gamepass information/ownership for an in-game shop. Otherwise it might not make sense to include badges, over data storing, aside from free promotion on users profiles where its effectiveness may vary.
1 Like
The web API allows you to test ownership of up to 100 badges at once, making seperate requests to check up to 100 badges isn’t ideal and isn’t even possible to do every minute for each player as the server rate-limit is 5 requests per player per minute with an additional 10 requests per minute. The web API already supports checking up to 100 badges at once, so it would only make sense to align the lua API to that, too.
2 Likes
Nice Feature!
One Solution I’ve already implemented into my game is that once a Badge has been awarded, it is set to owned in the DataStore, so I have to never use any UserHasBadgeAsync call
2 Likes
Do you guys plan on introducing a Bulk Datstore Write method?
would be very useful for trading systems
4 Likes