Nope.
Could this be related to the change in the ":" operator now suddenly allowing you to call procs? We never did determine why or when that changed. Lummox even said that the : operator shouldn't work in that context.
In response to Ter13
Ter13 wrote:
Could this be related to the change in the ":" operator now suddenly allowing you to call procs? We never did determine why or when that changed. Lummox even said that the : operator shouldn't work in that context.

o__O?
In the reference for bounds(), the final case reads with this relevant information-


'bounds(x, y, width, height, z)'
'x, y, z: Lower left corner of bounding box in absolute coords; '
'In the final form, bounds() can use absolute coordinates and does not need an object to be Ref. Absolute coordinates start at 1,1 at the lower left corner of the map, by tradition. '

It doesn't mention anywhere that this should be pixel coordinates (aside from mentioning a bounding box in the x,y,z args desc), and not atom x/y coordinates, which was confusing for me until Kaiochao explained it. He said-
[10:11:32] Kaiochao: world pixel coordinates
[10:11:36] Kaiochao: is what should be written there

Seems like a solid suggestion.
atom/bounds is both undocumented, and very useful.
From mob/group:

mob/verb/summon()
set src in usr.group
loc = usr.loc
view() << "[usr] summons [src]."


From src setting:

Args:
List: One of view(), oview(), world, world.contents, usr, usr.contents, or usr.loc

usr.group is strangely absent from the src settings list.
On the appearance_flags doc:

"RESET_COLOR - On overlays/images/etc., ignore the parent's color"


To me, this reads as "On overlays on this atom, ignore the atom's color", since the doc is for a var on atom, and overlays are things on atoms. Maybe it could be "When used as an overlay/image/etc, ignore the parent's color".
In response to Arokha
Arokha wrote:
On the appearance_flags doc:

"RESET_COLOR - On overlays/images/etc., ignore the parent's color"

To me, this reads as "On overlays on this atom, ignore the atom's color", since the doc is for a var on atom, and overlays are things on atoms. Maybe it could be "When used as an overlay/image/etc, ignore the parent's color".

Good call. Changed.
I've added #, ##, and ### to the documentation for #define, while adding variadic macro info for 511.

I did not document that failing to name the last parameter in a variadic macro (just using ...) will name it __VA_ARGS__ like in modern C++, because that seemed pointless to mention.

Also using ## before the variadic macro parameter will eliminate a preceding comma in the replacement expression, if there were no variable arguments used.
TILE_BOUND doesn't mention that SEE_PIXELS completely overrides TILE_BOUND's functionality. (assuming that's intentional)

And though I think its implied in the example, PLANE_MASTER doesn't mention that it's explicity meant to be used as a screen obj/image.
In response to Clusterfack
Technically any atom can be a PLANE_MASTER; there just isn't much in the way of valid use cases for other atoms, except maybe areas. Screen objects and images work best, though.
For awhile I had personally believed it could also be used as a global modifier to all things in a particular plane when outside of a screen.
Documentation for atom.appearance should probably state that any atomic type path can be used an appearance - you don't need to instantiate the object.
It'd be neat if the reference had an entry for the waitfor verb/proc setting.
The section describing Move() seem to be inaccurate, especially the parts where it describes how Bump() operates.

Any Move() is either a slide or a jump. Normal walking around is a slide; it can be stopped partway. A jump is pass/fail. See more information below.

This is what happens by default:

oldloc.Exit(src) is called for any turfs or areas being vacated, or the container if moving out of an obj or mob. neighbor.Uncross(src) is called for any movable atoms that will no longer be overlapping this object. If any of these return 0 (failure), movement fails.

newloc.Enter(src) is called for any turfs or areas that may be entered for the first time, or the container if moving into an obj or mob. neighbor.Cross(src) is called for any movable atoms that may be in collision with this object if the move fully succeeds. If any of these return 0 (failure), then a slide can be cut short but a jump will fail completely.

If any obstacles were encountered via Enter() or Cross() failing, then src.Bump(obstacle) will be called for each of them.

If movement did not fail completely, then loc and step_x/y, will be changed, and the following calls will be made: oldloc.Exited() for any turfs, areas, or other containers vacated; neighbor.Uncrossed() for any movable atoms no longer overlapping; newloc.Entered() for any turfs, areas, or other containers being entered for the first time; and neighbor.Crossed() for any movable atoms now overlapping the object.

What actually happens is that if any obstacles are countered via Enter() or Cross() failing, Bump() is only called on the first one to be checked, and ONLY if that object has density = 1.
Is there a downloadable reference other then the 2.0 guide?
Press F1 with Dream Maker open. Entire reference is available from there. If you're talking about the guide, it hasn't been updated in quite some time.
In response to Nadrew
The help file in dream maker has been excellent in helping me learn so that is good enough for me. Just wondering if people knew about another source that I didn't. Love to read anything about the code that helps me learn. :D
http://www.byond.com/developer/ Is the best source of resources to learn DM with.
Page: 1 2 3 4