The Problem
To make a long story short, as I worked on a map with the intent on ensuring that all of my atoms had the illusion of 3D - I noticed a distinct limitation on manipulating the pixel_z variable for turfs. Naturally, as I did so, the image was displaced leaving a nasty black spot.

And yes, this is an issue I've brought up before [with the solution being deemed redundant - although the feature request itself was different].

Thankfully, with the help of some intelligent BYONDers, I was able to find or recall a solution to help rectify the issue. That solution?? To use objects.

All in all, the answer was to simply place objects along the map, manipulate their step_x/y, then make it so that on creation, the object's variables were transferred to pixel_x/y (or in this case, pixel_z), then simply delete the object! And by god, it worked! My main issue is that, well this is probably unnecessary and I think it ought to be easier to do.

The Solution
As far as my understanding goes, the dmm files already allows for you to manipulate the images. When a new turf is applied onto a bottom turf, both aren't really in existence. Rather, the turf that was applied ontop simply adds the other as an underlay. IE, it becomes an image.

My solution is to just allow Images to be added onto the map itself.

I notice that in recent updates, more and more Data Types are being made available in the 'Object' Tree. I don't see why an image can't simply be made apart of the Tree - that way, the variables could be manipulated. And like a turf, it would be select-able and allowed to be placed along the map. Any turf (or object I suppose) on the map that you clicked, would have the image attached and represented.

Closing Thoughts

In any case, even though this is already possible via other means (like I've explained in that excerpt two paragraphs above), I just honestly feel the middle man should be cut out. If it wouldn't be too much trouble (and it probably is), this would be a small addition I think would amazing.