Since the time of its publication, the DM language has been under active development. Fortunately, the core syntax of the language is unchanged. A few aspects of DM have been extended and generalized, and new features have been added for ease of use and in order to accomplish things that were not possible before.

This addendum covers the most noteworthy changes and additions that have been made since the first edition of the Guide, which comprehensively covers BYOND 2.0--still the fundamental core of the DM language.

Contents

Changes

Hyperlinks may be embedded in text so that when the user clicks on them, Topic(href) gets called (page 78 section 7.6). Previously, the "href" text that got submitted back to client/Topic() was specified in the hyperlink using '#' as the delimiter like this:

client-side savefiles

The Del() procedure (page 73 section 7.2.2) has changed in the way it treats the contents of the object being deleted. Previously, it dumped these objects to the location of the container object. It now simply deletes these objects. It is a simple matter to achieve the old behavior if that is indeed desired:

mob/Del()
   var/O
   for(O in contents) O:Move(loc)
   return ..()

visibility

New Features

From the standpoint of elegance, the most important development has been the addition of object types that bring together all of the built-in DM objects.

Since the atomic objects /area, /turf, /obj, and /mob are all defined at the "top" of the inheritance tree, a new construct had to be invented to allow all of these to share a common ancestor. This is a variable named parent_type. It allows an object type to be derived from some other point in the type tree.

This naturally lead to the creation of various "ancestors" in the type tree. The new entries are listed below:

datum  //ancestor of all objects

atom   //ancestor of all atomic objects
   parent_type = /datum

atom/movable //ancestor of movable objects

area
   parent_type = /atom
turf
   parent_type = /atom
obj
   parent_type = /atom/movable
mob
   parent_type = /atom/movable

All object types at the top level are implicitly derived from /datum unless parent_type is pointed to something else. In the code above, therefore, the statement atom/parent_type = /datum is actually redundant.

Of course, types at lower levels of inheritance are still derived from the type "above" them, just like they used to be, unless parent_type is applied. For example, there was no need in the above code to make the statement atom/movable/parent_type = /atom.

The upshot of all this is that you can add properties to all objects, all atomic objects, or all movable objects by simply defining new procedures or variables in the ancestor object types. Previously, one sometimes had to resort to defining the same procedure once per atomic object type, which was silly.

It also allows you to create new atomic objects that behave as "siblings" of the built-in ones. For example, you might want to have separate /player and /monster types:

player
   parent_type = /mob
monster
   parent_type = /mob

Another important advance in DM syntax since BYOND 2.0 is the addition of named arguments. The normal method of passing arguments to a procedure is to use positional arguments. However, procedures with many independent optional arguments can become rather awkward to use.

The solution is to pass the arguments by name rather than by position. In general, you may pass any number of positional arguments first (typically the required ones) followed by any number of named arguments.

A good example of this is the image() procedure. It used to just take an icon and a location for the purpose of displaying a particular icon to selected users. It now takes additional arguments, allowing you to override the default icon state, drawing layer, and direction.

mob/var
   image/shield_image

mob/verb/shields_up()
   shield_image = image('shield.dmi',loc = usr,icon_state = "high power")
   usr << shield_image

mob/verb/shield_off()
   del shield_image

A significant amount of extra mouse control has been added. In BYOND 2.0, just Click() and DblClick() were defined. Now there is support for drag-and-drop, custom mouse cursors, pixel-level clicking, mouse-over detection, and extra mouse "opacity" control.

The map view size may now be set on a player-by-player basis and it is no longer restricted to being square. For example, the following sets the default view size to 17x13:

world/view = "17x13"

The layer in which an object's icon is drawn used to be fixed by the type of object, but it is now configurable via the layer variable. This allows for nifty effects such as turfs with "arch" overlays that appear over the top of people as they walk underneath.

A number of extra controls have been added to the vision system, including a full range of invisibility levels, infravision, night vision, independent verb visibility, and a choice between "mob" and "eye" perspectives in the player's view.

More information:

DM contains built-in features that allow you to easily link up to a centralized database known as BYOND Hub. It is by no means a requirement that this be used, but it has turned out to be an enormously important capability.

Another generalization of DM syntax is the addition of modified types. Anywhere that you can use a type value in DM (shuch as in new() or newlist()), you can make simple initializations of variables using the following syntax:

path {var1 = val1; var2 = val2}

Example:

mob/contents = newlist(
   /obj/scroll/readme {
      name = "Introduction"
      desc = "The fate of Bracolia depends on you ..."
   }
)

Another major area of development since BYOND 2.0 has been an improvement in the resource file transmission system. Icon and sound files can be downloaded by Dream Seeker on demand, all at once, or some combination of the two. It is also possible to create resource packs that are distributed from a web server, rather than from the game server itself, saving bandwidth on the machine hosting the game.

All changes of note to the DM Reference since BYOND 2.0 are listed below: