ID:116655
 
Applies to:
Status: Open

Issue hasn't been assigned a status value.
Please add support for some kind of /image flick(). Please.
Is there any reason why this isn't feasible?

It'd probably be sufficient if flicking the underlying object flicked all images attached to it, even if you couldn't flick a particular image object. It'd be a start, at least.

Currently image objects aren't that useful because you can't use them to represent objects that need to play animations.
Personally I'm waiting on this. I'm in the progress of recoding Tanx and I'm planning to implement multiple turrets which can flick their firing animations separate from the main tank.

I may just go the extra step and make them mobs that constantly update to match the owner, but I'm a bit iffy on that idea.
In response to Bravo1
Bravo1 wrote:
I may just go the extra step and make them mobs that constantly update to match the owner, but I'm a bit iffy on that idea.

They don't even need to be mobs, but that is a good alternative to using overlays. I think it's what Forum_account's Overlays library does to handle individual overlay flicking, actually.
Yes, when you flick an overlay it replaces the overlay with an obj at the same position.

It sounds possible to do what Bravo1 needs by making objects follow the tank's position. This is easy with the Pixel Movement library, you just override set_pos() and make it update the position of each turret.

This feature is still necessary though, since I'm pretty sure that image objects just can't be flicked (even if the atom they're attached to is).
Flick()ing overlays has been a feature long overdue.
In response to SuperAntx
SuperAntx wrote:
Flick()ing overlays has been a feature long overdue.

That's certainly true and I'd group it with this feature request, but it's possible to emulate flicking overlays in the meantime. The only way I can think to play an animation to only certain clients is with screen objects, which is much more difficult to manage than being able to flick an image attached to an atom.
/images have terrible design to begin with. They are difficult to work with/unintuitive, and obviously lacking in functionality. We shouldn't be trying to get them improved, we should be trying to get some competent visibility handling systems that we can apply to standard objects.
Images aren't any worse than overlays. We don't need an entirely different solution, we just need BYOND's pseudo objects (icons, images, overlays, etc.) to be a little more functional. Given the ability to pick which clients can see an image object lets you create whatever type of visibility handling you need.
In response to Forum_account
Forum_account wrote:
Given the ability to pick which clients can see an image object lets you create whatever type of visibility handling you need.

Having to create some special /image object is the problem to begin with. I should be able to easily set custom visibility on any atom, without needing to create an entire system to manage some awkward /images.
In response to Falacy
Falacy wrote:
I should be able to easily set custom visibility on any atom, without needing to create an entire system to manage some awkward /images.

I agree with Falacy on this one, but it's not quite related to this request. If BYOND was looking for a next big feature to add it would probably be this one. Though, Flick()ing overlays is still something which should have been added long ago. There's also this outstanding bug related to flick().
In response to Falacy
Falacy wrote:
Having to create some special /image object is the problem to begin with. I should be able to easily set custom visibility on any atom, without needing to create an entire system to manage some awkward /images.

While it'd be easier to be able to say something like "client.objects += some_atom" to make some_atom visible to that client only, you can't accomplish the same effects you currently can. What if you want the same object to appear differently to different players? Image objects aren't the easiest things to use and are lacking some important features, but the basic approach (creating an image which is the object's custom appearance and selecting who can see it) is correct and essential for these types of effects.

SuperAntx wrote:
If BYOND was looking for a next big feature to add it would probably be this one.

What kind of game would greatly benefit from that feature? I can't think of too many uses that aren't easily doable with image objects.
In response to Forum_account
Forum_account wrote:
While it'd be easier to be able to say something like "client.objects += some_atom" to make some_atom visible to that client only, you can't accomplish the same effects you currently can.
That's almost how it works now, and not how I'm requesting the new systems work. There should be per-atom lists that control visibility, as explained in that feature request we linked to, but Lummox said that wasn't possible for some reason.

