v4.1: LoS feedback

[Weissrolf]

Hello everyone.

- v4.1 Beta currently suffers from the same problem as 4.0, client token LoS is CPU calculated for every single pixel of movement when locked token movement is approved by the GM. This in turns leads to CPU overload, fps drops and generally slow movement of GM approved locked token movement.

Here is the original report, including an animated GIF to demonstrate the issue.

https://www.fantasygrounds.com/forums/showthread.php?65416-Slow-movement-of-token&p=585513&viewfull=1#post585513

- Furthermore I did some side-by-side test of tokens being manually moved by GM and players via a localhost network connection. When LoS is enabled then there is some lag/latency between each client's movement, with a 0.5 to 1.5 grid difference (30-50 ms?). There does not seem to be an improvement between 4.0 and 4.1 beta, so it may or may not be network stack based latency. I noticed that the highlight area around the token is flickering on the client that moves the token. So maybe the movement is only sent over network once the flickering is finished? No deal-breaker, but something to maybe improve on in the stack.

- I wonder if we will get "Low-light vision", too? As in light sources double their bright and dim light range for certain tokens?

[Moon Wizard]

Thanks for the reports.

Low-light vision that doubles light source distances will not be supported at this time. Any multiplication of light ranges increases lighting calculation costs dramatically; since light coverage is pre-calculated and multiplication of light ranges would preclude pre-calculation of light maps.

Regards,
JPG

[Weissrolf]

No love for Elves then.

[Weissrolf]

That being said, you can bet on any low-light vision player wanting token light corresponding to their character LoS range. So the calculations will happen anyway, just that the GM has to setup these things manually instead of getting automation. So automatic low-light vision would be highly preferred, especially since it's still optional for low spec players (just rename it on the char sheet).

[Moon Wizard]

This is a non-issue for PFRPG2 and 5E; as these game systems either do not have low-light vision or have a different implementation. So, this primarily affects PFRPG1/3.5E.

Like I said above, for performance reasons, we will not be looking at low-light vision in the near future.

Regards,
JPG

[Weissrolf]

You are correct. It would be nice, though, if those "different implementations" would be visible on screen as well (dim light = bright light). Not a showstopper, mind you.

[Weissrolf]

Getting back to the first two points I posted:

- LoS is too CPU processing intensive to begin with and approved client movement needs to be fixed until LoS eats less resources (or becomes GPU based).

- GM vs. client latency via localhost connection is quite surprising and points to a hopefully improvable bottleneck when manual token movement is used.

[kevininrussia]

This is a non-issue for PFRPG2 and 5E; as these game systems either do not have low-light vision or have a different implementation. So, this primarily affects PFRPG1/3.5E.

Like I said above, for performance reasons, we will not be looking at low-light vision in the near future.

Regards,
JPG

Affects 4e too. If anybody thinks up a workaround to manually adjust I would be happy to know it.

[Moon Wizard]

From my understanding, 4E is slightly different in that it doesn't double the range; but just allows creatures to see in dim light as if it were bright. This is more likely something that we can support, because it doesn't change the way that lights are drawn. In fact, the current darkvision implementation does something similar, but isn't limited to existing light.

Regards,
JPG

[kevininrussia]

From my understanding, 4E is slightly different in that it doesn't double the range; but just allows creatures to see in dim light as if it were bright. This is more likely something that we can support, because it doesn't change the way that lights are drawn. In fact, the current darkvision implementation does something similar, but isn't limited to existing light.

Regards,
JPG

That is correct. So it would adjust the falloff of the vision distance?

Testing in 4e is going well so far. Awesome :-)

[Moon Wizard]

4E low-light vision can't currently be represented; because it basically says only increase light intensity if the light value is not zero. We don't have any way to limit intensity increases by when non-zero yet. However, as I mentioned, that is much more do-able than the 3.5E/PFRPG1 version of low-light.

Regards,
JPG

[Moon Wizard]

The other limitation is that the engine only supports 3 vision independent vision types for performance reasons (limitation of low-level implementation as a shader for performance; limited number of bits for parameters). This does not include re-use scenarios like greater darkvision and devilsight using truesight as equivalent.

So, even if we added a 4E low-light, we would have to take away one of blindsight/darkvision/truesight options to make it work.

Regards,
JPG

[kevininrussia]

