- Fixed: Certain configuration settings were failing to show up correctly
in the Dream Seeker Preferences.
- Fixed: Occasionally sounds were failing to cache property in Dream Seeker.
- Fixed: new turfs created on large maps weren't refreshing immediately.
(Deadron)
- Fixed: client.dir had a number of problems. Instead of rotating the
client map viewport, it was flipping axes. For example, in a game of chess,
the black player (facing SOUTH) was seeing his queen on the left of the king,
which is what you get by looking at the board in a mirror rather than from
the other side.
- Fixed: Directional icons were not respecting client.dir.
- Fixed: Movement on a rotated map was was totally messed up.
- Fixed: After the first call to browse(), subsequent calls were
generating my favorite bug message: 'doubly premature return value.' (Spuzzum)
- Fixed: Overlays (and all movies for that matter) with the same number
of frames should now be synchronized. (James)
- Fixed: One-frame directional movies when used as flicks were lingering
forever rather than disappearing after one tick.
- Fixed: User-defined types embedded in text were not always being handled
correctly. The name of the object is printed (if a name variable exists)
and otherwise, the type is displayed. Previously, the wrong type was
sometimes inserted. (Guy T.)
- Fixed: On scrolling, some map edges were drawing improperly, giving the
impression of a "shrinking map" (Zilal)
- Fixed: The instance editor was freezing when trying to edit long text
blocks. (AbyssDragon)
- Fixed: Icons were getting displayed improperly after the palette
was changed in the editor. (Zilal .. the other half of her "mystery problem")
- Macros may now be any key, including those that overlap with BYOND keys
(like F1 and the spacebar). Be careful!
- When the user has a display resolution < 800x600, small-icons will be used
on the map by default. This allows the info pane to be viewed somewhat.
(Deadron)
- del null is no longer considered an error. It does nothing.
- Mob prototype names now default to the key name. If that isn't specified,
it falls back on the name of the type as it used to. This shouldn't make
much difference except in stuff that gets called before the name is assigned
at run-time (like Login() for players with hard-coded keys).
- Object references embedded in text (e.g. "\ref[src]") may now be passed to
locate() to reproduce the object reference. If the object has a tag, this
will be used by \ref instead of a numerical value. In either case, the
format is "[data]" where data may be the object tag or numerical reference
id. The tag is prefered over the numerical id because it is safer. For
example, even after a reboot, a tag reference could still refer to the same
object, whereas a numerical id might be invalid or point to the wrong object
altogether. The bottom line is, if you want embedded text references to an
object to last through a reboot or through any other re-creation of the
object, you need to tag the object.
- All object types now have a Topic() proc. This is called by the default
client.Topic() proc for href values beginning with an embedded object
reference. Example:
<![CDATA[
mob/Topic(href)
if(href == "story")
usr << "Once upon a time..."
else return ..()
mob/proc/Greet()
usr << "Hi, [usr]."
usr << "Want to hear a <A HREF='#\ref[src]story'>story</A>?"
]]>
Suppose the mob had tag="storyteller". Then the full href would be
"[storyteller]story". This gets passed to client.Topic(href,Obj,subtopic),
where href will contain the full link text, Obj will be a reference to the
storyteller mob, and subtopic will be "story". The default behavior of
client.Topic() will then be to call the mob's own Topic() proc with the
subtopic as the first argument.
Of course, you are free to override the default behavior for security or
other reasons. For example, you might not want people accessing links that
start with \ref[world], or you might want to attach a list of objects to
each client that specifies which objects that client may access.
- User-defined types derived from the root object now have a tag variable,
just like the game objects.
- Added "associations" to the basic list data type. Each item in a list may
have an associated value. This value is accessed by using the _item_ as the
index. The item may still be accessed as before by using its numerical
index. Example:
<![CDATA[
var
lst[0]
n
//set the associated values
lst["four"] = 4
lst["five"] = 5
lst["six"] = 6
//list now has contents ("four","five","six")
//and associated values (4,5,6)
//loop through the items in the list
for(n in lst)
usr << "The digit [lst[n]] is called [n]."
//accessing the list as an array (indices 1,2,3)
for(n=1,n<=lst.len,n++)
var/word = lst[n]
var/digit = lst[word]
usr << "The [n]\th item is [word]."
usr << "Its associated value is [digit]."
]]>
From this you may gather several things. Items are automatically added when
they are assigned an associated value. The above example could have begun by
explicitly doing lst.Add("four","five","six"), but that was unnecessary.
When you try to get the associated value for an item that does not exist
(like lst["ten"]), null is returned, but the item is _not_ added to the list
as a side-effect. The list will only be modified by writing to it, never by
reading from it.
The other thing to notice is that numerical list items may not have
associated values. The reason is that numerical indices cause the list to
be accessed as an array rather than an association.
The existing "vars" list now looks very much like an association. The items
in the list are the variable names and these are associated with the values
of the variables. That is part of the reason I added this feature--in order
to legitimize the way the vars list works. It is also pleasingly similar to
the way savefile directories are accessed.
- Added world.params. This is a list of associated name value pairs which
are initialized by the new -params command-line flag. The format is:
<![CDATA[
-params name1=value1&name2=value2&...
]]>
Several -params may be supplied, in which case the full param text string is
simply formed by concatenating them together.
Any special characters (such as spaces, '=', '&', etc.) should be specified
in the form %xx where xx are two hexadecimal digits representing the ASCII
value of the character. This is the standard
application/x-www-form-urlencoded format, which might prove useful if anyone
wants to write a CGI script in DM.
The world.params list is initialized by calling the new instruction
params2list(). This takes a urlencoded text string and returns a list
containing the names as array items and the data as associated values. The
complementary instruction list2params() returns a urlencoded text string
from the contents of a list. Currently, no type conversion is done in
params2list(). All values are read in as text strings. We could perhaps do
some automatic type conversion for numerical values. What do you think?
- The reference has been updated.