In both cases, the transactions should already be recorded. In your iTunes case, you might have purchased in a sandbox environment. You just need to enable Sandbox Transactions, and those transactions should then appear there.

Hi,

Actually - voting leaderboards are implemented via the PostScoreToLeaderboardOnBehalfOf() call - where you can basically vote for someone else's score. [i.e. voting for that person].

Create the leaderboard as a "Cumulative" leaderboard - and basically the player votes for the score of another player - incrementing it by +1.

I suppose we should add those details to the roadmap item!

I hope that helps to clarify things!

Paul.

As I mentioned in the support chat - the issue is that midnightPSTinUTC isn't dynamically calculated for midnight today -- it's midnight PST on Oct 4th. [i.e. over a week ago].

What's happening is the call is accepting that past date - which puts the script in the front of our queue to be run ('cause we think we're late!) - and it gets run in the next 60 second job interval. And then reschedules itself in the past again.

So basically this script is running roughly 60*24 = 1440 times a day.

Anyway - I'll have the devs look into it - we should return an error if you are scheduling the script too far into the past... [i.e. a second or two in the past is probably fine - and best to do in case the scheduling script has delays of some sort... but clearly 10 days in the past is too far! Probably 60 mins in the past is too far! 🙂 ]

HI @richard - we're currently working on a feature that will handle this directly for brainCloud 5.9.

In the meantime, an interim approach would be to:

Manage the Lives in a virtual currency. In the item catalog - you can indicate the currencies to award from the offer via the extra data JSON. And create a post-hook on PurchaseUserItem - calling a script to award the appropriate currencies - and immediately consume the new "item" that was purchased...

Just a thought...

[But yeah - we're going to have a more direct solution in 5.9 - which is currently targeted for November release.]

Paul.

Thanks for reporting this. I’ll forward it to our team and get it fixed.

@devsleeper - we hope you like it! 🙂

Cool. Thanks for the update @MattForemanDev !

@JasonL @Paul-Winterhalder Thanks for your help, the error no longer appears after the Google Android platform was enabled.

@william Thanks a lot for your feedback and suggestions! It’s really helpful, and we appreciate you taking the time to share your thoughts.

Just a heads-up, our team is working on this bulk userItem feature.

@JasonL
Yes we can do that too, I was just wondering how granular our control over the segment is, as one of the requirements for our testing was to have a precise number of users for each group.

Thank you so much for the info, I'll write again if I have more questions.

Cool - good to hear it. And once again: thanks for reporting it!

Hi @richard,

Hmm - yeah - I don't think that JSON is currently editable in the portal.

Paul.

Hi @william ,

We do have plans to support the new receipts. The work has been assessed - but not scheduled yet. I would expect it to be early next year.

Thanks for asking!

Paul.

Please refer to the article -- Implementing Continuous Lobbies in the brainCloud Help Center for details.

Apologies for the late reply, but thank you! This really clears up the flow for me. 🙂

The only thing regarding FindOrCreateLobby instead of CreateLobby is that the request to CreateLobby is deliberate. While I do intend to integrate FindOrCreateLobby as a "just throw me into a running game" option (which probably is the desired flow in most cases), I also want a player to be able to say "I want to start a game for my friends, and I also want to be the host and set the rules of the room".

I'm just clarifying that in case I'm misunderstanding the intent between the two calls, and that FindOrCreateLobby can indeed be used for either flow that I just described.

Sorry for the confusion, I was under the impression a publisher key gave you certain read-only permissions on a user given they own your game (this was silly in hindsight)

While the users in question had public profiles, their privacy settings for friends lists were set to private.

Thank you for your help! I now understand what you meant by "as long as users grant your app permission".

My view is that there should be a "guaranteed service availability" at the time of purchase not unlike buying an appliance with a year warranty..

Pull the game from stores and let the remaining players enjoy the sunset.
Of course it's not always as simple as "just keep the lights on longer" but a guaranteed period of availability which is tied to new purchases should be in your plans before your service ever reaches the public, rather than hoping to grab as much money as possible before dumping it and throwing the consumer under the bus.

Hi @william - thanks for the suggestion - I'll present it to the devs.

One note - when doing custom queries, MongoDB should automatically choose the appropriate index for it -- you shouldn't have to mention it in your query. Thus - adding a custom index for queries that you are finding slow SHOULD pseed them up... (thus your last feature is actually part of the system)