In the next release, we'll augment the sound() command to give more control over the storage and mixing of sounds.
Click on the "Preferences..." link in the pager to set this option. There are also
a few more options that you can read about there.
An icon may also be multiplied by another icon. This has the same effect, except the color values are taken from pixels at the same position in the two icons. That would allow you to change the color ratio in some arbitrary spacial pattern. (Lummox JR)
The MouseDrag() proc is called continuously while the left-button is held down and the mouse is moved over the map or statpanels. Events are reported relative to the object being dragged. The 'target' argument refers to the object or panel being dragged over, while the 'object-location' and 'target-location' refer to the locations or panels of the respective objects (more on the syntax below). Note that even though this function will typically be used to handle client operations (like selection images and such), it is still a server event that induces some network overhead, so be wary about abusing it.
The MouseDrop() proc has the exact same syntax, except it is called once when the mouse button is released over a target object or panel. This function is probably all you'll need to do drag & drop. For instance, if you drag a sword from a turf on the map onto a bag in your inventory, you'll have client.MouseDrop(sword,bag,turf,"inventory"), and sword.MouseDrop(bag,turf,"inventory") ... enough to snazz up any inventory management system!
The variables simply control the display of the mouse pointers associated with the various atoms. They need not indicate whether such atoms are draggable, etc, but it is probably good practice to do so. The reason that these procs are associated with the atoms is to make things more efficient; if the pointers were all set through procedure calls (in MouseDrag(), for instance), there would be a lot of needless client-server communication just to update the gdi.
Setting any of the pointer values to MOUSE_ACTIVE_POINTER (1) will enable the default "special function" mouse pointer for that particular context. The intention is that you would toggle these pointers on for objects that provide some special mouse functionality so the user is alerted to the fact when the mouse passes over that object. As a rule of thumb, you would set the mouse_over_pointer=MOUSE_ACTIVE_POINTER for atoms that have overriden Click(), mouse_drag_pointer=MOUSE_ACTIVE_POINTER for atoms that have overriden MouseDrag(), and mouse_drop_pointer=MOUSE_ACTIVE_POINTER for atoms that have overriden MouseDrop(). We don't make this assumption automatically because you may have certain prototypes that have these procs set but instances where they might not apply; for instance, an object might only be draggable (mouse_drag_pointer=MOUSE_ACTIVE_POINTER) when it is in the inventory. Since you can toggle these flags at runtime this behavior is easy to control.
The mouse_drop_zone var is not a mouse pointer, but rather a simple on/off toggle that specifies whether the object in question is a valid target for the MouseDrop() events. Again, this only affects the pointer display; it is up to you to actually make this designation within the procs. Of course it is easy to always correlate the labelled drop zones with the targets in MouseDrop():
In addition to the pointer states, you may specify your own custom pointers by simply assigning them to these vars. You may use not only an icon file, but anything also valid as an overlay: atomic objects, object types, and icon state text strings. When an icon state is specified, it is applied to the icon of the base object when creating the mouse pointer. For example, mouse_drag_pointer = "dragging" would select an icon in the base object from the icon state named "dragging". This allows you to package the mouse pointer in the same file as the object's icon, which is useful when the two are related. We may embed this notation right in the icon file (similar to the movement-states) in the future.
By default all of the MOUSE_ACTIVE_POINTER states use fixed pointers. You may actually access these by assigning the pointers to the enumerated values:
With this setup, you should rarely have to assign individual atom pointers to icon files. Instead, associate the pointers with the object types (as in the example above), or create specific pointers inside the objects' icon files and assign the atom pointers by state name. If you want to make a pointer that globally applies (ie- replace the default 'click' crosshairs) you can use the client pointer.
If items in an associative list are argument names, the values associated with these are assigned to the corresponding arguments. Example:
To prevent silent errors, a runtime error will result if named parameters do not match any argument. In the future, compile-time error checking may be added when possible, to give even earlier warning of such errors.
Since this new syntax depends on the variable names defined in the procedure being called, it is best not to use named arguments unless the procedure is documented to support them. Most built-in procedures do not support named arguments or even arglist() but support may be added in the future.
The best time to use named parameters is in calls to procedures with many optional arguments where you might want to set the value of an argument that follows a bunch of others that you do not care to set. In cases like that, pure positional argument syntax can just be confusing and error prone.
There is a small amount of extra overhead involved in named arguments, so do not use them in code that is highly cpu intensive due to being called very very frequently. Other than that, you shouldn't notice much difference and clarity of code may take higher priority.
It should be mentioned that even new() supports named arguments. It simply passes them on to the object's New() proc. The only special handling is that for atomic objects, an initial location may be passed as the first positional parameter or as an argument named "loc". Since the object is created at the specified location before New() is even called, this is a somewhat special case where the name of a parameter is hard-coded; it does not depend on the actual definition of New() that may exist.Example:
At this time, none of the built-in object procedures (such as Move(), Bump(), and so on) are intended to support named arguments, except New() as described above. You are, of course, free to make your own argument naming convensions by overriding these built-in procedures with your own definition. Calling ..() simply passes up the current set of positional arguments, so this poses no problem. Just don't call the built-in object procedures directly using named argument syntax, or you will just get a run-time error.