I’m trying to make a collectible item that’s only visible on the client’s side, think grass cutting incremental, which has each person having their own field and own grass to cut specific to them.
I’m not entirely sure how to design this in an exploit-safe way. Currently, I have collectibles in a folder in replicated storage, which holds the model of the collectible, with an int value of worth within. The idea is that it can then be cloned using a local script, invoked by a server script.
Now the problem is, I know a remote function is probably the best way to handle this, with values adding to the player only happening server side to curb exploitation, but I’ve drawn a complete blank on how to even do this.
I made the mistake of making it all server-side at first, (yes, even the collectible spawning, which obviously isn’t going to work too well for local-only collectibles) and had to completely scrap the code due to that, and making it local-only has presented me with a much bigger hurdle than I thought, especially because there aren’t many articles that I could find on here alluding specifically to local only collectibles. (Local parts and collectibles themselves are well documented from what I can see, but not the combination of the two)
Part of me is thinking to go the talent hub route, but I’m not 100% sure of its reliability as a hiring tool, though that’s irrelevant.
TL:DR, what is the best way to handle client-side only collectibles in an exploitation-safe manner? And how would one go around using remote functions to achieve this, if that’s even the best way to do so?
You could register the existence of the collectible on the server without rendering it in the workspace, for example you could cache the data in the player object
Then, you can use a sanity check on the server to check if the collectible exists:
if player.Collectibles:FindFirstChild(CollectableName) then
Determining when collectibles show should be handled by the server, and should fire the client when this happens to show the collectible in the workspace.
But if I could extend the question a tad, since I’m not 100% sure if it’d translate fully… Here’s an example screenshot, from when they were still being placed server-side.
Much like Grass cutting inc it has random placement on the field that’s taking clones of a model from replicated, with a tier (which affects which model is used) and value assigned within the model itself. So randomly placed, limited amount, regenerating more when the current amount of entities does not equal max amount.
With that in mind is that still a viable option? I hope asking isn’t too annoying, I just don’t want to run into any roadblocks that cause me to need to rewrite the ENTIRE code again.
@Nightfall_Intuition is suggesting that you have the server define what the collectable is and where it exists, then send a remote to the client to render it. then whenever the client wants to pick it up then send a message to the server, verify the item exists + the item is close enough
you can have a dictionary of items with an id for each, (generated from HTTPService:GenerateGuid())
