An event that fires once a player purchases a gamepass on the website.
Currently the only method of checking this purchase is if it happens in game, or by having a repetitive loop/continuous check per relevant in-game event.
This is not an event that fires for every server, just the one currently hosting the given player - if they are in-game.
From a technology perspective, I would think this probably isn’t something that already has architecture for on the website or on servers, this would be the only event on Roblox that is fired by something happening on the website that I can think of. Generally it’s the other way around, games update the website and then games use the updated website information when they ready things.
I do think it would be really useful to have the ability to subscribe to certain things happening on the website somehow, if the architecture was in place it could be used for some very cool things I bet, but, I don’t believe this is currently a possibility.
For your use case, checking on a loop is bad, I agree there, but, I think that checking when the player respawns or does something, like, open a shop, or, completes progress on something are the cases where you would tend to handle updates to gamepasses from the website if you wanted to, at least, that’s how I would tend to do that. That doesn’t fit every game, but, if you wanted to, you could introduce some mechanic into your game that lets people update their gamepasses, e.g. for a game that has a very open world.
Also, I do have one more question, while I think your use case is valid, why would a player generally buy something on site instead of in game? Doesn’t it make more sense to encourage the player to purchase in game anyway?
If the player can’t purchase something in game at certain times for example mid match, I would think you’d want to check if their gamepasses changed if they open the shop or when they exit out of the round or something.
The only time I see this being a problem where you won’t be able to find a natural place to update is when you’re not providing a way for them to purchase the items in game or if purchasing an item in game is harder than on the website.
I don’t think there’s ever a case where you would run into an unnatural place to update player statistics. UserOwnsGamePassAsync caches and ideally if the cache is on the game server (meaning no web calls) then it’d be pretty trivial to recheck a player’s game passes.
Purchasing a game pass on the website while in a game typically doesn’t happen but you already mentioned the best case scenario here which is to update the player’s ownership of a game pass as in when they open the shop or perform another action where the game pass should reasonably take effect. Having an extra function just to account for this one case isn’t necessary.
You can poll but it’d be better to check at specific points in the game where the game pass effects are expected to take place in or where the player might have a better chance at seeing them.
The one thing I don’t agree with here is that OP’s use case is valid, because I disagree and think it isn’t valid (why is checking in a loop or relevant game event bad or how does it not solve the issue that this feature would tackle?). The engine already has the API you need to account for potentially missing game passes during the session.
You have a good point with the caching. I always find it better to limit the amount of polling I do regardless, and, when I can I’ll even implement my own caching a lot of the time because it guarantees consistent performance. (For example, if Roblox stops caching a web call for some reason, I don’t want to hypothetically be calling it a hundred times by accident and burning through my http limits and slowing down my game. Probably a bit of a nonsensical example, but, I guess most of what I consider best practice is related to hypotheticals or edge cases)
When I say that I think the OP’s use case is valid, I guess I more mean that their reasoning behind requesting this makes sense to me, it isn’t ideal if you have to poll something, but, I don’t think that their reasoning warrants a new solution in the engine since there are already good ways to solve this without polling.
Generally, I tend to find any unnecessary loops bad, even if their impact is negligible. I would consider it best practice not to poll like mentioned because if you don’t poll you aren’t actively wasting resources (even if those resources mean nothing). You’re at the very least wasting a thread per player, and, to me, there are really good ways to avoid that that will even be more reliable from a player perspective and aren’t necessarily more or less difficult to implement.
That’s just how I look at things though.
What happens if they aren’t in the game? Should it ever fire when they join? What about re-trys similar to dev product handling? Need to iron out some of the ambiguity imo.
It should be a callback, similar to ProcessReceipt
To clarify, the only reason I’ve made this request is following a twitter conversation, where this was stated;
100% agree that this was open ended, partially intentional as I’m not massively familiar with how the marketplace seems to work.
I’ve worked very briefly on making a MarketPlaceService interface module, that handled all prompts/purchase/reciepts/checks for in-game items/passes. The one issue that I kept hitting was that I didn’t have a method of reliably checking to see if the player had bought a gamepass from the website while in game.
There are a few ways I can see solving this issue;
Perhaps the request could be altered around the change in this cache. Instead of an event directly prompted from the website, it could be fired if the ownership status in the cache changes. (@orange451 ideally, that solves a few of the issues you raised.)
Something else I missed in the initial FR;
Yes, 100% the aim should be trying to get the prompt to exist within the game. However, near every game has different interfaces set up for different things. If a player has difficulty navigating their way to where those passes are sold in-game, then the website is the easiest method of finding them. It’s unified across the platform. (This is more of a UI/UX topic, but it’s still something to consider. But in some cases, having in-game prompts won’t make sense.)
The more I read here, the more the request seems to just cater towards me not fully knowing or understanding how the service works. If anyone can think of any additional use-cases for this or reasons it should exist, post away. If theres no real use-cases I’ll mark the topic as solved at the end of the day.
If UserOwnsGamePassAsync returns true at any point, that result will be cached for the remainder of the game session. If it returns false, then false is cached for 10 seconds before another web call is made for a live result. Information in this Release Note:
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
