Cloud Code JS Authoring tool from the Editor - Pre-Release!

Update: Following the pre-release phase and from the feedback we’ve gathered, we are excited to announce that the Config-as-Code functionality that the deployment package ( link ) provides is now officially released! For the latest information please see this post .

8540951--1141181--retro-roll.gif
*Note that the gif above shows both Cloud Code and Remote-Config features leveraging the new pre-release deployment package.

Welcome to the Cloud Code JS Authoring tool from the Editor - Pre-Release discussion thread. You can use this thread to ask for help, share feedback and have discussions about the com.unity.services.cloudcode@2.1.1 package and the new feature enabled by the com.unity.services.deployment@1.0.0-pre.4. This is the next step from our previous experimental release .

Introduction
Introducing a new feature to Cloud Code to author it more easily! We are happy to bring all of the workflows you are used on the Unity Dashboard to the Unity Editor!
With Cloud Code Authoring you do not have to leave the Unity Editor more than you need to, it allows you to:

  • Author and Modify the cloud code js scripts in the Editor.
  • Deploy your assets from the Editor manually or by simply entering Play Mode!
  • Increment faster!

Requirements

  • This feature is only available Unity Editor 2021.3+
  • To use this feature you need to get the com.unity.services.deployment@1.0.0-pre.4 package and the com.unity.services.cloudcode@2.1.1.

Getting started

  • Make sure that your Unity Editor version is 2021.3+

  • Open your project in Unity and go to Package Manager

  • Add the com.unity.services.deployment package (Note: The package will be directly discoverable in the package manager soon)

  • Click the “+” button and choose “add the package by name…”

  • In the name field enter “com.unity.services.deployment”

  • In the version field enter “1.0.0-pre.4”

  • Add the com.unity.services.cloudcode package (Note: The package will be directly discoverable in the package manager soon)

  • Click the “+” button and choose “add the package by name…”

  • In the name field enter “com.unity.services.cloudcode” package

  • In the version field enter “2.1.1”

  • Go to “Assets” folder or any subfolder of “Assets” folder

  • Right click or click on the “+” in the project view

  • Left click on “Create” > “Cloud Code JS Script” asset

  • Double click on the asset to open in the IDE of your choice.

  • Navigate to “Window” > “Deployment” to open the deployment window

  • Choose the asset you want to deploy and double click on it.

Feedback
At Unity, we put the Users First so your feedback is extremely valuable to us. Please share your feedback in this thread so that we can continue improving our tools for you!

How to report bugs
Ideally we’d like any bugs reported through the built in bug reporter tool, as that will automatically provide us with some relevant context.

Once you have submitted a bug report through the bug reporter, please feel free to start a discussion about it in this thread.

Thank you for your interest, we’re looking forward to your feedback!

1 Like

Really cool stuff!

Here are some suggestions that could make authoring even much easier:

1. Configure what script can be deployed or not
I use libraries and I don’t want these libraries to show up in the deploy window

2. Show the directory or the path along with the script name in the deploy window
3. JS Library support
I made a custom .bat file to merge js files and be able to have libraries, but this mean I have to run that script before I deploy.

4. Can we deploy directly from a npm command? That would be cool to store scripts outside of the Assets folder
Also, would be cool to have a “watch” command that detect code changes and generate the final cloud scripts, that would allow JS Library support as well with includes

2 Likes

Hi Kevin, thanks for the feedback, very valuable and appreciated! We have some element in the works that we hope to be able to share soon.

In the meantime, for #1, one thing you could do is use the Deployment Definition files to organize the scrips’ grouping. Those creates groups within the Window and you can deploy per group.

For #2, we’ll look into it, but just wanted to share that, depending on what you are looking for, there is an option if you right click on a script in the deployment window to select it in the project view

  1. Configure what scripts will be deployed or not:
    Great feedback! We’re actively looking into this in two different ways! To build on what my boss is saying here, this is how we organize scripts.
    8560064--1145150--upload_2022-11-3_11-41-51.gif
    As you can see, I have a test file I dont like to deploy so I organize it under a different DeploymentDefinition (“ddef”).

