ID:2635218
 
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
A variable like vis_flags that instead of determining how the atom behaves when in another's vis_contents, it determines how atoms within this atom's vis_contents behave. It overrides vis_flags when defined.
I'm not sure that I see a strong use case for this. What would this be needed for, exactly?
It's so atoms can easily have different behaviors when in the vis_contents of specific things. For example if you want an object to behave differently when it's in the vis_contents of a HUD element versus when it's in the vis contents of something like a mirror or the sky or any number of things. Or even just so that it behaves differently when it's in different types of HUD elements.

Even if it couldn't have both behaviors simultaneously, it would still be useful.
An easy example of why specifically having vis behavior determined by the object isn't enough would be this:

Suppose I want to have an upstairs area that shows the ground floor out the windows. Alright cool, easy, we'll just have each turf grab the turf below and add it to vis contents and set our layer higher. But suppose we also want a mirror object that reflects nearby stuff using vis contents and alpha masking. Now wait a minute, to look right, our reflectionshould be VIS_INHERIT_DIR|VIS_INHERIT_ID, but the outside area wants those flags unset. There's no possible way to have an object shown both above and in a reflection properly at the same time. If there was a VIS_FORCE vis_flag that forced all objects in something's vis_contents to inherit its vis_flags, this situation would be easy to resolve.
Is this sort of feature difficult to implement? I don't know enough about the internal workings of vis_contents or vis_flags to have an idea
I could use this specifically for VIS_INHERIT_ID. Eg: TV screen would make everything inherit ID, while an actual open space would allow you to click things individually. With that said I wouldn't want it overriding things like VIS_HIDE.
This was something that was talked about in the original proposal and debated for a later date in dms. The trouble was that Lum and I were both brain soup when we talked about this feature nd just sort of shrugged.
In response to Ter13
In terms of feasibility or implementation design?
I believe Lummox was very positive about the feasibility at the time, we were just not clear on the design.