The other limitation is that the engine only supports 3 vision independent vision types for performance reasons (limitation of low-level implementation as a shader for performance; limited number of bits for parameters). This does not include re-use scenarios like greater darkvision and devilsight using truesight as equivalent.

So, even if we added a 4E low-light, we would have to take away one of blindsight/darkvision/truesight options to make it work.

Regards,
JPG

For 4E you could drop Truesight.

4E Visions from Rules Compendium

Low-Light
Darkvision
Blindsight

[Moon Wizard]

Is there a "Truesight" in 4E rules?

JPG

[kevininrussia]

Is there a "Truesight" in 4E rules?

JPG

Truesight: The monster can see invisible creatures and objects within the specified range and within its line of sight.

So not a light vision thing.

[mathgamain]

I just booted up the new test version and PFRPG2 Abomination Vaults all my map LoS data was not missing, I just opened the GM map and not the player map. However, this lead me to beginning to draw the LoS data in again which was not a big deal as I don't mind redoing it. A bug I just discovered is that if you CTRL-Z say a badly drawn door, it converts all over LoS cad to walls. All doors, secret doors, etc., a re all converted to wall data. That could be moderately annoying if you're mostly done drawing.

However, I want to note that the LoS data on the player map was in fact intact. So the bug I found while drawing was an accidental find.

[Moon Wizard]

@mathgamain,
It's always best to report your issues in a brand new thread; so that the thread discussion is relevant to just that issue.
Or find a thread that is exactly the issue you are having:
https://www.fantasygrounds.com/forums/showthread.php?67009-CTRL-Z-LOS-Bug&p=586390&viewfull=1#post586390

@kevininrussia,
Yeah, I just looked and only found the reference to True Sight in Ioun Stone of True Sight. So, it looks like that one would be safe to replace. We would still need to get a non-zero-only intensity increase vision type supported though.

Regards,
JPG

[mathgamain]

Thanks for the heads up Moonwizard! I've come l chimed in on the suggested thread.

[Weissrolf]

Blindsight is rare, low-light vision is common. So if we need to exchange one for the other, then low-light vision (for PF1 games). As I wrote, I suspect that users will exchange 20/40 or 30/60 token lights with 40/80 or 60/120 token lights anyway, so performance will take a hit just the same.

Is there no way for PF2 games to make a low-light vision players see all dim (x0.5) light areas as bright light (x1)?

Possible bug: When LoS is disabled then token light stops moving with the token and stays on the map at the last known position.

[viresanimi]

in 4.1 the map controls (Walls, FX, Lighning and all that), the buttons are basically invisible in the Vampire ruleset. The background and buttons basically have the same colour.

[Zacchaeus]

in 4.1 the map controls (Walls, FX, Lighning and all that), the buttons are basically invisible in the Vampire ruleset. The background and buttons basically have the same colour.

Rulesets which have lighting built in to date are listed here https://www.fantasygrounds.com/forums/showthread.php?66972-FG-Unity-Beta-Release-v4-1&p=586137&viewfull=1#post586137

[Weissrolf]

- I don't know about 5E, but in PF2 Darkvision "overwrites" dim light. Do the dim light circle of a lantern should not exist for darkvision characters, instead it turns the same monochrome as the rest outside of the lantern range.

- What happened to fog of war for players? Does it not exist anymore or do we have to turn on a specific option?

[Zacchaeus]

I’m not sure what the first question is really. A character with darkvision will see out beyond the range of any carried light source if the darkvision range is greater than the carried light source range.

Yes, fog if war is still present. If by that you mean is LOS the same then yes it is.

[Kelrugem]

- I don't know about 5E, but in PF2 Darkvision "overwrites" dim light. Do the dim light circle of a lantern should not exist for darkvision characters, instead it turns the same monochrome as the rest outside of the lantern range.

- What happened to fog of war for players? Does it not exist anymore or do we have to turn on a specific option?

If I understood correctly the lightings/visions add to each other, so, the darkvision should not make everything black and white in the ranges of the lantern :)

[rathen45]

No love for Elves then.

to compensate I gave them dark vision but limited the range to bright: 15ft and dim 30ft

[Weissrolf]

Darkvision in PF2:


A creature with darkvision or greater darkvision can see perfectly well in areas of darkness and dim light, though such vision is in black and white only.

Fog of War 4.0 (animated GIF):

https://i.imgur.com/xKa8jFV.gif


