Advanced Fog of War Feedback Thread 2.0

Brian C. said:

Jay R. said:

Yeah, DL and AFoW are very slow at the moment. Also, AFoW doesn't work with NPCs as per a test of mine today. An NPC armed with a torch and AFoW and DL enabled on two different maps had nothing "saved" in AFoW when the token moved away from an area they'd already explored. Basically it was like Dynamic Lighting was working, but AFoW was not. Did not have this issue with PCs.

I think fog of war is only cleared for tokens controlled by players unless the AFoW->All Tokens Reveal box is checked. Is that box checked on the page?

Ah! Thank you. It was not checked. I'll test that later today.

We just set up AFoW and DL today for DotMM (I paid for it but it's my DM who has the subscription, he's shy about posting!)

It's working well but the slowness is painful, especially with the huge size of the official DotMM module maps. Is this likely to be a temporary situation or is there a workaround for getting decent functionality without running both AFoW and DL together? Turning either off ends the lag. It's worse for the DM which is unfortunate as he has the most to do. 

Our DM watches the Roll20 Presents streams occasionally and their setup seems much more responsive despite working properly so I'm trying to understand whether the slowness is new (I see it mentioned in the recent responses here as a short term thing?) or whether we have something set up badly. Is there any way to achieve a similar effect on the DotMM maps to the stream without killing our DM's PC?

AFoW only: Can see through walls.
DL only: Can't see anything at all beyond the currently-visible area unless players create their own maps, making everything bewildering.
Regular FoW: Can show/hide areas manually but the DL hides everything far away in darkness.

Yuri - I also run DotMM and the AFoW is USELESS, the lag is unbearable. Additionally, I hate that the 0.5 scale makes the names, HP bars and Status effects look gigantic, so I ended up changing the scale back to 1... and then DOUBLED the size of the map in the process, increasing the size of the token layer, dynamic lighting and GM layer in the process.

One thing that seems to helps a lot is:

• Clear your cache on your browser
• Use Google Chrome Beta
• Play in 'incognito' mode
• Remove 'sight' from ALL monster tokens
• make sure that no other monsters 'emit light'

