In the specification, he asked for a system where you can claim cash based on clicking on a button, thus this would be required. Sure, in a automated system where you earn it automatically, this would work, but he needs a system that works with events.
Additionally, the code is to prevent abuse of the remote, rather than rule out his method entirely.
Are you sure this is how it works? nil isnât something that is necessary to be stored in memory, since itâs literally nothing, so even if lua would make t[3] = 3 into {nil,nil,3}, the nils shouldnât occupy the memory, as they are only the mark that there is no value under the keys 1 and 2, not that their value is an actual nil.
Forgive me - I misread. 
I could be wrong, and yes you are right about how nil values obviously donât occupy memory. It wasnât really that itâd occupy memory, it was more-so that I remember t[1000] = 1 being effectively the same as for i = 1,999 do t[i] = nil end t[1000] = 1 internally on the C-side, making it a more CPU-intensive calculation. It was something that I distinctly remember being prevalent back in the day. You could even crash games back then by setting a high index number. But I canât find anything on it in the documentation. Iâm going to do some more digging on the subject as Iâm interested now heh, perhaps I made an oopsy there. It doesnât really make sense either way, I just somehow distinctly remember that being a thing.
At any rate, for the moment, I will say I still think itâd be better to use the Player object as thatâs just a memory reference to something already in the memory. And in this case, heâd need to use game.Players:GetPlayerFromUserId which is just another calculation, although not intensive by any means, itâs still not necessary either in my opinion.
I donât think it does that. I just asked my friend (who reads lua source on a daily basis) and they said the same.
Moreover this code prints 0:
local t = {}
local a = os.time()
t[9e9] = 1
print(os.time() - a)I started thinking about this question a little more and I figured; why not just change the approach here? I find that this is backwards. Instead of the client telling the server that itâs ready to claim a reward, have the server tell the client that itâs been given a reward.
Over having the client click a button to claim a cash reward, change the logic. The server will update the cash on itâs side and then tell the client, via a remote, that they received a cash reward. The client will then display a Gui showing what cash was awarded and they can click claim. When claim is clicked, the client animates their cash value up until it reaches the appropriate goal (current + reward).
This way, itâs impossible to abuse a remote because the server isnât taking any requests from the client. You also keep the functionality you wanted. The backend may differ but players wonât see that.
cc @NinjoOnline