Fog of War 4.1:

https://i.imgur.com/VQqNS18.gif

[Weissrolf]

- created new thread -

[Kelrugem]

Darkvision in PF2:



Fog of War 4.0 (animated GIF):

https://i.imgur.com/xKa8jFV.gif


Fog of War 4.1:

https://i.imgur.com/VQqNS18.gif

Ah, now I understand; darkvision of FG works for all rulesets in the same way :) There is no distinction between the rulesets as far as I know. (I personally will use whatever FG will provide me, because I never cared about such rules; but of course still good and okay to point out ruleset-specific things in case it is (easily) possible to code for the devs :) Though the mentioned performance issue, which also prohibits low-light vision, may also prohibit that)

About the FoW (though I am not sure whether the devs call it FoW because there is a separate notion of FoW in the image sidebar; Roll20 calls it advanced FoW to distinct it, I believe): Not sure, I didn't test the client side. Or is that the player view of the DM? Then yes, I reproduced that, too, but that may be on purpose? Not sure :) However, for better tracking it might be better to open a separate thread for the FoW stuff

[Weissrolf]

Player view. The GM can switch back and forth between both. Seems to be intentional (as in restriction of the new system) for players not to reveal areas they have already been in.

[Kelrugem]

Player view. The GM can switch back and forth between both. Seems to be intentional (as in restriction of the new system) for players not to reveal areas they have already been in.

I just checked: LoS needs to be activated, too :) But, it is difficult to see; the "advanced FoW" seems to only cover the areas which you'd not see with LoS. That is, if you could see an area when Vision would not be activated (so, in sense of dynamic LoS as it is in 4.0), then this area will be shown black if outside the vision, regardless whether the player was there or not. So, it looks like that currently the "advanced FoW" is only with respect to the LoS system :) So, only "advanced FoW" for previously seen areas if outside of LoS (module vision as in 4.0); may be on purpose, may be changed, I am not sure what the plans are there in that regard :) Depending on the intention of the devs, it may be indeed worth to open a new thread :)

[Weissrolf]

For practical purposes this is just black, even when there are some map parts revealed in the faintest possible way:

https://i.imgur.com/SEVGyvE.png

[Kelrugem]

As said, whether something of "the past" is black or shown with a gray overlay, depends on whether it can be seen by the LoS system (as if it would be FGU 4.0). So, past areas which are black are in the LoS. Got also reported here by the way where Moon Wizard answered: https://www.fantasygrounds.com/forums/showthread.php?67003-VSYNC-options-to-turn-of-flicker-for-torch-and-candle-etc&p=586591&viewfull=1#post586591 :)

[Weissrolf]

https://i.imgur.com/cn0NzxI.png

As said, practically not visible, far too dark. This is the same image I posted in my last post (which was *not* black), just zoomed out.

[Kelrugem]

Yeah, therefore I linked the other thread where Moon Wizard wrote that it is on purpose with that low visibility :) (so, you may need to open a separate thread or a wish on the wish list about making it brighter maybe, or maybe with a separate slider which everyone can change if wanted)

[Weissrolf]

This is not "low" visibility, this is invisibility, mostly black for all practical purposes. It's another example of developers being blind to how users interact with their software interface. It's even worse than being full on black, because it mocks users.

[Ludd_G]

I'm with Weissrolf on this, if I understand correctly, and feel that 'post viewed' areas should supersede 'out of vision' masking, with the exception of NPC tokens. It just doesn't seem right the way it is now?

Cheers,

Simon

[Kelrugem]

I'm with Weissrolf on this, if I understand correctly, and feel that 'post viewed' areas should supersede 'out of vision' masking, with the exception of NPC tokens. It just doesn't seem right the way it is now?

Cheers,

Simon

In the comments of one of FG's YouTube videos SmiteWorks answered that they may consider some sort of setting/slider to adjust how the past-FoW looks like :)

[Ludd_G]

That would be great. Fingers crossed.

[Weissrolf]

Here is a comparison of player/client view of FoW (or LoS history) vs. GM view. Why can players not get the same contrast as GMs? On my screen the player/client view is nearly completely black on black, nothing is visible.

Animated GIF:
https://i.imgur.com/9mzMdqF.gif

[Weissrolf]

Here are the RGB values of client/player FoW, they are all close to zero. So it's not just a problem of my screen, it's effectively black on black.

