https://wiki.tinymux.org/index.php?title=Dbref&feed=atom&action=historyDbref - Revision history2024-03-28T17:45:31ZRevision history for this page on the wikiMediaWiki 1.41.0https://wiki.tinymux.org/index.php?title=Dbref&diff=2476&oldid=prevIan at 15:23, 9 December 20052005-12-09T15:23:44Z<p></p>
<p><b>New page</b></p><div>A dbref is a number that uniquely identifies an [[object]] at a given point in time. That is, at any given moment, any given dbref refers to a single object or to [[garbage]], and each object has a single dbref. Dbref is short for "database reference".<br />
<br />
Dbrefs are written with an initial # (hash mark or pound sign), begin with #0, and increase as more objects are created.<br />
<br />
Some dbrefs are typically provided in the minimal startup database and considered "special", including:<br />
<br />
* #0 is typically a [[room]] and serves as the [[base_room]] from which [[connectedness]] is tested.<br />
* #1 is typically the dbref of the [[God]] player.<br />
* #2 is typically the dbref of the [[master room]] for [[global commands]] and [[exit|exits]].<br />
<br />
Because dbrefs are recycled when objects are destroyed and new objects are created, it is possible for a given dbref to refer to different objects at different points in time. This can create a problem when softcode does permission checking based on a list of dbrefs and one of the objects on the list is destroyed without removing it from the list. In [[PennMUSH]], this problem can be avoided by using an object's [[objid]] instead of its dbref.<br />
<br />
== Server Differences ==<br />
<br />
On [[TinyMUX]], the test for [[floating]] rooms starts from the [[player_starting_room]]. Also, the initial database contains just Limbo (#0) and Wizard (#1). However, the Sandbox Globals Project (SGP) minimal database included with [[TinyMUX]] does use #2 for the [[master room]].<br />
<br />
== Poor Usage of #dbrefs in Softcode ==<br />
<br />
Often designers of softcode make the assumption that once a #dbref used by an object, it will always be used by this object. However, often players and objects will be deleted, recreated, replaced, etc.<br />
<br />
[[Category:Nifty Tricks]]<br />
== Nifty trick ==<br />
<br />
So how do you know if the object referenced in the past is the same in the present? By combining the #dbref with a timestamp and possibly other information.<br />
<br />
PennMUSH already has a builtin function called [[Objid|objid()]] to do this, however MUX does not. This can be easily softcoded with some different behavior:<br />
<br />
&f.objid functions object=default(%0/_objid,set(%0,_objid:[setr(0,num(%0):[secs(,3)][rand(100000)])])%q0)<br />
<br />
Such code assigns an object id on the fly if the object does not already have one. Otherwise, it simply grabs the object id out of the _objid attribute. (Attribute names prefixed with an underscore (_) are dark and wizard on MUX, see [[attr_access]])<br />
<br />
Finding the #dbref of an object from its object ID is fast: before(%0,:)<br />
<br />
Instead of reference objects by #dbrefs, objects can now be referenced by their object ID with one additional function:<br />
<br />
&f.objidnum functions object=case(xget(before(%0,:),_objid),%0,before(%0,:),#-1)<br />
<br />
This works like [[num()]], but it takes an object ID as its first argument instead.<br />
<br />
--[[User:Ian|Ian]]</div>Ian