Flicking a Multi-Tile Icon's state [Problem Solved]

Page: 1 2
Sep 4 2008, 6:37 am
In response to Xooxer
Xooxer wrote:
Proper use of overlays should automatically flick the same > state as the object it overlays. Your bottom half and top
half should have separate icons with the same exact
icon_states, but drawn to fit the top or bottom. When you
flick the mob, it should automatically flick the overlay if
the overlay has the same icon_state in it's icon. Movement
works like this as well. So long as the overlay has the same > icon_states, it should automatically try and match its
object's states as they change.

I already knew that, but...

That doesn't work the same if your overlay is of a "usr.overlays+=/obj/boyjump" style overlay, because for overlays that are not on the same 32x32 area (multi-tile icons) they don't flick properly like that

refer to
http://www.byond.com/developer/forum/?id=661588

That's like how i have it setup in a way,
I'm wanting the top icon to flick at the same time as the bottom icon, but because it's a multi-tile, that just makes it a hell of a lot more difficult
Sep 4 2008, 7:03 am
In response to ElderKain
Then don't do it like that. :P Add an object as an overlay and give the bottom mob a reference to the top. Then you can flick the object separately if you want, or rely on the automatic behavior.
Sep 4 2008, 7:22 am
In response to Xooxer
Xooxer wrote:
Then don't do it like that. :P Add an object as an overlay and give the bottom mob a reference to the top. Then you can flick the object separately if you want, or rely on the automatic behavior.

how would I go about editing the code like that, becasue every time I try to flick the top overlay icon, it doesn't flick at all.
Sep 4 2008, 7:30 am
In response to ElderKain
Instead of using overlays += /bla/bla/bla, create a new player variable called top, and set it to the object you want to overlay, then just do overlays += top. Then you can just flick the usr, and the overlay should also flick if you followed the directions in my previous post.
Sep 4 2008, 7:30 am
In response to ElderKain
Nevermind about that, I fiured it out now, I made the error of flicking the icon_state rather than the dmi itself, so I now have
    jumpblock()
                if(usr.dir==SOUTH)
                    src.density=0
                    flick('boyjump.dmi',usr)
                    usr.loc = locate(usr.x,usr.y-1,usr.z)
                    sleep(5)
                    usr.loc = locate(usr.x,usr.y-1,usr.z)
                    src.density=1
                else
                    ..()

and it works right now ^.^
Thanks for your help.

lol it sure is a less crowded code now, lol
Sep 4 2008, 10:41 am
In response to Xooxer
It's not needed to use a special way to overlays or anything, it should work and he must AFAIK have done a mistake somewhere. Also, there is not really any connection between an object that has been used as an overlay, to its actual overlay. The only thing keeping a reference to the object used is useful for, is removing it later (otherwise it's impossible without flushing the whole overlays list). It just seemed you imply if you change the object visually with flick() or whatever after it has been added, the overlay will update - but whenever you use some value (icon file, atom reference, atom type path, image...) and add it to the overlays, a visual 'snapshot' of it at the time of addition is what's 'overlayed'.

Anyway, ElderKain, make sure you understood what you actually need to do. Both the atom that the overlay belongs to and the overlay need to have the same icon state (you must flick() an icon_state name) in their icon file (the one you're using with flick()). Then the overlay will simply change to it whenever you flick() its 'owner', pixel-offsetted or not. I put up a quick example for you here. http://www.byond.com/members/Kaioken/files/ overlayflick_src.zip
Sep 4 2008, 10:49 am
In response to Kaioken
Kaioken wrote:
It's not needed to use a special way to overlays or anything, it should work and he must AFAIK have done a mistake somewhere. Also, there is not really any connection between an object that has been used as an overlay, to its actual overlay. The only thing keeping a reference to the object used is useful for, is removing it later (otherwise it's impossible without flushing the whole overlays list). It just seemed you imply if you change the object visually with flick() or whatever after it has been added, the overlay will update - but whenever you use some value (icon file, atom reference, atom type path, image...) and add it to the overlays, a visual 'snapshot' of it at the time of addition is what's 'overlayed'.