Animated GIF:
https://i.imgur.com/A19s7vn.gif

[Arghun]

In the comments of one of FG's YouTube videos SmiteWorks answered that they may consider some sort of setting/slider to adjust how the past-FoW looks like :)

I strongly hope so because if past-FoW turns back pitch black it's going to be unusable and seriously reduces Lighting usability to ONLY places where you do have *some* ambient light. I've talked about it with my players and they told me it would a bad and frustrating experience for them.

[Weissrolf]

Ambient light has no positive affect on FoW. Some of my screenshots here were done using sunlight on the map as a whole. It's still black on black for clients/players.

https://www.fantasygrounds.com/forums/showthread.php?66992-v4-1-LoS-feedback&p=586852&viewfull=1#post586852
https://www.fantasygrounds.com/forums/showthread.php?66992-v4-1-LoS-feedback&p=586885&viewfull=1#post586885

Of course we can ask players to draw their own maps if they don't want to get lost. But at the current state the whole FoW feature can just be turned off complete instead of mocking players with a 1% contrast image.

[BaneTBC]

If the players are in "sunlight", why would you be using lighting vision limiters? You would just use normal LoS settings and maybe some masking for inside structures with lighting (caves\buildings\et al). Part of the way you'll have to employ these new tools is in a logical manner for the maps you are using. For me there's going to be a lot more playing around with things to get to the level where I'm comfortable for where I'm using it to enhance gameplay. Not all maps will "have to use it", but I have plenty of places where it will definitely change my players behavior or have bad consequences for rushing in blindly (as it should).

[Weissrolf]

First: it was for testing and demonstrating that using ambient light makes no difference for the visibility of LoS history.

Second: This is an outside map with huts. Outside is sunlight, inside is dark (has to be masked). Except for when players arrive at night, then ambient light either is very dim (moon) or black.

When you change light settings per map then the whole FoW/LoS history difference is even more pronounced and confusing to players. One map will work, another will not. They sure will love that.

[BronzeDodger]

Here's a fix: move to a different VTT. You seem to be unhappy 100% of the time with FG. If you'd stick to technical items, where you seem to have some knowledge, instead of whining like a 5-year old about every atomic-level detail that doesn't fit your perfect idea of how FG should function, think of all the time you'd free-up to troll other sites.

You are hands-down the most prolific negative poster on these forums. People are excited about this new lighting features and you just drag down thread-after-thread.

Confusion is the least of the concerns I'd have about any players sentenced to join your games.

[Zacchaeus]

Here's a fix: move to a different VTT. You seem to be unhappy 100% of the time with FG. If you'd stick to technical items, where you seem to have some knowledge, instead of whining like a 5-year old about every atomic-level detail that doesn't fit your perfect idea of how FG should function, think of all the time you'd free-up to troll other sites.

You are hands-down the most prolific negative poster on these forums. People are excited about this new lighting features and you just drag down thread-after-thread.

Confusion is the least of the concerns I'd have about any players sentenced to join your games.

Not helpful. Please don't get dragged into such discussions. Even if it is all negative it's still feedback and the devs do appreciate feedback.

[BronzeDodger]

You are ever the soul of tact Zacchaeus. Heck, if I got some sort of temp ban for being a knob I could not dispute it (and would totally respect it). But I'd deleted that post about ten times in the last month and finally succumbed to the dark side. There's just no reason to add negative editorial to otherwise valuable technical feedback anytime, much less with a group as responsive as the workers and volunteers who just want to make FG great.

[Weissrolf]

Don't worry, both of my current groups are happy and appreciate me investing time and energy into GMing for them. They are not forced to play in my groups and my style is rather relaxed and helpful towards players. People keep dragging personality and animosity into these discussions about technical topics. Even when politely asked to keep on topic they have a hard time concentrating on the content at hand. But if some love is needed then I can put up a comprehensive post with positive feedback on various FG features.

That being said, I am rather annoyed at the LoS system getting "a huge refactoring" just shortly after Unity's officialrelease. Feels a bit like we customers have been cheated into trusting (and thus paying for) it earlier than we should have. That's a subjective stance that at least partly dictates my approach on dealing with the annoyances encountered during actual game-play.

