I got it. I’m just saying, it probably saves but you are probably assigning default values to the buttons. That might be the reason you are not seeing the proper outcome.
Can you confirm that it doesn’t save by looking at project sandbox?
I got it. I’m just saying, it probably saves but you are probably assigning default values to the buttons. That might be the reason you are not seeing the proper outcome.
Can you confirm that it doesn’t save by looking at project sandbox?
While display objects are technically a table, they have a lot of other information with them like the graphical object. The load-save stuff wasn’t designed around saving something like that instead it wants to save tables of strings and numbers and true/false values. It wasn’t meant to save the state of display objects. You may need a separate table that holds data about your object that you want to preserve and when you load it in, then you can apply that data back to the display objects.
Rob
Bgmadclown, Its doesn’t saves definitely.
Rob, that’s means that all data needs to be referred by writing it in before updating, but if there is a lot of objects its not efficient. Or if data would be passed into empty table how it would be applied for that specific object from which data was retrieved after updating? How to find what is what? And anyway I don’t see here how data from loop can be passed to the table without passing the object[i] itself with intention to assign it to the same object[i] again.
Let me back up a bit on this. The only time you actually need to load data is if your app exits for some reason, such as a crash or the user kills the app. iOS users don’t kill their apps that often, but Android users do with more frequency. Because of this, you should reasonably save data after you make a change to it, but the information will stay in memory until the app exists, this means you only need to load once.
All display objects will get re-created when the app starts. You can’t save them because the memory addresses for the textures are very likely going to be different each time the app runs. Since it seems you want to have a list of characters that are unlocked or not, maybe you should consider a table like (since I don’t know your game I’m going make up stuff):
local availableCharacters = {}
availableCharacters[1] = {}
availableCharacters[1].name = “Meanie Greenie”
availableCharacters[1].filename = “image1.png”
availableCharacters[1].unlocked = true
availableCharacters[2] = {}
availableCharacters[2].name = “Rocket Red”
availableCharacters[2].filename = “image2.png”
availableCharacters[2].unlocked = false
availableCharacters[3] = {}
availableCharacters[3].name = “Blue the Clue finder”
availableCharacters[3].filename = “image3.png”
availableCharacters[3].unlocked = false
Then you can use loadSave to save and load this table. When you load it and you need to generate your scene, you can loop over the table to create each display object and at that point you know if its locked or not. Use the information in this table to determine what information you need to pass to display.newImage().
Rob
I knew it’s easy before I made it complicated. Very great explanation, thanks Rob.
Thanks for help guys.