Migrated from RemoteSettings to RemoteConfig -> Questions & Issues

Unity Services
,
1

Hi there,

I’ve just migrated from RemoteSettings to RemoteConfig and have stumbled across (what I believe are) a few issues along the way.

  1. I setup the config data using the web dashboard, but initially struggled trying to create an environment called Development. It wasn’t until I created a dummy one then installed the package in the game, that the built-in Development & Release environments were auto-created (and subsequently appeared in the dashboard)

  2. The RemoteConfig docs below reference RemoteConfigSettings but if I’m not mistaken that’s part of the old RemoteSettings API that requires Unity Analytics. Hopefully just a docs typo?

https://docs.unity3d.com/Packages/com.unity.remote-config@1.0/manual/CodeIntegration.html

  1. The docs states that games running in the editor will always use the Development environment. But for me it’s always honouring the default environment in the editor (in this case Release). If I switch the default environment, this is then used next time the game runs (in the editor)

  2. I was expecting the FetchCompleted event to fire in the following order Defaults → Cache → Remote but all I ever see reported is Remote. Even if I disable the network connection, it still reports Remote but with a Failed status. Is this intended behaviour?

  3. I setup configs for each environment (called Default Config) but this doesn’t show up in the editor UI. All I see is Settings Config

  4. Is there a way to change config names?

  5. I assume that no rules is ok and in-effect means all players?

Using 1.2.0 (preview 4) the fetch code is like so…

ConfigManager.FetchConfigs(null, null);

And settings are retrieved like so…

ConfigManager.appConfig.GetBool(<name>, <default>)

Any help would be greatly appreciated. Many thanks!

2

Regarding points 1&3…

I just saw this in the 1.2.0.preview4 online docs…

Deleting the environment named Development is possible however; using a Development Build version of your Unity Project may cause unintended or breaking behavior. Those builds will receive the settings and rules from the environment which is set as the default environment.

So the web dashboard allowed me to corrupt the data to the point where behaviour is now broken, which is not ideal. Is there a way to undo this please?

3

Regarding point 4 (only the FetchCompleted → Origin.Remote event is fired)…

I looked at the ConfigManager code and the reason for this is that initialisation happens before scene load…

