10 Apr, 2010, Runter wrote in the 1st comment:
Votes: 0
After some discussion with some of you I developed a system for for using generic descriptive tags instead of vnums. It's going good so far. I'm looking for a little feedback and some direction. Here's the basic way they're constructed:
little.shiny.dagger
smelly.green.dragon
rakar.desert
the.oasis

Also

"this is".valid


The order isn't important. Also it searches for parts and fragments.

"edit rakar" very well could get you editing the area rakar.desert. Or perhaps just "edit rak" or "edit desert.rak"

They use namespaces to avoid possible conflicts. For example:

some.continent::rakar.desert::the.oasis


The syntax is optional for name spaces.

Currently I have new instances of classes which implement vtags autogenerating from sequences for a valid, unique ID within it's namespace.

for example for the Room class it would generate:
room.alpha.1
room.alpha.2
room.alpha.3
… up to
room.zulu.100

That's 2600 per namespace per class.

I don't think it's needed but beyond that it begins:
It then kicks over to room._a.1 up to room._zzzzz.100 as a fail safe.

In any event, the tags should actually be named something interesting instead of leaving default values.


One of the issues I've ran into is with areas trying to determine which tags should fall into what area. There's probably no way to do this by convention without requiring the construction of the namespace. (For example in some muds a range of vnums is assigned to an area and any room within that range is in that area.) Anywho, any input on this matter is appreciated.
11 Apr, 2010, JohnnyStarr wrote in the 2nd comment:
Votes: 0
I get why you would want this, but I don't understand your code examples.
My idea was just to use a hash with symbols:

r = area[:shire].room[:bagend]
o = area[:shire].obj[:bronze_sword]
n = area[:shire].npc[:runter]

I never implemented it, but it was kind of similar to your tag idea. I think using hash tables
is very functional, but less aesthetically pleasing.
11 Apr, 2010, Runter wrote in the 3rd comment:
Votes: 0
JohnnyStarr said:
I get why you would want this, but I don't understand your code examples.
My idea was just to use a hash with symbols:

r = area[:shire].room[:bagend]
o = area[:shire].obj[:bronze_sword]
n = area[:shire].npc[:runter]

I never implemented it, but it was kind of similar to your tag idea. I think using hash tables
is very functional, but less aesthetically pleasing.


Those weren't really code examples I posted. Those are just showing you how builders could type them.
A tag in my system is simply a string in this format "this.is.a.tag"
The way it's all stored is in a hash with the keys being the object's class, the objects namespace, and the tag.

Also, it's used in a very generic way. For example, a single command can be used to enter an editor for virtually anything that can be edited.
sample input:
>edit a.small.room
>edit the.green.dragon
>edit the.oasis

Perhaps there are more than one "the.oasis" and you need to specify which area you mean.

>edit rakar.desert::the.oasis

Of course, this would be used for editing something that already exists. The create command is used to create something new and it requires the type.
11 Apr, 2010, flumpy wrote in the 4th comment:
Votes: 0
That's sort of how I do it.

It works ok, but you can end up typing a lot of text to find the object you need.. Other than that I don't have any issues (yet) :)
11 Apr, 2010, Runter wrote in the 5th comment:
Votes: 0
flumpy said:
That's sort of how I do it.

It works ok, but you can end up typing a lot of text to find the object you need.. Other than that I don't have any issues (yet) :)


Well, yes. But that comes with building ambiguous tags, too. For example..

"path"
"river"
"well"
"sword"

etc would all be fairly ambiguous tags. If a builder *really* wanted to they could use vnums for tags

"1"
"2"
and on and on.

Since the system is really for builders, and the majority of typing is done when builders are actually creating areas, it's largely mitigated if you default the namespace (which I do) to the area the builder is in. For example, if they do "edit 1" it's not going to be ambiguous with 1 in every context. It'll select the stuff from the area they're in first.
0.0/5