Upcoming changes to game badges

Hi developers,

In order to keep scaling with our growing user base, we are going to be making some changes to badges which may affect your games. You may need to update your scripts to handle these changes.

If you are calling MarketplaceService:PlayerOwnsAsset() on a badge, please use BadgeService:UserHasBadge() instead. In the near future PlayerOwnsAsset will not handle badges properly and may return an incorrect result.

We understand that some of you are using PlayerOwnsAsset() on badges because it can be called from LocalScripts, so we are looking into modifying UserHasBadge to support this.

If you are calling BadgeService:UserHasBadge() on an asset that is not a badge, please use MarketplaceService:PlayerOwnsAsset() instead. UserHasBadge should only be used on badges otherwise it may return an incorrect result.

We will be notifying developers who are misusing these methods and add warnings to output to make sure everyone is aware of this change, but you do not need to wait for these warnings before you fix your scripts.

We’re still figuring out the exact timeline and will follow up when we have a target date for the change, but we expect it to fall within the next 4-6 weeks.


Does BadgeService work for badges that are not part of the current Game? If not, it should.


BadgeService works for badges that aren’t part of the current game.


We need a UserOwnsAsset method to go alongside PlayerOwnsAsset (or optionally allow overloading of player instance with userId) – part of the reason developers are misusing UserHasBadge is because it doesn’t require the user to be in-game, unlike PlayerOwnsAsset.

This is actually a pretty annoying issue that extends past badges – it’d be great if badges could be the first step in modernizing all methods not directly related to the game that require a player object to take UserId instead.

###Methods that need to be updated

  • MarketplaceService:PlayerOwnsAsset(Player, assetId) -> MarketplaceService:UserOwnsAsset(userId, assetId)
  • Player:GetRankInGroup(groupId) -> GroupService:GetUserRankInGroup(userId, groupId)
  • Player.GetRoleInGroup(groupId) -> GroupService:GetUserRoleInGroup(userId, groupId)
  • Or, if the above data is easy to get at the same time, combine into a single method that returns both
  • Player:IsInGroup(groupId) -> GroupService:UserIsInGroup(userId, groupId)
  • Deprecate GamePassService:PlayerHasPass(Player, assetId)
  • Wiki page already encourages PlayerOwnsAsset, but it’s not technically deprecated yet

###Potential need for change:

  • Player:IsFriendsWith(userId) -> Players:IsUserFriendsWith(userId, userId)
  • Can’t really think of why this would be needed when neither user is in-game, but maybe someone else has a use case

###Should not change:

  • AssetService:CreatePlaceInPlayerInventoryAsync(Player, …)
  • Developers shouldn’t be able to spam users’ inventories with places when they’ve never even joined their game

Actually UserHasBadge does require that the player be in the current game server:

userId = 261
badgeId = 716416188
print(game:GetService("BadgeService"):UserHasBadge(userId, badgeId))
--> Sorry, player with userId=261 is not in this level at the moment
--> false

If you still want this functionality, I suggest posting a thread in feature requests.

1 Like

Moved my older thread to become a feature request - BadgeService:UserHasBadge behavior change - request

I don’t see an incentive to not make it so players who aren’t in the game can be checked for their badges.

May I ask, why is this change happening for PlayerOwnsAsset to no longer function correctly for badges? - My guess is because it’s awarded, rather than published/owned by the user. But same thing can be said about clothing, models, audio, etc. as well then. Is it for aesthetics?

1 Like

We have one giant database table which records which assets a user owns. This includes hats, gear, places, badges, etc. We’re running out of space in this table so we’re moving all badge ownership records to a new table just for badges.


By any chance have you made any changes to PlayerOwnsAsset in the past week? I’m getting reports that people’s purchases/stuff they already bought are not being recognized by the server on rare occasions and I can’t find what I’m possibly doing wrong if nothing(to my knowledge) has been changed.

edit: The issue started happening on May 1st when there was hosting issues and everyone’s games went down to a thousand players or less. Could there be a bug still happening because of that day? Just went through all server and client code, all 28k lines, and compared each line that wasnt identical and everything did not impact my checking if a player owns a gamepass or not.

So what happens when it becomes full?

Also - does BadgeService:UserHasBadge cache, in case I check if a player owns a badge at one point, which returns false, and later on try again where the player has the badge - will the cached false be returned, or will it do a fresh lookup and return true instead? What about in the admittedly rare case of a player removing the badge from their inventory?

Also, from this wiki page, the restricted door tutorial should be changed to use MarketplaceService:PlayerOwnsAsset instead.
And restrictions such as it only working in live servers.

1 Like

Not that I’m aware of. Would you mind filing a bug about this so we can investigate?

After that point in time, all attempts to award badges would fail.

Yes, it does. I’ll see about adding this information to the wiki article.

1 Like

So couldn’t we just expand the size of it?

1 Like

I don’t know enough of the technical details to answer your question but I can assure you that we considered all our options and chose the best approach.

1 Like

Posted a feature request here that was targeted at all older methods instead of a specific one like with @As8D’s thread.

I think this change went live, however:

This did not happen at all, AFAIK. I had some leftover UserHasBadge call in my game that I skipped, and it just silently failed (returned false all the time) without warning, and caused a lot of inconvenience to players of my game.

1 Like

Yep, I can confirm. I just got a ton of reports of things not working because I was relying on the having the warnings there.
I was using BadgeService because MarketplaceService is throttled way too much and I keep getting 429 responses


We did not intend for the change to go live this early. We have temporarily turned it off until Monday of next week, so please update your games by then.


Thanks for the update. Will wrongly used calls trigger warnings after Monday? This was the main inconvenience that I wanted to point out (not the change itself going live after a long preparatory period, that’s completely fine of course :slight_smile: )

1 Like

No, unfortunately the warning messages are not live yet. We are working on it.


I got an email yesterday from ROBLOX warning me that a few of my games may be affected by this change. I was confused about why it chose the games it did. Is this warning system simply based on games that utilize either UserHasBadge or PlayerOwnsAsset?