What if you want the same object to appear differently to different players? Image objects aren't the easiest things to use and are lacking some important features, but the basic approach (creating an image which is the object's custom appearance and selecting who can see it) is correct and essential for these types of effects.
Doesn't seem like it, but I can't think of anything better at the moment.

What kind of game would greatly benefit from that feature? I can't think of too many uses that aren't easily doable with image objects.
As mentioned in that request, there are several common uses: invisible classes, traps, roofs, cut-scenes, per-player puzzles (pushable blocks and such) in a shared area, etc.

EDIT:
* With lists on the atoms, instancing would be simple. You would simply set the show_visible=list("Instance 1") and the see_visible=list("Instance 1"). You could even easily override hit detection using Cross() and these vars.
* For something like a chest, you could just set its show_visible=list("Chest 1") and have the default see_visible contain "Chest 1". When they open the chest, you just take its show_visible from your see_visible, and reveal an open chest below.
* For things like TF2 spies, you would do something similar to instances, when they turn invisible, you set their show_invisible=list("Red Team") and the red team members will have see_invisible=list("Red Team") so the spy would only disappear to all blu members.
* If you wanted to show something to a specific player, you could simply use their key as the entry in the lists
* An empty show_visible list would just show to everyone. An empty see_visible list would have no special effect.
* There could also be some built-in options like SEE_ALL that you could place in the show/see_visible lists
* As these are lists, you can obviously customize them with multiple sight groups
In response to Falacy
A per-atom list doesn't help you create different appearances for the same atom either - the atom still has one icon/icon_state.

EDIT: ...

Everything you described there is easily possible with images. The visibility lists are a simple way to determine when to show an image object to a particular client and works almost exactly like the Visibility Groups library. Adding a built-in way to handle this still doesn't give us the ability to flick image objects, which is something that'd be nice to have anyway.
In response to Forum_account
Forum_account wrote:
A per-atom list doesn't help you create different appearances for the same atom either - the atom still has one icon/icon_state.
The lists are just for hiding/showing objects.

Everything you described there is easily possible with images.
Nothing is easy with /images, since /images themselves are clunky to use.

The visibility lists are a simple way to determine when to show an image object to a particular client and works almost exactly like the Visibility Groups library.
Horseshoes and hand grenades!

Adding a built-in way to handle this still doesn't give us the ability to flick image objects, which is something that'd be nice to have anyway.
That edit I made really belongs in/is restating information from the other topic, but you were asking when it would be beneficial, so I was explaining it here.
I'll just skip the banter and say:

Visibility groups: Yes

Allowing you to attach any movable atom to another: Yes

Allowing you to set the icon state/ flick animation of the attached atom to the base atom: Hell yes

Basically, adding visibility groups and then enabling all movable atoms to have the pros of both images and overlays/underlays without any of the cons is probably the best way to go.

I would like to see images get flick() but upon retrospect, images are kind of crummy and the effect that many developers are looking to get with images could easily be handled in different ways with much more efficiency.
Bravo1 wrote:
images are kind of crummy and the effect that many developers are looking to get with images could easily be handled in different ways with much more efficiency.

The reason that's true is because images are general purpose and people need more specific things. There's nothing wrong with that - the oview() proc doesn't return a list of targets for a magic spell, but using oview() I can easily make the proc I need. The problem here isn't that images are entirely the wrong feature and aren't useful. The problem is just that image objects are lacking some features. Instead of trying to create some complicated built-in visibility system, there are some small improvements that'd go a long way.

Images don't behave exactly like overlays. If you attach an overlay to a mob and flick the mob, it animates the overlay. If you attach an image to a mob and flick the mob, it doesn't animate the image. If you have a mob that appears as a ghost to most players, but some players can see their true form, you would use images to create the ghost and true form representations. The problem is, when you flick the mob to play their attack animation, the images aren't animated. The problem here isn't that it's difficult to manage these representations (it can't be much easier), the problem is the lack of functionality.

