26 Oct, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
So for you Ruby folks out there, what do you think about vnums? I thought about
using a Hash with vnum keys, much like a traditional hash table in ROM. I noticed
that TeensyMud uses an id field for each game object, although I'm not exactly
sure how that is used in the application. Have any of you come up with a
different solution?

Also: I don't know much about LPC's file-path system, but from what I've heard,
it seems like a neat idea. Have any of you used this in your projects?
26 Oct, 2009, Runter wrote in the 2nd comment:
Votes: 0
My thoughts on the subject is a hash in Ruby would work, however, I wouldn't just have a collection of vnums. I would have a collection of areas, each with a collection of vnums.

For example, a1v1 a1v2 a2v1 a2v2

This solves some development issues later on that straight vnums usually has.
26 Oct, 2009, JohnnyStarr wrote in the 3rd comment:
Votes: 0
Nice, that makes a ton of sense.
BTW, thanks for the invitation of Ruby support on the last thread Runter :)
27 Oct, 2009, elanthis wrote in the 4th comment:
Votes: 0
Why use numbers? Use meaningful labels. Way easier for people to work with. If you have an area Dark Wood with a room The Oak Stump, identify it as darkwood.oakstump or such. If you have a ton of nearly identical rooms, you can identify them by position or something else meaningful to the designers (e.g., area.x_y, like area.3_5) instead of trying to memorize a ton of meaningless numbers.

It's not even remotely a performance issue, either, especially when you're looking them up in an efficient hash (like just about every scripting engine has, Ruby included).
27 Oct, 2009, Confuto wrote in the 5th comment:
Votes: 0
What if you have several identical mobs/items/whatever?

EDIT: To make that clearer, several seemingly identical mobs/items/whatever - two steel longswords that look the same but have different stats, for instance.

Eh, nevermind, thinking as a player and not a developer. :rolleyes:
27 Oct, 2009, David Haley wrote in the 6th comment:
Votes: 0
I don't think this is quite what you meant, but there's a difference between the prototype of a mob and an instance. Differentiating the two is actually kind of interesting and isn't a problem that should be dismissed so readily, but indeed, it's quite possible to identify a "catalog copy" of some entity using a different schema than the "world copies".
27 Oct, 2009, Scandum wrote in the 7th comment:
Votes: 0
staryavsky said:
So for you Ruby folks out there, what do you think about vnums? I thought about
using a Hash with vnum keys, much like a traditional hash table in ROM.

We had a discussion like this recently, I think the outcome was to use an array if 40% or more of the vnum range is used, otherwise use a hash if concerned about memory, or an array if concerned about speed or want to keep things simple.

As a side note, vnums don't exclude the option to add meaningful labels, without the added mess when builders don't utilize the meaningful labels in a meaningful manner.
27 Oct, 2009, quixadhal wrote in the 8th comment:
Votes: 0
You might want to take a look at how people do things in the LpMUD universe. Over there, everything is a filesystem pathname, because almost everything is an actual file on disk. However, there's nothing wrong with that setup for a nice hierarchical naming system.

/Shire/DarkForest/Path13 is a perfectly good and useable way to identify rooms uniquely. For that matter, you could easily extend it to cover all objects (rooms, mobs, weapons, whatever)….

/Shire/DarkForest/room/Path13, which loads /Shire/DarkForest/mob/squirrel and /obj/nut

Doing it that way, you can see the squirrel is specific to the DarkForest part of the Shire area, and that the nut is a generic object. If you're even more clever, you can assign permissions so builders can modify anything in the Shire, or only things in the DarkForest, or perhaps only rooms.

Much nicer than: room 4501, loading mob 4577 and obj 10092.
27 Oct, 2009, Runter wrote in the 9th comment:
Votes: 0
elanthis said:
Why use numbers? Use meaningful labels. Way easier for people to work with. If you have an area Dark Wood with a room The Oak Stump, identify it as darkwood.oakstump or such. If you have a ton of nearly identical rooms, you can identify them by position or something else meaningful to the designers (e.g., area.x_y, like area.3_5) instead of trying to memorize a ton of meaningless numbers.

It's not even remotely a performance issue, either, especially when you're looking them up in an efficient hash (like just about every scripting engine has, Ruby included).


This is where I should mention that hash datatype isn't an efficient hash. It's an array in C.

If the original poster is looking for some other type of implementation they should browse some gems.
27 Oct, 2009, Runter wrote in the 10th comment:
Votes: 0
Confuto said:
What if you have several identical mobs/items/whatever?

EDIT: To make that clearer, several seemingly identical mobs/items/whatever - two steel longswords that look the same but have different stats, for instance.

Eh, nevermind, thinking as a player and not a developer. :rolleyes:


