Strings as IDs instead of number IDs

Unturned II U4 Discussion
1

INTRODUCTION

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.

DEFINITION

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?

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.

ID STRINGS VS ID NUMBERS

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.

CO-EXISTENCE & AN OPTION

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.

CONCLUSION

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.

41 Likes
2

Good suggestion!:+1:

2 Likes
3

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

:+1:

3 Likes
4

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
5

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
6

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
7

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

8

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)

3 Likes
9

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.

image

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.

3 Likes
10

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

1 Like
11

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
12

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

13

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.

26 Likes
14

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

15

Only if we have TAB like in Minecraft

16

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