Cloud Code JS Authoring tool from the Editor - Experimental

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 .

8260467--1081161--demo-gif-3.gif

Welcome to the com.unity.services.cloudcode.authoring discussion thread. You can use this thread to ask for help, share feedback, and have discussions about the Cloud Code JS Authoring package.

Introduction
This package enables Cloud Code authoring for javascript, including script modification and script deployment directly from the Unity Editor!

Resources
The package includes a documentation to help you better understands the feature. This documentation is available directly from the package manager’s links and here

Requirements
The minimum required Unity version is 2021.3+

Getting started

Current state
The package is currently experimental to test both the authoring tools for the js scripting in Cloud Code and the deployments features from the Editor.

Feedback
In terms of feedback, we’re especially looking for:

  • Can you think of any use cases that are not covered yet?

  • Are there any workflows that are unclear or missing?

  • Is there anything that is unclear or that you don’t understand?

  • Are there any issues or unclear parts in the documentation?

Please share your feedback in this thread.

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!

9 Likes

Nice one! Thats looks like a great time saver.
How ever when I install it I get errors in plenty of third party packages / scripts.
As it seems to use Editor as a namepace while they used it as type.
I can go through each script now and tell them to use UnityEditor.Editor but if we update the third party sdk my changes will be overwritten. So it would be great to not use Editor as namespace to avoid that conflict.

Hey David!

Thanks for the feedback!

Do you mind providing us a concrete example? (like a conflicting 3rd party package?)
I believe I understand what you mean, but rather be sure and have something to test against.
The package’s code is under the Unity.Services.CloudCode.Authoring.Editor namespace,
but other packages are using “Editor” as a type, and the IDE can’t tell them apart.

It might also be a matter of turning off the “Auto-Referenced” in the asmdef.

Thanks!

1 Like

A pretty popular package would be I2 Localizations

or a free one is

Assets/I2/Localization/Scripts/Manager/LocalizationManager_Translation.cs(157,62): error CS0118: 'Editor' is a namespace but is used like a type

Most of them are scripts inheriting from Editor as a type like:
“public class InspectorButton : Editor”

But if i change it there to be UnityEditor.Editor, it fixes the problem but It pops up in even more scripts. Its all over the place and as mentioned if I upgrade that packages my changes will be overwritten again.

I will look into your mention:
It might also be a matter of turning off the “Auto-Referenced” in the asmdef.
EDIT: I am not really familiar with assemblies but changing auto ref to false for all authoring files did not work out.

Maybe I also have no permission to do so, or need some guidance of what and where exactly.

Thanks!

Thanks David!

We’ll try that setup out.
I think its actually our assemblies that need to have it turned off, so that your assemblies don’t reference it by default. (would be an opt in). If our assemblies are not referenced, there’s no way they can conflict with yours.
Additionally, we can also revisit the namespace.

1 Like

Hey David!

We tried out your setup and reproduced the problem.
It seems its an oversight in our namespace rules, we’ll get to addressing the problem and creating a new minor version of our package (0.4.2).

Additionally, we’ll set “autoReferenced” to false, so that only assemblies use the namespaces on an opt-in basis

We’ll let you know when we have an update!

1 Like

Hey David!

We’ve updated the package to address the issue! The new version is 0.4.2

  1. We move the classes from the wrong namespace and put validations in place so that it doesnt happen in the future
  2. We’ve set “autoreference” to false in our assemblies so that you need to actively opt-in into referencing the assemblies in the asmdef.
  3. You may need to reimport your ‘.js’ and ‘.ddef’ files after an update

If there’s anything else we can help you with, or any other feedback you’d like to give us, we’re all ears!

Cheers!

Gab

1 Like

@GabKBelmonte thank you!

Hey, I can’t find the Deployment panel… Following the docs it should be under ‘Cloud Code > Deployment’, but I don’t have a tab or item called ‘Cloud Code’.

Hey Thomas!

Thank you for trying out our package! What version are you using?
If it is 2021.3+ it is under ‘Window > Deployment’ for 2022+ it is under ‘Services > Deployment’
Note that for versions below 2021.3 the package is not supported.

Hope that helps!

Jahangir

Nice! Can’t wait to use it! I couldn’t deploy yet, here are some feedback:

  • The installation process of the documentation Script authoring within the Unity Editor does not match with the process described in the first post of this thread (one is using a package called authoring, the other not).
  • I’m having an error when trying to deploy a script (with both installation processes) on a blank 2021.3.11 project where my UGS project is linked in the dashboard