We’re discussing using ddefs in particular to filter files out or add files outside of the Assets folder!

  1. Show the directory or the path along with the script name in the deploy window
    Let us know if the ddefs help!
    If they don’t, we may consider alternative options.

  2. JS Library support
    This is also something we’ve considered, some sort of bundling support. However, it’s not become a priority yet, but number 4’s answer might really be what you’re looking for…

4. Can we deploy directly from a npm command? That would be cool to store scripts outside of the Assets folder

Almost! There’s two questions here.
First, including files outside the assets folder is not a hard restriction. It’s something we’re considering to use the ddef to leverage…

But what might really help you here for 3 AND 4, is that we’re working on a UGS commandline tool, which allows you to perform the same deploy operation, but for automation, CI and all this useful stuff!
I can’t give any dates yet or I might get in trouble, but it should allow you to chain the ugs-cli call immediately after the bundling!

Thanks for this feedback, it is very valuable and confirms we’re going on the right direction!


A quick question though, did you update your package versions?
We’d like to know if the fix is from the service or the package :slight_smile:

Yes the ddefs helped! It’s a great workaround that prevent me from publishing non intended stuff.

The UGS commandline tool is a really great news :slight_smile: Really looking forward! Do you have suggestions for bundling? At the moment I wrote a .bat script to do it and it’s not optimal.

Yes I updated my packages.

Hi, I noticed a bug with the deployement tool, it always erase the Script Parameters settings when deploying, no matter if we use module.exports.params = { … } or not.


That’s not really a problem per se, but when the parameters settings are empty, the params object given to the script is empty and all scripts that require parameters don’t work anymore.

The workaround is to manually reconfigure the parameters after each deploy.

EDIT
I noticed the problem above was not happening on every script, but only on one with parameters that I first created manually on the dashboard without the deployment package and without module.exports.params. Whereas the one where I used module.exports.params seems to never loose its parameters even if you delete the script, remove everything related to it in JS, and deploy it again.

Seems like there is a cache issue with the deployment package. You can try to reproduce that bug:

  • Create a script that has some module.exports.params with one string parameter, required
  • Deploy it, the string parameter is visible in the dashboard
  • Delete it from the dashboard
  • In the script, remove the module.exports.params
  • Deploy it again, the string parameter is still here

Hey Kevin!

First, with regards to the bundling, this is something we’ve had quite some feedback about, so my best recommendation is to wait for an update that would support it more natively.
However, if you have a preference, your feedback would be valuable.

  1. Support a predeployment event
  2. Native bundle support
  3. Expose deployment api publicly for consumption in the editor
  4. Other?

We have 2 in our roadmap, but can’t give an ETA just yet, and 3 is something we have under consideration.

Second, I tried reproducing the issue as you described.
Step 2, I tried deleting the whole script from the dashboard.
Step 5, I was deploying from the editor.

However, after deploying the script with the same name, the parameter was not there.

To confirm it, however, I would like to clarify a few things:

  1. The deployment should always override the script and its parameters (which is what you experienced first).
  2. You must specify the parameters (if any) in the editor, via one of two ways:
  3. The first way is in the inspector:
    8563010--1145777--upload_2022-11-4_12-22-17.png
  4. The second way, is via the in-script parameters you are mentioning.
  5. The inscript parameters will override the inspector parameters (if any)
  6. Removing the inscript parameters will fallback again to using the parameters in the asset (if any)

I suspect one of two things are happening, and would like your confirmation

  1. Step 5 is being done directly from the dashboard. in which case the inscript parameters are not taken into account. Inscript params are a editor-only feature for now! We wanted to make the script self-contained for version control

  2. Step 4 is falling back to previously set up inspector-based parameters (these are saved in the file.js.meta, so deleting that and regenerating it should suffice). Deleting the .meta and deploying should fix the issue. It would also explain why it happens on some, but not all scripts
    (seeing the .meta file of the scripts that has the issue might help us debug your pb)

Thanks again for your feedback!
I look forward to hear from you !

1 Like

Thanks for the clarification! I understand how to manage my parameters now and I can do everything in-script, which is cool.

One problem I had is that I was using Number type instead of Numeric type, so parameters weren’t detected (and no warning in the console or the .js asset).

Deleting .meta files to re-setup things correctly helped.

Thanks!

Hey Kevin!

