ID:138542
 
I really like the approach to overlay/underlay stuff -- an elegant solution to what has been requested. It's not stated explicitly, so I'd just like to make sure: the overlay/underlays are visible to everyone without being sent like image(), right?

Second, I don't really understand what this means, though it sounds promising. Could you provide more explanation?

The dmp format now supports multiple turfs. All but the top-most turf (along with any icons) get converted into turf underlays.
On 6/19/00 3:59 pm Deadron wrote:
I really like the approach to overlay/underlay stuff -- an elegant solution to what has been requested. It's not stated explicitly, so I'd just like to make sure: the overlay/underlays are visible to everyone without being sent like image(), right?

Yes.

Second, I don't really understand what this means, though it sounds promising. Could you provide more explanation?

The dmp format now supports multiple turfs. All but the top-most turf (along with any icons) get converted into turf underlays.

This means that you can place multiple turfs at a single location on the mapper. All but the top turf are virtual, in the sense that only their icons (and icon-states & dir) are used. The turf properties are extracted from the top turf. Essentially this replaces the painter dir, which did the same thing in a much more clunky fashion.
In response to Tom H. (#1)
On 6/19/00 4:46 pm Tom H. wrote:
On 6/19/00 3:59 pm Deadron wrote:
I really like the approach to overlay/underlay stuff -- an elegant solution to what has been requested. It's not stated explicitly, so I'd just like to make sure: the overlay/underlays are visible to everyone without being sent like image(), right?

Yes.

Though you're almost completely unlikely to implement this (after all, you're trying to market this thing), could you change the properties of image()? So you could instead create overlays with a display list that contains all of the mobs that it would show to? By default, that list would be a reference to a new predefined list like world.players or something, so by default all players would be able to see all objects in an overlays list. Thus, all overlays in the other format would appear using a standard image(src) proc.

For example, for a souped up default image you might try:

image('icon.dmi',"icon_state",src=usr,list/display)

Where the first arg is an icon or object reference, the second (optional) is that icon state, the third is the reference to overlay it on, and the list is the mobs that it would show to. By default, it would overlay over usr and with the list of world.players. Somehow, though, you'd have to tie in world.players directly with the object, so whenever something updates in world.players it updates in the object too, so new players could see overlays too; of course, if the list wasn't world.players, then it won't display for new players logging in.

Then, whenever you add something to the overlays list, it internally (automatically) calls an image() proc with the arguments passed in and thus it would work the same way.

Basically, what I'm getting at is that it wouldn't change the way it works right now (at least, not visibly), but you could have the added abilities of displaying it to individual mobs.

So the format would be src.overlays += image(blah) if you wanted specific targets, and src.overlays += O otherwise.

Yeah, I know, that's one hell of a beetch to program, but try to see it from my point of view...