Images and overlays would both benefit from being able to be flicked individually. It seems like it should be easy to do. It's possible to keep a reference to an overlay, so if you pass that reference to flick() it should be able to animate just one overlay. I suppose there might be problems with concurrent flicks (ex: what happens to the overlay when you flick a single overlay then flick the mob it's attached to?).
As Bravo mentioned "Allowing you to attach any movable atom to another". This is the proper way to handle things, not with some custom subtype of /images that don't work worth a crap themselves and are unintuitive to make use of in the first place.

If we had proper visibility settings, and a way to attach any atom to another atom, there would be no need for this. You simply create /mob/Alive /mob/Dead and attach them both to /mob/Player (like functional overlays). There is no special /image creation, or management of who these are output to. To change who can see them, you just intuitively manage the see_visible lists. If you want to flick() all of these things at once, you could just do for(var/atom/A in src.attachedAtoms+src) flick("Attack",A).

Overlays do not visually work as they should, they do not properly maintain references to objects, and they do not update properly. /images are clunky to use in just about every way, and visually update even less effectively.
Attaching a mob to a mob isn't any easier than attaching an image to a mob, the difference is in how the attached object behaves. The only other difference is that you're using lists to determine visibility, but you can easily build this abstraction yourself and use it to decide when you add or remove an image from a client's image list.

Overlays do not visually work as they should, they do not properly maintain references to objects

You'd only need to maintain a reference so you can call flick later:

var/o = new /obj/some_obj()
overlays += o

// later on:
flick("attack", o)

You can maintain references to overlays so you can remove them or add them back later, so these references should be sufficient for calling flick().

and they do not update properly.

Unfortunately there's a reason why things happen that way and what you're asking for might not be feasible.
In response to Forum_account
Forum_account wrote:
Attaching a mob to a mob isn't any easier than attaching an image to a mob
mob/var/tmp/ghostImage
mob/verb/Ghost_Image()
src.ghostImage=new/image('Ghosts.dmi',src)
src.client.images+=src.ghostImage
//you have to then manage this on a per player basis
//every time a new player logged in, you would have to output this image to them for every mob in existence
//assuming players can toggle seeing ghosts, you would have to loop through every mob in existence and add or remove their ghostImage

//vs

src.ghostImage=new/obj/Ghost
src.attached_atoms+=src.ghostImage
//you wouldn't necessarily even need a reference to the object here
//you could easily find it in a loop, or may never even need to directly use it
//it would also have standard functionality, unlike an /image or overlay
//assuming players can toggle seeing ghosts, all you would have to do is add or remove "Ghosts" from that player's see_visible list

//Just a quick example of the type you could create
obj/Ghost
icon='Ghosts.dmi'
layer=FLOAT_LAYER
show_visible=list("Ghosts")
To further complicate things, if it was a toggle between seeing alive players or seeing their ghosts: With /images, you would have to create and manage another /image to represent the alive players, while the players themselves were basically just iconless mobs. With attached atoms and proper visibility, you could use the player as their alive version by simply setting show_visible=list("Alive Players").

the difference is in how the attached object behaves.
Which wouldn't be an issue if this was supported for standard atoms, instead of some awkward /image objects and overlays converted into "appearances", whatever that even means.

The only other difference is that you're using lists to determine visibility, but you can easily build this abstraction yourself and use it to decide when you add or remove an image from a client's image list.
I suppose you could build it yourself, in a far more complicated, far less efficient/intuitive/standard "library", but that isn't a very good alternative solution to something that should be natively supported.

You'd only need to maintain a reference so you can call flick later:
You can maintain references to overlays so you can remove them or add them back later, so these references should be sufficient for calling flick().
Are you saying that is how you want it to work? Because that isn't how it works now. There is also the issue where flicking the player also flicks all of their overlays, which isn't necessarily desirable, and there isn't a way to avoid it.

Unfortunately there's a reason why things happen that way and what you're asking for might not be feasible.
Aren't you the one requesting the overlay changes?
Page: 1 2