brainCloud personnel
Hi - I'm probably missing the subtleties of your use case.
But in your scenario, what folks would normally do is:
Is there a reason that you don't set the product as NOT FOR SALE initially?
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.
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. 
Please let me know at your convenience,
Regards,
John H
-Design
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.
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:
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?
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.
Hi @greggoryaddison ,
Good question - and it points out some differences (and similarities) with PlayFab.
Playfab rationalized that they didn't need a client secret because:
Well - brainCloud actually has the same API separation - in our CLIENT vs. S2S APIs -- but we figure security is all about layering - and so we still require the app secret in the client.
But note that this app secret is SEPARATE from the secrets that get use for privileged SERVER/S2S API calls. When you declare an external server interface a separate secret is generated just for that interface. And that secret you'd normally keep in a .env file on server... Our Builder API uses a similar concept (also with separate API keys).
The brainCloud CLIENT APIs are very sandboxed. You can only access info about your player -- you explicitely can't access information about other players. You can also use API Blocking to prevent even those sandboxed calls from being done from the client. And implement sensitive calculations and operations in cloud code scripts that run on the server.
So - the app secret isn't as sensitive as you'd think.
That said - there are some best practices to improve things:
So - in summary - the app secret that our client uses is an additional layer of security that Playfab doesn't have. It is still separate from the secrets that the privileged S2S and Builder APIs use - so there's no compromise there.
I hope that helps to clarify things!
More info here - https://help.getbraincloud.com/en/articles/14855017-storing-your-app-secret-safely
Paul.
Hi @greggoryaddison ,
Send a message into our support chat with your appId and we'll check it out.
Numbers like these would tend to indicate a low DAU for the app (common in development) - with maybe some background processes that you are debugging. Normally the api counts for those processes would be absorbed across a bunch of Daily Active Users - but since your DAU is low, the API / DAU is going to look very high.
Anyway - send us you appId and we'll take a look.
Paul.
Dear @dbgtdbz2 ,
About your feature request #2. "Required item conditions for virtual and bundle items"
Question 1:
For your feature request, do the prerequisite requirements need to apply in the case that the item is included in a Cash Offer (or Cash Bundle Offer that this item might be within)?
Question 1b:
If YES that means a Cash Purchase attempt by the player could be denied by brainCloud due to the player not having the required Item. Is that appropriate?
Question 2
In the case that an item attempts to be awarded to the user by way of a Quest, level up, or gameplay mechanic, if the player does not have the prerequisite items, what should happen?
Thanks,
JH
Thanks for the suggestions, we will look into it...
