Applies to:DM Language
Status: Redundant

This feature has already been implemented, or is already achievable with existing methods.
This might be a bit far-fetched, but it'd be so useful.

It'd be cool if turfs could be parts of different "grids", while remaining on the same z-level. What this means is, a grid moves and interacts independently from every other grid. So there could be multiple turfs overlapping, but on different grids, so they wouldn't interact.

A use-case for this would be things such as airships, boats, spaceships, etc, which would be full-featured rooms, but can be moved around the world easily.
This can already be accomplished using vis_contents.
In response to Nadrew
Nadrew wrote:
This can already be accomplished using vis_contents.

How so?
You'd throw your other stuff on another z-level, then use vis_contents of something on the first layer to display those turfs elsewhere on the map.
Lummox JR resolved issue (Redundant)
In response to Nadrew
This is such a bad approach that the request shouldn't be resolved as redundant. He'd have to add every turf from the second z level to the vis_content of the correspondent turf in the first z level.
That can easily be automated.
In response to Nadrew
what about the clients that are on the upper z levels? their eye would have to be set to the lower z level aswell, it's all sorts of trouble.
In response to NSBR
NSBR wrote:
it's all sorts of trouble.

That's why you automate the process, so you don't have to concern yourself with this sort of thing. And that is very much possible. I recall seeing one or two games back in the 00's without all the new vis_contents stuff that managed to accomplish things like this.
In response to Popisfizzy
I'm not saying it isn't possible to do, nor that it can't be automated. I'm just saying that in my opinion it's a bad approach to it.
In response to NSBR
NSBR wrote:
He'd have to add every turf from the second z level to the vis_content of the correspondent turf in the first z level.
When adding multiple turfs to a single object's vis_contents, they are already automatically offset to their relative positions.

If multiple turfs are present in visual contents, they will be offset as needed (relative to the southwest-most turf) to appear in the correct positions.

It can be as simple as:
vehicle.vis_contents += block(lower_corner_turf, upper_corner_turf)

which is pretty much exactly what I do here: 1911651?page=353#comment24781090
In response to NSBR
NSBR wrote:
I'm just saying that in my opinion it's a bad approach to it.

Going off of opinions alone is only a reasonable way to proceed with a project in fringe cases. Unless you can give a reason why it's substantially more difficult than other things or doing it in soft code is inefficient, there isn't really a good motivation to put it in hard code.
In response to Popisfizzy
having to concern yourself with client view is reason enought. having to create a different z level for each "z-layer" you want to have is also not pratical.
In response to Kaiochao
Hey, would you mind sharing the code from your Boats example?
In response to Steamp0rt
Basically you have a vehicle system where entering the vehicle teleports you to the vehicle's interior space, which may be an instanced space on some other z-level. (Same as any instanced housing system, just that the house moves.)

Then, you add all the turfs from the interior space to the vis_contents of the exterior vehicle obj. It's that simple for showing the entire interior on the exterior map. By just adding turfs, you also get everything in those turfs' contents, so you're basically displaying a separate part of the map attached to the exterior obj.

The seamlessness in the Boats video comes from pixel movement, custom movement controls, and camera control, so that the player seamlessly enters the boat at the correct relative position, the movement controls' directions stay relative to external space, and the camera follows the player in external space.

Gliding (tile and non-tile) doesn't happen through vis_contents. That is a big problem with this. oops
In response to Kaiochao
Visual contents actually do preserve gliding in certain cases. If a turf is in vis_contents, any objects on that turf that are gliding will show their correct glide positions. The only caveat is that it can't show objects that are gliding out of the turfs in vis_contents onto an outside turf.
That caveat is the only issue I've ever had using it, and it's easy enough to overcome with some visual padding.