Strings as IDs instead of number IDs


ID numbers proved to be finite in Unturned 3.0 unless if it were to change for UII. But it can prove to be not too specific and prone to ID conflicts. I think in my opinion that it’s better to make IDs rely on strings instead of numbers because it is more versatile than the ID system we use today.


The way that this new ID system works is that the IDs are typed into words instead of numbers. This makes it so that it highlights a specific item while giving the exact idea of what it is.

Here are a few examples you might understand:

  • Eaglefire - 4 to eaglefire_m4a1
  • Russian APC - 119 to vodnik_apc
  • Spotlight - 459 to spotlight_placeable

Here, we notice a massive difference. If you compare from left to right, you’ll notice that my suggested ID structures are more specific & point out that exact item than the numbers that don’t really point it out & would usually conflict with other IDs.


Why you may say? If you look back at the current Unturned workshop, you’ll notice that publishers have content that conflict with another. Usually, the publishers struggle with the ID conflicts & other publishers doesn’t have the time to update their workshop mods for a while or not anymore. In other times, people don’t seem to be comfortable with the IDs not being specific by first glance, especially for newer players. In rare cases, they can be forgotten because they don’t give clues to what exactly are they.


They hold their functions & features that are beneficial &/or unique to them. But that doesn’t mean that either of them has all that it takes to be perfect. Here we simply summarize the 3 strengths each other have &/or what is unique to them.

ID strings over ID numbers:

  • Specifies exactly what a certain item, vehicle, etc is.
  • Its structure makes a visual clue of what the item, vehicle, etc is.
  • Rarely prone to ID conflicts.

ID numbers over ID strings:

  • Straight to the point although not specific to the item.
  • Compact.
  • IDs can be typed in quicker.

They have benefits over one another, with some unlisted neutral features that I didn’t add. After all, it’s natural that they have features that are better than another.


Some people would say that it can co-exist since a person can simply set the ID to a number as usual. But if you compare the usability between strings & numbers, the only thing that’s being compared here is the versatility versus speed & size. Number IDs are quick & compact but aren’t showing clues to what is in the ID while being prone to ID conflicts. String IDs, on the other hand, are extremely versatile, specific & rarely prone to ID conflicts.

Don’t get me wrong. I would keep the normal number ID system but then if string IDs are UII’s new feature which is more versatile & would very unlikely encounter ID conflicts, it renders the number IDs useless against that argument. There would be little to no point of using them after. String IDs have a structure that is extremely usable & flexible & would outdo the number IDs nonetheless.


String IDs are a must for Unturned 4 to have ID consistency for the long run of the game, especially when most of the possibilities are from the community itself. Most of the time there would be new content, not monthly, but also daily. Many people would see this as a win because there would be no limit & almost no flaw to the insane amount of content the people, curated creators, & even Nelson Sexton himself to create. This is would be a great addition to UII & I would be happy to see this become added into the game eventually.

What do you think about all this? As a topic, comment down below about anything you have to say about it. It’s an open suggestion so I’d as well be open to what you may say.


Good suggestion!:+1:


This is one of the few suggestions that has no negative sides to it that i know/think of, very nice.



Sounds really great! As a modded it can sometimes be hard to figure out which ID ranges to use, so having strings would simplify the process a whole lot more.

1 Like

Would also be nice if there was some sort of autofill/suggestion/abbreviation feature to regain any speed or convenience from the brevity of the numerical IDs.

1 Like

But what happens if two string IDs do conflict? I can assume that there would easily be conflict in mods that have the same items, like gun and clothing mods, as there probably would be at least a dozen mods that would have “gorka_top” as an ID.

Also, what if the game automatically assigned the string ID based on the file name?

1 Like

Installing mods by priority then, if conflict occurs, a higher priority item will be assigned to an ID.

One can simply change it. That’s all. If the item conflicts like that, just change fro “gorka_top” to “tgydk_gorka_top”. Easy as it is. Bruh.

Edit: Who would be silly enough to not think that eventually something else will also be a gorka top lmfao :rofl: :joy:

(is joke, please no mad)


I’d prefer a combination of strings and numbers. Here’s an example on what I mean assuming there are four door variants sharing the same regular number ID.


With this example, the ID number and the string ID are created by the user and conflicts are allowed. The “Generated ID” is included as a way to deal with intentional and accidental conflicts. If a conflict happens like in the example, calling ID 50 would always refer to the Birch Door and you would have to use the string ID or include the “:x” part to refer to a different door variant. If two string IDs conflict, a “_x” is added on with “_0” being the first one that loaded in.


Yes, please let this be a thing. It’s a nightmare with the contradicting Number IDs out there.

1 Like

For modded items we could do what Minecraft does and have the mod name (eg ‘cool_mod’) in front of the ID so it can be distinguished. For example, cool_mod:cool_item and cooler_mod:cool_item wouldn’t conflict.

1 Like

Makes a lot of sense. Please, let it be a thing.

This suggestion (and ideas in comments) do make a lot of sense, and ideally we would go do this direction. Unfortunately the limiting factors are both the huge amount of code that use 16-bit IDs, and the sheer amount of content as well.

Initially 16-bit IDs were chosen (in 2014) in order to reduce bandwidth required to replicate items, vehicles, animals, etc, but in hindsight that was obviously a poor decision.

Later on (~2017) there was some work started to resolve this by using GUIDs. You may have noticed that each asset file generates a random GUID, which is a 128-bit number. For network purposes the server and client reconcile a GUID lookup table which maps GUIDs to 16-bit IDs and vice versa.

Objects properly use this and actually ignore the 16-bit IDs except when loading old maps, but the undertaking to make a similar change for items or another system is daunting. It might still happen, but it’s been lower priority than other stuff. Until that’s eventually tidied up there have been some placeholder workarounds like server workshop items overriding existing IDs.

As mentioned about 4.0: yes, strings / path names are used rather than numeric IDs thankfully. One issue this does bring up is dealing with renamed assets when loading savedata, but a workaround is to setup name redirects. I’m planning to do some work on this in the future to make it more automatic however.


Understandable Nelson, do what ID system feels best for you.

Only if we have TAB like in Minecraft

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