Default to enabled for existing apps to ensure compatibility

Default to disabled for new apps, so that they aren’t subject to legacy system limitations

In 5.4, brainCloud added new progress events that are broadcast to all lobby members when hosted room and relay servers are launched.

Existing client apps could be confused by these events - so they are suppressed by default (for existing apps only).

Leaving this flag enabled suppresses these new events

Prior to 5.3, brainCloud was not enforcing the country code values that would be accepted by the server

As of 5.3, the new behavior is to reject updates that do not adhere to the accepted list of country codes.

Leaving this flag enabled continues to allow any value to be set

In 5.3, if the data argument is null when updating a score - the existing data value will be preserved. Prior to 5.3 the data value would have been reset to null.

Leaving the flag enabled preserved the legacy behavior

Prior to 5.2, brainCloud was not properly enforcing that only the current player can call SubmitTurn() on an async match. This has been corrected.

Note that this flag does not affect any of the other AsyncMatch methods - which also enforces that only the current player can update the match.

Apps that need to update a match via the non-current player (for example - in timeout scenarios) are encouraged to impersonate the other player using a cloud code script via this technique (https://help.getbraincloud.com/en/articles/3631086-how-do-impersonate-a-user-using-the-braincloud-api) as opposed to enabling this compatibility flag.

Leaving this flag enabled compromises match security.

Prior to 5.2, brainCloud was performing case-sensitive lookups for redemption codes. The system was changed to store codes in UPPERCASE and perform case-insensitive lookups. This compatibility flag is for older apps with existing redemption codes - to ensure the older codes are still found by the API.

Leaving this flag enabled slows down redemption code lookups.

Prior to 5.1, brainCloud mistakenly allowed AwardUserItem() to be called from the client. We even mistakenly added it to the libs! That call is now restricted to being called from the server - unless this compatibility flag is enabled.

Leaving this flag enabled compromises the item security of your app.

Prior to 5.0, the eventType parameter fo SendEvent() was highly recommended by not required. This parameter is now required by default.

Leaving this flag enabled allows null eventTypes - but will slow down the event processing of your app.

In 4.15 brainCloud added a default accept header to all HTTPClient calls to improve compatibility with external systems. This change could cause issues if a 3rd party system wasn't expecting the header for some reason.

Leaving this flag enabled removes the header unless specifically added by the developer to the HTTPClient calls.

The default GetEntityPage() behaviour was changed in a special 4.10 patch after several customer encountered severe performance issues with the call. It had to do with how the call was handling the check for ACL permissions (by default).

The call was changed to exclude searching for shared objects (i.e. owned entities with ACL set to accessible by other users) in favor with a stricter, faster search for objects owned by the current user ownly.

More information here

Apps should not enable this flag. If an app needs to search across shared entities, they should instead specifically include ownedOnly: false in the query context options

Release 4.10 fixed some issues with Group and GroupEntity ACL behaviour. In particular, some GroupEntity operations were being gated via the Group ACL instead of the Group Entity ACL

Release 4.9 updated brainCloud’s handling of paths for the bridge.callScript() method to make it more consistent with industry standards (and our own bridge.include() method.

In 4.8 the data structures and IDs commonly used between Lobby Services and Relay Services were changed to be more consistent. The biggest impact of this was the replacement of the owner field in the Lobby data with the proper ownerCxId field.

Enabling this flag adds the legacy owner field back into lobby data messages

In 4.7, the Item Catalog service has been refactored to enable better image-file handling.

As part of those improvements, the service (by default) no longer allows for custom image paths (i.e. non-brainCloud anchored paths) to be set in the image field.

Apps wanting to use custom image URLs can use the custom JSON section or resource data sections for this information

Several API methods, including UserService SysGetPage/Offset() calls, were fixed to properly return "profileId" instead of "playerId".

The behavior of GetMultiSocialLeaderboard() was changed in 4.4 so that it no longer returns friends that haven’t played on any of the leaderboards requested

The schema for the embedded tasks within a Quest changed in Release 4.3.5.

Enable this flag to preserve the old behavior.

Storage of purchase transactions was changed significantly in Release 3.9

Enabling this option stores transactions in both the new and the old (legacy) format.

This option is obsolete and should never be enabled.

Release 3.5 cleaned up the JSON response for some API calls.

Release 3.3 fixed the json outputted during reward handling for XP level-ups – the returned json no longer includes the redundant “reward” section

In 4.13 the processing of non-consumable IAP products was changed - so that the awards would be processed even if the transaction had been previously processed by the user.

Enabling this options disables this behaviour. See the release notes for 4.13 for more information.

A significant optimization to UpdateSingleton() API performance was made in 3.2.5.

As part of that optimization, the entityId, acl, createdAt and updatedAt fields are no longer returned in the response for the call.

Enabling this option overrides the change, but also removes the optimization - resulting in significantly slower UpdateSingleton() API calls

Before release 3.2, the brainCloud Event System used numeric event IDs: eventId. These IDs had some significant limitations, including being slow to generate. The system has now been refactored to use a new and improved GUID-based ID: evId.

Enabling this compatibility flag tells the system to continue to create (at some performance penalty) the old eventId for Events. This is required if your app is still using the older API methods. It is recommended that all apps move to the newer APIs, and the new evId, at their earliest convenience.

Leaving this flag enabled slows down event processing.

Enable this option to get the payout rewards info included in the response of when the player re-login. Defaults to disabled because most apps will want to manually retrieve the reward information and present the earnings to the player directly.

In brainCloud 3.2, as a security + anti-fraud measure, we removed [by default] the ability for client apps to directly manage virtual currency balances. The affected methods, AwardCurrency(), ConsumeCurrency() and ResetCurrency() are still callable from server-side Cloud Code, which is much more secure.

Enabling this compatibility flag overrides this new restriction, and allows these calls to continue to be called from the client libraries.

Enabling this setting disables the Content Distribution Network (CDN) optimizations that were introduced in brainCloud 2.25. The main reason you might want to do this is because your client doesn’t properly handle the HTTP-based Redirects that are part of CDN processing. [your app asks us for a particular file, and we redirect the request to the appropriate CDN server. Older versions of Unity in particular do not support redirects – so this *should* be enabled for existing Unity-based apps.]

Workaround: Apps without redirect support should use the GetCDNUrl() method to retrieve the CDN version of a file’s URL for faster downloads (instead of enabling this setting).

For best results, the file retrieval compatibility flag should be left unchecked.

Before Release 2.25, brainCloud always returned the full contents of an entity object after Create() and Update() operations. This seemed to make sense at the time, but as some customers expanded to writing objects of 100K or more, it became painfully obvious that this was a waste of bandwidth.

Enabling this compatibility flag will needlessly slow down client responses and increase the data usage of your app (affecting your customers)

In brainCloud 2.25 we fixed a defect where the server was not correctly enforcing currency balances under all scenarios in currency consumption. This has since been addressed, but the compatibility flag exists in case some apps were depending upon the prior behavior.

brainCloud added support for manually managed friends in Release 2.22 – the implementation of which forced some changes to the JSON data returned from the social leaderboard APIs. This flag should only be enabled if your app pre-dates 2.22 and depends upon the details of the old format.

Before Release 2.22, brainCloud was used to return all of a user’s User Entities in response to Authenticate() and ReadPlayerState() methods. This was pretty convenient for quickly launching and logging into apps – but didn’t scale when some apps started storing thousands of entities per user!

brainCloud no longer does this by default.

brainCloud includes an Events system that can be used to send messages (events) to individual users. This is useful for sending chat messages, awards, gifts, challenges, and the like. Earlier builds of brainCloud would automatically check for any incoming events for a user during the processing of every API call. This processing has a server toll, and as most apps aren’t using events, unnecessarily slowed down processing for everyday apps. Apps can instead use the GetEvents() method to poll for new events.

Update brainCloud RTT provides superior real-time notification for most classes of events. Apps requiring real-time notification should use RTT instead of enabling this flag.

Enabling the flag will slow down all API processing for the app.

In brainCloud 2.10 we adjusted the JSON returns from Cloud Code scripts to align them better with the returns from regular API calls. This setting allows older scripts to still run.