ID:2334531
 
(See the best response by Flick.)
Code:
world/icon_size = 32
world/maxx = 4
world/maxy = 4
world/maxz = 1
turf
icon = '32px.dmi'
icon_state = "turf"

var/testTime = 20

client/New() // When the project starts, begin test.
. = ..()
// Trigger the addition of borders so we can see the full test
var/obj/borderObj = new()
borderObj.screen_loc = "1,1 to 4,8"
screen.Add(borderObj)
// Make the test plane and begin cycling it
var/testPlane/T = new(src)
spawn(1)
while(src) // Run the test continually
T.lift()
sleep(testTime)
T.lower()
sleep(testTime)

testPlane
parent_type = /obj
plane = 10
appearance_flags = PLANE_MASTER | TILE_BOUND
screen_loc = "1,1"
//screen_loc = "1,-4"
icon = '128px.dmi'
icon_state = "planeMaster"
New(client/client)
var /liftObject/L = new()
client.screen.Add(src)
client.screen.Add(L)

proc
lift()
var high = 128
var highMatrix = matrix().Translate(0, high)
animate(src, transform = highMatrix, time = testTime)
lower()
var lowMatrix = matrix()
animate(src, transform = lowMatrix , time = testTime)

liftObject
parent_type = /obj
plane = 10
icon = '128px.dmi'
icon_state = "planeTest"
screen_loc = "1,1"


Problems and Tacos:
I want to make a plane of screen objects that I can translate over the map. The end goal is to be able to group screen objects and move the groups independently. I'm trying to do this by grouping hud objects into planes, and then applying a Translation transformation to the plane master.

If you run the test above (supplying appropriate icons) you'll see the problem. As the plane is moved north, the lower portion of the plane objects begin to disappear.

This can be countered by changing the screen_loc of the plane master (uncomment the noted line). However, this causes the problem of adding a large border to the bottom of the map. Adding TILE_BOUND to the plane master's appearance_flags has no effect.

Any ideas?


This sounds a lot like id:2277933 which was supposedly fixed/added? Are you using the current beta?
Thanks for the heads up! I just updated from 1401 to 1402 to be sure. Behavior hasn't changed. It certainly does look like the same issue you were having (same use-case, too).

If you have a moment, you could try compiling the above code to see if you experience the same behavior. If you do and we have different versions, then I'll file a bug report. If you do and we have the same version, then we can conclude there's a solution in code.
Best response
Yeah, that's odd. I'm not sure it's quite the same issue actually, and I don't know if mine actually got fixed. By the time the fix was done, I had changed my method for doing it to something else and never went back and tested it :P
Check out the beta's vis_contents feature. It seems like the perfect solution for HUD groups that move as a unit while still keeping the individual parts completely interactive.
In response to Flick
Flick wrote:
By the time the fix was done, I had changed my method for doing it to something else and never went back and tested it :P

I've done the same for the moment. Because my hud objects all derive from a common type and keep track of their children, I'm able to define a translate() proc that animates itself and then calls translate() recursively on its children. There are some other effects I'd like to be able to use plane offsets for, though, and this strategy won't work.

I'd say this is definitely a bug. If you change
var highMatrix = matrix().Translate(0, high)

to:
var highMatrix = matrix().Translate(high, 0)

the hud slides in and out to the right just fine. It's only up and down that is a problem.