ID:2960992
 
Resolved
Setting the pixel_w argument in image() was applying it incorrectly to pixel_z, which would then get clobbered by the actual pixel_z argument if present.
BYOND Version:515
Operating System:Windows 11 Home 64-bit
Web Browser:Chrome 131.0.0.0
Applies to:Dream Daemon
Status: Resolved (516.1652)

This issue has been resolved.
Descriptive Problem Summary:
Per the v323 release notes, image() has several optional arguments for pixel offsets. Providing arguments for pixel_x, pixel_y, and pixel_z will work, but not for pixel_w.

Code Snippet:
mob/verb/ImagePixelOffsets()
// pixel_w doesn't work, regardless of whether or not the argument is explicitly named, i.e. pixel_w = 128
var/image/i = image(icon(), src, "what", 2, NORTH, 16, 32, 64, 128)

world << "pixel_* offsets: {x = [i.pixel_x], y = [i.pixel_y], z = [i.pixel_z], w = [i.pixel_w]}"


Expected Results:
Output: pixel_* offsets: {x = 16, y = 32, z = 64, w = 128}

Actual Results:
Output: pixel_* offsets: {x = 16, y = 32, z = 64, w = 0}

Reasoning:
I'd wager this is a bug due to the fact image() accepts pixel_w as a named argument--yet will reject anything else that isn't supported (like suffix or maptext_x, for example). It would also be strange to only support setting pixel_z and not its companion pixel_w.
Oh. There's some history here. pixel_x,y, and z are old; 1999 or so. Pixel_w was added in 2013 or so in response to a problem I ran into.
Lummox JR resolved issue with message:
Setting the pixel_w argument in image() was applying it incorrectly to pixel_z, which would then get clobbered by the actual pixel_z argument if present.

Login to reply.