Part of the problem is that module writers don't write with programming limitations in mind. AFoW+DL breaks down on really large and complex maps. It's not ideal, but my suggestion would be (in addition to godthedj's performance enhancements above), turn off AFoW altogether and judiciously add Light Crumbs along the party's path.

@Yuri, The other thing to check is whether Dynamic Light->Global Illumination is on at the same time as AFoW. That combination seems to scan the entire map and really lock things up on larger maps. You can turn off Global Illumination and add lights to the rooms if that is the case.

Thank you all; we'll try using light crumbs for this next map and see how we go :)

Yuri said:

Thank you all; we'll try using light crumbs for this next map and see how we go :)

Great tip/reminder Keith. 

FYI:  while this can be done manually w/out the API, the LightCrumb script(Pro perk) can do this very easily.

// Roll20 API Script to leave a breadcrumb trail of torches. Based on "Mark" from The Aaron //

"Everything Old Is New Again".  ;-P

We discovered last night that a player is able to drag the portrait (not the token) from his character sheet to an area of the map still covered by AFoW.  The portrait automatically becomes a token under the players control, and if there is a light source in the area, the area will be revealed to the player.

This cannot be intended behavior.  A player can reveal the entire map this way (at least anywhere with light sources), even with "only update on drop" and "restrict movement" enabled.

I was not able to find this reported elsewhere.

The player did this entirely by accident; his mouse button was acting a bit sticky, and he just accidentally dragged and dropped it. Of course, the place he dropped the portrait was the secret room where all the baddies were waiting to ambush the PCs....it had a very big impact on the playing experience.

I'm really not sure why a portrait ever needs to be dragged to the playing area, frankly, but it certainly shouldn't be able to be dropped in an area covered by FoW/AFoW, and reveal the area.

Tony said:

We discovered last night that a player is able to drag the portrait (not the token) from his character sheet to an area of the map still covered by AFoW.  The portrait automatically becomes a token under the players control, and if there is a light source in the area, the area will be revealed to the player.

This cannot be intended behavior.  A player can reveal the entire map this way (at least anywhere with light sources), even with "only update on drop" and "restrict movement" enabled.

I was not able to find this reported elsewhere.

The player did this entirely by accident; his mouse button was acting a bit sticky, and he just accidentally dragged and dropped it. Of course, the place he dropped the portrait was the secret room where all the baddies were waiting to ambush the PCs....it had a very big impact on the playing experience.

I'm really not sure why a portrait ever needs to be dragged to the playing area, frankly, but it certainly shouldn't be able to be dropped in an area covered by FoW/AFoW, and reveal the area.

A player can drag and drop a character they control on to the map. That is as intended I believe, I have a folder of AoE Spell effect templates that the players have control of. They work just like characters and they just drag and drop them when they cast the spell to create the token. I would advise your players to just not do that in the future and move them to a landing page in between sessions to prevent any players from exploring between sessions.

You make the default token without sight although you'd have to add sight later.

'though I trust players not to do this myself.

That's all fine and dandy.  I can see the use for dropping templates.

Keep in mind that I'm talking about dragging the portrait from the character sheet, not dragging a token from the Journal.

However, I still believe it is very broken model that those tokens can be dropped by players into areas that are covered by AFoW.  That just shouldn't be possible--or least it shouldn't reveal the area when it does happen. It defeats the point of having "only update on drop" and "restrict movement" enabled.

As I stated, it was by accident, so no amount of "advising my players" would have changed anything.  I can move them to a landing page between sessions, but again it does nothing to stop this from happening during play (accidentally or not).  Do you want your players to be able to cast a spell into an unrevealed area (even with a partial overlap) and have the area revealed to them?

Jim W. said:

You make the default token without sight although you'd have to add sight later.

'though I trust players not to do this myself.

This is not the default token. This is a portrait from the character sheet, not a token from the Journal.

In this case it has nothing to do with trust--it was entirely an accident.

Edit: also, the sight that the portrait inherits is always "sight enabled", regardless of whether the default token has sight enabled or not.

Yes so you set a default token so when you drag that's what you get!

Jim, you are not understanding.

This is not the default token. This is a portrait from the character sheet, not a token from the Journal.

This is not dragging from the Journal, and therefore getting the default token.

This IS dragging the character portrait from the character sheet to the main play area, where it becomes a new token.

It inherits:

1. The "represents character" setting. So it is still linked to the character sheet.

It does NOT inherit:

1. Any other token setting, including "has sight". It defaults only to "has sight" enabled, no matter the what the default token linked to the character sheet has for this setting. Other settings are also default; you cannot change how they show up when dragging the character portrait to the play area. They will always be the same values.

I'm trying to attach an animated GIF to this post to show this....not sure if it's going to work (haven't done it before in this forum).

Hopefully this makes things clearer.

The default "has sight" is most likely because of all the z-order issues from here (linked to the patch notes in the discussion, so you can see what the current solution is): https://app.roll20.net/forum/permalink/7540691/  Z-order representation is now tied to has-sight being on/off, so the default is now on.

Based on that thread, that seems likely. But it causes problems because players are not restricted in where they can place a token, in terms of FoW/AFoW.

I've never dragged a portrait - trying it - it seems to work only one one browser and only if I have Clicked Edit.

Yes I agree that's a rather poor decision by Roll20 on allowing this at all!

Reinforces my decision to avoid starting new campaigns that will include AFOW/FOW features

I never tried it either, until my player's sticky mouse button made him do it accidentally!

Only works (i.e. only a problem) when it's not the GM doing it...

or - to be more accurate - it no longer happens - seems it was fixed ???

I'm still seeing the same behavior.

Tony, it also looks like you are running the Enhancement Suite extension, which is not supported and could also be breaking things. Is the same behavior happening without the extensions enabled?

Why not to ask your players not to do that. I think If i a player have control of the sheet they can just draw it into the map- Just ask the players not to cheat

Loren the GM said:

Tony, it also looks like you are running the Enhancement Suite extension, which is not supported and could also be breaking things. Is the same behavior happening without the extensions enabled?

Yes, the same thing happens if all extensions (including the Enhancement Suite) are disabled.

Danny C. said:

Why not to ask your players not to do that. I think If i a player have control of the sheet they can just draw it into the map- Just ask the players not to cheat

This is really not the point at all here.

Can everyone playing Roll20 always, without exception, count on their players to never do this, even by accident?  This is more improbable than winning the lottery, I dare say.

Therefore I am reporting the undesirable behavior here, because I perceive it to be undesirable behavior, even a 'bug', in hopes that the Roll20 devs will alter the behavior.

I actually play with a close group of friends, that in fact I do trust to never do this on purpose....now that we know about it.  However, that does nothing to stop someone with a sticky mouse button and/or arthritis and/or a motor neuron disease from accidentally doing this.  The behavior of Roll20 in allowing this to happen at all is undesirable.

Players being able to drag their token on to the map is not a bug and is desirable. If your players cheat, find new players. If it happens by accident, not a big deal. Players should avoid metagaming anyway.

Caelum said:

Players being able to drag their token on to the map is not a bug and is desirable. If your players cheat, find new players. If it happens by accident, not a big deal. Players should avoid metagaming anyway.

This has been covered already.
Please read this post above.  This is not about dragging a token from the Journal to the map. It's about dragging a portrait from the character sheet to the map, and the fact that this creates a new token with "has vision" enabled, regardless if the default token in the journal does or not. Thanks.

Go to your campaign settings page and game default settings and uncheck Has Sight. That will prevent the avatar from being turned into a token with sight.

I didn't know that was possible either, but I cannot replicate the sight issue. Tokens I create that way do not have sight enabled. Do you have "has sight" checked as a default on you game settings page? You could try toggling that off.

@Tony what browser and operating system did your player experience the drag problem?

Caelum said:

Go to your campaign settings page and game default settings and uncheck Has Sight. That will prevent the avatar from being turned into a token with sight.

keithcurtis said:

I didn't know that was possible either, but I cannot replicate the sight issue. Tokens I create that way do not have sight enabled. Do you have "has sight" checked as a default on you game settings page? You could try toggling that off.

Thank you, gentlemen. This is correct. It's been so long since I've looked at my Game Settings page, I'd completely forgotten that there were default token settings there. Removing "has sight" from the default settings effectively prevents the metagaming and cheating possibilities, accidentally or on-purpose. A new token dragged from the character portrait to the map area will no longer reveal  everything to the owning player.

I would still argue that a player should never be able to drag a token into an area covered by AFoW/FoW, especially with "restrict movement" enabled in the Dynamic Lighting settings. It's a pretty significant loophole in that setting.

Or perhaps the "has sight" default setting needs to come with a big pop-up warning when enabled?

Kenton said:

@Tony what browser and operating system did your player experience the drag problem?

He was using Windows 10, and Firefox as a browser.

I can replicate it at-will, in Windows 10, using either Firefox or Chrome. A player can drag the character portrait from his character sheet anywhere on the map, behind DL lines and areas covered by AFoW.  If the default campaign token settings are set to "has sight" (or even worse, "emits light"), the player will be able to see the area because he owns the token. It requires alternate light sources or global illumination with only "has sight", and requires nothing else when "emits light" is a default setting.

So, I guess there isn't really a bug with respect to the "has sight" default setting, but it should come with a big flashing warning. Ditto for "emits light".

In my mind, the issue would be with allowing a player to drag a new token to a place where he can't move an existing token. Doesn't seem to make any sense.

Tony said:

Kenton said:

@Tony what browser and operating system did your player experience the drag problem?

He was using Windows 10, and Firefox as a browser.

I can replicate it at-will, in Windows 10, using either Firefox or Chrome. A player can drag the character portrait from his character sheet anywhere on the map, behind DL lines and areas covered by AFoW.  If the default campaign token settings are set to "has sight" (or even worse, "emits light"), the player will be able to see the area because he owns the token. It requires alternate light sources or global illumination with only "has sight", and requires nothing else when "emits light" is a default setting.

So, I guess there isn't really a bug with respect to the "has sight" default setting, but it should come with a big flashing warning. Ditto for "emits light".

In my mind, the issue would be with allowing a player to drag a new token to a place where he can't move an existing token. Doesn't seem to make any sense.

Dynamic lighting using lines to create boundaries, so it does not let player tokens pass through the lines you create. Short of making all dynamic lighting be filled in shapes, I don't see how you would make certain areas "non dropable areas" and "Dropable areas". I just don't know how they would implement what you are trying to get done.

The defaults for tokens should be no sight and no light. Anything else would lead to huge performance issues for players unaware of the implications. And yeah, DL lines keep you from dragging a token across them. Placing a token on the map cannot account for this, since the Roll20 engine has no idea which side of the line you are supposed to be on. And placing a token in an area of FoW would make no difference how sighted the token was. FoW trumps just about everything.

Hey everyone! I wanted to share the latest information we have for you.

Previously, we discussed research we were conducting to provide a better solution for graphic rendering features, including Advanced Fog of War, Dynamic Lighting, and Animations. At this point, we are confident that an in-depth optimization of the system would be the best approach and we are currently exploring a timeframe for it.

This work will make the system more robust to allow for use cases people have described in this thread and elsewhere. We learned a lot about your expectations for Advanced Fog of War from Get a New Look, and we’re taking care to integrate as many of those expectations as we can into the core design of this next iteration.

Thank you all for your patience and feedback thus far and we will keep you posted on our progress! Since it’s a large project, those updates may be less frequent as we get a handle on the technical requirements, but it’s a high priority for us and we are working to bring you as much information as we can.

Without getting into the specifics, is this more optimization, or more of a paradigm change in how the concept is approached? Assuming you are at liberty to say. :)

Hmm. I think it would be fair to call it a paradigm change, yes!

Ooooh. :)

