30 Apr, 2010, Runter wrote in the 1st comment:
Votes: 0
Topic is in regards to using unique ID numbers as a means to interface with items in game as a player.

Example:

You are holding:
journal91254 a journal of the elements
manuscript116428 a bound manuscript
vial173129 a black glass vial
egg223252 an inlaid gemstone egg
marque244087 a marque of unquestioned seaworthiness
deck320831 a deck of black and gold cards
kit321137 an olivewood stationery kit


Small example inventory (taken from Achaea). The idea is you could interact with items with either keywords or with the id number. If you have 3 bags by the same you could interact with a specific id number that never changes. An alternative ID would be letting players assign unique tags to items they own. This has its own set of problems.

I'm looking for other solutions because I don't particularly like either solution. Any discussion on the topic is welcome.
30 Apr, 2010, David Haley wrote in the 2nd comment:
Votes: 0
Why not allow unique IDs, and require them only when there is ambiguity?

So you can always use keywords, and if your keywords ever match to several things, report the ambiguity and allow the player to view items' unique IDs. Then, if they request an item by unique ID, you're done. (You can have the unique ID display be a configurable option.)

What's wrong with this? Not sure how else you can uniquely identify an object; playing games with "the third iron long sword" leads to a great deal of trouble. Perhaps you could add more attributes: "the long sword that is half broken", although syntax for this starts becoming pretty nasty.
30 Apr, 2010, Idealiad wrote in the 3rd comment:
Votes: 0
I think it's great in theory but less so in practice, from an interface perspective – typing a string of even just four or five numbers is annoying.

Preferable IMO is to just use shorter ids – long sword 1, long sword 2 – then the player can 'get sword 1' or whatever. The view side doesn't have to be the same as the model side. The algorithm to number the items would maybe reserve a number for a while (30 minutes?) if its object is removed from play, to avoid the situation where a player makes something, refers to it, destroys it, then someone else drops a copy item into the same room.
30 Apr, 2010, David Haley wrote in the 4th comment:
Votes: 0
If you did something like that, you'd have to be very, very careful that IDs didn't change as you're looking at them. I agree that you can present a simpler model to the player, however you basically need to guarantee that those IDs won't change during the player's "interaction session" with the objects. (I won't define "interaction session" for now, but as an example leaving and returning to the room would create a new "interaction session".)
30 Apr, 2010, Idealiad wrote in the 5th comment:
Votes: 0
Agreed. I wonder if you couldn't number items based on allthe clone items in the game? Then just reserve numbers of items that are destroyed for 72 hours or so.
30 Apr, 2010, Runter wrote in the 6th comment:
Votes: 0
It seems like a reasonable approach but from what I've read players on games like achaea can expect ID numbers to always be the same. Letting them write alias or script with addons with them in mind.
30 Apr, 2010, flumpy wrote in the 7th comment:
Votes: 0
I guess if you use some sort of DB the primary key or a key pair could be used.
30 Apr, 2010, Orrin wrote in the 8th comment:
Votes: 0
I use a combination of keywords, relative numbering and unique IDs so players can use whatever method works best for them in the circumstances. So for example if you had several swords you could refer to 2.sword for the second, 3.sword for the third etc, or to sword2121, sword3892, etc or as a shorter form just 2121 or 3892.

If you need to unambiguously refer to a specific object then I think that a unique ID number is the best way to go. However I agree it's something that should be hidden from the player as much as possible and I think in our case there are very few circumstances where you really need to use an ID number to interact with an object.
30 Apr, 2010, Runter wrote in the 9th comment:
Votes: 0
It still seems to have the problem of exposing something ugly to players potentially.

I dunno if I want people to have to type get sword1023910 just because there's 2 of them in the room.

As the game gets older if I start handing out unique numbers it'll eventually reach a point where stuff has a big number.
30 Apr, 2010, Runter wrote in the 10th comment:
Votes: 0
Quote
If you need to unambiguously refer to a specific object then I think that a unique ID number is the best way to go. However I agree it's something that should be hidden from the player as much as possible and I think in our case there are very few circumstances where you really need to use an ID number to interact with an object.