RequestFailedException: Exception of type 'Unity.Services.Core.RequestFailedException' was thrown.
Unity.Services.Core.Editor.TokenExchange.ExchangeServicesGatewayTokenAsync (System.String genesisToken) (at Library/PackageCache/com.unity.services.core@1.4.3/Editor/Core/Networking/TokenExchange.cs:92)
Unity.Services.Core.Editor.AccessTokens.GetServicesGatewayTokenAsync () (at Library/PackageCache/com.unity.services.core@1.4.3/Editor/Core/Utils/AccessTokens.cs:37)
Unity.Services.Core.Clients.GatewayTokenProvider.FetchGatewayToken () (at Library/PackageCache/com.unity.services.cloudcode.authoring@0.4.2/Editor/Core/Clients/GatewayTokenProvider.cs:31)
Unity.Services.CloudCode.Authoring.Editor.AdminApi.RemoteScriptFactory.BuildAsync () (at Library/PackageCache/com.unity.services.cloudcode.authoring@0.4.2/Editor/CloudCodeAuthoring/AdminApi/RemoteScriptFactory.cs:29)
Unity.Services.CloudCode.Authoring.Editor.Deployment.DeployCommand.ExecuteAsync (System.Collections.Generic.IEnumerable`1[T] items) (at Library/PackageCache/com.unity.services.cloudcode.authoring@0.4.2/Editor/CloudCodeAuthoring/Deployment/DeployCommand.cs:34)
Unity.Services.DeploymentWindow.Interface.UI.Views.DeploymentView.ExecuteCommands (System.Collections.Generic.IEnumerable`1[T] providerCommands, System.Collections.Generic.IEnumerable`1[T] items) (at Library/PackageCache/com.unity.services.cloudcode.authoring@0.4.2/Editor/DeploymentWindow/Interface/UI/Views/DeploymentView.cs:418)
Unity.Services.DeploymentWindow.Interface.UI.Views.DeploymentView.DeployItemsAsync (System.Collections.Generic.IEnumerable`1[T] items) (at Library/PackageCache/com.unity.services.cloudcode.authoring@0.4.2/Editor/DeploymentWindow/Interface/UI/Views/DeploymentView.cs:390)
Unity.Services.DeploymentWindow.Interface.UI.Views.DeploymentView.OnItemDeployedFromContextMenuClicked (Unity.Services.DeploymentWindow.Interface.UI.Components.DeploymentElementViewBase itemView) (at Library/PackageCache/com.unity.services.cloudcode.authoring@0.4.2/Editor/DeploymentWindow/Interface/UI/Views/DeploymentView.cs:121)
System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__7_0 (System.Object state) (at <9aad1b3a47484d63ba2b3985692d80e9>:0)
UnityEngine.UnitySynchronizationContext+WorkRequest.Invoke () (at <86acb61e0d2b4b36bc20af11093be9a5>:0)
UnityEngine.UnitySynchronizationContext.Exec () (at <86acb61e0d2b4b36bc20af11093be9a5>:0)
UnityEngine.UnitySynchronizationContext.ExecuteTasks () (at <86acb61e0d2b4b36bc20af11093be9a5>:0)

And sometimes I get a different error

Even though I have this environment on the dashboard. I tried creating scripts manually first (unpublished and published), but it doesn’t help.

Hello @kevin-masson_1 thank you so much for using Cloud Code JS Authoring tool and thank you for providing your feedback. At Unity we always put the Users first and really appreciate the feedback as it helps us to improve our tools for you!

For the first issue, we are working on updating the documentation process to make it easier for users to get started. The package with the name authoring is an experimental package aimed at testing this new workflow. The second link that you attached is the updated workflow.

For the second issue that you have attached it shows editor as the environment selected. Could you verify if unity-testing environment is active on the dashboard?

Jahangir

To clarify what my colleague is mentioning, you are attempting to deploy to the ‘unit-testing’ environment, but have selected the ‘editor’ environment in the dashboard:


8536934--1140134--upload_2022-10-24_17-0-19.png

Does that project have the unit-testing environment?

Not sure why this would happen, unless there’s multiple projects, environment creation/deletion involved

And sometimes I get a different error

So, does it works intermittently?

Let us know, we’re here to help!

Yes I have that environment, and no it doesn’t work intermittently. This code works in play mode though (to make sure connection can be established):

var options = new InitializationOptions();
options.SetEnvironmentName("unit-testing");
await UnityServices.InitializeAsync(options);
await AuthenticationService.Instance.SignInAnonymouslyAsync();

This is the actual error I get from the server

EDIT:
By using the debugger, I noticed many requests were sent, adding breakpoints to pause the request allowed me to deploy. Adding a Delay in the upload process could fix that problem. But it’s surprising no one experienced that before.

Hey Kevin!
That’s rather strange!

We’ll look into it, but just to be totally sure, could you send us the package versions you’re using?
From looking at the pictures you began with the alpha package com.unity.services.cloudcode.authoring and then upgraded to cloudcode 2.1.1, right? You’re also using Deployment package 1.0.0-pre.4 and which version of the com.unity.services.core package?
(you can find this info in the packages-lock.json file (or just send the whole file, we’ll figure it out :slight_smile: )

thank you for your patience!

There it is :slight_smile:

Thanks for looking into it!

8540459–1141094–packages-lock.txt (13.7 KB)

Hi Kevin, thanks for the info! The team will look closer into it.

In the meantime I wanted to let you know that we’ve updated the initial post of this thread regarding your point on the installation setup documentation. We were in the process of releasing a new pre-release version were the topology of the package was changed, the latest thread should clarify the latest recommended setup, sorry for the confusion.

Hello again Kevin, we are still trying to reproduce your issue (we were not able to reproduce with the package-lock setup). Another thing that could help us identifying what is happening, could you also share the request-id that was hidden in your previous post ? (this is a UUID for each requests, so it is fine to share).

Also you mentioned logging the requests (in the console I presume), that could perhaps also shed some lights if you have those logs.

Thanks