if i wanted to create a unique serial system system, like Criminality’s, by RVVZ, how would i go about this without exceeding rate limits while keeping it on the roblox platform?
for those who don’t know, in criminality, serials are sorted one after another, say your skin has a serial of #26, next player to unbox that skin will get #27
i am looking to achieve the same effect while using only roblox’s services, an idea i had was to use MemoryStoreService, for short term caching, in combination with DataStoreService, for long term
--// Services
local DataStoreService = game:GetService('DataStoreService')
local MemoryStoreService = game:GetService('MemoryStoreService')
--// Storage
local StoreName = 'SKIN.SERIALS.1'
local SerialDataStore = DataStoreService:GetDataStore(StoreName)
local SerialHashMap = MemoryStoreService:GetHashMap(StoreName)
local SerialManager = {}
local StaticSkin = {}
StaticSkin.__index = StaticSkin
function StaticSkin:AddEntryAsync()
local newSerial = nil
SerialHashMap:UpdateAsync(self.Name, function(value)
newSerial = value + 1
self.Serials = newSerial
return newSerial
end, 3600 * 24)
return newSerial
end
function StaticSkin:GetSerialsAsync()
local Serials = SerialHashMap:GetAsync(self.Name)
self.Serials = Serials
return Serials
end
function SerialManager.new(Skin: string)
local self = setmetatable({}, StaticSkin)
self.Name = Skin
self.Serials = self:GetSerialsAsync()
return self
end
return SerialManager
this is the concept module i made, obviously it is unpracticed considering i want high traffic in many servers to just test it, which i have no idea how to do unless i just use alts and while loops
ive thought about using GUID, but i want to save these skins in a datastore with other player data and i am afraid i will somehow exceed the 4mb limit of data, i want to keep inventories limitless
i know 4mb is a lot of data but i feel like every byte counts, maybe im dramatic?
maybe i could temporarily tie the GUID with the # serial in the hashmap, what do you think?
main issue would be the limitations if you were to keep a serial using either memory store or datastore, reason being, you would need to store a counter of how many of each item has been created and update it without delay, if it delays at all then you can potentially end up with 2 servers queing at the same time for the same serial id.
meaning it would likely require a timestamp along with messaging service to actually be 100% acurate without duplicates.
You can easily make multiple datatstores per player on the other hand making guid viable
the limitations on more than 1 per player is significantly less usage compared to updating per item
^ on that note, you can estimate the size of the save file and make split the inventory into multiple stores based off the size, basically you can work out the rough bytes per item and add a buffer, then use that as the cutoff per segment of the store, as for the serial you could potentially still use that system but its unbelivably demanding on limitations to do so
What id prob reccomend at this point would be using guid to prevent duplicates and using httpservice with a webpage or text storage service to keep track of the serial, then using messaging service to quickly update other servers when a serial is taken to increment the serial count on an item. this means you wont have to constantly fetch the count and could probably designate a single server at a time to update or fetch the values and depend more on messaging service to update serial count on each item
i believe an approach utilizing messagingservice for cross server updating, memorystoreservice for caching, and datastoreservice for storage could work, at least theoretically it should since you get additional request limits for each player
Guid’s generated by GenerateGUID() are 36 characters long. The limit is a bit above 4 million characters, if you divide 4 million by 36, you get 111 thousands. So if you store just guids, you can store more than 111k guids