I did not ask you to use task.wait
anywhere. Use breakpoints to investigate the downloading code. Attempt to disable auto updates
I used the break points to find top 15 because of how much it kept loading the same user over and over, all it did was load in the same user on the leaderboard. I’m not sure where else to put break points to find the problem. I did find out that it normally loads on the Wins leaderboard and everything else is repeated.
But a breakpoint on the break
keyword in your loop to confirm it is ending. You can also print out the index of the item to see how it’s progressing pages
The indexes for shreds and donations leaderboard do not stop at all and does not progress pages at all and stays at the first one. The only one that behaves correctly is the wins leaderboard.
Can you send GIFs or images? It would be easier to coordinate with your code rather than your statements
This was the printed updated code:
repeat
local currentPage = pages:GetCurrentPage()
for _, data in currentPage do
table.insert(top, data)
end
if pages.IsFinished or #currentPage == 0 then
break
else
pages:AdvanceToNextPageAsync()
end
print(self.DataStore, "Page", #currentPage)
until #top >= DISPLAY_COUNT
#currentPage
does not tell you about the objective index of the item. It tells you how many items are in the current page. You need to make your own incremental value, or print out the index in the the loop through currentPage
’s contents
oh
if I were to make my own, that would go until it errors or until it reaches max because it won’t stop until the loop is broken. I’m assuming that the page isn’t advancing because it’s the same player each time and the page isFinished bool is false. It usually forcefully stops at 16 or 17
No wait:
1 second wait:
This is the code I used to print out the indexes:
local pg = 0
repeat
local currentPage = pages:GetCurrentPage()
for _, data in currentPage do
table.insert(top, data)
end
if pages.IsFinished or #currentPage == 0 then
break
else
task.wait(1)
pages:AdvanceToNextPageAsync()
pg += 1
end
print(pg)
until #top >= DISPLAY_COUNT
The users do not display on the leaderboard if it gives a warning or error
Hm. Things just aren’t adding up. Can you add me to the place so I can take a full crack at this? If not, add me on Discord @ziffix and I’ll walk you through my personal debugging steps
I’ll need to look at your data. A copy won’t carry that over. I can try emulating if nothing else works for you
Join the group, it won’t let me give you access until then.
Here’s the game:
The Great Cheese War - Roblox
I have joined the group. Let me know when I have access
LeaderboardHandler is in ServerScriptService
LeaderboardSystem is in ReplicatedStorage → Services
Reply to this post with your changes once youre finished
I was not able to find any issues with your code. After testing the data-store, it seems that the “Donations” ordered data-store is corrupt. I first removed the record of the only apparent donation. When attempting to retrieve the maximum number of elements on a single page, the reported elements is 0. However, when reading .IsFinished
, the value is false. This is a clear contradiction, and should be reported as an engine bug. I moved your data-store to “DonationsB”, and restored the previous record. All seems to be working now
When hitting the last page of ordered datastore pages, IsFinished is bugged and never becomes true. Instead of lingering on the last page when calling advance(), it loops around to the first page for some reason. I worked around this by storing the first key of the first page and checking the first key of every subsequent page against that key
sample
ReadPageAndContinue = function(pages :DataStorePages, list :list, limit :uint, DelayTime :uint,
FirstKey :string?) :uint
local page = pages:GetCurrentPage()
--Duplicate loop around page check since IsFinished property is broken half the time
local CurrentPageFirstKey = page[1].key
if FirstKey and CurrentPageFirstKey == FirstKey then return 2 end
When using a separate ordered data-store, .IsFinished
began operating as normal; I’m not sure the issue is consistent, so it’s better to call that a fail-safe. I wonder what triggers the bug
Some user here says it might be older ordered datastores that are broken, but I created a bunch of ordered data stores in a test place, and half of them were bugged, and half of them were working. The test place was a couple months old and that might have to do with the bug too.