ID:1752618
 
About 30% of my players, (about 45 people) are having a problem where client side saving doesn't work for them.

I suspect it has something to do with their firewalls or antivirus. But I would like clarification as to if this is the case please.

In my game, miscellaneous player settings are saved to the client and used on any server they play on. But for 30% of the people it just doesn't work.

Whenever they log out and come back, all their settings are erased, as if the file was blocked from saving to their PC.
Also what can I do about this? It could be a bug with BYOND's client.Import/Export()
We'll have to look into that code since it's remnants of a very early development. I actually would recommend against using it since it most likely won't be supported for the webclient (as there is currently no equivalent to a global storage in HTML5). I suppose the more modern, albeit cumbersome, way to do it would be to have a centralized database or data space somewhere that you could query. I'm not sure if there are free services that allow api-based access for this sort of thing, but I wouldn't be surprised.
Ok we can do that. Thanks. I was just using this method because it is simpler and only requires DM code.
In response to Tom
Tom wrote:
there is currently no equivalent to a global storage in HTML5

There is the Local Storage API in HTML5, though it's most likely not the best solution because you'd have to convert savefiles to JSON (and back again to load them), and it has a limit of five megabytes for storage space.
That won't work for client-side files since the origin is based on the url (ip:port). That is, unless the game is running from the same server (which kind of defeats the purpose), it won't have access to the local storage. We need a global storage so that any server can query the client data. At the moment, I think the only way to do this would be to have a third party remote host like we used to with hubfiles. It's not a very used feature though.
Hello LizardSphereX I downloaded your hosts files but I cant upload as a server can you help me
EXGenesis has public hosting off, so there is no way really
I don't believe any of those options work between arbitrary domains (specifically, allowing both reads from and writes to a different domain than the origin). Last I investigated, the cross-domain "hacks" only worked from domain to subdomain, which isn't useful for us. I previously investigated the referenced article from the bottom link and concluded that the method wouldn't work in our case, but I can revisit it to be sure. A true global storage option is much more useful beyond this request, because it would allow us to cache game resources between different hosts (like DS does).

[Edit] Upon review, this may in fact be workable if we provide a "proxy" domain at byond.com, assuming we can have it accessible from all domains (since we won't know that information ahead of time to make the policy file). For caching, we use and IndexedDB over LocalStorage (although LocalStorage would suffice for the OP); presumably that will work the same way. Anyway, it's noted and we'll take another look at it.
A reverse proxy is a great idea, but it depends on how much infrastructure you want to implement..

Honestly, client side saving is IMO absolutely worthless, if you want a user to have access to data over multiple sessions use a remote MySQL database..

[EDIT] And if enough people are interested in that, I have no problem offering it for free for as long as I can.
It's not really the client-side saving that concerns me. What I'd like is global caching so that, eg, you could host two instance of the same game on different ports and it wouldn't have to redownload all of the resources. This is a digression from the original topic, but it's the same implementation. Anyway, I'll take a look. It's not of paramount importance but it certainly is something we'd like to have long-term. I really wish HTML5 would just put globalStorage back on the spec though, since it's a very useful thing.
In response to Tom
All that cache talk needs time and money to implement and upkeep though.

Could you not give each game a unique ID, if the games ID equals what's in the users cache, load it? Or even check the MD5 sums of the .rsc file / other files that are in a specified folder (the unique ID).
I think we're talking about different things. I'm referring to the caching of resources on the webclient. The server acts as a webserver for the purpose of delivering resources-- we do this so it can leverage the browser's native cache, which means that when you reconnect to the same game instance (ip:port), you don't have to redownload all of the resources. However, unlike DS, which uses a global cache (the byond.rsc), if you connect to a different instance of the same game (a different ip:port), you will have to redownload the resources. This is the case even if we use the extended cache options such as LocalStorage or IndexedDB. Unlike the browser cache, these modules allow manual setting/getting of resources, but the implementation deliberately limits this to the same origin (the ip:port in our case). There is no reason this has to be the case, but it is a part of the HTML5 spec at this time (for security reasons).

The resources you noted may provide a hacky workaround to this problem (although they all refer to LocalStorage, which isn't really feasible for resource caching). Outside of development time to get this working, this wouldn't involve any extra overhead since the caching is all done locally-- the origin is just a marker stored client-side (that is, nothing is actually stored on the remote server).

Anyway, this is a pretty sizable digression from the OP, who was making more-or-less a DS bug report!