Delete cache

Hi,
I’m trying to trigger the ConfigOrigin.Default behavior with ApplyRemoteSettings, but I can’t find where the cache is on macOS. It always triggers ConfigOrigin.Cached.
Can you help ?

Hi @julien-b .
Locally on your mac, cached file from remote config is usually at
/Users/your-name/Library/Application Support/DefaultCompany/your-project-name/RemoteConfig.json

Hey @julien-b , just as a heads up, the ConfigOrigin.Default behavior will only (currently) happen if you query the ConfigManager before its been initialized. This is more future proofing for when we move to async cache reads/writes, at which point, depending on the size of the cache, on initialization the cache might not be loaded yet.

Hope this helps shine some light into what’s happening under the covers.

Strangely, ApplyRemoteSettings currently returns ConfigOrigin.Remote value even when I turn off internet and there is no connection at all. This is my code and it worked well a year ago when I tested but I guess maybe in Unity 2020 it’s broken because it always returns the Remote value.

    void ApplyRemoteSettings(ConfigResponse configResponse)
    {
        // Conditionally update settings, depending on the response's origin:
        switch (configResponse.requestOrigin)
        {
            case ConfigOrigin.Default:
                Debug.Log("No settings loaded this session; using default values.");
                if (IsLaunchScene())
                    GetComponent<LevelManager>().OnRemoteSettingsFetched();
                break;
            case ConfigOrigin.Cached:
                Debug.Log("No settings loaded this session; using cached values from a previous session.");
                ApplyRemoteOrCachedConfigSettings();
                break;
            case ConfigOrigin.Remote:
                Debug.Log("New settings loaded this session.");
                ApplyRemoteOrCachedConfigSettings();
                break;
        }

This was fixed after we’ve updated our Remote Config version from 1.4.0 (current ‘verified’) to the latest 2.1.2. Either way, may be worth to fix the bug in 1.4.0 or remove the ‘verified’ label on it.

We did “fix the bug in 1.4.0”. When a bug is fixed, the fix comes out in a new version. If we updated “in place”, then some users would have a “good” version of 1.4.0 while others would have the “bad” version of 1.4.0. How would you the developer know which one you have? That is the reason for versioning. Verified does not mean “no bugs”, all software will always have bugs.