@kamil-preciuk said in brainCloud 5.4 is on it's way!:

• portal-X require more clicks than previous version of dashboard to achieve same effect

This is so true and is the reason why it initially made my transition hard as well. Cloud code definitely is an area that needs to improve on that aspect. Although to be fair, Portal-X has a lot of good things too and Legacy had a lot of issues that we were no longer bothering with since we've gotten used to them.

That being said, when Portal-X was still in Beta and not the main UI, i remember that a new Braincloud user was about to quit the product since he didn't like the Legacy and hadn't yet found out about the Portal-X. Portal-X made him stay. That's when i realised the issues of the Legacy UI even though i was ignoring them. I guess that's the 'developer effect'

The new user menu is much better. Also did you add colors to the side bar. It visually feels smoother but i'm not sure why.

@kuabs A few things to keep in mind when using RTT:

• There's a 2 KB max message size to broadcast to a channel.

• RTT closes the connection after a couple of hours. The usual scenario that i've noticed is that it shuts down after 2 hours in the first session and upon reconnect sometimes it shutted down after 1 hour. So you'll need to have a fallback mechanism to handle that.

• RTT has more latency involved than a fully fledged server solution so it wouldn't work for anything fast paced.

• Api calls count depend on how many players are listening. Don't do that in a global channel where you might have thousands of players listening. Perhaps it's a feasible solution in a channel with <=100 players but it still depends on how often you broadcast it and you should keep in mind that for every broadcast in that case it will count as ~2 API calls.

In my opinion, this use-case is probably only viable in time-based games where player actions take minutes or hours or turn based games and even then you'll still have to combine it with cloud code.

@zespizatl A possible alternative, If you want absolute freedom over your data is to create your own (serverless or dedicated) cluster in MongoDB. Use MongoDB's functions service to expose http endpoints for crud operations and use braincloud's rest api through cloud code to communicate with your endpoints to MongoDB. Also, make sure to host your cluster in US-East (US-VA area) to minimize latency.

It's inefficient but you'll have absolute control over your data.

I have a pretty large screen so i didn't see any difference in 5.2. But from the above gif, i just realised the existence of the menu on the left side of the cloud code editor.