This is a problem only in conception. Depending on how flexible your implementation is there's no reason actual stats need to be attached to the prototype for an item. A lot of muds solve this by using the prototype values for all instances if the instance is exactly the same. However, these MUDs make it possible to change the values from the prototype on the instance in question. In which case it wouldn't use the prototype values for said values.

With all that being said, I think it's worth mentioning that you can use the same data type for prototypes as instances. In some ways it can make your system more flexible and friendly than hard segregation. I'd just be mindful about exactly what you are doing and exactly why. Getting to clever with this sort of thing could bog you down instead of making your life easier.
27 Oct, 2009, David Haley wrote in the 11th comment:
Votes: 0
Runter said:
This is where I should mention that hash datatype isn't an efficient hash. It's an array in C.

Most hash tables are arrays under the hood – that's kind of the idea, right? Since you don't access the hash by index, but by key, surely there is in fact some kind of hashing going on. Now, it is probably not using a hash function most suited to the problem at hand, but nonetheless I think it's still a hash table…
27 Oct, 2009, Runter wrote in the 12th comment:
Votes: 0
David Haley said:
Runter said:
This is where I should mention that hash datatype isn't an efficient hash. It's an array in C.

Most hash tables are arrays under the hood – that's kind of the idea, right? Since you don't access the hash by index, but by key, surely there is in fact some kind of hashing going on. Now, it is probably not using a hash function most suited to the problem at hand, but nonetheless I think it's still a hash table…


Perhaps I misread some months ago when I was researching it. I believe it is a hash table upon delving into the actual source.

// Ruby 1.9 internal hash entry struct
struct st_table_entry {
unsigned int hash;
st_data_t key;
st_data_t record;
st_table_entry *next;
st_table_entry *fore, *back; // new in Ruby 1.9
};


So yes, strike my original comment from the record. :)
29 Oct, 2009, Tyche wrote in the 13th comment:
Votes: 0
staryavsky said:
So for you Ruby folks out there, what do you think about vnums? I thought about
using a Hash with vnum keys, much like a traditional hash table in ROM. I noticed
that TeensyMud uses an id field for each game object, although I'm not exactly
sure how that is used in the application. Have any of you come up with a
different solution?



Vnums, dbrefs, oids, guids are all somewhat interchangeable terms, however a particular applications implementation may solve different problems. Now I could very well be wrong on this, but I've never personally seen the term vnum or 'virtual numbers' used anywhere else but on DikuMuds. The rest of the programming world uses terms like OIDs (object ids), UIDs (unique ids), GUIDs (global unique ids), and SUIDs (system unique ids).

Vnums in ROM are not really unique, Vnums are unique among types of each prototypical Room, Object, and Mobile objects, but the same vnum could be associated with a different object type. Not only that, but game instances of Objects and Mobs inherit their prototype's vnum. In ROM, vnums are manually assigned by the builder.
The primary purpose of vnums though is to provide labels to associations in the file store. When an area is loaded the vnums are translated into memory pointers, when it's saved the pointers are translated into vnums. Pointers cannot be used to save references to objects on disk because the pointer isn't going to be the same between different runs of the mud.

In Ruby there are no pointers, but each object has an object_id. Like pointers an object_id may differ from run to run of the application, so it's only good for runtime comparisons, not offline store.

TeensyMud works much like Muck and Mush, not DikuMud. Each object no matter what the type has a unique oid. The oid is assigned starting from 0 and incrementing and assigned every time a new object is created. Although it as different options. If you are using YAML for a file store, the entire database of objects is loaded into a hash at runtime. This mode is very similar to how ROM muds work. If you are using the object cache and a dbm, then only non-swappable objects are loaded into the object cache, and objects are loaded as referenced from the dbm and kept in the object cache. When the object cache is full, it flushes out objects that haven't been used in while. Thus you could theoretically have a mud with billions of objects running in a limited memory environment.

Unlike ROM, references to other objects in TeensyMud are oids and are never translated in direct references/pointers. Since every object has unique oid key, one can use any sort of back end storage one can think of whether it be spreadsheet, hash database, btrieve, relational database, etc.
29 Oct, 2009, Tyche wrote in the 14th comment:
Votes: 0
The hash mechanism in ROM is known as single-hashing separate-chaining. Looks like this:

[0]->link->link
[1]->link
[2]->link->link->link->link
[3]->null
[…]
[1023]->link->link->link->link->link

The hash algorithm used is the vnum % 1024, which is okay for going after things by
vnum. Completely useless for spatial data though.
29 Oct, 2009, Tyche wrote in the 15th comment:
Votes: 0
Runter said:
// Ruby 1.9 internal hash entry struct
struct st_table_entry {
unsigned int hash;
st_data_t key;
st_data_t record;
st_table_entry *next;
st_table_entry *fore, *back; // new in Ruby 1.9
};


The current implementation appears to be a circular doubly-linked list, that also tracks insertion order.
Very odd.
0.0/15