Flick() for /image
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.
Flick()ing overlays has been a feature long overdue.
Given the ability to pick which clients can see an image object lets you create whatever type of visibility handling you need.
I should be able to easily set custom visibility on any atom, without needing to create an entire system to manage some awkward /images.
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.
If BYOND was looking for a next big feature to add it would probably be this one.
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.
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.
A per-atom list doesn't help you create different appearances for the same atom either - the atom still has one icon/icon_state.
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.
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.
Overlays do not visually work as they should, they do not properly maintain references to objects
var/o = new /obj/some_obj()overlays += o// later on:flick("attack", o)
and they do not update properly.
Attaching a mob to a mob isn't any easier than attaching an image to a mob
mob/var/tmp/ghostImagemob/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 createobj/Ghost icon='Ghosts.dmi' layer=FLOAT_LAYER show_visible=list("Ghosts")
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.
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().
Unfortunately there's a reason why things happen that way and what you're asking for might not be feasible.