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 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.

From mob/group:



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:



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".

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.

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.

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.

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.

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.

http://www.byond.com/developer/ Is the best source of resources to learn DM with.