Question about the new "Local Storage" plugin

Are the local storage datas deleted if the user empties the cache of his phone, as it was the case with the webstorage?

I don't think this is not mentionned in the update notes.

Another question : at the beginning of my game, I should load around 150 datas. With webstorage it appeared to load instantly, but Ashley tells that we should use the "get item" action and then a moment later the "On item get" trigger fires with the value being available. Are the datas loaded in the chronological order?

i.e. if I check if the last data I loaded, does it implies that ALL other datas are ready to use?

Is the loading speed the same as with WebStorage?

I suppose this will come a little bit later, but a manual entry for it would also be greatly appreciated.

I have another question-

I set a value into webstorage every tick, it works fine.

But in local storage, the hard disk rotates always with big noise.

I can really see it in my mind now...this "new cool" local storage is trouble.

Twice the action needed to get what would have been a single line of code.

All I see is the amount of re-write awaiting my game.

Why can't Construct 2 handle this "On item get" trigger automatically ? Why isn't that an option [auto]

Can't construct 2 assign/compare the value when the data "decided" to arrive in the background ?

Why must we handle this...

This is trouble...

Where I used to be able to check a set of parameters on start of layout (if they exist and, if so, what their values are), this now requires me to pause the layout until all of the triggers have fired, lest the player is spawned in the wrong place etc. Which means extra faff tracking which triggers have and have not fired as well. I am not sure that this is an improvement... Perhaps there needs to be an option to wait for a trigger to fire - but the on start of layout / load a bunch of variables from web storage seemed to work well and was not in need of tweaking IMO. As Toddler said, could this waiting for a load trigger be an option?

Colludium is right, now things like this:

Cannot be done easily anymore, now you need to implement some trigger crap.

Now in the previous case, it might STILL be fine but what about this ?

This code is called when a certain frame in a looping animation is reached.

I know some might say you should load the data into some variable and not access the file system that often but I am telling you, the game works smoothly, webstorage is working well, no, I am not loading the ENTIRE INTERNET on every frame so it is not going to be a problem that this new plugin is so eager to try to handle [loading BIG ENORMOUS DATA because yeah that is what most game created using construct2 have to deal with right ? BIG DATA the size of the internet... pssh...]

It was SOOOO easy presently.

But now with the new and improved "localstorage", things are going to be more complicated than it has to be.

"Oooo with the new *parallel* processing, things will be faster" and all that crap.

If it is supposedly going to be so fast, and "along side", why do we now have to face the issue of not only re-writing our codes but have to implement some sort of "wait"/"pause" function like Colludium said to do what you are seeing here ?

This "new upgrade" is not a even close to "good".

It is Terrible.

Just Terrible.

Can Construct2 atleast make this *New and Cool and parallel and so awesome you should forget about using the old webstorage* plugin have like this internal build in "wait until the result is retrieved and then continue" option that makes it behave like the original supossedly *bad or OLD* system that is actually friendly to us ?

I have been working on my game for four months now and this crap happens.

I am just going to wait and see where this terrible direction is going before I continue, I have stopped the game development for now.

This is Terrible...why is anyone even praising this new *improvement* ?

To all the fans of this new *awesome new way of loading data* plugin:

Yes I am glad you now have the ability to load 1GB of data into your game on a "parallel" thread without slowing down you game and be notified when your 1GB of data has been loaded.

No 99.9% of us creating casual games don't have to deal with that, so thanks for messing it up for the rest of us, because we REALLY LOVE having to access a saved data that is like maybe 100kb and have to then wait for another trigger to tell us when that has been loaded for us to then access it, yeah that *awesome* we really love that...

You know what else we love ?

Maybe construct 2 will *improve* its sound playing system by making a function to play a sound but then create a trigger to let us know that the sound device is now actually ready to play the sound before we THEN play it, if we are going to mess it up why don't we go all the way ?

Hey check that, why don't we ALSO implement like when pinning a sprite to another sprite, we make it so that we have to wait for a trigger after calling "pin to object" that tells us that the sprite is *ready* to be pinned which we will then call another function to *actually* pin it ?

Let's do that, lets *improve* construct 2...

Toddler I agree with you that having to rewrite our codes is not really good news, but it is still very early to start complaining.

Maybe the loading time will be as fast as it was previously (I asked it in the first topic) which was nearly instantaneous.

The old WebStorage plugin is still usable if you have it in your current projet, so if it doesn't work well for you, you can keep the Webstorage.

It seems like the WebStorage "may" be deprecated in the future by browsers, which would simply disable the saves in our games... Frightening! I don't see this happenning before a bunch of years, but still I'll try to avoid this.

If the LocalStorage keeps the datas when the users empties his cache, it would be a great improvement IMO. It's also something I asked for in the first thread and hopefully Ashley has an answer for us.

So, if everything is working fine I see this as an improvement... that will cost us some additional work.

Please implement the "Check if Exist wait until respond received" or "Compare value wait until respond received".

Nobody appreciate a trigger for this, nobody is loading 1GB of data for the majority of us, stop this nonsense.

I will admit that everything asynchronous is something hard to keep up inside C2's event system (which is based on a from top to bottom logic, with events needed to be complete before the next)

Toddler maybe you could use a dctionnary, and save that dictionary to the Local Storage (since the dictionary values are setted ASAP, you will not have that much trouble).

Thanks Aphrodite.

However, no amount of gymnastics is going to cover for the fact that a freaking trigger is needed just to get a value from a storage system.

Again, we are not talking about 1GB of game data to be loaded here, please stop this nonsense before it becomes the norm and everyone stop talking about it and silently accepts this is the direction Construct 2 is going...

