Lack of documentation of a feature that is missing through the engine trying to cheat functionality that it can't really support.


That really doesn't sit well with me.

This has gone way off topic. The bottom line is, a turf is a tile, therefore you can't have two turfs per tile. This is documented; as I said, there is a case to be made that this could be made clearer in several places, including the map editor, although specific suggestions along those lines would be best.

Saying the best way to clear this up would be to support the behavior of both turfs, even though only one is present, denies the reality of the situation. Internally there is no other turf--there is only an Appearance, and at runtime not only is the "second" turf not instantiated, there's not even any reference to its type path. Major alterations would be required just for the runtime environment to know the underlay belonged to a specific type path, and then to give it a different ID so the mouse could interact with it. All this is basically saying is "I wish this worked the way it looks like it works to a newbie." But that's simply not possible, so the best we can do is improve documentation and clarity.

The map editor isn't trying to cheat or trick anyone; it's merely offering a very handy shortcut for someone who wants to visually put, say, a thin wall or a column over a floor tile. If there were a way to make the distinction between actual turf and underlay clearer in the map editor, I'd be happy to consider it.

Rushnut wrote:

From the game developers point of view, when he places two turfs down on one spot, they function perfectly as you'd expect.

Rush, there is absolutely no reason to expect that. It's a completely unreasonable expectation.

The DM Guide:

Turfs cannot be moved. They can only be created or destroyed by changing world.maxx, world.maxy, or world.maxz. When you create a new turf with new(), it always replaces the old one.

What happens when you cross the boundaries of two turfs at once, for instance? Without a Z coordinate, there is no way to specify which location is dominant unless you use layer as dominant.

No game engine does this. 2D game engines use tiled data in sheets, because it it is incredibly easy to render, easy to work with, and there is no reason to have more than one "tile" at a specific point location. Games are written with the Euclidean space in mind, and multiple locales sharing the same coordinate is contrary to Euclidean reasoning. The locale isn't the locale because it's placed at a coordinate. The locale IS delimited by the coordinate.

Now, if you wanted to stack turfs and still have them be physical as well as logical, BYOND doesn't by default handle more than one sheet of the map being displayed at a time. As such, you have to find workarounds. One method is to use only one physical sheet, and keep your logical data in a hand-rolled structure (which works pretty well), another is to use images and objects to simulate the physical nature of logical turfs. (which is clunky and not scalable.)

Until which time there are ways to specify that more than one sheet of tiles should be displayed to the player, entities will have to suffice because entities are by definition, not part of a physical locale.

Rushnut wrote:

Lack of documentation of a feature that is missing through the engine trying to cheat functionality that it can't really support.

Name ONE 2D game engine that uses, or ever has used collocated tiles. Every single one of them uses either mapentities, separate coordinate planes, layered sheets, a z coordinate, etc. Nobody does what you are describing because it is a useless feature except in the creation of incredibly niche "non-euclidean" games, whose primary purpose is to confuse people, who generally are only comfortable thinking in euclidean spaces.