[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
private static void Initialize()
{
  Init();
}

But my game initialisation happens immediately after (splash) scene load.

Would it be possible to allow for manual RemoteConfig initialisation please?

4

@PeachyPixels sorry you’re running into issues, hopefully I can help with them!

  1. Yeah, this is a weird finicky behavior between the <1.0.X packages and the >1.1 packages. In the past, there were Development and Release environment names so those are reserved, and can only be made by the package.

  2. Yeah, the 1.0.9 and below packages used the analytics runtime to get configs, but didn’t require analytics to be enabled. In 1.1.0 and beyond (1.2.0-preview.4 is currently undergoing verification), we’ve fully decoupled from the analytics runtime in the engine, and no longer rely on that.

  3. Did this happen in a 1.0.X package? If so, that’s definitely a bug on our end and we’ll get it addressed. In 1.1.0 and beyond, the default environment is served, unless you call ConfigManager.SetEnvironmentID with the id of the environment you’d like to use before calling FetchConfigs

  4. Yeah, this was a big issue in 1.0.X, since we leveraged the old analytics runtime, which can capture the default remote config call. Do you notice this behavior in 1.2.0-preview.4?

  5. Sorry, that seems to be a naming inconsistency, we’ll fix that. The default config is the settings config.

  6. We don’t offer that today, but we’re exploring it when we look at adding multiple configs.

  7. Yep! No rules means all users.

As for 1&3 and the docs, that seems to be an error in the docs, we’ll get that addressed, the development build shouldn’t cause any issues. Let me know if you see any

5

This is an interesting feature request, the initialization method initializes the Remote Config underlying classes and begins the process of loading from the cache. Would you like that to be invoked by you manually?

6

I think that would be a worthwhile addition :slight_smile:

Analytics already does this and I’m certainly using it to good effect…

Analytics.initializeOnStartup = false;

AnalyticsResult result = Analytics.ResumeInitialization();

I have a GlobalManager (DoNotDestroyOnLoad) object whose Init (Coroutine) is invoked on Start of the splash screen. Allowing manual initialisation means this can be delayed a little, at which point objects will exist and event handlers assigned (so at the very least, should mean a FetchCompleted for Cache & Remote)

1 Like
7

Hi rambod,

Thanks for the reply.

Sorry can’t say, I initially used 1.0.9 but moved to 1.2.0 (preview4) fairly quickly. This issue is outlined in your docs now, but I wondered if there was a way to fix the backend data?

As of right now, I’m going to have to manually code the SetEnvironmentId to handle this. Not a big deal, but would be nice to not have to-do this if it’s just corrupt data that can be fixed.

8

Thank you! I’ve added to our list of features to add.
One thing that might be helpful for this in the meantime, is that ConfigManager.appConfig will have your cached config loaded by the time your GlobalManager loads up. You can check the origin field on the RuntimeConfig object as well for if needed.

1 Like
9

For this one, I need some more details to better understand what’s going on. What’s the data you’re worried about being corrupted?

For some background on the custom environment work: our hope with it is that you can do things like using a precompile directive for a development build to set the environment id for your test environment, then have your production build use the default environment.

1 Like
10

Great idea. Thanks!

All the calls to RemoteConfig from within the game are made from an abstract class, so as a work around just before calling FetchConfigs I call my UpdateSettings method manually. This will force whatever settings have currently been fetched into the settings POCO.

UpdateSettings(MapSource(ConfigManager.appConfig.origin));

However, on running I was surprised to see the source was Defaults although the values appeared to be from the cache. Did a little digging and think I found why. In ConfigManager.Init you will see the following code…

LoadFromCache();
RawResponseReturned += OnRawResponseReturned;
RawResponseValidated += SaveCache;

But the LoadFromCache method appears to need the event handlers to update certain values, so I believe they should be like so…

RawResponseReturned += OnRawResponseReturned;
RawResponseValidated += SaveCache;
LoadFromCache();

I changed them around and am now seeing the expected result (that is, Cache then Remote) but didn’t dig deeper to truly understand the code. Will leave that one to you :slight_smile:

I noticed there is no event fired for Default on Init, so would be nice if that could be added. Saying that, to be honest my UpdateSettings method just issues calls to the Get methods with defaults. Meaning the game just takes what it can when it can and doesn’t really care where they came from or whether the fetch was a success or not. The defaults are sensible and the values validated (post fetch) to try and detect cache tampering.

Hope that helps!

1 Like
11

In the mess of setting up the initial Development environment (i.e. conflicting with the in-built one) the data appears to now be in that state where the auto-environment feature isn’t working.

Regardless of whether the Development Build flag is checked (or not) the values for the default environment are always used. Basically it means I now have to code around this. Not ideal, but not a deal breaker either. I just liked the idea of the auto-environment feature.

12

Another thing I noticed is that ConfigManager.Init is still referencing Unity Analytics…

userid = AnalyticsSessionInfo.userId

Not sure if the intention was to completely decouple from it, but thought I’d mention.

13

@PeachyPixels

Thanks for catching the bug with the events not being properly applied (and showing us the fix - makes my job a lot easier :p)! We’re going through verification for the fix now and should have a new versions of the 1.2.X, and 1.3.X package releases out by the end of the week.

As for this one, if you’re using package versions 1.1.0+ this is expected behavior, the default environment will be served to the runtime unless you call ConfigManager.SetEnvironmentID. However, I’ll flag this with the team to look into if we can provide the auto-environment feature, while also allowing you to create more than two environments.

Lastly, regarding the last UnityAnalytics dependency, that piece of code doesn’t actually require the analytics package, or analytics to be turned on. That being said, we are looking for a fallback that doesn’t require the analytics namespace, but we want to be careful, in case developers are relying on the fallback user ID for reporting.

1 Like
14

@PeachyPixels we just released 1.2.0-preview.5 last night, with the fix you noted about the ordering of the initialization, let us know if you see the problem again! It’ll also be included in the next 1.3 release as well

1 Like
15

Thanks rambod :slight_smile:

Beat you to it, saw earlier and installed and a-ok! Thanks for the speedy work with this, much appreciated. Sorry for not replying earlier, been fighting Cloud Build today unfortunately.

I’m a few weeks away from my 1.0 release and although 1.2-preview seems stable to me, I would be interested to hear your thoughts on a Unity preview package going live? I’m reluctant to revert to 1.0.9 as 1.2 seems a nice step forward.

Will 1.2 go live before 1.3 or will you just skip it and push 1.3 live eventually?

1 Like
16

You’re welcome. Am a life long developer (but newbie game designer) so old habits and all that :slight_smile:

Ironically, I added Environment support to my abstract class yesterday and prefer the manual control now. Sorry! :roll_eyes:

That said, I definitely think this would be of use to most people as the vast majority will only ever require Develpoment & Release environments and having them controlled automatically does ultimately mean less work.

17

I’m glad things are working as expected!

We are currently going through the process of getting 1.2.0-preview.5 as a verified package, so we can confidently say that version is production ready already!

We will eventually get 1.3 verified as well, but that probably won’t be for another few months, since we want to make sure it’s been in the wild a bit and there are no issues, since the addition of JSON as a type is a substantial change.

No need to be sorry! I’m glad you’re finding better than the previous system :smile:

2 Likes
18

That’s great, thanks!

Btw am still only seeing the one event back from RemoteConfig (i.e. Remote) so am assuming the Cached event change\fix is further down the line? Either way, the spoof Cached event I added is a good workaround for now.

19

Hi, @rambod I was trying to use the RemoteConfig in my game .
I imported the package from the asset store and while using it I am getting this error .

The type or namespace name 'RemoteConfig' does not exist in the namespace 'Unity' (are you missing an assembly reference?)

Dont understand what could i possibly do to solve it .Please help !

20

Hi rambod!

Just thought I’d check up on this as I’m approaching launch and keen to drop the use of a preview package before.

I noticed that there is no 1.2.0 release yet, but there is a 1.2.1 preview (with no code changes it seems)

Just wondering what your latest advice would be on this. Shall I stick with 1.2.0-p5 or switch to 1.2.1-p or wait for the official release?