Anyway, ElderKain, make sure you understood what you actually need to do. Both the atom that the overlay belongs to and the overlay need to have the same icon state (you must flick() an icon_state name) in their icon file (the one you're using with flick()). Then the overlay will simply change to it whenever you flick() its 'owner', pixel-offsetted or not. I put up a quick example for you here. http://www.byond.com/members/Kaioken/files/ overlayflick_src.zip

i've already solved this problem, but thanks anyway for the responce
Sep 4 2008, 10:54 am
In response to ElderKain
Apparently inadequately, though. I was also posting for the sake of providing information to everyone anyway; some of the previous post(s) here were somewhat mistaken.
Sep 4 2008, 11:29 am
In response to Kaioken
Yes, I know it's only graphical, but what I said still holds true. His mistake was not using the right icon setup, as I already stated. He needs to have the images for the bottom and top to be in two separate icons with the same EXACT states, or else the default automatic behavior I'm describing won't work.
Sep 4 2008, 12:27 pm
In response to Kaioken
Kaioken wrote:
Also, there is not really any connection between an object that has been used as an overlay, to its actual overlay.

That's not entirely correct. He would have to remove and add the object if he wants to flick just that overlay, but the original object can reference its overlay, but only when adding or removing it from the overlays list, or if you del() the original object.

The only thing keeping a reference to the object used is useful for, is removing it later (otherwise it's impossible without flushing the whole overlays list).

Also not true. He can do overlays -= /bla/bla/bla and remove an overlay from the list without having to dump all the overlays. Keeping a reference to an overlaid object has many benefits besides access it's overlay. You can't overlay a type with pixel_ offsets, for one. Other features require an actual obj reference as well.


It just seemed you imply if you change the object visually with flick() or whatever after it has been added, the overlay will update - but whenever you use some value (icon file, atom reference, atom type path, image...) and add it to the overlays, a visual 'snapshot' of it at the time of addition is what's 'overlayed'.

Well, in way. I wasn't flick()ing the overlay, though, but the underlaying mob. The overlay, if created properly, will match the mob's flick if it's icon has the same state as it's underlying mob. That's what I said, and no matter what you might think, it is correct. The same behavior is seen for movement states too.


Anyway, ElderKain, make sure you understood what you actually need to do. Both the atom that the overlay belongs to and the overlay need to have the same icon state (you must flick() an icon_state name) in their icon file (the one you're using with flick()). Then the overlay will simply change to it whenever you flick() its 'owner', pixel-offsetted or not. I put up a quick example for you here. http://www.byond.com/members/Kaioken/files/ overlayflick_src.zip

Yeah, wait. I already said that before you posted this. o_0 Did you even read my replies?
Sep 5 2008, 12:24 am
In response to Xooxer
Xooxer wrote:
The only thing keeping a reference to the object used is useful for, is removing it later (otherwise it's impossible without flushing the whole overlays list).

Also not true. He can do overlays -= /bla/bla/bla and remove an overlay from the list without having to dump all the overlays.

Incorrect. You can only delete an overlay by removing [from the overlays list] the same value you've used to add it in the first place. Removing a type path such as /bla/bla/bla will only work if that overlay was originally added like this: 
overlays += /bla/bla/bla

More info here. [link]

Keeping a reference to an overlaid object has many benefits besides access it's overlay.

With regards to overlays (and not anything unrelated, such as keeping a reference to an equipped...piece of equipment, so you can reference it later and do stuff with it), I don't see any other benefit strictly in keeping the reference.

You can't overlay a type with pixel_ offsets, for one.

Of course you can. I've also done it in the example environment posted before.

Other features require an actual obj reference as well.

Not necessarily, but anyway you're misunderstanding. I'm discussing keeping a reference to the object, which is really overlay-wise only useful to remove its overlay later. You can also set a temporary reference to the object but not keep it, causing it to be deleted, and accomplish it without keeping a reference. 
//not keeping a reference, and the object will get 'garbaged':
var/obj/O = new()
O.icon = 'i.dmi'
O.pixel_y = 32
O.layer = MOB_LAYER
usr.overlays += O
//end of the proc
//del O

//keeping a reference
mob/var/obj/myObject
//...
usr.myObject = new()
//...
usr.myObject.pixel_y = 32
usr.overlays += usr.myObject

(
//different proc later
usr.overlays -= usr.myObject
)



Well, in way. I wasn't flick()ing the overlay, though, but the underlaying mob. The overlay, if created properly, will match the mob's flick if it's icon has the same state as it's underlying mob. That's what I said, and no matter what you might think, it is correct. The same behavior is seen for movement states too.

Hm? I wasn't saying you were incorrect on this. In fact I told the OP to use the same behavior and used it in my example. And it has nothing directly to do with keeping a reference to the object, only with the object and mob having suitable icons.

Yeah, wait. I already said that before you posted this. o_0 Did you even read my replies?

Yes, I have. As I said, if it didn't work for him he must have done something wrong, therefore I told him how to try it again and provided an example in case he doesn't understand our explanations.
Sep 5 2008, 7:46 am
In response to Kaioken
Kaioken wrote:
Also not true. He can do overlays -= /bla/bla/bla and remove an overlay from the list without having to dump all the overlays.

Incorrect. You can only delete an overlay by removing [from the overlays list] the same value you've used to add it in the first place.

No. I'm not incorrect.


With regards to overlays (and not anything unrelated, such as keeping a reference to an equipped...piece of equipment, so you can reference it later and do stuff with it), I don't see any other benefit strictly in keeping the reference.

No, you wouldn't.


Of course you can. I've also done it in the example environment posted before.

I didn't look at your demo. I already answered his question and the topic, as far as I knew, was done.


Not necessarily, but anyway you're misunderstanding.

No, I m not. You are misunderstanding just about everything I write. Please stop. It's really starting to get old.


I'm discussing keeping a reference to the object, which is really overlay-wise only useful to remove its overlay later. You can also set a temporary reference to the object but not keep it, causing it to be deleted, and accomplish it without keeping a reference.

Yeah, I just tested this and I was wrong that deleting an object would remove the overlay. It remains even if the object is gone. I was sure this wasn't the case, but perhaps I was thinking about images.


Hm? I wasn't saying you were incorrect on this. In fact I told the OP to use the same behavior and used it in my example. And it has nothing directly to do with keeping a reference to the object, only with the object and mob having suitable icons.

Yes, you did say I was incorrect. Your whole reply was one big "you're wrong", when in fact, I was not.


Yes, I have. As I said, if it didn't work for him he must have done something wrong, therefore I told him how to try it again and provided an example in case he doesn't understand our explanations.

No. You posted specifically to "clear up the confusion". Confusion, I must say, that you brought. Sounds a little to close to our last little tiff about areas, doesn't it? This seemed to me to be a deliberate attempt to get some sort of rise out of me, and I don't appreciate being told I'm wrong then having my own solution given as correct. Just stop.
Sep 5 2008, 7:55 am
In response to Xooxer
ok, there is enough arguing people.
I have a meathod that works, and it works just fine now, so there is no need to argue anymore.

all it's doing is confuing people who try to read through it, lol.
Sep 5 2008, 8:03 am
In response to ElderKain
Yeah, I'm done here. Kaioken can have the last word. I won't let this slip into another pointless rant.
Sep 5 2008, 8:35 am
In response to Xooxer
Whoa, slow down, dude. You really don't need to get so heated up (sensitive much? :o), though I can't help it if you decide to misinterpret what I've said and make up that I've said things I didn't. I can't help it if you decide to apparently get confused and blame it on me, either; I was simply posting because regardless of your statement that the topic "was over", the OP didn't seem to get your solution to work (it is unclear what he did in the end, but he did change to flicking a DMI which wouldn't flick the overlay as he wanted) and I attempted to explain it again so he can do it. I also posted to correct some things you've said which were quite inaccurate, which I don't feel calls for attacking me.

Xooxer wrote:
Sounds a little to close to our last little tiff about areas, doesn't it?

If I get what you mean then that was ages ago, so I wouldn't call it the latest/last, or it shouldn't be called as such anyway. If you're still concerned about it enough to bring it up inadvertently months later, though, maybe you're the one actually trying to get a jab at me for it.

This seemed to me to be a deliberate attempt to get some sort of rise out of me, and I don't appreciate being told I'm wrong then having my own solution given as correct.

I was saying you were wrong on some specific things, one of which you've agreed you were wrong about, and you're confusing it with a completely different thing (the fact flick()ing an object with an icon state will also 'flick' its overlays and underlays under the suitable conditions, such as the overlay having that state in the DMI used to create it). I did not say you were wrong in talking about the above filck() behavior, and was aware of it before this topic. I would like you not to make up crap. Getting needlessly personal is not required, either.
Sep 5 2008, 8:39 am
In response to Kaioken
I'm not too concerned about who started this, or who said what. Please leave it there, it isn't really helping the OP any more. Cheers.
Sep 5 2008, 8:48 am
In response to Stephen001
Stephen001 wrote:
I'm not too concerned about who started this, or who said what. Please leave it there, it isn't really helping the OP any more. Cheers.

I completly agree with you there, lol
at least Xooxer, said he would stop with the pointless argument, lol.

This problem has been solved anyways, and going into argument over it anymore it just pointless, it's not like some1 is gonna read through every one of thoes argument issues... lol
Sep 5 2008, 9:02 am
In response to Kaioken
I've got nothing against you. You're one of the more helpful posters here, and your advice is usually spot on. I just think we need to stop butting heads like this. It's giving me a migraine. :P
Page: 1 2