This issue is affecting both hashmaps and sortedmaps, haven’t tested queues.
Upon using SetAsync() or GetAsync() on either environment (Studio Play Solo or In-Experience), the data between them is shared, and not separate as the intended behavior would suggest.
This means that studio memory stores are able to access and edit memory store data from the live experience.
Reproduction Steps:
create a new empty baseplate
publish the file to a new experience
from a script save data to a memorystore hash/sorted map in studio
from in-game load the data from the same key
view script used in example video
local mms = game:GetService('MemoryStoreService')
local ps = game:GetService('Players')
local hashmap = mms:GetHashMap('hash')
local sortmap = mms:GetSortedMap('sort')
local hint = Instance.new('Hint', workspace)
--saves chatted string to either hashmap or sortmap
ps.PlayerAdded:Connect(function(player)
player.Chatted:Connect(function(msg)
local command = msg:sub(1,4)
local remaining = msg:sub(#command+2)
if command == 'hash' then
hashmap:SetAsync(player.UserId, remaining, 24*60*60)
hint.Text = `set hashmap [{player.Name}.UserId] [{remaining}]`
elseif command == 'sort' then
sortmap:SetAsync(player.UserId, remaining, 24*60*60)
hint.Text = `set sortmap [{player.Name}.UserId] [{remaining}]`
end
if command == 'show' then
if remaining:match('hash') then
local saved = hashmap:GetAsync(player.UserId)
hint.Text = `got [{saved}]`
elseif remaining:match('sort') then
local saved = sortmap:GetAsync(player.UserId)
hint.Text = `got [{saved}]`
end
end
end)
end)
Honestly I’m with Tomi on this and this isn’t a bug this would be a feature request more so, a not so needed one as you can easily just do this code
local mms = game:GetService('MemoryStoreService')
local ps = game:GetService('Players')
local runservice = game:GetService(`RunService`)
local studioKey = if runservice:IsStudio() then '0' else '1'
local hashmap = mms:GetHashMap(`{studioKey}_hash`)
local sortmap = mms:GetSortedMap(`{studioKey}_sort`)
local hint = Instance.new('Hint', workspace)
--saves chatted string to either hashmap or sortmap
ps.PlayerAdded:Connect(function(player)
player.Chatted:Connect(function(msg)
local command = msg:sub(1,4)
local remaining = msg:sub(#command+2)
if command == 'hash' then
hashmap:SetAsync(player.UserId, remaining, 24*60*60)
hint.Text = `set hashmap [{player.Name}.UserId] [{remaining}]`
elseif command == 'sort' then
sortmap:SetAsync(player.UserId, remaining, 24*60*60)
hint.Text = `set sortmap [{player.Name}.UserId] [{remaining}]`
end
if command == 'show' then
if remaining:match('hash') then
local saved = hashmap:GetAsync(player.UserId)
hint.Text = `hash | got [{saved}]`
elseif remaining:match('sort') then
local saved = sortmap:GetAsync(player.UserId)
hint.Text = `sort | got [{saved}]`
end
end
end)
end)
People do this with datastore systems all the time you can have a mock datastore in studio and a different one for in-game or if you prefer to have everything running off the same system just run it off the same entry. It’s really up to you as the developer on if you simply want to use a different memorystore key or not.
Well, it definitely is a bug as the documentation (and devforum announcement posts) clearly state that the data between studio and lives games is separate
But it is quite odd to have memory stores be separate, but not datastores, creating a discrepancy between the two, which is notably undesirable if using memory stores in conjunction with datastores.
Moreover, it is possible, as you have stated, to simply use a different datastore, but it isn’t possible to do the inverse with memory stores (getting the “same” memory store)
Not sure Roblox would change this behaviour of memory stores as they have been released for a short while now, and this could be a problematic change if developers expect memory stores to be different (for queues at least, or for those unaffected?)