There has been nothing solid on how this should be implemented, but I'll go at it.
In an iframe as long as it's on the same domain it's possible to communicate between the iframe and the underlying page.
So in this scenario BYOND could use an iframe of a URL such as http://www.byond.com/Local_Storage/HubOwner/GameName/ and pass data to and from the frame to the page so that data can be stored, separate from the byond.com/play URL and separate from the IP:PORT underlying URL that you essentially load when connecting to a game.
This would make it so that data could persist over a whole hub/game regardless of the server.
I don't know if it's feasible in the current setup though as I'm not sure how communication is currently setup between the game and the underlaying byond.com/play url and the IP:PORT url which is the host. It may have to be 2 step where it communicates from the server IP:Port url.
**IP:PORT URL refers to the host address your connecting to.
**and byond.com/play url varies wildly as it can use a world ID, which changes each time the world is hosted. Unless you use the IP:PORT version to connect to the world over the webclient in which case local storage would still only persist until they changed ports, which is also not ideal.
So the only way it'd work well is like above where it passes to a specific URL loaded in a frame which stores the data and passes the data back.
***If you need an example of how this is setup in a basic environment I can make a demo of it on my website.
Setting it up like this though would allow you to load up any URL you want in an iframe, pass data to it that you want it to save, and it will save it to localstorage for that iframe's URL instead of the URL your actually on.
Of course you need access to the source code for the URL your loading in the iframe so you can program the interaction between the two pages.
ID:1855067
May 19 2015, 8:23 am
|
|||||||
| |||||||
May 19 2015, 9:22 am
|
|
The localStorage value only goes by domain AFAIK, so I don't think you could have separate localStorage per hub entry. Nevertheless it's entirely possible for the BYOND site to handle all of that internally by providing a sort of proxy to localStorage.
|
In response to Lummox JR
|
|
I was thinking of subdomains where it's possible each subdomain have their own localStorage, although I don't know if it's feasible that BYOND create subdomains for each hub entry to use for this purpose.
BYOND could simply act as a proxy or allow us an easy way to interact with the underlying page so I could embed the game on my own site but use localStorage from my own page to load from and initialize stuff like saved macros, etc. |
With newer JS tools it should be fairly doable to come up with a system for providing an object that would act like localStorage and communicate with the outer frames. It would help in this process to have an idea of what kinds of things people would like to store, keeping in mind that the data would be easy to get at and shouldn't be used for, say, savefiles.
|
In response to Lummox JR
|
|
The few cases I can think of for localStorage would be would be to store macros and with games that don't just use the key associated with byond for characters can store the unique player id and password hash so the user connecting can seamlessly login next time they join.
Although if it's extremely easy to get at and maybe even add to yourself than the 2nd maybe a security risk. Even if it's un-readable it opens up the possibility someone could copy the data from one pc to another to gain access without actually knowing the login details. |