Kruptein / PlanarAlly

A companion tool for when you travel into the planes.
https://www.planarally.io/
MIT License
392 stars 71 forks source link

[FEAT] A vision-blocking object should only block the area behind it, not itself #1324

Closed refparo closed 6 months ago

refparo commented 7 months ago

Is your feature request related to a problem? Please describe. When I set a shape to "block vision", it blocks not only the area away from the player character's line of sight, but also itself, making itself a black shape. For example, when a tree trunk is set to "block vision", I want to prevent my players seeing things after the trunk, but I also want to allow them to see the trunk itself, while PlanarAlly currently shows the trunk as a black circle.

Describe the solution you'd like Players should be able to see the vision-blocking shapes.

Describe alternatives you've considered I have tried to emulate this kind of effect by making the shape emit a light that covers only itself. However, this doesn't work when the shape is in the dimming area of a player's area of sight. (It doesn't dim along with the area)

Additional context None.

Kruptein commented 7 months ago

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):

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 ?

rexy712 commented 7 months ago

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:

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.

develroo commented 7 months ago

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.

develroo commented 7 months ago
  • 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)

https://github.com/Kruptein/PlanarAlly/assets/7777993/ab1a3f37-4f0e-47d2-a963-6014dc43d048

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.

refparo commented 7 months ago

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...

develroo commented 7 months ago

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 Screenshot from 2023-11-29 12-47-26 Screenshot from 2023-11-29 12-47-12 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

https://github.com/Kruptein/PlanarAlly/assets/7777993/580c9ed1-7b13-4314-bdf6-d9797feaebd2

Kruptein commented 7 months ago

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)

develroo commented 7 months ago

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 <info@darragh.dev>
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

Kruptein commented 7 months ago

You need to change to the branch in the linked PR

develroo commented 7 months ago

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.

https://github.com/Kruptein/PlanarAlly/assets/7777993/48333b22-8394-42d7-a8c8-de8f2a5b0568

develroo commented 7 months ago

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.

Screenshot from 2023-12-11 22-51-59 Screenshot from 2023-12-11 22-51-49

Kruptein commented 6 months ago

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

Kruptein commented 6 months ago

This is now supported as a new vision blocking mode!