I mean this (Unless it was added in 5.2 which then it's great)

For debug, i was just using the button on top right.

I think you should apply some color to the images of the above menu as well as the one in the image below to add some emphasis.

Also, the font scale as well as tab size for the cloud code editor are great options that didn't know they existed

A good way to handle failure besides retrying in code, is to schedule another script to run 1 minute later that will basically repeat the same action.

It's not. Just knowing a playerId is really not important as it's only a unique identifier for another player and nothing more than that.

Use API blocking in the cloud code category to block all apis from client that write your user entities. Then clients can only write their entities using cloud-code and there you have the total control

@kuabs Exactly. Always use braincloud server time for features that rely on time passed. Also, if you want to modify your recharge rate during gameplay, you might want to consider keeping it in a global entity instead so every user will be affected by it.

Save a (current millis) timestamp, the recharge rate and the energy available in a user entity. Everytime the player makes an action, create a method that checks if he has the available energy, consume it & re-calculate the energy based on time passed from last timestamp to current. You can get the timestamp on the cloud using new Date().getTime(). Sync this process to the client for the player to see his energy.

(Total API Consumption = Read + write user entity in a cloud script = 1 API call)

If you want to have microtransactions upon the energy, create a virtual currency that the player can use it to buy energy. Since the energy is directly related to gameplay, i would want to keep it separately from my virtual currency.

@Paul-Winterhalder I think the expander in the bottom right did not exist in 4.15 when i reported it. It can be seen from the image as well. Version 5.0 has vastly improved the entity viewer. For comparison with the previous image i posted, i'm attaching an image from how i see it now

The script saving has become better without the transition animation. Also ideally, i'd like to use CTRL+S to save scripts.

Also, could you perhaps increase the gaps between job property fields a bit to the Job Queue window (Scheduled time, Creation time, Type etc...) and maybe add some colour codes for job status?

@panagiotis-milios

@paul-winterhalder Hello,

I was referring to Custom Entities, specifically on the side panel. If i am correct, It is resizeable only horizontally. Ideally, i'd like the data part to occupy more space vertically. If possible, could you perhaps make the Entity Details part of the window minimizable so the data part can take over that space.

The pop-up window for editing the entities is great and a nice upgrade of the legacy system.

Also, could you add some colored texts in Job Status (In job queue Window). Green for Success, Blue for Scheduled, Red for failure & Orange for cancelled perhaps? (I'm using the dark mode, i don't know if that would make sense in the light mode)

@paul-winterhalder Follow up on the upper comment, i think the entity view also needs to become a bit bigger. While the entity editing is a great improvement over the legacy system, the window for viewing the entity is too small

@benjamin-maison I think the appId field below the packetId field is obsolete. The error code you're getting is for an invalid app id. Check if it's the correct one. Also, have you registered your server with the proper app id?

@paul-winterhalder

Hello,

I've already mentioned this with the support but i'll post that here too. I think the cloud code needs to become a bit more frictionless just like the legacy cloud system when it comes to editing/saving scripts.
Ideally, i'd want to be able to edit scripts without clicking the edit button but rather just clicking typing inside the script.
Also saving the script without losing 'sight' of the script if that makes sense (Without the loading transition animation so i don't 'space out' cause even when i'm saving i'm still looking at the code. Kinda like the legacy system was in that aspect)
And more style configurations for the cloud code which as far as i'm aware, that's already planned?

@Paul-Winterhalder

My only complaint i have about the cloud-code API policy is that after the first 3 API calls, each extra API call should be charged at a rate of 0.33 instead of 0.5. Basically with the cloud code API policy, Braincloud charges 3.33$ for the first million and 5$ for every extra million API calls in cloud code.

i.e In a Cloud script with 9 'Pure' API calls that's called 333.333 times within a month (total: ~3 million 'pure' API Calls) the first million is basically charged at 3.33$ and the other 2 millions are charged at 5$. So total charge would be: 13.33$ which is true since this cloud script counts as 4 actual API Calls (total: 1,333,332 API calls).

But if my use-case allowed, i could break this Cloud Script in 3 different Cloud Scripts (3 api calls each) and call them from the client in order and using the return result as input to the next cloud-script to continue exactly where i left it. Now that would be 999.999 total API calls and i just saved for myself 3.33$ but in reality the backend did a lot more work.

Please do consider my suggestion of reducing the API count rate at 0.33

Any chance web payment support will be integrated in Braincloud in the near future (Before 2022)?

Reminder that there's a discord server for Game Devs with official support from many Services including BC. Braincloud seems a bit inactive in that server. Would be great to have some extra staff in there for showcasing.

Link: https://discord.gg/PZqADA

Yes, that solved the problem. Thanks for your input Chris. Although, i'm always "scared" of using statics so i ended up doing it in a kindly different way.

Since the forum is new, i'll post the solution here in case any future newbies like myself get stuck in the same problem. It's more of a Unity problem and less of a BrainCloud problem but thanks to BC support, i understood what i was doing wrong.

In order to use BrainCloud in multiple scenes you can either use a static variable like Chris said (it's easier doing it like that) or you need to create a GameObject and attach to it the script below.

using UnityEngine;

public class BCConfig : MonoBehaviour
{
    private BrainCloudWrapper _bc;

    public BrainCloudWrapper GetBrainCloud()
    {
        return _bc;
    }

    void Awake()
    {
        
        gameObject.name = "BrainCloud"; // I assign the name Braincloud to my game object to use it in the Find() function
        _bc = gameObject.AddComponent<BrainCloudWrapper>();
        _bc.WrapperName = "MyWrapper"; // optionally set a wrapper-name
        _bc.Init(); // extra data, such as: _appId, _secret and _appVersion, is taken from the brainCloud Unity Plugin. See Installation Guide above
        DontDestroyOnLoad(gameObject);
    }

}

In some other scene where you need access to the _bc variable you just simply do the following on the start method:

 _bc = GameObject.Find("BrainCloud").GetComponent<BCConfig>().GetBrainCloud();

edit: small fix made to the example code, by a brainCloud mod (@Jonathan)