ID:132974
 
Would it be too engine-intensive to give the DM developers a means to evaluate opacity on a tile-by-tile basis based on conditions that pertain to a mob?

For example, I'm thinking of having a model where you would have tiles representing elevation. If you're on level 0 and have a unit that is only one level tall, you can't see beyond level 1 or level 2 tiles. If you're on top of a level 1 tile, you should be able to see beyond the level 1 tiles. This much SEE_TURFS would cover. However, you still shouldn't be able to see past a level 2 tile, and SEE_TURFS wouldn't cover that.

For these reasons and others, it'd be neat to have some kind of opacity-determining procedure that could be overridden.
There's a One-Way-View demo out there. It has one-way windows where you can't see past them on one side, but you can on the other side. Looks like what you want.

Of course, built-in features are probably faster than DM-coded ones, but possibly more annoying to make.
In response to Kaiochao
Manipulating client.images could indeed be an effective workaround, but it's tricky business what with all the cloning I'd need to do: going through each tile and making sure I have something representative of its current contents.
In response to Geldonyetich
You could try using invisibility on opacity markers. Assuming invisible things wont act as opaque (never tried it) you could easily setup something like the height levels you're talking about.
In response to Falacy
Falacy wrote:
You could try using invisibility on opacity markers.

If I'm understanding you here, if that worked, it would work for one character. When the second characters involved, I'd have these opacity markers laying around that might interfere with them.

Unless maybe I used objects related to specific clients... I don't think opacity can be evaluated based off of objects on client.screen or client.statobj though.

I almost think it might be easier just to have a special case "IsVisibleWhen()" proc on atoms that is run whenever the tile is on screen that causes it to appear regardless of other conditions.
In response to Geldonyetich
If you take advantage of invisibility and see_invisible, you should be able to rig what you described relatively easily.

You would, as Falacy said, create opacity objects for each tile (maybe skipping over level 0 which can't block site) and give them an invisibility setting inverse to their elevation (invisibility=MAX_ELEVATION-tile.elevation). Then whenever a character moves onto a new elevation, set their see_invisibility to MAX_ELEVATION-char.elevation-char.height.

I believe that would work, anyways.

<edit>Bwhahaha, ninja'd

It was so close your post was already displayed after I hit submit!
</edit>
In response to Geldonyetich
You set the invisibility layer on whatever you currently have the opacity on related to their height <.< then just modify each players see_invisible so they can see past whatever height they're on, which will also let them see past all heights below them
I was thinking of making a library for this. The general way it worked would involve using the invisibility and layer var of atoms and the see_invisible var of mobs. As a mob would increase or decrease in height, the invisibility, layer, and see_invisible vars would change. When outside, the see_invisible var would've been automatically set to 100, so that outside players would see the top-most visible portion of whatever they were looking at. Downsides are that this would probably preclude any usage of the invisibility and see_invisible vars, but I don't believe they're very often-used anyways. It would also allow only a maximum layer of 100, but I doubt that's a problem.

The library part of the whole thing would've come from the fact that the developer would simply make a map for each layer of whatever they're working on (a building in most cases, I'm sure). Then the library would automatically build the building from the seperate map pieces.