Question about the new "Local Storage" plugin

— agreed fully on the "good practices", we should have some design indications like "a save should be done only at specific points, not constantly.

Reasons:

-reading and writing from the memory is fast enough to happen on a quick regular basis, but from a physical disk it is slow and you should not try to access those constantly

-if something goes wrong, you might prefer that the user have a valid savepoint rather than a save with elements that may contradict each others due to the fact a part of the save happened mid level before crashing, and another at the start."

I am currently halting my game development to see if there will be any new *improvements* to the local storage plug-in like an internal option to make it behave like the old thing by having the local storage do the request and pause the program until a return value is returned, maybe if by the next update there is no more improvement to be made for the local plug-in, I might give up and messify my code with this new and improved plug-in that can do in many lines, what used to take one line of code.

I am holding a stop sign to my project and crossing my fingers.

I am currently halting my game development to see if there will be any new *improvements* to the local storage

why not simply skip this update? it is afterall a beta version.. I just updated to r200 a couple weeks ago, I was on r187 since Nov because of jank issues. There's always the potential for some update that will break your code or force you to rework things a bit... it's par for the course.

'2012 me' would have implemented it a very different way if he knew any better. But due to a lack of best practices documentation, he really didn't know what to do. 2012 me didn't even know what file I/O was!

understood... '2013 me' made a mess of my intricate UI system because I didn't fully grasp picking (and a number of other things)... and now to go back, it's like ugh.. I did overhaul one area and it took a week to actually insert it into my game.

I am currently halting my game development to see if there will be any new *improvements* to ...

Never do this. Work on some other aspect of the game. You stand the risk of never finnishing the game. Features, updates, improvements, new tech is all happening and waits for no one. Do what you can with what you have.

why not simply skip this update? it is afterall a beta version.. I just updated to r200 a couple weeks ago, I was on r187 since Nov because of jank issues. There's always the potential for some update that will break your code or force you to rework things a bit... it's par for the course.

Because the saving mechanism is very *integrated* into the coding structure in my game, the idea that I will have to change this very basic of things later on through an ever increasing amount of lines really scares me.

I rather wait for one more release, if really no hope for an improvement for this *new awesome* plugin, then I will go back in fix all the codes and accommodate this awesome bothersome local storage system that makes you wish for a time where improvements actually means improvement and wish the next construct 2 upgrade doesn't come with another awesome feature that requires you to do the following step before you can destroy an object:

Destroying an Object in the next version of construct 2 the same way webstorage is changed in local storage.

Step 1: Call *Is object ready to be destroyed*.

Step 2: A Trigger is return later because parallel processing and all the awesome thing because F you that's why to let you know you can destroy the object now.

Step 3: Now you are allowed to actually called an action called *Actually destroy the object for real now.*

In later more awesome updates, every trigger in Construct 2 will require another trigger before it because F you that's why !

And parallel processing and all that crap.

Because Reasons !

Yeah !

Toddler, your saving to webstorage should be put into a function "Save Data" and you use that function everywhere. That way you only change your function which is 3 or so events.

Never repeat code.

So when you have to make changes... you only change the function. The same is for everything and anything that is dublicated. I create a variable so that I only have to change the variable and it changes throughout the project. Good coding practice.

Variable constant. example DiceNumber = 6 or Main Character name = "Luke" Main character Surname = "Skywalker" etc etc

Of course the variables get excessive, that is why I use dictionary, and have a fetch data function, but whatever floats your boat.

Also you can add params to save any number of various things (The code is the same, the outcome will be different based on params)

Toddler funnily enough, I am pretty sure the destroying mechanic actually works like that, it just appear to be destroyed when you call the action, but actually is not yet (and might not be due to recycling).

as for the save, for retrocompatibility reasons, having a seemingly synchronous in option would be nice, as webstorage, while still being there, is still likely to be dropped.

That's why !

You got it —

The original post on this thread stated "I suppose this will come a little bit later, but a manual entry for it would also be greatly appreciated. "

Is there anything out there that describes Local Storage and explains how to use it? I have searched and cannot seem to find anything other than people showing small examples of their work. Not a complaint, but I find it odd to recommend changing code we have written to a new feature without giving any documentation about the new feature. Any help would be greatly appreciated. Thanks.

CDogs1964 they normally don't add manual entry's for new feature until it is in a stable build

as of to today local storage in out of beta as a stable build was released so they have made a manual entry detailing its actions and conditions https://www.scirra.com/manual/188/local-storage

Ok, lost track of the number of times I've tried to post what was to be my first post.

For those like myself that need a little more help re loading and saving from local storage here (I hope) is a simple example capx.

mega.co.nz

As — and Aphrodite have said, use a Dictionary. Just load it from Local Storage when your game starts and save it only when needed, such as when changing level, exiting the options screen, game over screen etc.

I've just switched my project from WebStorage to LocalStorage just now. It seemed quite cumbersome until I've started using the Dictionary method and now it's nice and easy.

Async data loading is generally better because it doesn't freeze your game when loading and the standard for many other engines/coding languages (C#, Flash for example). I know most Construct games won't have loads of data to load but you also have to remember that one of the targets for Construct 2 games is the mobile market where the games won't perform as well as on PC and any bit of optimisation welcome.

I made a capx as well and used a dictionary which from what I have learned is a good way to go if you have a 'lot' of info being stored with the Local Storage plug-in.

https://www.dropbox.com/s/61kstfx7pbr3j ... .capx?dl=0