brainCloudAdmin group

Paul Winterhalder

Hi - you custom entity based solution for this is sound.

You also might want to check on the messaging system - which has an "inbox" and a concept of whether entries have been "read" or not. It might do what you are looking for more directly?

Michael Costa

@LEE-JONG-GUN,

Hmm, unfortunately I don't believe you can set JsonReader to be able to use a converter. In this case you might want to continue using JsonConvert then.

The first solution I shared where you deserialize & serialize the response to strip out the trailing .0 might be your option here. Additionally, you can also modify your local copy of BrainCloudComms.cs to do this for all responses in-case this situation pops up elsewhere. This will essentially replicate the same behaviour in BC 5.9.2 and older.

If that's the route you take you can modify BrainCloudComms.cs in the HandleResponseBundle function on line 972 like so:

private void HandleResponseBundle(string jsonData)
{
    jsonData = jsonData.Trim();
    if ((jsonData.StartsWith("{") && jsonData.EndsWith("}")) ||
        (jsonData.StartsWith("[") && jsonData.EndsWith("]")))
    {
        jsonData = JsonWriter.Serialize(JsonReader.Deserialize(jsonData)); // This will strip any leading .0 for int values, replicating the behaviour from 5.9.2
    }

We will have to look into if we should have this be an optional flag that can be enabled for compatibility... Do note though that this will mean that a lot of the memory and performance gains from 5.9.3 will be lost.

There is another option though and that's to leverage JsonConverter

Here's a script that should take floats/doubles during deserialization and convert them to an int. I modified it and tested it, I think it should work for this situation:

using System;
using Newtonsoft.Json;

/// <summary>
/// Converts JSON floating-point numbers (float/double) to int during deserialization.
/// </summary>
public class FloatToIntJsonConverter : JsonConverter<int>
{
    public override int ReadJson(JsonReader reader, Type objectType, int existingValue, bool hasExistingValue, JsonSerializer serializer)
    {
        switch (reader.TokenType)
        {
            case JsonToken.Float:
                return Convert.ToInt32(Math.Round(Convert.ToDouble(reader.Value), MidpointRounding.AwayFromZero));

            case JsonToken.Integer:
                return Convert.ToInt32(reader.Value);

            case JsonToken.String:
                string sVal = reader.Value?.ToString() ?? "0";
                if (double.TryParse(sVal, out double parsed))
                {
                    return Convert.ToInt32(Math.Round(parsed, MidpointRounding.AwayFromZero));
                }

                throw new JsonSerializationException($"Cannot deserialize string to int: {sVal}");

            case JsonToken.Null:
                return 0;

            default:
                throw new JsonSerializationException($"Unexpected token when tryign to deserialize as int: {reader.TokenType}");
        }
    }

    public override void WriteJson(JsonWriter writer, int value, JsonSerializer serializer)
    {
        writer.WriteValue(value);
    }
}

You can apply this to any specific problematic int like so:

public class ScoreData
{
    [JsonConverter(typeof(FloatToIntJsonConverter))]
    public int tier;
}

Of course you can also apply it globally, but that might be a bit riskier to do Also note that this script will round floats/doubles to the nearest whole number so if you end up using it make sure to keep that in-mind (or feel free to modify it to suit your needs).

Let us know if either of these work out for you!

Michael Costa

Hello @LEE-JONG-GUN!

So looking into JsonConvert it looks like it actually uses LitJson underneath the hood

So one option to replicate the old functionality is to use BrainCloud.JsonFx.Json.JsonReader to deserialize into Dictionary<string, object> and then BrainCloud.JsonFx.Json.JsonWriter back into a string before having JObject.Parse() use it. This is basically what the old behaviour was and it would strip out trailing .0 values from JS Numbers.

SuccessCallback successCallback = (response, cbObject) =>
{
    response = JsonWriter.Serialize(JsonReader.Deserialize(response)); // Replicate the old BCComms behaviour

    DisplayLog(string.Format("Success | {0}", response));
    JObject jsonData = JObject.Parse(response);

    if (jsonData["data"]["response"] != null && jsonData["status"].ToString() == "200")
    {
        scoreData = JsonConvert.DeserializeObject<ScoreData>(jsonData["data"]["response"].ToString()); // This should be working now as JsonWriter will strip trailing .0 from doubles
        // ...
    }
    // ...
}

Although you could also just use JsonReader instead of JsonConvert as this should also strip the trailing .0 so you don't have to waste CPU cycles on the serialization/deserialization:

scoreData = JsonReader.Deserialize<ScoreData>(jsonData["data"]["response"].ToString());

Alternatively you can also bypass using JObjects and JsonConvert in this situation and make use of our BrainCloud.Common.JsonParser together with JsonReader like so:

SuccessCallback successCallback = (response, cbObject) =>
{
    DisplayLog(string.Format("Success | {0}", response));

    if (JsonParser.GetString(response, "data", "response") is string responseData &&
        !string.IsNullOrEmpty(responseData) &&
        JsonParser.GetValue<int>(response, "status") == 200) // JsonParser can grab strings directly without having to do object memory allocations
    {
        scoreData = JsonReader.Deserialize<ScoreData>(responseData);
        // ...
    }
    // ...
}

I think JsonParser can be handy for grabbing strings of json objects, json arrays, and values directly without having to do memory allocations

Let us know if any of these solutions work for you!

Paul Winterhalder

Note - the client devs have asked me to point out that this serialization challenge is only for folks using LitJson. All the other libs seem to handle things just fine.

Paul Winterhalder

Hi @LEE-JONG-GUN - did you have any luck with that?

Steve Jones

Great news — we've been able to dig into this and have a better picture of what's going on with the client_tier vs. stage_rank behavior.

Here's what we found: stage_rank is defined as an integer in the leaderboard scores response payload, so it comes through cleanly. However, client_tier originates from a Cloud Script Number value, which is treated internally as a double — meaning it can come across with a trailing .0 (e.g., 1.0 instead of 1).

In the past, this was silently handled during serialization/deserialization on the client side. But since the optimized client no longer goes through that process, that .0 is no longer being stripped before the data reaches your callbacks.

In the meantime, here's a quick fix: If you're on version 5.9.3, running the response through a JSON serializer/deserializer — such as JsonParser, Newtonsoft.Json, or Unity's JsonUtility — should clean up that reading path and resolve the issue. There may be a disadvantage in using LitJson.JsonMapper for this case, which presents this as a double, instead of an int like the other object parsers.

We're also actively exploring longer-term solutions to make this more robust on our end, potentially through a configuration option or a fix at the source, so you don't have to work around it manually.

Let us know if you have any questions or run into anything else — happy to help!

Paul Winterhalder

Hi Lee,

We are having difficulties recreating the issue.

Can you post an example JSON response where you are seeing the issue... it may help us to track down what it causing it...

Thanks,

Paul.

Steve Jones

Hey @LEE-JONG-GUN Thanks for reaching out,

For us to better support and uncover the issue you are raising, can you provide the appId, and profileId of the user that this occurred on? Can you send this information through the support widget, instead of in the public forum.

This will help us analyze the response and requests and confirm the payload and data being int to float.

Paul Winterhalder

Hmm - deployment is a very complex process - and in this case the complexity of picking and choosing what collection definitions get migrated over outweighs the complexity you would have to add a new field "week" to your collections and queries.

So apologies - but you should make the appropriate changes so that you have a "week" field in your collections (with appropriate indexes).

In compensation - I can offer up that:

We ARE adding the ability to exclude Division Set Configs from deploys (as you requested) <-- this should be available next week sometime.
And we DO now support migrating META data WITHOUT SCRIPTS via the builder API... (that got patched YESTERDAY!)

I hope you can understand.

Paul Winterhalder

What sort of edits are you doing to the leaderboards that updating multiple of them at the same time would be appropriate / convenient?

brainCloudAdmin

Posts

Member List