Is there a way to get a full stacktrace for errors?

Especially when using bridge.include, it is possible to have deeply nested logic which makes it very difficult to track down the code path that caused the errors.

I have some code that works locally (node.js env), but not in Rhino, it seems:

const Assert = {}; 

function stackTrace() {
    var err = new Error();
    return err.stack;
}
Assert.assert = function(expr, message){
    if ( !expr ){
        console.log(stackTrace());
        throw message;
    }
};

Thanks,
Travis

@Henry-Smith said in Recommended way to read Entity data? (Unity, C#):

Sorry to bring back an old thread, but I'm just learning the platform and I thought I'd share my solution to this.

First, define a generic class to handle the raw json response data:
eg. my Tut1_AddTwoNumbers api returns:

{"data":{"response":{"answer":24},"success":true},"status":200}

    public class Response<T>
    {
        public ResponseData<T> data;
        public int status;
    }
    public class ResponseData<T>
    {
        public T response;
        public bool success;
    }

Then for each api call that you have, define a class that contains the fields that are custom to that response.

    public class Tut1_AddTwoNumbersResponse
    {
        public int answer;
    }

Now, you call your function and handle the response like this:

    public void Tut1_AddTwoNumbers()
    {
        string scriptName = "Tut1_AddTwoNumbers";
        // Anonymous object to supply the params.
        var data = new
        {
            num1 = 16,
            num2 = 8
        };

        var jsonScriptData = JsonWriter.Serialize(data);
        SuccessCallback successCallback = (response, userdata) =>
        {
            var responseObject = JsonReader.Deserialize<Response<Tut1_AddTwoNumbersResponse>>(response);
            //var responseObject = JObject.Parse(response);
            Debug.Log($"Success The answer is '{responseObject.data.response.answer}' | raw_json={response}");
        };
        FailureCallback failureCallback = (status, code, error, userdata) =>
        {
            Debug.Log(string.Format("Failed | {0}  {1}  {2}", status, code, error));
        };
        // Call the script 
        _bc.ScriptService.RunScript(scriptName, jsonScriptData, successCallback, failureCallback);
    }

this line is the important part:

JsonReader.Deserialize<Response<Tut1_AddTwoNumbersResponse>>(response);

Hope that helps someone!

Is there a way to get a full stacktrace for errors?

Especially when using bridge.include, it is possible to have deeply nested logic which makes it very difficult to track down the code path that caused the errors.

I have some code that works locally (node.js env), but not in Rhino, it seems:

const Assert = {}; 

function stackTrace() {
    var err = new Error();
    return err.stack;
}
Assert.assert = function(expr, message){
    if ( !expr ){
        console.log(stackTrace());
        throw message;
    }
};

Thanks,
Travis

@Paul-Winterhalder said in Shared Global Context for each CloudCode invocation?:

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.
Perfect, thanks. Good to know a rough size to work with.

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.

I think the id lookup restriction will be fine, and since they are read-only, I won't need to worry about write contention.

One more question, I wa hunting around the dashboard, and I couldn't find a place to create a global entity. What am I missing?

Thanks,
Travis

@JasonL said in Shared Global Context for each CloudCode invocation?:

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

I've read that article, but it doesn't talk specifically about Global Properties.

What is the downside of going with Global Properties, or Global Entities?

As far as ACL goes, I was planning on blacklisting most BrainCloud client apis (more likely whitelisting apis) and returning the data I want to go to the client with custom cloud code.

@Paul-Winterhalder said in Shared Global Context for each CloudCode invocation?:

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

Thanks Paul,

Question: with Global Properties or any of these other approaches, what are some performance implications or limits to keep in mind? Is 100kb of json (stringified) per property slot too large?

I am looking for a place to store my global app "tuning" data. The tuning is broken up into logical sections (for example: Clash Royale style loot drop tuning, world progression tuning etc.). The largest sample tuning section I have right now is around 100kb of json data. Is that too large?

The tuning would be "read-only" from the client/players perspective: neither the client, nor cloud code could modify the tuning. Some of the tuning would be sent down to the client, probably via a custom cloud script call (getClientTuning), and some of the of the tuning would be exclusive to the server (drop rates).

I have been playing around with this idea in Cloud Code, and it would look something like this:

    var tuning = {}
    tuning.lootbox= JSON.parse(bridge.getGlobalProperty('lootbox'));
    tuning.cards = JSON.parse(bridge.getGlobalProperty('cards'));
    tuning.levels= JSON.parse(bridge.getGlobalProperty('levels'));

    DropItems(tuning);

Hope this makes some sense!
Travis

@Paul-Winterhalder @Ali-Raza Thanks for the help!

OK. I don't see the extra api call being flagged in the api explorer though.

For Example:

you get 2 more apis calls free so this one shouldnt cost extra.

If I need to make 3 or more api calls in my custom Cloud Code then I will, in effect, be paying for this call

For example if I set up a pre hook as outlined here: https://getbraincloud.com/apidocs/cloud-code-central/handy-cloud-code-scripts/restrictclientcalls-script/

Will it consume an extra API call for each API call made from the client? From my testing in the API Explorer, I don't see it registering the pre hook as an extra API call, but there was a discussion on discord that suggested that a whitelist prehook would create an extra api call per invocation.

Thanks!

@Henry-Smith said in Recommended way to read Entity data? (Unity, C#):

Sorry to bring back an old thread, but I'm just learning the platform and I thought I'd share my solution to this.

First, define a generic class to handle the raw json response data:
eg. my Tut1_AddTwoNumbers api returns:

{"data":{"response":{"answer":24},"success":true},"status":200}

    public class Response<T>
    {
        public ResponseData<T> data;
        public int status;
    }
    public class ResponseData<T>
    {
        public T response;
        public bool success;
    }

Then for each api call that you have, define a class that contains the fields that are custom to that response.

    public class Tut1_AddTwoNumbersResponse
    {
        public int answer;
    }

Now, you call your function and handle the response like this:

    public void Tut1_AddTwoNumbers()
    {
        string scriptName = "Tut1_AddTwoNumbers";
        // Anonymous object to supply the params.
        var data = new
        {
            num1 = 16,
            num2 = 8
        };

        var jsonScriptData = JsonWriter.Serialize(data);
        SuccessCallback successCallback = (response, userdata) =>
        {
            var responseObject = JsonReader.Deserialize<Response<Tut1_AddTwoNumbersResponse>>(response);
            //var responseObject = JObject.Parse(response);
            Debug.Log($"Success The answer is '{responseObject.data.response.answer}' | raw_json={response}");
        };
        FailureCallback failureCallback = (status, code, error, userdata) =>
        {
            Debug.Log(string.Format("Failed | {0}  {1}  {2}", status, code, error));
        };
        // Call the script 
        _bc.ScriptService.RunScript(scriptName, jsonScriptData, successCallback, failureCallback);
    }

this line is the important part:

JsonReader.Deserialize<Response<Tut1_AddTwoNumbersResponse>>(response);

Hope that helps someone!

Does each CloudCode call have some global/shared context?

I'm thinking of global "tuning" data for a custom loot box system. Or would this be System Global Data? If it is System Global Data, then I suppose accessing the data would cost me 1 api call per invocation.

Thanks,
Travis