Hey all, this is a super basic plugin, not sure if anyone else finds themseleves in a position where they want to generate unique names for objects, but I encounter this issue quite frequently, this plugin makes it easy - just select the parts and click the button.
Works with CHS (ChangeHistoryService), if you mess up Ctrl+Z is your friend
Uses HttpService:GenerateGUID() which delivers a universally unique identifier, meaning no two parts will ever have the same name.
Generated GUIDs are saved locally to allow the ‘Check Duplicates’ function to work, where it will find duplicates of IDs in your game.
Just added a ‘Check Duplicates’ function. What’s the point in unique IDs if the IDs occur more than once in your game!? The plugin auto saves the GUIDs it creates on your computer on a per game basis (local), you can also search the full list of GUIDs you’ve ever generated in all games (global). The check duplicates function allows you to search all the GUIds the plugin has ever created, or just those in the game you’re currently developing in (incase you port assets over or republish a place).
Instances with duplicate GUIDs are auto selected (note that it only selects the extra instances, i.e. your game may have instances 1i, 2i & 3i with the same guid, this will only select 2i & 3i, not 1i) :
Just curious, but why would anyone not want the same name for parts in their place? Not saying like that i would want to its just why would you want them to have different names?
Hey, that’s a completely fair question - this is intended for allowing the parts/instances to be individually referenced/ saved in scripting. In my use case I’m using this for giving items in my game unique identifiers, allowing me to easily automatically save the items a player owns by it’s ID, instead of it’s name (just saving by the item’s name is generally very bad practice, as you then can’t change the name, and you can’t have two items with the same name without running into big issues). An alternative I sometimes use is storing item information in a ModuleScript indexed by IDs, that then references the asset instances, but this seems easier and possibly more efficient than that.
The duplicate checking exists for this exact reason - it would be very dangerous to have two items with the same ID as a player could own one and the other loads from their save, or they own both items when they only paid for one.
Thanks for the reply. Great explanation i appreciate it. Im actually making a system with the similar idea of using UUIDs but im using them to make each item unique.
New update for StringValues, putting it as a reply since it’s not a core mechanic of the plugin:
If you use the UID generation on StringValues you will be asked whether you would like to change the Value or Name property of these instances. (The duplication checker has been edited to check Value fields on StringValues too, so still works for finding StringValue duplicates).
I’d like to get into using GUIDS for my games however when I use it to name the part (in-game), I can’t really figure out how I could reference that object from other scripts which may not know the GUID. I’d appreciate it if anyone could give me some tips so I can jump right into using these in my games!
I use these as the identifier themselves. The item is globally referenced with a GUID, and everything else is a property of that item (name, price etc). Players don’t own item names, they own the item GUID, from my experience this is the most reliable way of doing it.
Correct me if I’m wrong - but if you stored stats on each client and used this you could potentially obfuscate the stats in a way to make it difficult for exploiters (FE mitigates a lot of this but still). You could even do this with core stuff (such as RemoteEvents) to break scripts that use these to exploit parts of a game. It would just require a little bit of work to modify the scripts to properly identify stuff even with a changed name. Like you could have string values or int values as children of an instance and it’s their respective value that actually identifies it as what’s needed. So like a script like:
Event1
Event2
for i, v in pairs(ReplicatedStorage:GetDescendants()) do
if v:IsA("IntValue") then
if v == "2" then
Event1 = v.Parent
end
if v == "3" then
Event2 = v.Parent
end
end
end
It might take a bit longer of a loading time (but really not that much) but it would absolutely break any script or loadstring that relies on knowing the event’s name.
(I have no idea if what I’m saying is actually that feasible, but still awesome plugin!)
This would not be effective solution to exploitation in any way.
Exploiters would simply track changes to the stats and cast judgment to what they are. Not that would matter considering there would be no point of hiding them due to the addition of FE. With regards to your notion about RemoteEvents; I’d imagine this wouldn’t affect exploiters at all either as they’d be able to deduce this by simply seing what arguments are being fed to the remote (a process that can be entirely automated). And if all else fails, they can simply hijack a reference to the RemoteEvent using debug methods through a LocalScript that relies on it.
You’re best off not opening these types of vulnerabilities to exploiters in the first place. Secure your remotes and you will not have an issue to worry about.
