Cache annoying ness


Couple of Cache things

I was messing around with a model re uploading it and such doing the www.mymodel?v1 www.mymodel?v2 thing to reload it and getting annoyed because a texture wasn’t loading. i storm off in disgust and when i log back in a hour later there it is all loaded correctly

This is annoying cos i’m spending time trying to fix something that it seems isn’t broken.

Second thing

In my mind a cache is a folder full of all the models from in world loaded into a folder on my pc.
The idea of doing that is next time I come back everything loads really quickly as its not being downloaded.
This cant be happening or it would all be amazingly quick like in grand theft auto
What does seem to be happening is everything downloading from the interweb each time, which is kinda slow and unnecessarily hammering my server.

If Hifis spec is looking similar to the rifts then prospective users have terabytes of storage available for all this content. And will get a better user experience at the same time.


It looks like what actually happens is it pings asset server on each session start to validate if cached copy is current - that invokes some overhead and certainly seemed faster in past build (2 weeks or so ago it seems I recall it changing to a much slower scene load each time I enter a domain with cached content).

But - that’s all well and good, overhead for validating cached copies shouldn’t be that big a deal if you do rez from cache first, validate then replace if necessary type logic.

That’s maybe how it should work, but, cache seems to have gone back to its former evil ways of not always honoring changed content even with the tricks of adding a ?### after. That said - I went to ATP and have less issue as it always has a unique asset name - but it’s a royal pain to use if you don’t have something to translate from ATP SHA256 based filenames to something humans understand.


It should jsut scoop all the models from my pc’s cache then in its own time check to see if anything not up to date
and swap em out later
so i don’t have that slow load and performance drop thing goin on
I also want domain by domain caching so i can delete one without deleting them all


So, I didn’t post anything about it, because I wanted to see if I could improve it a bit, but a couple weeks ago I added a new scripting interface for helping content developers. It allows you to specify a URL prefix and another URL prefix to serve as an override. For instance, I keep my domain’s content on S3, but I have a local copy of it as well. When I want to experiment with content I load this script, which causes interface to fetch from the local version instead of the server:

var publicPath = "";
var basePath = Script.resolvePath("..");
print("Base path " + basePath);
Resources.overrideUrlPrefix(publicPath, "file:///" + basePath);

Note that I have to load the script from the local version, because it determines the override path via Script.resolvePath.

Once the script runs, anything that I try to load from the S3 path instead gets read directly off my filesystem, no caching involved.

Since it only affects resource loads after the script is running it’s best to load the script and then restart the application. For shaders, there is some special case code which will reload the shader if it’s changed on disk, but for models you’d have to restart the application each time you make a change to see what it looks like. It’s imperfect, but should be better than waiting for cache expiration. The other big advantage is that until you push your content to the network, no one else has to see your work in progress.


Not sure I understand this.

Does this mean even with the script running you must restart Interface to see the updated content? If so, how is that better than just making unique names for each version?


You don’t have to edit the entities, and you don’t have to wait for a networking cache timeout, which might be longer than the amount of time required to just restart the application. You also have 0 impact on other visitors to your domain until you push your content live.


Oo… makes sense now. Thanks for the reply!