Hi Gavin, Did you resolve the crash issue on iOS? I am experiencing it as well, so I feel I must have missed something Cheers, Andreas

@JasonL Thanks, I ended up with this cloudCode: isForceCreate = String(data.callingMessage.forceCreate) == "true"; isNewUser = String(data.message.newUser) == "true"; var response = {}; response.status = 200; response.data = data.message; if (isForceCreate && isNewUser) { var min = 10000000, max = 999999999 prefix = ["player", "user", "member"] const num = Math.floor(Math.random() * (max - min + 1)) + min; const pre = prefix[Math.floor(Math.random() * prefix.length)]; var defaultPlayerName = pre + String(num); var playerStateProxy = bridge.getPlayerStateServiceProxy(); // We are changing the player name on the server. playerStateProxy.updatePlayerName(defaultPlayerName); // And in this API Call's return data. response.data.playerName = pre + String(num); } response; //return the object This works just the way I need

Call AttachUniversalIdentity() method from client lib, the username is uniqueness enforced.

I agree - and security-wise prefer it to the pre-hook solution we were considering... We are looking into it. Jake - I've sent you a question in the support chat - wondering what the timelines for your app are... Paul.

Hi, I temporarily solved it by adding this line in the proguard_user: -keep class com.braincloud.unity.* { *; } so the BrainCloud classes are no longer minified.

@Ben-Morris unfortunately yes they promised to solve it in BC 5.0 though

Hey, there must be some syntax error in your script, would you be able to provide your script code here?

Delete call update and everything is working now. Thanks!

Hi Dylan, actually, the argument purchaseData for StartPurchase() method takes the Steam Item ID (from Edit Price Entry pop-up) as the input field (not the Item ID from the product list)

I posted this almost 13 days ago with zero answers, so I took some time to look through a bunch of documentation and did a ton of trial and error. Please Braincloud for the love of god add this to your API. Rhino does not handle Arrays the way that other coding languages do. I figured it out, unlike most arrays that return an array after you call push- Rhino returns the new length. So if you call push, don't set it's value. var copyArray = []; //I assume this line tells it to be an array for (var i = 0; i < postResult.data..length; i++) { copyArray[i] = postResult.data[i]; //arrays do not behave like .Net arrays, you can change length without initializing, so you just set each index to the index of the array you're copying } copyArray.push(variableToAdd); //Do NOT set this as the value of your array, the push method returns an int (length of array) NOT an array! //you probably dont need to call push at all to add to the array as shown in the for loop above if you already know your length or want a specific length Then just set your value to the variable, like this var entityData = { "variableName": copyArray }; //No need to call Array(copyArray) or any of the prototype. slice stuff. If you call Array() you'll just nest the array a second time. Use this page for further info on functions you can do with arrays.

Hi, Any updates on what's coming up on the Builder API? I've been using it so far to automate the deployment of cloudscripts during development and has been a great time saver so far. I'd like to know or if you have some kind of a timeframe of when we can expect "Global Properties" to be available. Cause having would allows us to automate deployment of configuration files too. Also, is the Builder API going to able to make calls to interact with entities? We're migrating from gamesparks, and a useful tool for liveops was to build custom screens that would serve as tools for interacting with user data. Since Braincloud doesn't have that feature, we're looking into rebuilding those screens in Unity, but the missing piece of the puzzle is that we need a way to have access to entity data. Thank you for your time! J.B.

These points above are indeed good examples regarding "forcing bad practices": If I have 3 free API calls after the API call, after the 3rd freebie, I can return it and call again for 1 core + 3 more that can branch off again. This is inefficient for BC, yet beneficial for end-users (thus, forcing bad practices since it costs and gives more if we avoid the pre and post hooks). If a workaround to save API costs would be more work for the user, and costs more for BC, that's a lose-lose. If such a "hole" exists, shouldn't it be repriced for that consideration to make it the win-win you folks want it to be?