I'm playing around SIDE-MAP, and it's going great except any overlay/images' offsets get lost when I add them to screen when using pixel_z. Seems odd since they're virtually interchangeable, except for SIDE-MAP's layer difference.
I would just apply said atom's pixel_z to pixel_y upon displaying it but these atoms have multiple overlays with their own pixel offsets as well.
Honestly the two behaviors should probably be reversed, pixel_y remaining identical across all formats and pixel_z inheriting the layering feature for the sake of consistency.
ID:2045128
Feb 28 2016, 11:15 am (Edited on Feb 29 2016, 5:08 pm)
|
|||||||||||||
Resolved
| |||||||||||||
Feb 28 2016, 12:53 pm
|
|
What you're asking runs directly against the whole point of the var. It sounds like you're trying to use it for a purpose it wasn't intended for.
|
I'm trying to add atoms to a client's screen and wish to have them appear as they are on the map. Some of the overlays in the atom have a pixel_z var to adjust their position (since I'm using SIDE_MAP pixel_y would shift their layer as well as position which I don't want).
Upon adding said atom to a client's screen pixel_z is lost entirely (so the overlays position is not as on the map) which I don't see exactly why that is. |
Pixel offsets are not respected by screen objects, unless they're on an image or overlay. You simply need to position the screen_loc correctly.
|
Is there a possibility of an overlay's pixel offset to be saved somehow? Can you elaborate? |
If you have an overlay attached to an atom that has a pixel offset, I'd like it if overlays weren't subject to the same pixel offset loss as the atoms being added to a client screen.
|
In response to Lummox JR
|
|
Lummox JR wrote:
Pixel offsets are not respected by screen objects, unless they're on an image or overlay. He did say the pixel_z was on an overlay. |
Yeah I remember pixel_y/x working, misread and thought none of the offsets work but only z doesn't.
|
Pixel offsets should always work on an overlay. The code doesn't really allow for them not to.
|
It doesn't for pixel_z, which was my very unclear point, sorry about that. I thought this was intended behavior, I guess this is a bug then?
|