ID:651156
 
Keywords: mapeditor
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
It was submitted as a bug last year, but I thought I would officially submit this as a feature request to see if it's feasible to improve on this behavior.

As it is now, when inserting a turf on top of a another, the map editor shows the underlaying turf with its defined direction. However, when the game is actually run, the underlay uses the top turf's direction.

I would like to request that it pass the underlaying turf's direction to its runtime underlay counterpart.

You cannot set the direction of an underlay, unless they plan on changing that. You can, however, just make single direction icon_states, if you plan on using them as stackable turfs. Though, you shouldn't be stacking turfs to begin with.
You can set the direction if you use a /image or /icon object. However, it doesn't appear to work if you do it by type path.

Interestingly, actually probing the underlays at runtime reveals that they do have the proper directions set. It appears you can actually fix them by just re-adding any underlays via image():
turf/proc/FixUnderlays()
if(underlays.len)
var/list/newUnderlays = list()
for(var/A in underlays)
newUnderlays += image(icon=A:icon, icon_state=A:icon_state, layer=A:layer, dir=A:dir)

underlays.Cut()
underlays += newUnderlays
In response to DarkCampainger
DarkCampainger wrote:
Interestingly, actually probing the underlays at runtime reveals that they do have the proper directions set.
I suppose I shouldn't have said that you can't set them. You can set them, it just doesn't effect the way they display. For example, you can create a sword object, set its direction to north, but if you add it to a player's overlays, it will still match their direction, instead of always facing north.

It appears you can actually fix them by just re-adding any underlays via image():
It is possible that the image() proc works by creating a new icon that only contains the specific data, though I can't seem to setup a test to check what actually gets created through image(). Assuming that it works like the icon() proc, then it does just create a new icon with a single relevant frame.
In response to Falacy
Falacy wrote:
I suppose I shouldn't have said that you can't set them. You can set them, it just doesn't effect the way they display. For example, you can create a sword object, set its direction to north, but if you add it to a player's overlays, it will still match their direction, instead of always facing north.

Works fine for me so long as the underlay is a /image or /icon with the dir specified:
obj/TestPath
icon = 'dir2.dmi'
dir = SOUTH

mob/verb/TestByPath()
// Doesn't preserve direction
loc.underlays += /obj/TestPath

mob/verb/TestByImage()
// Does preserve direction
loc.underlays += image('dir2.dmi', dir=SOUTH)

mob/verb/TestByIcon()
// Does preserve direction
loc.underlays += icon('dir2.dmi', dir=SOUTH)


Falacy wrote:
It is possible that the image() proc works by creating a new icon that only contains the specific data, though I can't seem to setup a test to check what actually gets created through image(). Assuming that it works like the icon() proc, then it does just create a new icon with a single relevant frame.

/icon objects actually create a new icon file, but /image objects do not. From the reference entry for the image() process:
[image()] is much preferable to achieving the same effect with icon('pants.dmi',"red"), since that involves the overhead of creating a new icon file, which should only be done when it is really necessary.