Overlays and Matrix

ID:1842354
 
Apr 29 2015, 3:32 am (Edited on Apr 29 2015, 3:39 am)
(See the best response by Lummox JR.)
So I am currently using Scale() to flip an icon horizontally for when the player moves left and right. My current issue is I have an indicator on the player,s number that is in the players overlays and I don't want that to flip. I tried doing something like:

move_west()
     for(var/obj/o in usr.indicator)
          usr.overlays-=o

     var/matrix/M = matrix()
     M.Scale(-1, 1)
     usr.transform=M

     for(var/obj/o in usr.indicator)
          usr.overlays+=o
     //moving code here

I did this thinking that the reason the indicator was flipping was because it was being given the same matrix because it was an overlay at the time of changing the transform. I was wrong and it seems that anything added to overlays before or after transform is changed also changes the overlays.

What I need is a way to keep the indicator's current matrix. I tried:
move_west()
     for(var/obj/o in usr.indicator)
          usr.overlays-=o

     var/matrix/M = matrix()
     M.Scale(-1, 1)
     usr.transform=M

     for(var/obj/o in usr.indicator)
          o.transform=M
          usr.overlays+=o
     //moving code here


I think the issue I am having is that my shooting verb is calling a flick() and for some reason the Scale flip isn't working on the flick(). But this is tricky.. because the Scale is working on rest of the icon just not the indicator.


Is there a way to fix this?
Apr 29 2015, 8:03 pm
Best response
An atom's transform, color, and alpha all impact its overlays and underlays. There's a feature request for something that would override this, but so far there isn't a good syntax for it. If you have ideas for it, feel free to contribute them to that thread.
Apr 30 2015, 4:57 am
"to that thread". Guess you read something different to others eh? lol
Apr 30 2015, 4:57 am
Doing that with a custom layer would be a really ugly method, especially since altering the layer would likely be desirable. I think the situation does call for a new var, but the best suggestion we've got so far is bitflags. That might be what I have to end up going with, but I'd like to get more input and more discussion.
Apr 30 2015, 7:25 am
In response to Lummox JR
I thought i knew which thread it was but i got lost, could you link the topic please?

Apr 30 2015, 9:13 am
The post is id:1763636, but there's probably an older one hanging around somewhere too.
Apr 30 2015, 9:15 am
Alright, thanks.
Apr 30 2015, 2:18 pm
It isn't the best way to fix it, but as a temporary fix:

mob
     Move()
          ..()
          for(var/obj/o in src.indicator)
               o.loc=src.loc
               o.step_x=src.step_x
               o.step_y=src.step_y


Forget having it as an overlay or underlay.. just make it follow with Move().

If it isn't too much to ask what is the point of having overlays and underlays... You could have an overlay that acts as an underlay and vise-versa by simply making the layer higher/lower than the icon.
May 1 2015, 3:49 pm
I'd guess the point of them is to simplify the whole process for developers; one is able to make the base object know about/manage it's own overlays and underlays in a sensible manner, expected behaviour -like an object's o/u-lays moving relative to the object- automatically handled, without much thought or additional specification needing to be done by the programmer.

To sum it up, i'd say it's just more convenient ...well mostly ;). At the same, i'd imagine this means that if we are to decide that defining an o/u-lays system directly is our preferred method, then beyond the ease of the process*, programming wise (only needing to manipulate the lists and keeping track of the order in which changes are made to them) i would think that one wouldn't particularly lose much of anything by choosing to create something ourselves.


*I'd think though that having things like movement in relation to the anchor/pivotal atom handled internally by the system for this kind of thing will also mean it will always be the more optimised and all that, which is naturally a good thing.