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

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 the the HTTPClient 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.

Select this option to get the payout rewards info displayed from the response of when the player re-login.

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.