That's kinda my take on it.
01 May, 2010, quixadhal wrote in the 11th comment:
Votes: 0
Yep, a good way to do it is to give every object a unique ID, but don't ever show them to the players.

>inventory
Your backpack contains:
3 apples
a longsword
a dull knife
a sharp knife
a dull knife

> wield knife
Which knife do you mean?

Because there are two dull knives, and they don't stack because they have different properties, the typical way to disambiguate them is to enumerate them. However, you want their sort order to always remain consistent, so that 2.knife is always the sharp knife, and 3.knife is always the second dull knife.

If you keep hidden ID's, they can be listed by their ID ordering, and referred to by their enumeration in the context you're acting upon them. So:

>@inventory
Your backpack [007CF011] contains:
3 apples [01102D99]
a longsword [01FB0C9F]
a dull knife [01FC876B]
a sharp knife [02044A80]
a dull knife [021FEB03]

The player never sees the actual ID numbers, but all the various routines that manipulate objects always sort by them, so an enumeration will always match the same one as long as the set remains constant. If you add another sword to your backpack, it might sort in above or below your existing one.

Nethack does something along these lines, and it also allows you to specify the sort order and assign labels to specific items. So, you could have something along the lines of an object alias, where the weapon you prefer is the longsword, so you could alias it as "my cool sword", and then commands would unalias "my cool sword" into [01FB0C9F] automatically.
01 May, 2010, Cratylus wrote in the 12th comment:
Votes: 0
quixadhal said:
Nethack does something along these lines, and it also allows you to specify the sort order and assign labels to specific items. So, you could have something along the lines of an object alias, where the weapon you prefer is the longsword, so you could alias it as "my cool sword", and then commands would unalias "my cool sword" into [01FB0C9F] automatically.


dead beef
01 May, 2010, KaVir wrote in the 13th comment:
Votes: 0
quixadhal said:
The player never sees the actual ID numbers, but all the various routines that manipulate objects always sort by them, so an enumeration will always match the same one as long as the set remains constant. If you add another sword to your backpack, it might sort in above or below your existing one.

The problem is you could end up with scenarios like this:

>
Bubba looks at you.

>
Bubba gives you the Ubersword of ultimate power.

>
Bubba says, 'Use that instead.'

> say thanks!
You say, 'Thanks!'

> remove sword
You stop using a small wooden sword.

> junk sword
You junk the Ubersword of ultimate power.


Or:

You kill the tiny rat!
You loot an iron tower shield from the corpse.

> say bah, worthless
You say, 'Bah, worthless.'

> give shield boffo
You give an epic aegis shield to Boffo.


I ran into a similar issue long ago on my mud with 'wear' and 'remove', as it would simply toggle a 'worn' flag on the item. I had to change the code to also push the item to the front of your carried list when removed.

Likewise, it's common for many commands to check 'worn', 'carried' and 'on the ground' in that order. In my case, I sort 'on the ground' items by distance, so that the nearest items come first, and I think it would be pretty confusing to show things in a different order - particularly if they are creatures.

Some muds also combine identical items into a single object (in fact your own example included "3 apples") - this would cause problems too, as new IDs would be created and destroyed as apples were added or remoted from the metaitem.

I agree with Runter about IDs looking ugly when incorporated into the short description, and personally I would find it really jarring from an immersion perspective, but like most things I guess it depends what you're used to.

Way back in the early development of my mud, items had to be manipulated by unique ID, but only as a temporary placeholder. Admin can still refer to items by ID if they wish, but players can only use keywords. I know some of the new MUSHclient plugins rely on unique IDs, so (in the interest of supporting cool plugin features) I may end up allowing players to view and reference IDs again, but I would make it optional - perhaps via a config option.
01 May, 2010, Scandum wrote in the 14th comment:
Votes: 0
Items being pushed to either the front or the back of the list is a big interface issue, modern MUDs tend to push it to the end of the list, most older MUDs use a singly linked list and add it to the front. All things considered adding new items to the end of the list is the best approach as it doesn't mess up the player's idea of what their inventory looks like, though there's an argument to be made for players without a long term memory, I'd say screw them. Example to prove my point:

