Unity Remote Config packages "2.1.2" and "3.0.0-pre.4" are now available

Remote Config v0.3.1 is now available in the Package Manager. (original post date: 7/25/19)

Release Notes:

  • Added long type support for settings

  • Fixed bug that caused the Remote Config Management Window to not display correctly after a domain reload.

  • Added slider control for rollout percentage on rules

  • The UI will now properly recover from any server-side errors.

  • The UI will now reject duplicate rule names rather than depending on the Service API

  • Moved Remote Config configuration requests to new URIs in the API Gateway

  • Removed reliance on API Gateway URL that needs -prd at the end.

  • The "All Users" pseudo-rule, is now named what it actually is, "Default Config."

Remote Config v0.3.2 is now available in the Package Manager. (original post date 8/7/19)

Release Notes:

  • The input field on each setting is now the type of that setting, so developers don't have to worry about having incorrect values.

  • Added warning when a setting key name reached 255 characters.

[1.0.7 Preview] - 2019-10-14
We're currently promoting the 1.0.7-preview release of the package . You can install via the Asset store or the Services Window. Here's what's going out with it:

  • Boolean checkbox is now a dropdown with True and False
  • The "Rollout Percentage" slider label is now an editable text field as well
  • Added support for more unity attributes: unity.cpu, unity.graphicsDeviceVendor and unity.ram
  • Fixed floating point rounding issue
  • The editor window now saves the last fetched environment, configs and rules on editor close, and on playmode enter
1 Like

[1.0.8 Preview] - 2019-10-29

We just shipped a 1.0.8-preview release, here are the release notes:

  • Fixed bug where RemoteConfigDataManager would try set the RemoteConfigDataStoreAsset dirty when it doesn’t exist
  • Added documentation for unity.model predefined attribute
  • The Remote Config window now supports having duplicate setting key names, but the backend will still reject duplicate setting keys.
  • On a failed push to servers, the Remote Config window will re-fetch everything, so that users see the state of their environment on the server.
  • Added a button to the Remote Config window that will take you to the Remote Config dashboard
  • Now the release environment will have “Default” next to it in the environment dropdown.
  • The cursor now turns into an editing cursor when hovering over editable fields in the Remote Config window.
  • Fixed bug on Windows which would cause the name of a rule to wrap onto the lower line when the Remote Config window is small.

1.
It´s so frustrating, that there is no working sample code.
I am trying the snippet from the documentation:
ConfigManager.FetchCompleted += ApplyRemoteSettings;
ApplyRemoteSettings IS NEVER CALLED!
And what the heck is appAttributes and userAttributes?
How does that go together with the RemoteConfig Editor?

2.
When pushing values, all floats are multiplied by 1E+7 when being pulled back. REALLY?

3.
I am trying to use Unity.RemoteConfig.ConfigManager.appConfig.GetInt("PostPro-Lift", 0)
Value is always 0.

Unity.RemoteConfig.ConfigManager.status is always none

ok - I solved 1+3. Analytics has to be ON. I thought the new thing was independent from Analytics?
Anyway Issue #2 remains

check your locale settings. many many times float serialization broke on US numbers (e.g. 1,234,567.89) vs rest of the world (1.234.567,89)
still a bug, mention your locale explicitly in the report otherwise they respond with “can’t reproduce”

As mentioned in the previous post regarding locale settings, can you share your specific values?

Are you calling ConfigManager.FetchConfigs? This is also probably causing the other symptoms.

The user and app attributes are custom structs that you can use to provide attributes for rule conditions. I can provide an example implementation if that’s helpful.

This is a bug with the 1.0.6 package. It’s since been addressed in subsequent preview package updates. Can you try one of the newer versions and see if this solves the issue? 1.0.8-preview.1 is going through the verification process now.

2 Likes

what is the difference between them? are they handled differently internally? if not, why have 2 of them?

No differences, other than how they’re accessed in a rule’s condition (user.[attribute], app.[attribute]). We de-coupled them due to some feedback from developers who wanted app attributes that stay the same across a session, but user attributes that may change.

If you have thoughts on that though, it’d be valuable feedback for us!

that can be easily emulated with a single struct with user and app fields. also there is not even an API to refresh only one of them at a time, so you still need to create and pass both even if the app attributes stay the same

I also noticed that internally they are converted to object, implying boxing and GC

otherwise it can make sense to allow for an arbitrary number of attribute structs, identified by string and refreshable separately, e.g.

RemoteConfig.SetAttributes("user", userAttributes);
RemoteConfig.SetAttributes("app",appAttributes);
RemoteConfig.FetchConfig(); // or auto-fetch when any attribute changed

also ability to change specific attributes (e.g. RemoteConfig.SetAttribute("user.level", 42) if user has a numeric "level" attribute)

also, if/when you have a user management service, auto-integrate it with RC (e.g. user attributes are fetched from the server that stores authoritative user data, app attributes (and user fallbacks) from the client) and/or provide API to do the same with our server

1 Like

I tried 1.234 and 1,234 which gets converted into 1.234. Both deliver 1234000 after push/pull.

Got it, we’ll look into this right away.

1 Like

important: German Localisation

1 Like

GetKeys() is not working: returns empty Array. However, HasKey() does work.

Are you sure the Rules-System is working? I am trying with no success.
With FetchConfigs I pass this struct:
new userAttributes() { developer = "klaus" }
I added a rule with this condition:
user.developer="klaus"
then I add a key and change the value to something different then in the default settings.
the rule is enabled (which interestingly greys out the whole rule - why?)

anyway: only the default values are being sent as a result.
I also tried a start and end date and 100% rollout with no luck.

Maybe an input for a nice feature:
it would be great if keys could be grouped together. It can get complicated to manage, if amount of key-value pairs get into 100+

For proper tracking, it would probably be best to open separate threads for each issue/request. Thanks!

1 Like

This is the v1.2.0-preview release of Unity Remote Config

  • The configs and rules for a config are now displayed separately, and appropriately labeled.
  • Added support for Variant rules in the Remote Config GUI.

  • Added a rule type dropdown next to the rule name, use this to change between segmentation and variant rules.

  • NOTE: When switching from a variant rule to a segmentation rule, it will result in a loss of local changes to variants.

  • Updates to the settings table for variant rules:

  • Added an Add Variant button that will add a variant.

  • Each variant has a name, and a variant weight.

  • The weights are null by default, which will result in a even balancing on the backend at time of assignment.

  • Added a public get to config as a JObject to RuntimeConfig, so entire config can be retreived as a JObject.

  • Added a "Select All" button to the variant rules settings view that will add all settings to the rule.

  • A slew of UI stability fixes and refactors.

1 Like