Back on topic, this time with more spicy sauce on top of it, because some people here seem to enjoy that: Putting RGB 7/7/7 pixels on 0/0/0 background and calling it a feature would be a kick in the face and border on insulting customers. Better turn it off completely then. We did not get any official reply on this here yet, though, so it may or may not be unintentional in its current form.

Today we turned off LoS completely and returned to manually unmasking parts of the map. It was more work and looked less refined, but allowed one of my (under-spec) players to keep playing. Good to have the option to turn both LoS and now Lighting off when needed.

[Noelus]

Ran a game last night with the test channel and the overall experience was great. A couple of things strike me as worthy of comment. Would it be possible to have a blur option or similar for the ambient light mask setting as is the case for the fx masks, as I find the stark change from light to dark unattractive. The LOS blocking would also benefit greatly from being dithered somewhat imo, as it is again too severe right now. Appreciate if this might cause performance issues but got to ask. Also would it be possible to look at increasing the flicker effect, perhaps to the whole light range as it is just too subtle at the moment. Finally any thoughts about lights with more than one colour, cycling through a range for instance?

[DevildrummerX]

Don't worry, both of my current groups are happy and appreciate me investing time and energy into GMing for them. They are not forced to play in my groups and my style is rather relaxed and helpful towards players. People keep dragging personality and animosity into these discussions about technical topics. Even when politely asked to keep on topic they have a hard time concentrating on the content at hand. But if some love is needed then I can put up a comprehensive post with positive feedback on various FG features.

That being said, I am rather annoyed at the LoS system getting "a huge refactoring" just shortly after Unity's officialrelease. Feels a bit like we customers have been cheated into trusting (and thus paying for) it earlier than we should have. That's a subjective stance that at least partly dictates my approach on dealing with the annoyances encountered during actual game-play.

Back on topic, this time with more spicy sauce on top of it, because some people here seem to enjoy that: Putting RGB 7/7/7 pixels on 0/0/0 background and calling it a feature would be a kick in the face and border on insulting customers. Better turn it off completely then. We did not get any official reply on this here yet, though, so it may or may not be unintentional in its current form.

Today we turned off LoS completely and returned to manually unmasking parts of the map. It was more work and looked less refined, but allowed one of my (under-spec) players to keep playing. Good to have the option to turn both LoS and now Lighting off when needed.

Its funny you say other people bring animosity and "personality" into discussions when almost all of your technical discussions involve jabs at the competency of the Smiteworks teams and pushing your own opinions off as those of the vast majority of Forum users. I don't get why you would be "annoyed" at the LOS system being refactored, they clearly needed to do for the Dynamic Lighting which was by far the most requested feature.

But seriously even in this post you talk about the LoS system and its history being a "kick in the face bordering on insulting customers" without giving MW or anyone else from Smiteworks reasonable time to respond, or without any proof that other users see it as a "kick in the face." Seriously and you wonder why other users get tried of the thinly veiled insults and attempting to speak for the whole community, but every time someone calls it out you want to play the victim and act like you are just being misunderstood...

Either way I'm done with it, you'll stay in my Ignore List and I'll continue to happily watch FGU improve and offer suggestions I have without insulting the competency of the team just because they don't agree with me.

[Zacchaeus]

Its funny you say other people bring animosity and "personality" into discussions when almost all of your technical discussions involve jabs at the competency of the Smiteworks teams and pushing your own opinions off as those of the vast majority of Forum users. I don't get why you would be "annoyed" at the LOS system being refactored, they clearly needed to do for the Dynamic Lighting which was by far the most requested feature.

But seriously even in this post you talk about the LoS system and its history being a "kick in the face bordering on insulting customers" without giving MW or anyone else from Smiteworks reasonable time to respond, or without any proof that other users see it as a "kick in the face." Seriously and you wonder why other users get tried of the thinly veiled insults and attempting to speak for the whole community, but every time someone calls it out you want to play the victim and act like you are just being misunderstood...

Either way I'm done with it, you'll stay in my Ignore List and I'll continue to happily watch FGU improve and offer suggestions I have without insulting the competency of the team just because they don't agree with me.

Again, not helpful. Please don't.

[Weissrolf]

FoW - GM vs. PC (animated GIF):

https://i.imgur.com/UZttEln.gif

[broodling123]

