ID:2128538
 
Resolved
A new SEE_BLACKNESS sight flag has been added, to render dark tiles to plane 0. (SEE_PIXELS does so also, but virtually turns on SEE_TURFS/OBJS/MOBS which may not be desirable.) This only applies to topdown map modes.
Applies to:DM Language
Status: Resolved (511.1359)

This issue has been resolved.
One of my favourite things about SEE_PIXEL was that it rendered darkness at plane = 0, making it relatively easy to add planes above this layer, allowing for pretty interesting and efficient possibilities that were not otherwise possible. Unfortunately, the other things which come bundled in with SEE_PIXEL was not appropriate for what we intended to use it for.

If it is possible, it would be great if there could be a setting or something for darkness to be rendered at plane = 0 regardless of SEE_PIXEL, allowing people to create things above darkness without having to play around with client images and the like.
What you're asking for is SEE_PIXELS behavior that doesn't behave like SEE_PIXELS. It's a non-sequitur.

SEE_PIXELS causes darkness to be rendered physically--when in topdown mode--which it does by drawing the entire map and then painting black squares over every tile that shouldn't be seen. There are downsides to this approach. It can't work in non-topdown modes because it makes no sense there. It doesn't work with the other SEE flags like SEE_TURFS and SEE_OBJS, because there'd be no way to render only objs (for instance) on the hidden tiles. It can't handle pixel offset trickiness like SS13 uses to display something only on one side of a wall, because that's completely antithetical to the entire purpose of SEE_PIXELS.

Ultimately, what I'd like to do is to create some kind of darkness mask that could be redrawn on and added in post, but that still wouldn't handle the pixel offset wall-object cases.
It can't handle pixel offset trickiness like SS13 uses to display something only on one side of a wall, because that's completely antithetical to the entire purpose of SEE_PIXELS.
Well that's why I was suggesting this, knowing SEE_PIXELS was not an appropriate thing to use for it, as you told me prior.

Ultimately, what I'd like to do is to create some kind of darkness mask that could be redrawn on and added in post, but that still wouldn't handle the pixel offset wall-object cases.

Forgive me for being obtuse, but is there no way to turn the SEE_OBJS and such darkness into a pseudo-SEE_PIXEL darkness in that it is added in post, and can be easily plane'd above - even if we rely on the normal SEE_OBJ vision?
In response to DrCelt
DrCelt wrote:
Forgive me for being obtuse, but is there no way to turn the SEE_OBJS and such darkness into a pseudo-SEE_PIXEL darkness in that it is added in post, and can be easily plane'd above - even if we rely on the normal SEE_OBJ vision?

I don't follow.
Uh, You know how you can render mobs or turfs above the normal view cone without SEE_PIXEL using SEE_MOB or SEE_TURF and such, right? It'd be, in my view, quite useful to have objects above a certain plane, (ie above darkness), render in the same way. I guess I'm not explaining this well enough, sorry.
With SEE_PIXELS, all objects should render regardless of whether their turf is visible, so if they're on a higher plane they should render above the darkness automatically.
Well that's correct, which is why I think having that sort of functionality independent of SEE_PIXEL, which comes with all sorts of other behaviour, would be really neat.
If you want that, you can always turn on SEE_OBJS and/or SEE_MOBS. If you want a specific object to be visible, a better idea might be giving it some infra_luminosity and giving your mob SEE_INFRA.
Lummox, that functionality is flawed in that you could only have one specific item that would work in that way, which makes it an extremely limited approach.
using images is very useful here.
Again, client images are far, far, too cumbersome compared to planes. Say you have a form of thermal vision, where you can see all mobs. Every time a new mob logs in and out, each and every mob in the world needs their client image appended or removed. Planes on the other hand, would just give a person a planesmaster that deals with it, efficiently and clientsided.
How would you handle the layering in that case then? Planes on a higher or lower layer will remain above or below other planes at all times no matter how you set the layering. It's also not cumbersome if you set up a few procs to handle most of the work for you. For example, a global list that holds all images for client to load when they log in, a uninitialized images list for all mobs and objects who need to have an image seen by only a set of players. You can even assign tags as keys in the global image list. For example, having a list under all_images["w"], and a can_see list for clients. If w is in their can_see list, they'll see ghosts, for example. It should all work out fine, it's just a matter of setting it all up. I use this type of system extensively, and while their were issues in the beginning, after extensive testing, it works great, even online. I have players see NPCs uniquely to themselves, and each unique render is under a single entity so it's pretty ideal to how a dev would want it.
Ishuri, I'm not sure how you mean, regarding layering. As planes are simply a form of layering for layers, a codebase that utilises planes, and does it well, would have no problem in having objects appear above and below whatever is intended, as layers are presently. I understand perfectly how your system would work, and I admit that it works very well for what you'd want it to do. However, I think that instead of having a client, upon logging in, be bombarded with every appropriate client image under the sun, and have that be updated constantly, rather than, in my opinion, the much neater way of doing it in native byond, keeping everything within a plane, which is a clientsided approach. At the very least, even if you disagree how exactly to approach this problem, you must at the very least, admit that it would be useful to have darkness as a physical entity that can be placed on a plane, which would enable my approach.
I'm confused as to why you think infravision would be too limited as a solution to this issue. As I understand it, you want certain objects to render above the darkness without using SEE_PIXELS, which effectively turns on many of the other sight flags. Using infravision for those certain objects would make them appear regardless of darkness or being obscured by a wall, so it would do exactly what you wanted without using a blanket solution like SEE_OBJS/SEE_MOBS.
Issue is that that works only for 1 specific thing, if you want to apply this to multiple things, each with their own object types to make visible, you're back to square one.
You can set infra_luminosity on a whole class of objects at once, by building it right into the prototype. I don't think we're on the same page.
Infra luminosity can only work on one set of objects and only one. He wants to be able to: not see any ghosts, see one of two types of ghosts, see only the other of the 2 types of ghosts, or see both, the number of hidden types of ghosts being infinity, not just 1.
If the desired result is invisibility that's conditional to the player, then this is a discussion that has nothing to do with planes--which are a different animal entirely--or the sight flags, which are blunt instruments.
Not true, lummox. I am happy to say that planes is incredibly useful at creating invisibility that is conditional to the player, using client-specific planesmasters and setting the alpha variable appropriately. The reason WHY this is applicable to planes is I'd like to be able to have some planes appear above darkness to apply this functionality among others where you would not otherwise see them through walls.
o-o

conditional invisibility channels using planes?

Share your secrets, I must know your secrets.
Page: 1 2