tarrdo
|
  |
| Joined: 24 Jun 2008 |
| Total Posts: 476 |
|
|
| 26 Jul 2014 11:07 AM |
| How do I use data store to save backpack? |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 11:24 AM |
| Associate each tool with a value and save those values. When you load the data, take those values to see which tools they should have. |
|
|
| Report Abuse |
|
|
tarrdo
|
  |
| Joined: 24 Jun 2008 |
| Total Posts: 476 |
|
|
| 26 Jul 2014 07:56 PM |
| Is that not data persistence not data store? |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 07:58 PM |
| Do NOT use data store. It's more likely to error when the GetAsync cashes. It's safer to use data persistence with an object value. I tried learning data store and it sucks, really badly. it's too limited. |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 08:26 PM |
| Data Persistance is outdated, Data Stores allow inter place data transfer and the saving of far more data. |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 08:28 PM |
| @Notunknown Data persistence is unreliable at times, too. |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:13 PM |
| You can't save instances with data store, no matter what, making it useless, and extremely stupid. |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:15 PM |
| @accomplishable: nope! If you are saving instances, you are probably doing it wrong. |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:18 PM |
" nope! If you are saving instances, you are probably doing it wrong."
Proving my point. It cannot save instances, making it useless. And, it's just as unreliable as data persistence, since the GetAsync cashes |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:20 PM |
No.
You should NEVER be storing instances. If you are, you have gone wrong somewhere. |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:22 PM |
| How else do you expect people to load thing likes backpacks, morphs, and such? Not everything is int and number values for boring, dumb old data store. There's more to games than that |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:25 PM |
local contents = {}
for k, v in next, backpack:GetChildren() do contents[k] = v.Name end
Save(contents) |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:26 PM |
| Your script wouldn't even do anything, and Save is a nil. I'm not stupid. |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:29 PM |
| I am on an iPad. Do you really expect me to go through all the steps. You should be capable of writing the Save function yourself. |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:36 PM |
This is a fiery battle!
While I accept that DataPersistence is much easier to use than DataStores, it has one major problem, and that is that ROBLOX may stop supporting it at any time.
GetAsync caches: are they a problem? Well, compared to DataPersistence, no. If you're emulating DataPersistence (data saved on a per-player basis), you need to load for a player when they enter the game, and never load after that. Caching is no big deal.
Saving instances: DataPersistence takes the cake. Sometimes saving instances is just easy and nice. On Maelstronomer's island building game, you can save your creations, and you can save MANY parts. I'm sure it wasn't that hard for him to build, too! I'm working on a DataStore building game, and turning parts into strings is a pain. (See, pain: http://www.roblox.com/Forum/ShowPost.aspx?PostID=141624141#141682801)
Anyway, in this scenario, you should really use the tool names (strings), not the instances to save them. And, take a look here: http://www.roblox.com/PlayerDataStore-Module-item?id=159129148
That might help you out!
Happy scripting. |
|
|
| Report Abuse |
|
|
|
| 26 Jul 2014 09:38 PM |
| @blobbyblob: unless you are saving scripts (why do that?) it's better to save the parts data than the parts themselves, or use CreatePlace/SavePlace |
|
|
| Report Abuse |
|
|