• Categories
  • Recent
  • Tags
  • Popular
  • Solved
  • Unsolved
  • Users
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Darkly)
  • No Skin
Collapse
brainCloud Forums

brainCloudAdmin

brainCloud personnel

Private

Posts


    New users are never counted — all users appear as Returning Users after launch
  • Paul WinterhalderP Paul Winterhalder

    First of all - from what you describe - you don't need to set forceCreate: true in your authentication call - because the account was already previously created via the S2S call.

    Also - since you are creating the accounts via the S2S call, then yes - when you authenticate, newUser will come back as false - since they previously existing (via the S2S call).

    That said - we'll have to look into the analytics of this a bit more. Certainly seems like a mismatch... maybe the "fix" would be to return newUser for any user account that had zero logins... and thus let the analytics take care of themselves based on that.

    I'll put this to our devs. Thanks for raising it.

    Oh - and for Q3 - certainly NOT pre-creating the accounts via S2S would make all this line up correctly.


  • Automated Promotions with no discount — "Not for Sale" workaround and purchase count tracking
  • Paul WinterhalderP Paul Winterhalder

    Hi - we highly recommend that you use CachePurchasePayloadContext() in all cases. brainCloud will attempt to do a best effort reconstruction of the product and price - but if you start using appStore IAP ids across products than all bets are off. We strongly recommend you add the payload cache in all cases - even for your Apple case that seems to be working so far.


  • Automated Promotions with no discount — "Not for Sale" workaround and purchase count tracking
  • Paul WinterhalderP Paul Winterhalder

    Question 1

    Let me clarify how this is normally handled.

    The client app gets a list of the available items for purchase by calling GetSalesInventory(). That call take into account who the user is, what segments they are in, etc. to determine which Cash Products to return in that call.

    So if you want to use segments to determine who can purchase an item, you would normally:

    • Set the item as "Not for Sale" as it's default price
    • Then in the segmented Promotions, you set the sale (in this case "Regular") price.

    In that way - people normally cannot buy the product - but it the user is in the segment covered by the promotion - it WILL appear at what you call the "regular price" for that user when they call GetSalesInventory().

    Do you get how this does what you are asking for?

    Question 2 - How is promotionId to be passed.

    The promotion is automatically taken into account when calling GetSalesInventory(). The trick is to still know a promotion is involved when we are processing the purchase receipt. That is accomplished by caching the new "payload" field.

    So the client should:

    • Call GetSalesInventory() to determine what products to show to the user
    • Bring up their store UI so the user can view things. Probably involves calling the platform's store APIs to get localized prices of everything.
    • When the user selects an item to purchase, the client app world:
      • Call AppStore.CachePurchasePayloadContext() with the "payload" field that was associated with the item the user has chosen.
      • then call the platform's appstore api to initiate the purchase.

    Then when brainCloud is processing the purchase it will retrieve the cached "payload" information - which includes information about the promotionId that was involved (if there was one).

    So note - in this flow you don't really NEED to call GetEligiblePromotions() - though that can be handy if you need to use that to show some banners in your store or something.


    Regarding counting of sandbox purchases - I don't think we include those in the stats. We record the purchase so that you can verify that it is happening end-to-end, but we now keep those totals out of the stats.

    I hope that helps!


  • Automated Promotions with no discount — "Not for Sale" workaround and purchase count tracking
  • J JasonL

    Did you call CachePurchasePayloadContext() with the promotionId before calling verifyPurchase() ? That’s the piece that passes the promotion ID through and should trigger an increase in the maxPurchases counter.


  • Automated Promotions with no discount — "Not for Sale" workaround and purchase count tracking
  • Paul WinterhalderP Paul Winterhalder

    Hi - I'm probably missing the subtleties of your use case.

    But in your scenario, what folks would normally do is:

    • Set the product as NOT FOR SALE by default.
    • Then have Promotion set it as AVAILABLE at the STANDARD price point.

    Is there a reason that you don't set the product as NOT FOR SALE initially?


  • Automated Promotions with no discount — "Not for Sale" workaround and purchase count tracking
  • J JasonL

    If your promotion is for a cash product and the promotional product is set to Not for Sale, you need to complete the flow by calling verifyPurchase in brainCloud with the purchasePayload from the store.

    As long as that payload contains the promotionId you received from GetEligiblePromotions, the promotion will be correctly attributed and the server-side flow will reach the counter increment logic.

    Also make sure you set maxPurchases on the promotion configuration page so the system knows when to stop returning that promotion for the user.

    As for your feature request to allow promotions without requiring a discount, I will forward this to our team for review.


  • missing features
  • johnhJ johnh

    Dear @dbgtdbz2 ,

    About your feature request #1, “Please allow specifying items as conditions for purchasing virtual or bundle items."

    I have developed a mockup for this feature.

    If we add your Prerequisite Items request to the system as shown, will this work for your needs?

    Note that in this implementation, the prerequisite requirement applies only to a Virtual Currency transaction. PrereqItemsMockup.png

    Please let me know at your convenience,
    Regards,
    John H
    -Design


  • Matchmaking To An Edgegap Hosted Server Instance
  • Steve JonesS Steve Jones

    Hey, thanks for reaching out. To answer your main question directly: yes, brainCloud's lobby and matchmaking system can trigger an Edgegap server deployment automatically. You do not need to build a custom C++ room server to make this work.

    https://github.com/getbraincloud/examples-cpp/tree/develop/relaytestapp

    The relaytestapp example on the develop branch of examples-cpp is a working client example that does exactly what you are describing. It uses brainCloud lobbies and matchmaking to find a match, and once the lobby is ready to launch, brainCloud handles spinning up the Edgegap server and passes the connection details back to all players through RTT.
    The server configuration you see in the screenshot is what ties everything together on the brainCloud side. That entry defines which Edgegap application to deploy, which regions to consider based on the selected beacons, and the credentials needed to make the deployment call. Once that server is linked to a lobby type, the entire launch sequence is handled for you.
    The relaytestapp is a solid starting point to see this end to end.
    Screenshot 2026-05-07 at 12.13.17 PM.png


  • Matchmaking To An Edgegap Hosted Server Instance
  • Paul WinterhalderP Paul Winterhalder

    HI @greggoryaddison - maybe I can clarify some terms here:

    brainCloud refers to hosted multiplayer servers as [Custom] Room Servers and Relay Servers.

    Room Servers are custom software that you write that will implement the authoritative multiplayer session. It is generally implemented as a docker image - using any number of multiplayer technologies. After matchmaking, clients will directly connect to your Room Server to participate in the multiplayer experience.

    Relay Servers use brainCloud own Relay Server tech (and Relay Protocol libraries) to implement peer-to-peer multiplayer. The off-the-shelf brainCloud Relay Server tech automatically "relays" the messages to the peer-to-peer host...

    Relay Servers are generally hosted natively by brainCloud itself.

    For Room Servers there are a number of options:

    • Room Servers - native hosting on brainCloud's servers. This is the simplest to set up. Enter the name of the dockerhub-based image for brainCloud to pull and launch.
    • EdgeGap integration - very similar - except the docker images are launched on EdgeGap's servers
    • GameLift integration - brainCloud will trigger the launching of GameLift-based servers. You need to build Gamelift images, not docker images.
    • i3d integration - integration with i3D's orchestrator for true AAA hosting of multiplayer services

    Once a Room Server is launched (on any of these services) is communicates back with brainCloud via the S2S API.

    We would very much suggest that the easiest path is to get your multiplayer working on brainCloud natively, and then migrate to one of the hosting integrations (if desired) once the basics are working.

    Does that help?


  • Does GetEligiblePromotions trigger Automated Promotions in real-time after XP level update?
  • J JasonL

    Hi, GetEligiblePromotions is snapshot-driven, not fully real-time. It relies on a cached promotion-eligibility snapshot stored on the UserProfile, which is only refreshed at specific points.

    • GetEligiblePromotions does not reevaluate Automated Promotion segment conditions (like experienceLevel >= 4) against the latest player state on every call. Instead, it uses the last calculated promotion snapshot that was written to the UserProfile. That snapshot is normally refreshed at login, or when you explicitly call the RefreshPromotions CAPI.

    • Because of that, the “delay” you are seeing is essentially “until the next snapshot refresh.” In your current flow, that refresh happens on the next login, which is why restarting the app makes the promotion suddenly appear. There is no fixed time-based delay; it is purely tied to when the snapshot is updated.

    • To make the promotion available immediately mid-session, add an explicit refresh step to your flow. After your CloudCode call to incrementExperiencePoints (once the player has reached level 4), call RefreshPromotions on the client, and then call GetEligiblePromotions. That will force an immediate refresh of the promotion snapshot so the level-4 promotion is returned without requiring a new session.

    API details for RefreshPromotions:
    https://docs.braincloudservers.com/api/capi/appstore/refreshpromotions.

Member List

R Roger Masse
Paul WinterhalderP Paul Winterhalder
C Claire Raby
C Corey Clarke
Mark DouthwrightM Mark Douthwright
A adamg
bitAlexiB bitAlexi
Hoar JoanneH Hoar Joanne
johnhJ johnh
V Vasanthan Rajendran
C Cody Melvin
Scott SimpsonS Scott Simpson
R Rick McMullin
Pierre ProulxP Pierre Proulx
Michael CostaM Michael Costa
N Nick Haidar
Franco LagoF Franco Lago
J JasonL
Greg MouldsG Greg Moulds
H Holly Leung
  • Login

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Solved
  • Unsolved
  • Users