I’m trying to do a catalog item finder, where it checks if you have an item from the catalog. It goes in a for loop inside the catalog array and checks through the MarketPlaceService:PlayerOwnsAsset() every item if player owns it. The first item ín the list that I have bought it recognises it well, but after it doesn’t recognise anymore items.
for i, v in pairs(catalog) do
print(v, game:GetService("MarketplaceService"):PlayerOwnsAsset(game.Players.LocalPlayer, v))
if game:GetService("MarketplaceService"):PlayerOwnsAsset(game.Players.LocalPlayer, v) then
print(v)
end
wait(1)
end
Its just that after the game has confirmed that I own an item, the following item that I have is game:GetService("MarketplaceService"):PlayerOwnsAsset(game.Players.LocalPlayer) = false
What type of assets does the catalog array contain? :PlayerOwnsAsset() will return whether you own a catalog asset such as an accessory, face or shirt.
As an example, providing the function with the assetid of this badge I own will return false, since I the assetid is a corresponding catalog item.
To clarify, how many times is true/false outputted? I’d like to attempt to reproduce this in my own local environment, so please send the catalog array containing all 300 assets. If you don’t want to do so here, please send it via PM to me here.
PlayerOwnsAsset is internally a web call, so good practice for using this event would be wrapping it in a pcall in case the endpoint is down or the code throws an error. You can catch that error and handle blocks as they come.
In addition, you should have absolutely no reason to be calling web APIs so many times in quick succession. If you do find yourself needing that many calls, you need to rethink your code’s structure or purpose, or how to achieve the same functionality without excessive calls.
local success, result = pcall(MarketplaceService.PlayerOwnsAsset, MarketplaceService, Player, AssetId)
if success then
-- Handle success
else
warn(result) --> Print the error message to the console in yellow
end
Don’t just try it. You aren’t going to experience a different result just by changing the way you handle the function call. The issue is fundamentally the way you’re handling your tasks in general, which is excessively calling a web API in quick succession.
…yeah, you’re really not going to find any solution for this problem unless you either remove that leaderboard, change how it operates or deal with the server spending several minutes trying to queue leaderboards. With the current implementation, the data between the code’s projected finish time and when it started queueing will most likely be heavily out of synchronisation.
There’s nothing further I can really comment about this problem.