For my part I don't mind having the previously explored area be rather (or even extremely) dark. Remembering vaguely which areas your character has already visited is, at least in my opinion, an interesting part of the game. If too much time has passed since the last session and the players don't remember something that their character should, I don't mind as a DM giving them a nudge in the right direction. And if the party still can't quite remember the right way back to camp and takes a wrong turn, well, all the more opportunity for adventure. :)

With that said, ideally it would be nice to be able to manually configure how dark that area is (for the players or groups that don't like that style of play), or even better, apply one or more visual effects to previously explored but not in LOS areas (sepia maybe, to give a map-like feel?).

[Weissrolf]

Disable FoW or make it usable. Black on black is neither, it's saying "here is a feature, don't mind that it's unusable in practice".

I spoke with my players this week. While we can follow your argument about getting lost and nudge-nudge, their main argument was that we play each campaign only every 2 weeks for 3-4 hours. What may be "opportunity for adventure" once or twice then quickly becomes an annoying time-sink.

[kevininrussia]

My group and I like it as it is now. One of my players likes sketching out a map as they travel and engage the party “turn left here”. And as Broodling mentions, I can always nudge them along if needed.

[Neovirtus]

I think if you're going to play with Dynamic Lighting, having it be dark outside your vision is a feature, not a bug. Would it be nice to have a slider for opacity of FoW? Sure. I would vote for it as a feature enhancement.

[Weissrolf]

So your groups would prefer this feature to be disabled. Fine by me. Our group feels much more comfortable with disabled vs. enabled compared to disabled vs. practically still disabled.

The former allows our group to either use it when present or ask SW to please implement/enable it. The latter leaves us with SW stating: "But the feature is already there! <shows black on black screen> We have higher priorities than to implement a slider for it".

On a side-note: One of my players likes to write everything down during sessions. This gives everyone a (theoretical) documentation of what happened in the past. But it also leads to this player not being fully "there", because he is preoccupied with his documentation. If I now ask another player to start drawing dungeon maps then half my group would be busy documenting instead of playing.

[Modu]

I agree with Weissrolf, the black on black doesn't look very good. The opacity needs to be lowered, even just a little bit would help. I suspect they are doing this for GPU resource reasons though, because otherwise it just doesn't make sense to change it from what we had previously.

[Weissrolf]

The GPU shouldn't care if you are using 1% contrast or 10% contrast. Enabled vs. disabled might affect GPU performance, we users don't know that yet. Currently we get enabled (=possible GPU impact) combined with an unusable low contrast, so worse of both worlds.

[Modu]

Maybe, but I'm skeptical when seemingly arbitrary decisions like this are made when a major feature gets introduced. Were there complaints about old FoW? Otherwise, why change it? It just feels like a decision made for performance/resource reasons. I could (probably) be totally wrong.

[Neovirtus]

Maybe, but I'm skeptical when seemingly arbitrary decisions like this are made when a major feature gets introduced. Were there complaints about old FoW? Otherwise, why change it? It just feels like a decision made for performance/resource reasons. I could (probably) be totally wrong.

It's a new feature, intersecting with an old one. This is a beta, and it's purpose of to highlight issues exactly like this one. Whether they decide this is how they want it to perform or if they need to adjust is up to them, but those of us who are trying the new features are providing our feedback on how we think it should work.

[broodling123]

I suspect the logic behind the current contrast levels is that the full contrast range is used to distinguish five states ("unexplored" > "explored, in LOS, no light" > "explored, not in LOS" > "explored, in LOS, dim light" > "explored, in LOS, bright light") instead of the original three ("unexplored" > "explored, not in LOS", "explored, in LOS").

On a side note - and perhaps this might alleviate some of Weissrolf and Modu's concerns - I'm not sure I see the need to distinguish "explored, in LOS, no light" and "explored, not in LOS". Currently according to the animated GIF above, the former is slightly darker than the latter. However, if there's no light sources and they have no darkvision (or equivalent), I don't see how thematically a character should be able to determine what their potential cone of vision is. That might free up some contrast range.

[Kelrugem]

There were indeed several threads about that it should be darker (because of mazes and so on, and when it was a "living dungeon", then one could too easily spot changes of the map); may or may not be due to these reports. As I wrote earlier, in some comment on YouTube SmiteWorks said they may consider to allow customization of that :) It is beta currently and may still be under consideration, let us all wait until a dev answers or a new patch comes etc. :) (everything is already said I think, to avoid running in circles :) )

EDIT: That said, there is a patch now :) So, check again :D

