Reported here:
https://community.cesium.com/t/cesium-for-unity-not-updating-resource-positions-after-changes-on-cesium-ion-until-unity-restarts/43594
We cache the result of Cesium ion asset/#/endpoint requests in process memory. This is useful to avoid using extra Bing and Google sessions unnecessarily, such as every time the user starts a Play-in-Editor session. However, it causes problems when the user is trying to tweak the location of their own tileset on Cesium ion.
When the user edits a location on Cesium ion, the asset's "version" is bumped. This would work as an effective cache bust, except for one little problem: cesium-native never sees the new version because it never re-requests the asset/#/endpoint service.
Perhaps we shouldn't be caching this response at all? After all, it does have a no-cache header. But won't that run up sessions?
At the very least, we can provide an explicit way for users to clear this in-memory asset endpoint cache.
Reported here:
https://community.cesium.com/t/cesium-for-unity-not-updating-resource-positions-after-changes-on-cesium-ion-until-unity-restarts/43594
We cache the result of Cesium ion
asset/#/endpointrequests in process memory. This is useful to avoid using extra Bing and Google sessions unnecessarily, such as every time the user starts a Play-in-Editor session. However, it causes problems when the user is trying to tweak the location of their own tileset on Cesium ion.When the user edits a location on Cesium ion, the asset's "version" is bumped. This would work as an effective cache bust, except for one little problem: cesium-native never sees the new version because it never re-requests the
asset/#/endpointservice.Perhaps we shouldn't be caching this response at all? After all, it does have a
no-cacheheader. But won't that run up sessions?At the very least, we can provide an explicit way for users to clear this in-memory asset endpoint cache.