ID:2377904
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
as it stands now, vis contents works as follows:

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. That is, pixel_x and pixel_y offsets will be applied automatically, so if you add an entire block to visual contents (be aware this will impact performance), you don't have to do anything else to make the block appear normal.

however, this doesn't apply when transforms are used, effectively locking vis contents to a *1 scale.

Ideally, vis_contents would allow custom offsets, but perhaps making the offsets based on the atom with the vis_content's scale would work as well. I'm not quite sure how it works internally - so I can't really provide any suggestions on the matter.
Maybe a mockup of what you are trying to acheive would communicate the idea better?
In response to Ter13

Maybe a mockup of what you are trying to acheive would communicate the idea better?

Yeah, good point.

I'm currently trying to make a multi-level z-rendering system (eg, you can see the level below you) - however, I also wanted to make the preview of the next floor down smaller.

When applying a transform to the turf with vis_contents getting added to it, however, I get something like this:
https://cdn.discordapp.com/attachments/318253562096386048/ 459032950852288513/unknown.png

Ideally all those "blocks" of vis_contents would be condensed into the single turf, but I don't think there's a way to do this quite yet.

When I get home, Ill see if I can remember what I did here. Its probably not going to be viable, but Ill check.
Wouldn't this be doable by putting an object with the offset in your visual contents, and then putting the turfs in that?
In response to Lummox JR
Lummox JR wrote:
Wouldn't this be doable by putting an object with the offset in your visual contents, and then putting the turfs in that?

Yes. The trick I found is to KEEP_TOGETHER the block of turfs and then scale them down using transform.
Speaking that, I haven't made a test case for this yet as I found it by using ss13 debugging tools to do it at runtime so i haven't been able to submit a fulltime bug report, but vis_contents and auto-offsetted turfs don't work on secondary map controls. It scales the map control as one tile (understandable, but annoying) and it just shows white for all but the bottom left most tile if you manually scale the map control.

I was hoping to take the ai multicam thing and expand it to secondary map controls in order to allow for basically pop out views of the game world that can go on another monitor as an admin tool.
MSO, there's a quick solution to that: Have at least two screen objects on the secondary map, one for the lower left corner and one for the upper right, that have no icons. (E.g., "1,1" and "6,6" for a 6x6-tile map.) Then you can place the object with the turfs wherever you like in that region.
In response to Lummox JR
Lummox JR wrote:
MSO, there's a quick solution to that: Have at least two screen objects on the secondary map, one for the lower left corner and one for the upper right, that have no icons. (E.g., "1,1" and "6,6" for a 6x6-tile map.) Then you can place the object with the turfs wherever you like in that region.

Does TILE_BOUND prevent view stretching in secondary maps?
TILE_BOUND should not prevent an atom from appearing in visual contents, but will prevent it from being marked as an "ex" turf, or from marking the turf it's on in that way if it's a movable.

It also prevents some checks that see if a big icon has differing visibility over multiple tiles. I.e. if the tile it's on is blocked out, it can still be shown if it appears on another, but not so with TILE_BOUND.

In any event it shouldn't impact the control's tile size, which is determined entirely by screen_loc. Unless you mean the behavior in which screen_loc will also stretch because of a big icon, in which case it does prevent that. And that screen_loc stretching does not take visual contents into account, which frankly would be way more trouble than it's worth.
Okay, so by virtue of being in vis_contents alone, the view is not stretched. Nice.