[LordEntrails]

Update. There is an update to the Test channel that should resolve this.
https://www.fantasygrounds.com/forums/showthread.php?66972-FG-Unity-Beta-Release-v4-1&p=587762&viewfull=1#post587762

The devs are listening!

[kevininrussia]

With new update

Token in total darkness

Door Open
https://i.imgur.com/3UGw97R.png

Door Closed
https://i.imgur.com/eB7a2Fw.png


When the door is closed I would prefer it to be total black again but I understand others thoughts on the mater.

[Weissrolf]

If you prefer total black, why not close the map? Your char doesn't see his own feet at this point, even less so neighboring tokens. The current solution is too bright to be "total black" and too dark to be discernible. Everyone loses. Anyway, I provided enough information on this topic.

https://i.imgur.com/PMmZsNI.gif

[Weissrolf]

Next question: Is darkness supposed to break LoS or not?

https://i.imgur.com/eGrZHKI.gif

[Neovirtus]

I may be wrong but I don't believe LoS ever stopped you from targeting something that was "blocked". It's an aid to help you identify what you do or do not have line of sight on. As a DM there are so many situations where my players don't have line of sight on the map because of strange map design issues, or they get line of sight through role play, etc. In those cases I'd hate to have FGU refuse to let targeting happen.

[Weissrolf]

Both LoS and lighting allow to target and hit enemies via combat-tracker. But LoS disables those targeting arrows that tell you where the enemy is located, lighting does not.

[LordEntrails]

Next question: Is darkness supposed to break LoS or not?
"Darkness" such as a spell or unlit area between source and target? Not that I know of. I don't think any ruleset has defined that. But in part it depends on if you consider spell darkness to be an absence of light, or a light blocker. I've always played it as an absence. Such as you can see a figure holding a torch 200 feet away, but you can't see the lurker in the darkness 70 feet away.

As for your example, in D&D 5E, you can target (in some situations) creatures you can not see. As well you are assumed (in some situations) to know which square they are in even if you can not see them. So, the behavior you show is pretty much what I would expect. Maybe it might be worth some sort of option in the future, but its probably not one I would ever use myself.

[Zacchaeus]

I can confirm what Weissrolf is saying. With only LoS turned on you can target an enemy that is the other side of a wall and you won't see a targeting arrow. Neither will you see it with LoS and Lighting turned on. However with only lighting on you will get a targeting arrow. I'm going to surmise that is working as intended since only LoS technically blocks targeting. Without the LoS on FG won't know that the target is the other side of a wall since there's no occluders. I think it's the presence of occluders which block the targeting arrow. Lighting (or vision) doesn't care that the enemy is the other side of a wall.

The lighting system is designed to work with LoS rather than as a separate system which does the same as LoS and more.

[Weissrolf]

Now the question is, should missing light present an occluder to LoS arrows? Not as in, darkness in between two points breaks LoS arrows, but target standing in darkness aka not visible on the map.

We can always turn the target invisible via CT, of course. But since lighting already does the "cannot be seen" automation on the map, it could go the full mile and also remove the arrows.

[Kelrugem]

Hmm, in 3.5e darkness blocks LoS (so, @LordEntrails, there are some rulesets defining that :D), but it does not block line of effect, which is why one can often still cast into darkness in order to try hitting someone; however, one needs to guess the square then. If FGU is showing the targetting arrow, then players can actually see where someone is positioned, such that metagame problems can arise (because it is reasonable difficult to ignore such type of information even if one tries :D). So, if possible, then I'd like to see that the targeting arrows respect actual LoS as in 3.5e, right now it basically shows line of effect instead

(or alternatively: The visibility in the CT automatically switches which a lot of people already wish for, but as far as I understood it is a bit difficult to implement. EDIT: Though that gets problematic with different visions of the clients)

[Weissrolf]

Automatic switching in CT could be nice and it would even remove any active targeting arrows (permanently). The latter may or may not be wanted.

[kevininrussia]

Automatic switching in CT could be nice and it would even remove any active targeting arrows (permanently). The latter may or may not be wanted.

There is a wish item for this located here:

https://fgapp.idea.informer.com/proj/?ia=135345

[Weissrolf]

That idea proposes to remove the tokens from CT, here we propose to just switch them invisible.

