simple visibility procs

ID:1817927
 
Mar 26 2015, 5:08 am
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
atom.visible(mob/m or client/m)

if this returns zero, the atom is/becomes invisible to m.
returns(by default): atom.is_visible(m)
atom.is_visible(mob/m or client/m)

returns: 1 if the atom is visible to m, 0 if not.(more efficient than generating a view() or hearers() proc because it doesn't require a list and only checks for a single atom)


client-sided rendering for whether individual objects are visible is extremely sensible and vastly superior to using image objects.

being able to ask the engine whether a single atom is visible to another atom is also superior to the currently available methods in CPU usage and in design.
Mar 26 2015, 5:44 am
If you mean this should simply be a drop-in substitute for (src in view(m)), I don't think it actually avoids the problem. For the view code to work it still has to calculate the line of sight and luminosity, and our view algorithm really isn't something that can be easily split up so that it's directed towards a single atom.

Also, if this was called several times the savings would disappear; the overhead from doing even a partial LOS/luminosity would still be in play. You'd be better off in that case grabbing view(m) and caching it for the remainder of the tick. That's a technique I actually use for the AIs in SotS II.
Mar 26 2015, 7:21 am (Edited on Mar 26 2015, 7:27 am)
what about directly giving us access to the built-in line of sight? would it then not need to factor in luminosity?

and what of the first procedure i suggested? it's much, much more useful than the latter. for example, you could color anything you can't see through opacity purple instead of having to use the ugly black blocks:
turf/visible(client/c)
    if(..())
        c.images << purple_image
        return 1


by default visible() could not be called similar to mouse procedures so that default rendering takes place and only atoms that define visible() use it to determine rendering in order to save any overhead it might cause
Mar 26 2015, 7:26 am
Ah, I didn't actually realize that was two separate things.

Honestly I don't see how the first procedure would be all that workable; visibility is an internal thing where either an atom is visible or it isn't. (More specifically, the invisibility level determines this.) There's no setup in place for viewer-specific visibility, except for the see_invisible var.

If selectively hiding an atom from certain mobs is desirable, I would go with the much simpler option of applying an image with the override var set. I don't think the image's visibility applies at all, but if it has a blank icon and no name or mouse_opacity, it's as good as missing as far as the map display is concerned. (Verbs not so much.)

[edit]
Oh, and I didn't realize this was also about making atoms selectively visible regardless of LOS. I don't see how that would work either; the image is attached to the loc, and if the loc can't be seen then the image can't either.
Mar 26 2015, 7:30 am
Just to be clear, I'm open to finding ways to do various things that are hard or impossible to do now. But these particular things would involve massive overhauls to the way atoms are seen, and whenever anything falls into the massive overhaul category it's unlikely to pan out.

It'd be easier brainstorming if I knew what the intended goals were.
Mar 26 2015, 7:34 am (Edited on Mar 26 2015, 7:52 am)
that solution is also what i'm currently doing, but you can't flick() an image, which is a major downside.
(edit: override does solve this particular easy pretty well)

the intended goal is to make a developer-friendly way to give developers control over how individual atoms are rendered to the screen

for example, how would the "color things you can't see purple instead of hiding them altogether" issue efficiently be solved with the current tools BYOND has?
Mar 26 2015, 8:31 am
The only way to handle that presently would be to avoid using opacity altogether and roll your own shadowcaster. Admittedly this is not ideal.
Mar 27 2015, 6:25 am
that solution is also what i'm currently doing, but you can't flick() an image, which is a major downside.
(edit: override does solve this particular easy pretty well)

I'm of the mindset that flick() has been functionally deprecated since about 2010.

play-once icon states are a great way of going about a flick in modern DM, and as of 500, animate() makes it intensely easy to switch back to the default state when the play-once animation is done playing.

It also gives you a lot more control over what's going on to boot.