search

overextended / ox_inventory

Slot-based inventory with metadata.
https://overextended.dev/ox_inventory
GNU General Public License v3.0
467 stars 706 forks source link

Police Evidence Lockers Trim Leading 0s #1230

Closed Manason closed 1 year ago

Manason commented 1 year ago

Describe the bug Asking to see Locker 09 brings up Locker 9, despite both 09 and 9 existing as different evidence lockers within the database

To Reproduce Steps to reproduce the behavior:

  1. Create two evidence lockers in the db, 09 and 9 with different items in each
  2. in-game, enter attempt to retrieve 09's locker

Expected behavior Entering locker 09 would bring locker 09. Locker ids should not be converted to numbers if that's the root cause.

Additional context QB supports the leading 0s and police in my server use them to denote contextual meaning.

thelindat commented 1 year ago

Leading zeros kind of weird, and what context do they give? Supporting it would be trivial, but having extra lockers "09, 009, 0009, 0000000000000000000000000000009" isn't very intuitive.

Manason commented 1 year ago

Leading zeros kind of weird, and what context do they give? Supporting it would be trivial, but having extra lockers "09, 009, 0009, 0000000000000000000000000000009" isn't very intuitive.

In the MDT we use, we have incidents and reports, each with their own incrementing number. We append a 0 before report numbers to avoid conflicts with incidents. Because you could have incident 799 and report 799, so we'll use locker 0799 for the report and 799 for the incident.

thelindat commented 1 year ago

Hardly an inventory issue, and numbering iterations like that a just a workaround. It “works” because arbitrary input for qb.

I assume locker poopybuttface is also valid.

Manason commented 1 year ago

Hardly an inventory issue, and numbering iterations like that a just a workaround. It “works” because arbitrary input for qb.

I assume locker poopybuttface is also valid.

Whats wrong with that? I don't see the benefit to being restrictive on locker ids unless we use the properties of numbers in some way. Otherwise it makes sense to me that ids are strings. One use case would be entering driver license ids for locker ids, or character names. It's currently needlessly restrictive.

thelindat commented 1 year ago

Whats wrong with that?

It's supposed to be a number, not a random string.

It's currently needlessly restrictive.

Expectedly limited to a specific use-case; but qb is designed around the ultimate freedom of the client being allowed to do anything they feel like.

Internal stash stuff (which evidence ultimately still is) is basically deprecated in favour of RegisterStash and externally handled zones/markers/whatever.

Manason commented 1 year ago

I've done this for myself by checking that all characters of the string are digits rather than converting the string to a number. If you change your mind and want it PR'd in the future, let me know.