I recently subsribed and used the dynamic lighting and advanced fog of war.
Me and my players feedback is as follow:

• There is a need for a "share vision between players" option. At start, each of my players could only see their own vision. It's realistic, but terribly frustrating for them to be stuck behind and not see the action. I solved this by giving control of each character to each player, so they share all vision, but it means they can move each other tokens.
• The grid-based aspect is annoying. As long as the environnement is only square angles, no prob. But as soon as you have circles, diagonals, irregular surfaces, the fog of war is ugly and potentially game-breaking. If you have a secret passage behind a thin diagonal wall, the square can be fully revealed by the fog of war, displaying a little bit of empty space behind the wall and making the player guess that there is a secret there..
• The performance is atrocious... Without "update only on drop" option, dragging characters tokens is very very laggy. But even with this option, some of my players noticed lag and poor performance, and my own computer had some responsivity issues (and I have a beast of a computer..). As soon as I disabled AFOW, everything was perfectly fluid for everyone. As a developper, I think this feature need a severe optimization, or a complete overhaul. I never worked on dynamic lighting, but I'm sure there is a better method to display a fog of war.

I'm glad you are working a solution, but you seems to implicate a long delay before we see some result..
Meanwhile, I will have to find a solution, and I think I will desactivate AFOW and use light crumbs. The only problem is I wanted some colored lights to differenciate player vision and "fog of war", but it doesn't seems possible.

