[FEAT] A vision-blocking object should only block the area behind it, not itself about planarally HOT 13 CLOSED

Hey, this is also something that has irked me in the past.

A naïve solution would be to just exclude themselves, however in the current way lighting is done, this means that the entirety of that object is ignored for vision. When reading this you might be confused as that probably sounds right. And this is fine for small objects, a rock or a tree trunk is indeed something you'll probably see in its entirety most of the time.

There are however 2 issues (that I experienced):

• Suppose you have some dungeon and you have decided to use thick rectangles to block out the walls. If a player walks past the wall they'll see these 30ft thick walls and then suddenly there is a thin wall, without doors. Our secret hidden room has been spoiled! (note: In practice I personally use the polygon tool for walls so it wouldn't really apply to me)
• A side-effect of the current lighting/vision implementation I wasn't able to resolve when I did a stab at this a couple of months ago, was that it wasn't possible to limit what you saw of vision-blocking items to just that which fell within a light aura. Instead if your vision covered part of the object, you saw the entire object.

Now with this monologue out of the way, there is a cheap solution to offer what you're looking for: Make it a new optional toggle per shape. In that case you could mark your tree trunk or a door as some new property which would exclude itself and reveal its entirety, which for small shapes should be fine.

It's just a bit more work on the DM's end to toggle this.

I would like to tackle this more properly at one point, especially (2) as for (1) I actually don't know if there is a proper solution.

Would this toggle be an acceptable solution for you ?

from planarally.

I'd like to weigh in with my opinion since I've also thought of bringing this to attention from time to time.

First, I want to say that this hypothetical new toggle would be very much appreciated. That's the most common problem for me in regards to revealing things.

As for issue (1) I had an idea. Something akin to the Reveal mode of drawing shapes, but instead of always being revealed like the current Reveal mode, it only shows when in line of sight for a token. In the scenario:

• Supposing I have a dungeon with rectangular walls, I would mark them as blocking vision which would operate as it currently does and not allow seeing the shape at all and blocking all vision behind the shape. Then I would draw a 'Reveal When In Vision' rectangle over top of the wall but inset slightly to only allow seeing part of it, allowing the GM to prevent showing spoilers by revealing the entire shape of the wall.

I don't know how complex it would be to implement this idea or if it would be worth the effort, but I think it would allow for the more fine grained approach to revealing parts of shapes at the expense of the GM essentially having to draw the shape twice.

from planarally.

I actually made an implementation that seems to work. If people running dev want to check it out and provide me with feedback that would always be appreciated.

It does not change the save file format, so you can freely swap between dev and the branch in the linked PR above freely at this point in time. (the notes PR that is in progress does change the save format)

from planarally.

You need to change to the branch in the linked PR

from planarally.

This is now supported as a new vision blocking mode!

from planarally.

Now with this monologue out of the way, there is a cheap solution to offer what you're looking for: Make it a new optional toggle per shape. In that case you could mark your tree trunk or a door as some new property which would exclude itself and reveal its entirety, which for small shapes should be fine.

The simplest option would be instead of just an invisible tick box you have an Always visable tick box, which will still follow FOW rendering but just mean when a PC sees it, it is visible despite blocking light or movement. That is how I envision it, anyway.

from planarally.

• Supposing I have a dungeon with rectangular walls, I would mark them as blocking vision which would operate as it currently does and not allow seeing the shape at all and blocking all vision behind the shape. Then I would draw a 'Reveal When In Vision' rectangle over top of the wall but inset slightly to only allow seeing part of it, allowing the GM to prevent showing spoilers by revealing the entire shape of the wall.

What I do, really depends on the underlying map. For secret doors it has always been a square block that is marked out on the DMs map. That is never a problem, really. (see video)

But for visible doors it is a little trickier as when you make a token block light it is blocking itself at the same time.

from planarally.

I don't know how lighting in PA works, but my intuitive solution is: to cast lights from the character to everything around them, and each ray of light ends when they exit an object (instead of when entering an object). If this can be implemented in code, it should solve the issue (2) you mentioned, but not issue (1).

As for issue (1), I think I would cut the secret room from the map to make it a separate object, and only make it visible when it's discovered...

from planarally.

As for issue (1), I think I would cut the secret room from the map to make it a separate object, and only make it visible when it's discovered...

That is essentially what I already do for both doors and secret doors when making a map mask. The issue is not so visible in maps where the door symbols are drawn, and it is easy for the player to see them despite a line representing the actual door.

The problem come when the map doesn't have doors that stand proud and align with the actual wall. Then, even adding a new object to stick out covers the object behind it.

The solution I have settled on atm which is a bit of a faff to do for every door, is to lay a door asset in place, and then draw a line as the blocking part. This works, but


it is inconvenient if you have hundreds of doors to place.

EDIT:

Actually strike that.. It is not a solution at all as when clicking on the door line it just swallows up the door token anyway. sighs

from planarally.

I actually made an implementation that seems to work. If people running dev want to check it out and provide me with feedback that would always be appreciated.

It does not change the save file format, so you can freely swap between dev and the branch in the linked PR above freely at this point in time. (the notes PR that is in progress does change the save format)

Well am running dev is this the right commit?

commit c802dbde8f7666a97cf71c65b7192a83896b906d (HEAD -> dev, origin/dev, origin/HEAD)
Author: Darragh Van Tichelen <[email protected]>
Date:   Wed Dec 6 22:24:37 2023 +0100

    bug(Ruler): Fix server log spam

Edit:

Oh see another commit. I will switch to that and check

from planarally.

WOOT! seem to work in my specific example. All I hade to do was move the token from a layer to another for some reason but it works as intended with the metal door token and the door bar on the same layer and the Fake player can see the handles but not what is behing the door.

Thanks so much for tackling this quickly. It was becoming and issue in places like this.

from planarally.

Hehe.. ok .. So not a bug exactly but I am wondering how easy it would be to make shadows fade away like light does to make this sort of scene seem more realstic.

from planarally.

That doesn't sound easy to accomplish, so it's definitely out of scope for now.

from planarally.