Getting the Environment in Use | Official Unity Discord | Page 1

bright hinge Dec 12, 2023, 4:05 PM

#

We're not currently exposing an API for this but it's on our list of improvements we need to make. Your best bet right now is to explicitly initialize with InitializationOptions and cache the environment you specify somewhere yourself.

meager linden Dec 12, 2023, 4:11 PM

#

I'm not actually setting the environment, but I just wanted to check what it's being set to. I've set the editor to use a "development" environment in the settings, so I'm assuming otherwise it's going to fallback to "production", is that correct?

#

I mean, fall back to "production" in builds

bright hinge Dec 12, 2023, 4:15 PM

#

If absolutely nothing is specified it'll default to production.

The setting should persist into builds unless you override it explicitly using InitializationOptions.

meager linden Dec 12, 2023, 4:30 PM

#

I'm specifically talking about this setting:

#

which I'm assuming wont persist into a build?

#

I was able to do this:

var options = new InitializationOptions();

await UnityServices.InitializeAsync(options);

var envs = CoreRegistry.Instance.GetServiceComponent<IEnvironments>();
Debug.Log($"Environment is {envs.Current}");

#

I had to initialize here myself because I'm doing this in RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad) and it doesn't get automatically initialised until later

bright hinge Dec 12, 2023, 4:42 PM

#

That works, just keep in mind that's an internal API.

I believe the setting you screenshotted is setting the default that will be used even in builds.

meager linden Dec 12, 2023, 4:56 PM

#

I confirmed that's true in a build, which is disappointing with it only mentioning the editor (and numerious times)

bright hinge Dec 12, 2023, 4:57 PM

#

That's good feedback, would you expect it to be more clearly documented next to the setting? Or would you expect it to behave differently?

meager linden Dec 12, 2023, 4:57 PM

#

My expectation was it only affected the editor

bright hinge Dec 12, 2023, 4:57 PM

#

And then always need to explicitly set it for builds?

meager linden Dec 12, 2023, 4:58 PM

#

or let it default to "production", yeah

#

just that would handle a majority of cases I think (you don't want in-editor development and testing to go to your production environment, you would have to manually handle the builds that are for internal testing but then you wouldn't need to do anything for released builds)

#

you could even create a "development" environment by default and set the editor to that by default as well

#

to set the environment for a build, do I just need to use something like EnvironmentsApi.SetActiveEnvironment, do the build, then set it back?

bright hinge Dec 12, 2023, 5:09 PM

#

You could give that a shot, you can also use a #define and switch things up when you use InitializationOptions depending on what's easier for you to setup.

meager linden Dec 12, 2023, 5:15 PM

#

I know at build time what type of build it's going to be, at runtime it could be ambiguous

#

btw the code blocks in https://docs.unity.com/ugs/en-us/manual/overview/manual/environments-api are confusing, the namespace is wrong for EnvironmentsApi in the first two blocks, the second and third blocks seem to actually be for IEnvironmentsApi

jagged gulch Dec 12, 2023, 5:54 PM

#

The environment api does not work in batch mode right now unfortunately so it depends what your build workflow looks like.

I think the simplest and most versatile solution right now is to take control of the environment management for runtime by wrapping it in a scriptable object on your side.

Runtime can use that value to populate the initialization options and your build CI can update the scriptable object value and persist it.

meager linden Dec 12, 2023, 6:15 PM

#

ah ok, I did just finish implenting that but it shouldn't take much to change it to modify a SO instead

#Getting the Environment in Use