Off-topic but on-topic question: Would be be possible to automatically apply the hidden effect to any CT token that is switched to invisible in the CT? Either by ruleset or by extension?

[kevininrussia]

That idea proposes to remove the tokens from CT, here we propose to just switch them invisible.

Off-topic but on-topic question: Would be be possible to automatically apply the hidden effect to any CT token that is switched to invisible in the CT? Either by ruleset or by extension?

I guess I should reword that wish list item as it suppose to make the token invisible on the CT (which removes them on the players CT).

[Weissrolf]

It seems that 4.1 beta calculates all LoS point on a map when a token is moved, not just the ones that are visible to the token (aka walls do not block LoS calculation). I posted a workaround in the Healing forum, but ultimately FGU should stop calculation at the next occluder instead of spending CPU cycles on the rest of the unseen map.

[Megaprr]

So I found some strange behavior with the toggles.

I don't know if this is intentional or not, but toggling off LoS but keeping lighting on still keeps the LoS while reducing updates until you actually let go of the token.

Animated gif (thanks weissrolf for suggesting ScreenToGif):

45005

Furthermore, I also noticed that dark vision doesn't seem to be playing nicely with lights, in the sense that it seems to go be totally overridden by areas with any lighting. So any areas with no light you can see perfectly fine, but if you get near a dim light then you can 'lose' vision up to near total darkness.

Here's an example with a low-light torch (It practically nullifies the darkvision effect):
45007

I'm a bit confused as to why no one's brought this up anywhere (that I saw...). It seemed to work properly in the demo videos, so I thought it might be on my end. However I made that gif in a fresh, empty campaign with no extensions immediately after updating to the latest test channel version.

[Weissrolf]

That looks like moving a token with LoS enabled and SHIFT being pressed during movement.

In PF2 darkvision should override dim light anyway (as in: stay monochrome). Other systems may handle it differently, though.

[Megaprr]

Right, it should stay monochrome for 5e as well as far as I know. And yeah it does look like a SHIFT move (though it wasn't). There must be something wonky going on in the background.

[Moon Wizard]

Actually, animated GIFs are actually larger files to download and less useful than video files (like MP4s) since there is no clear beginning/end.

While using the different toggles independently may not be working 100%; is there a particular reason to be switching between them like that or just testing edge cases?

Regards,
JPG

[estrolof]

I was looking at 4.1 vs Live- like most, I have been long awaiting lighting and vision. I was looking at the 'brightness' of my maps. It seems that in 4.1, the LOS darkens the map without application of ambient light. Looking at this in Live, it didn't appear to do this. Is this intended?

45009

[Megaprr]

Sorry about the format confusion. In retrospect I should have left a bit of room at the end to make it clear it ended before restarting the gif (I've never done videos before... maybe I should look into that for the future).

I was mainly just testing edge cases here. Prompted primarily by that weird darkvision bug I mentioned in the latter part of the post.

The takeaway is this:
LoS+Lighting = smooth
LoS alone = smooth
Lighting alone = not smooth.

You wouldn't ever really toggle that in-game. I was just doing it there to showcase the differences between them. And it's not even much of a problem considering that needing lighting but no line of sight is a very niche situation. And even then you could do that by just disabling the walls layer.

[Megaprr]

I was looking at 4.1 vs Live- like most, I have been long awaiting lighting and vision. I was looking at the 'brightness' of my maps. It seems that in 4.1, the LOS darkens the map without application of ambient light. Looking at this in Live, it didn't appear to do this. Is this intended?

45009

Are you sure that's the live channel? Both the top and bottom pictures seem to have the new sidebar with the lighting toggles. That's not in the live channel (to my knowledge).

EDIT: And yeah, the picture differences kinda showcases what I was talking about in my post. Toggling either LoS or lighting enables the walls feature (which in itself shades the whole map a bit if you don't have a token selected).

[Moon Wizard]

@estrolof,

Were any tokens selected when you were comparing? The reason I ask is because the map is supposed to be shaded slightly when lighting/LoS on to indicate FoW regions.

Regards,
JPG

[Megaprr]

@Moon Wizard Should I start another thread regarding the darkvision bug? I'm thinking maybe this LoS feedback one isn't the right place for it since it's not really LoS related...

[Moon Wizard]

Probably; this thread is so convoluted that it's hard to track. In fact, I'm going to close the thread to make sure each issue gets it's own thread.

Regards,
JPG