Great Robloxian Bug Hunt

Sometimes players are losing their farms. I’m using Google Analytics to catch errors and nothing is showing up that would cause complete barn data loss. I’m willing to offer a reward to anyone that can either find a bug in my code that’s causing the rare and random data loss or can improve the saving system while keeping it backwards compatible. I’m willing to negotiate compensation based on what you are able to tell me or even fix yourself. I’ll add you to Little Creek as a given (7k R$ value) and depending on what you fix I suppose I could spare 5k-15k R$ after taxes.

Barn Saving Code: Barn Storge System - Pastebin.com (Warning: long; also, a good bit of the code is for serializing and deserializing objects and probably isn’t related to data losses.)

Well, line 167 should be wrapped in a pcall. Other then that, I find it difficult to read your code and find the problem myself.

local RegionDataStore = game:GetService("DataStoreService"):GetDataStore("RegionStorage")

I don’t think anyone here is too eager to read and thoroughly comprehend 700+ lines of code. Perhaps you could narrow down the issue a bit?

While it’s a huge mess, this very likely causes it:

local success, why = pcall(function()
    for i, v in pairs( savePieces )do
        --print( i )
        RegionDataStore:SetAsync("REGION_" .. Player.userId .. "_" .. i, v)
        CurrentPlayerData[Player.userId][4][i] = "REGION_" .. Player.userId .. "_" .. i
    end
end)

You’re overriding the key REGION_userid_i every time, if it fails halfway through (say there are 5 pieces, it errors at i = 3, you have succesfully saved 2 “pieces” of data, while the older data is still in i > 3 (depending on how many pieces there were in the previous save). It’s easy to realize that you end up with corrupted data. When trying to load this, it’ll obviously fail to parse completely.

You should store data, when using such a “partitioned” system, in different keys from the last succesfull save. When all segments have saved successfully, change some indicator in another key to point to these new keys. If it fails halfway through, that pointer should still be pointing to the older keys you haven’t touched (so in the worst case you’ll fall back to the previous version instead of corrupting it all).
So you can either toggle between two keys, say REGION_userid_i_evenorodd, or increment a counter for each save and use fresh keys for each save: REGION_userid_i_revision.

Too bad Roblox doesn’t support transactional writes to multiple keys, that would simplify solving it a lot, but you’ll probably have to create such a simple system yourself for now ;).

1 Like

If line 167 fails to work the game is toast anyways :frowning: The user will get told that saving is screwed up on their end.

I have a custom parser and I always assumed corrupted data wouldn’t be the issue. Really stupid and silly assumption. I have actually changed over to sticking math.floor(tick())%1451700000 to the end of every key. The system already will not update the main key if the data doesn’t save but overwriting could be causing issues.

I DIDN’T HANDLE THE ERROR IN THE LOAD REGION FUNCTION!!!

I have a pcall but if the load fails I just pass the bad data as if there was no issue loading it. I need to actually error so the exterior pcall catches the issue and the load system doesn’t try loading an empty farm. Oh goodness.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.