It does indeed seem like a misparsed param type does not provide adequate feedback, after importing!
I will create a ticket to follow this up!

This has never worked for me no matter if the script is new or old, or if I delete the meta files (or the script). The parameters are grayed out and says that “In-Script parameters are detected” even if the script is empty. Adding the module.exports.params does not create the parameters. Reinstalling Deployment package does not fix the problem.

I tried everything mentioned above and every time it deletes my existing parameters and I have to tediously manually enter all the parameters from the website (some scripts have 5). This bug makes the tool useless for me. Copy/paste works better than having to manually re-enter the params.

I’m running on a Mac so maybe it is not supported there.

Hi Isaeteurn,

I’m sorry you’re experiencing this, we’ll do our best to get you up and running quickly.
Some good news, we definitely support it on Mac as half our team works on it.

Do you mind giving us the package versions you’re using? For CloudCode, and Deployments, and Deployment.api

Additionally, do you have node js installed? The prefs can be found here:
8830747--1202422--upload_2023-2-23_14-48-28.png

Also, to confirm, you mentioned that they’re detected, but are they listed?
For instance, the following example:

module.exports.params = { "echo" : "Boolean" }

yields

8830747--1202425--upload_2023-2-23_14-52-57.png

Additionally, if you’re comfortable sending us your script / parameters (in a direct message too), it might speed up the resolution of our mistake.

Thanks in advance for your help, and once again, we apologize for this frustration

They are not listed. It always says detected even if the script is empty or newly created from the Editor.

Adding “module.exports.params = { “echo” : “Boolean” }” does not show the params nor does it add it to the Dashboard website.

Versions:
Cloud Code 2.2.2
Deployment 1.0.0-pre.7

I installed the mac version of node js and set the path.

Initializing JS Project yields this error:
NpmCommandFailedException: ‘/usr/local/bin/npm install’ command exited with 1
STDERR: npm WARN tar TAR_ENTRY_INVALID invalid base256 encodingnpm WARN tar TAR_ENTRY_INVALID invalid base256 encodingnpm WARN tar TAR_ENTRY_INVALID invalid base256 encodingnpm WARN tar TAR_ENTRY_INVALID invalid base256 encodingnpm WARN tar TAR_ENTRY_INVALID

Hi Isaeteurn!

I am pretty sure this issue was fixed in CloudCode 2.2.4, could you try updating that package and get back to us?

We clearly have to improve the messaging in the case of a failure to obtain the inscript params, so I’ll bring it up to the team so we can tackle it for the next release.

Let me know if that fixes your problem!

Additionally, I’ll take the opportunity to let you know we also have a CLI version of deploy: GitHub - Unity-Technologies/unity-gaming-services-cli: The unity gaming services (UGS) CLI is a unified command line interface tool for gaming services.

This will allow you to set up CI/CD workflows, like github actions to automate your deployments.

Now I’m getting this error with Importing the scripts:
Asset import failed, “Assets/CloudCode/GenerateProfileToken.js” > InvalidOperationException: Failed to add object of type CloudCodeScript. Check that the definition is in a file of the same name and that it compiles properly.
Unity.Services.CloudCode.Authoring.Editor.Parameters.UI.CloudCodeScriptImporter.OnImportAsset (UnityEditor.AssetImporters.AssetImportContext ctx) (at ./Library/PackageCache/com.unity.services.cloudcode@2.2.4/Editor/Authoring/Parameters/UI/CloudCodeScriptImporter.cs:41)
UnityEditor.AssetImporters.ScriptedImporter.GenerateAssetData (UnityEditor.AssetImporters.AssetImportContext ctx) (at /Users/bokken/build/output/unity/unity/Modules/AssetPipelineEditor/Public/ScriptedImporter.cs:25)

(Filename: ./Modules/AssetPipelineEditor/Public/ScriptedImporter.cpp Line: 219)

Hi Isaeteurn,

We have not been able to reproduce the issue, could you try to reimport the asset?
Do you have any other error logs besides that one?

Okay, I reimported everything and the error is gone. I can now specify the parameters, but it won’t autodetect the ones in the script. Not a big deal for me as long as the parameters are saved.

Glad to hear we’ve resolved the parameters issue. I’ll PM you to see if we can check the issue with the in-script parameters.