Bubbo smiles.
>give sword bub
Bubba has arrived.
You give an uber sword of slaying to Bubba.

Then there is the issue of what list to process first: worn, carried, room, or: room, carried, worn. DikuMUDs process the room content first which has its issues.

Regarding unique IDs, they're pretty much a must for MUDs that do heavy scripting, you'd want both unique IDs per vnum (give i3763 bubba would give an item with vnum 3763 to Bubba), as well as unique IDs for individual items, though only having a usable unique ID per vnum will go a long way.

I'm not a big fan of exposing unique IDs to players, but if I was to settle for that I'd probably go for the vnum based approach so a player can use: quaff i2345 to be guaranteed to quaff a potion of sanctuary, which isn't possible with unique IDs for individual items.
01 May, 2010, David Haley wrote in the 15th comment:
Votes: 0
I'm not sure why people seem to think it's unacceptable to prompt the player for more information if there is ambiguity in the command.

> drop sword
"Did you mean the worthless sword or the awesome sword?"
> drop worthless sword
Ok.
01 May, 2010, Barm wrote in the 16th comment:
Votes: 0
The approach I've been taking is to use UUID's for items and locations. These are never exposed to the player.

For selecting items or mobs, I'm matching names using a trie. So the player can type any partial string (in any order) that matches the item name:

[journal | jou | ele | journal of ele | element journal] == "a journal of the elements"

The downside is matching is greedy, so some care is needed before typing 'sell s'. I'm still working on it but I'll probably have some selections expect singular matches and warn the player about multiples.

Here's the thread from last year on it; http://www.mudbytes.net/index.php?a=topi...
01 May, 2010, Tyche wrote in the 17th comment:
Votes: 0
Runter said:
Topic is in regards to using unique ID numbers as a means to interface with items in game as a player.


I don't like the idea of players getting object_ids/uids in their output. I don't even like builders and programmers having to deal with them. In fact my solution for programmers looks sort of similar to what Achaea does for players, Symbols generated by the prototype object. $sword, $sword_8162, $user, $user_bubba, etc.

David Haley said:
I'm not sure why people seem to think it's unacceptable to prompt the player for more information if there is ambiguity in the command.


That's exactly what I do. I generate a list of all matching commands/targets. If the length is greater than one, I print an "ambiguity" message listing what was matched. If the list is empty, I print the informative "huh?" message. Otherwise it's executed.
02 May, 2010, Mudder wrote in the 18th comment:
Votes: 0
It could get irritating if you needed to drop that sword in a heated PK situation and the prompts kept coming up. Especially if you knew which one would be dropped via it's place in your inventory. People tend to overcome those minor inconveniences and optimize their typing. This would make those players unable to do things quickly.

…At least that comes from my heavy PK perspective.
02 May, 2010, David Haley wrote in the 19th comment:
Votes: 0
Quote
Especially if you knew which one would be dropped via it's place in your inventory. People tend to overcome those minor inconveniences and optimize their typing. This would make those players unable to do things quickly.

If you're somebody willing to "overcome those minor inconveniences" and "optimize their typing", surely using precise ID numbers wouldn't bother you. Besides, this ambiguity thing could easily be a configurable option.
03 May, 2010, Runter wrote in the 20th comment:
Votes: 0
David Haley said:
Quote
Especially if you knew which one would be dropped via it's place in your inventory. People tend to overcome those minor inconveniences and optimize their typing. This would make those players unable to do things quickly.

If you're somebody willing to "overcome those minor inconveniences" and "optimize their typing", surely using precise ID numbers wouldn't bother you. Besides, this ambiguity thing could easily be a configurable option.


I think his point was valid, especially if ID numbers aren't displayed in tandem with short descriptions.
0.0/72