brainCloud

Apologies but no - there isn't currently a way to have refunds appear in the transaction logs for users in the portal.

Paul.

Hi Davis,

brainCloud does not currently support processing of refunds.

You could potentially create an owned custom entity collection to store the details of refunded collections in - so that you would have an entry against that user.

Note - you could also use a user entity for such data - but custom entities have the advantage of being globally searchable -- i.e. you can easily search for all refunds in the system.

Note - global entities are less ideal - they don't scale as well. Not recommended for data associated with users that could conceivably scale over time.

Paul.

Hi Lee,

You can schedule jobs in brainCloud using the ScheduleRuleScriptMinutes() or ScheduleRunScriptMillisUTC() calls - http://getbraincloud.com/apidocs/apiref/#capi-script-schedulerunscriptminutes

And those jobs can reschedule themselves to run again at another time.

You can find an example scheduler script here: https://getbraincloud.com/apidocs/cloud-code-central/handy-cloud-code-scripts/scriptscheduler-script/

Hope that helps!

Paul.

Hi folks,

brainCloud 4.6 is now live!

The biggest change is that we've upgraded our MongoDB abstraction layers to be compatible with MongoDB 4.X going forward. All without affecting the brainCloud APIs that our customers use.

In addition, there are a few cool new features including:

• Script API Usage Stats - makes it easier to understand the performance and cost implications of your scripts
• SAML End-user authentication - for those writing apps that require SAML authentication
• Random Custom Entities API - great for those writing custom selection or matchmaking services
• API Keys System - a foundational component for our new Builder APIs, coming soon

In addition, there are mucho improvements to the client libraries including:

• Greatly improved RTT connection handling
• Removed tons of previously deprecated methods (so the client libs are now cleaner and leaner!)

For all the details, see the release notes here - https://getbraincloud.com/apidocs/release-4-6/

Feedback welcome!

Paul.
(PS - Also a reminder, anyone moving to the 4.6 libs (from libs earlier than 4.5.6)- if you are using Relay Servers, be sure to upgrade your relay servers as well - instructions in the 4.5.6 release notes - http://getbraincloud.com/apidocs/release-4-5-6/ )

@Travis-Brown-John You can create them manually from the Monitoring menu.

Monitoring | Global Monitoring | Global Entities.

Note - if your app is live, you need to unlock it first. You'll see a bit [+] button to the right of the Bulk actions drop-down.

Good luck!

Paul.

Hi Travis,

Hmm - 100Kb is not appropriate for Global Properties. We don't recommend more than 3-4Kb of JSON in a global property, for example.

That said - you can have a bunch of global properties. Lots of folks use them for their tuning data - but more as individual key+value pairs - and smaller JSON blobs. So you can definitely store tuning data there - in more atomic form.

Global Entities are fine for tuning data - just ensure that you can look up your entities using the entityIndexedId. That id is essential for fast lookup.

Global Entities are not good for transactional data or player-owned data - cause the numbers group to large. For those, you definitely want Custom Entities. But if you are talking about reference (i.e. read-only) data with known ids for quick look-ups, then Global Entities should work fine for you.

Hope that helps!

Paul.

Based on the description of your use case, I'd recommend you to use custom entities, which natively have the user access control (ACL) configured. And check out this article about some size limits on entities in case you haven't see it. http://help.getbraincloud.com/en/articles/3472603-what-are-the-size-limits-on-user-entities

Hi Travis,

I can confirm that indeed there is an API call count for calling a pre/post hook script - we'll look to see if we can make that clearer in the docs.

That said, Ali is very correct, like all scripts, the next 3 API calls are free, and scripts after that are 1/2 count each.

Hope that clarifies things!

Paul.

Hi Travis,

You have a few options:

• Global Entities - simple, basic API - but not very scalable. Definitely make sure you have < 1000 entities.
• Un-owned Custom Entities - more scalable, custom indexes, etc. Requires plus plan
• Global Properties - store simple strings and smaller JSON objects

Those would be the main options. And yes - accessing them uses API calls - but remember, you get 3 free API calls in a script - and every call from then on is just 1/2 a count.

So if you have a script that makes say 5 API calls - it will actually only cost you 2 API counts: 1 to call the script, 3 are free, and the remaining 2 calls are 1/2 each.

Hope that helps!

Paul.

As a further heads up folks - it is looking like the 4.5.6 server release may get delayed until early next week. This is to allow us to create a proper mechanism for controlling with specific versions of Lobby Services are active at a time... (right now, it is possible for both old and new lobby services to be active during an upgrade transition - and given how much lobby processing has changed in this release - that wouldn't be good).

That said - the rest of 4.5.6 is ready - so we are going to be doing a bit of an incremental roll-out...

• We are starting to release the 4.5.6 Client Libraries today
• We are also making the 4.5.6 Relay Servers available (on our existing 4.5.5 servers) <- this is a simple feature gate for us to enable.

Then, once the 4.5.6 servers (with the new Lobby Servers and a few other fixes) are available, we will release them... that should be either late this week, or more likely early next week).

Anyway, just FYI...

Paul.