Which wouldn't be an issue if this was supported for standard atoms

I expect that's just not feasible. I'm also not sure how it'd behaved if the attached atom is really an atom - when you click on it, whose Click proc is called?

instead of some awkward /image objects and overlays converted into "appearances", whatever that even means.

Images aren't awkward. You're code example shows nearly identical code for both the image and attached mob. The only problem with images is that their capabilities are limited but being able to flick() them and having them animate to match the object they're attached to would fix this.
In response to Forum_account
Forum_account wrote:
I expect that's just not feasible. I'm also not sure how it'd behaved if the attached atom is really an atom - when you click on it, whose Click proc is called?
Undecided, perhaps both with a special parameter.

Images aren't awkward.
The very creation of an /image is awkward, you have to attach it to another atom.

The only problem with images is that their capabilities are limited but being able to flick() them and having them animate to match the object they're attached to would fix this.
Far from the only problem(s), and it doesn't address the issue that if there were better visibility settings, we could use standard objects, and special /images would be completely unnecessary to begin with.
The very creation of an /image is awkward, you have to attach it to another atom.

Which is the same thing you're doing with the proposed ability to attach mobs. I suppose that both things are a little awkward but there's no way around it, so images aren't unnecessarily awkward.
In response to Forum_account
Forum_account wrote:
Which is the same thing you're doing with the proposed ability to attach mobs.

When creating an /image, you have to attach it to a mob (or atom of some type); new/image(icon,mob). You would not have to do this with standard objects, you would just create them normally, and then add them as an attachment whenever you see fit (similar to overlays). It is more of an issue that /images are the only way to provide selective invisibility, the idea for invisibility lists would basically replace /images, as well as provide far more possibilities and generally better functionality.
It's true that when you create an image that you have to attach it to a mob, but that's the point of images - you attach them to mobs. It's like saying that turfs are bad because you have to define them *and* place them on the map.

Images could function better but it seems very unlikely that the staff will remove images and replace them with a very similar but slightly improved feature, when all they have to do is improve how images work.
In response to Forum_account
Forum_account wrote:
It's like saying that turfs are bad because you have to define them *and* place them on the map.

I would say turfs are bad. Not quite as bad as images, but turfs have a ton of issues themselves, and really shouldn't be used for anything other than the most basic level of "ground", though people tend to use them for building just about everything. The only real advantage of turfs is that you can somehow have a practically unlimited amount of them when you start the game, while most/all other types are limited to ~65k.
Being able to flick images would be nice.
Klaatu Verata... uh...
wot
The way flicks are handled, I believe this will require a minor message format change and therefore should wait till 510 at the earliest.
Any updates on this? Perhaps something for 511?
Lummox JR resolved issue with message:
flick() has been extended to images.
lummox
update the ref bro

pages for: image objects and override var (atom)
Currently images are not affected by flick().
In response to Super Saiyan X
Thanks. I missed those.
Page: 1 2