Icebird, I feel your pain. We all do!

My stopgap solution is to disable fog of war, give everyone only access to their own character and then make a new little clear 'png' or 'gif' that is invisible to everyone. Even the DM. I then give it a 0 sized 'Aura' in the token settings and set it so only the GM can see the aura.

I call it something like breadcrumb, and give everyone access to control it.

I put its settings as maybe 'light:100ft' Start Dim:0ft

Then just drop these around the map as they navigate through, or even a little further ahead if there is a single player taking part in a battle up ahead....

More info on Light Crumbs

^ I'm going full light crumb now. Beyond the issue with light revealing in AFoW, it's just too much of a performance hit for me to want to use. The Light Crumb script works really well for me.

I have run into an odd issue lately, that I am not sure is due to light crumbs. I have had players log in and report that all they can see are the light crumb icons. No map or anything else. Usually a reload clears that up, but just a heads up. Again, I don't know if this is related, but it started happening after I had about 15-20 light crumbs on a single map.

Eivil said:

Kinda mind-boggling that the users have to resort to such awkward workarounds to get a feature that is blocked beyond a paywall to work properly for so long.

agreed.

keithcurtis said:

I have run into an odd issue lately, that I am not sure is due to light crumbs. I have had players log in and report that all they can see are the light crumb icons. No map or anything else. Usually a reload clears that up, but just a heads up. Again, I don't know if this is related, but it started happening after I had about 15-20 light crumbs on a single map.

Hmm. I'll have to see if I encounter the same issue in the next adventure I run. 

Eivil said:

Kinda mind-boggling that the users have to resort to such awkward workarounds to get a feature that is blocked beyond a paywall to work properly for so long.

Yup. It's incredibly frustrating to say the least.

Trying to see through a player's token using the ctrl+L shortcut no longer works for me. I can't see any light sources from their view unless it's their own, but only when that player is also connected to the game.

kpulv said:

Eivil said:

Kinda mind-boggling that the users have to resort to such awkward workarounds to get a feature that is blocked beyond a paywall to work properly for so long.

Yup. It's incredibly frustrating to say the least.

Trying to see through a player's token using the ctrl+L shortcut no longer works for me. I can't see any light sources from their view unless it's their own, but only when that player is also connected to the game.

It's even more frustrating to know that the previous AFoW implementation worked fine.  Switching back to the old AFoW system would immediately resolve these issues, but for some reason they wont let us do that.  Even after finally acknowledging the problems with the current implementation, and committing to an in-depth rework of the entire graphic rendering system as a result, we still have to persist with the current botched implementation until the new one is ready.  Why? 

For seven months now paying users have switched off the AFoW system entirely while we wait for the new "paradigm-changing" optimisations to be completed. And how many more months will that be?

Hey all, so to recap a little, we are currently in the research and proof of concept phase of this process.

Stephanie (our Scrum Master) mentioned getting to play with a little of the work that has been done so far in August’s Community Roundtable, if you want to hear directly from her. Once complete with this current phase, we will move through Design, Development, Testing, and Beta phases before launch. We expect to update you all at each of those steps, and release an update before the end of 2019.