The next thing you know you will need a trigger to know that a sprite is ready to have its animation changed or else you cannot set the animation...you never know right ? I mean who would have expect that you need a trigger to know that a value have been retrieved when trying to load from a web storage and to be told it is an "upgrade" ? People would say that this crazy, but here we are !

Ok, I can accept that maybe the old web storage is too far gone in the deep end of deprecation to be future proof or "accommodated", but surely this new "awesome" localstorage could be made to simulate the old simply more logical direct approach right ?

Please implement the feature option right into this *new and awesome* local storage to internally wait and then when the value is retrieved continue the program.

Please please please don't say that would cause a lag in the game if internal *wait until loaded* is implemented, cause isn't this parallel bullcrap supposed to be "faster" ?

Oh suddenly it is causing a lag now ? OH WOW really ?

I haven't looked at the new plugin yet, but can you just use Dictionary instead? And when you need to save/load just do so with dictionary json data?

Are the local storage datas deleted if the user empties the cache of his phone, as it was the case with the webstorage?

I think it's the same as with WebStorage. Stored data and the browser cache are two different things. The cache is to store online resources locally to avoid having to request them multiple times, but if it goes missing from the cache it will request it online again. Offline data like IndexedDB is not part of that process. I think Chrome clears offline data if you also clear cookies, and Firefox has a separate "Offline website data" checkbox to clear, so I guess it depends on the browser. It's definitely not in the cache though.

[quote:1mufp55o]Are the datas loaded in the chronological order?

Not necessarily. In theory the triggers could fire in a different order to the actions you used. If you have 150 small values which are always read and written at the same time, perhaps you could just use a Dictionary object and read and write it all as JSON data. That won't scale well for very large amounts of data though (in to the megabytes).

I set a value into webstorage every tick, it works fine.

But in local storage, the hard disk rotates always with big noise.

You should never do this with any storage mechanism. Other browsers might have thrashed the hard disk with the webstorage method too. Only write data when you need to!

Why can't Construct 2 handle this "On item get" trigger automatically ?

I am aware it involves more events with the new system, and I'm trying to come up with something to solve this and make it easier while preserving the async feature. See this thread: https://www.scirra.com/forum/idea-make-async-easier-with-quot-then-quot-event_t128870

[quote:1mufp55o]"Oooo with the new *parallel* processing, things will be faster" and all that crap.

Well, lots of other users wonder why C2 doesn't have more parallel features that can make use of multiple cores to improve performance. Jank (small pauses during games) is also a big problem for a lot of people. This new async storage plugin allows for parallel processing and reduced jank. If you don't like that then I don't know what we can do, we just can't win, someone will always be unhappy either way!

You can of course just keep using WebStorage for existing projects. You are not *required* to update, we just suggest that it is a good idea if you can. If you have hundreds of values and a huge project depending on complex usage of WebStorage, maybe you could just leave it, and use Local Storage for your next project. The decision is up to you, but transitioning to Local Storage is simply recommended, not mandatory.

Toddler while it would make sense to have trigger for everything asynchronous, I will admit that it can become a huge bother, and being able to stay in the realm of synchronous events would be nice when asynch is not needed and will be bothersome to implement.

Or rather, finding a cleaver way to make those asynchronous events work would be a benediction, for now we just have AJAX, and saves, and now local storage, and yet people stuggles when dealing with that, sure a trigger is the current way of doing it, and it is not a real issue with storage (as saving datas should be something done at one specific point rather than constently in game) but as more and more feature would go that way, it will become unusable pretty quickly.

Async storage is not the problem, Async events are in general tricky to use, as they go against the spirit of the event system. And we cannot just say "No" to those, as they can be pretty useful, so a solution has to be found.

Agree, which I *hope* will be implemented, maybe the load event can have the option to wait until the trigger happen, get that data from the returned trigger and assign it to the variable so that at the front end, it behaves JUST LIKE the good old friendly webstorage.

Or else, we will soon have to say good bye to really simple one line codes like this:

For this *new* & *improved* method that do in multiple lines, what can be done in one line in the past, YEAH UPGRADE !

Who needs a cell phone when you have cups and strings !

Let's rub two woods together to make fire, it's *better* because it takes more effort !

It's true that this new system is definitely overall harder to work with. However, maybe what we should be asking is, are our current Webstorage practices bad? I currently use Webstorage as a replacement for variables all over the place, and very often set its values every tick. Maybe that's acually in general bad practice? Disk I/O is expensive after all (afaik), and (maybe?) won't show up in CPU usage tables.

Could just be another case of C2 making something 'too' easy.

I think the manual could do with a lot more written on 'best practices'. It could alleviate a lot of confusion at times like this.

It's true that this new system is definitely overall harder to work with. However, maybe what we should be asking is, are our current Webstorage practices bad? I currently use Webstorage as a replacement for variables all over the place, and very often set its values every tick. Maybe that's acually in general bad practice? Disk I/O is expensive after all (afaik), and (maybe?) won't show up in CPU usage tables.

Could just be another case of C2 making something 'too' easy.

I think the manual could do with a lot more written on 'best practices'. It could alleviate a lot of confusion at times like this.

Indeed saving the datas in other places than memory is something you normally do on specific occasions, not on a current basis, here are some exemples:

-save points in many early games

-pause screen with a save option in most PC games (the user chooses when to actually save, and so, no need to save constantly)

-automatic save of data between level transitions

-in game and watch gallery, the game would actually save when pausing the game, so if the player quits it, when turning the power on again, it will remuse the gameplay.

-etc..

All in all, treating a save (and this local storage one Particularly) like a non-local save seems to actually be the way to handle it: when you save data over to a server, you cannot think it will be back instantly, this seems to work in a similar way, perhaps having this in mind may be easier, having the lowest number of data to save, and knowing when it is a necessity to actually save them or retrieve them, the same way you would do if they were on a distant server.

At least this is how it seems to work.