J.D. said:
@Berenice and Roll20 Mods-The title for the game is called Faerun’s Falling. I couldn’t see anything else to identify the page by. If there is a specific number for the Game ID, I do not know what that is. Thanks!
The game id is the long number in the URL when you are on the game's landing page.
AFOW/Dynamic lighting still not playing together properly despite the hot fix. Works though in the Test Server. Any news on when this will be looked at? Unlike some others my players can live with it, but losing features always leaves a bad taste in your mouth.
Bekradan said:
AFOW/Dynamic lighting still not playing together properly despite the hot fix. Works though in the Test Server. Any news on when this will be looked at? Unlike some others my players can live with it, but losing features always leaves a bad taste in your mouth.
Holy &$*(&%($!
Many more parts are working on the Dev server. Most importantly, fog of war does not block what a token should be able to see. Interestingly the changes from Friday's hotfix do not seem to be implemented.
The only big bug I see on the Dev server is AFoW View Distance clearing fog of war for an area that the player cannot actually see. This creates a problematic catch-22. If a token's AFoW View Distance is blank or 0, the fog of war is only cleared for the space they are on regardless of what they can see. If the View Distance is set, that portion of the map is revealed regardless of whether the token can see the space or not.
This creates several problems for people running games.
In my opinion, the resolutions that would work best in order of usefulness for the user:
If I can think of any other useful permutations, I will add them here.
I'm having a terrible time with the fog of war; having the two of them active at the same time just refuses to work properly. The current issues I've observed, in order, are:
I've been forced to drop AFOW entirely and just use dynamic lighting, since it still works fine; not being able to have my players able to see where they've already been is obnoxious, though! I wish I didn't have to choose between dynamic lighting and vision-blocking and my players being able to see where they've been...
I feel like these problems weren't happening earlier today, either, but I might be wrong there.
Hydrall, I am in total agreement that the system needs fixing, but here is the workaround we used to use before AFoW existed.
Create a character that is controlled by all players, called "Light Crumb" or something similar. Give its token sight and illumination, typically 30-60 feet of dim light only. Save that default token to the character. Whenever your players leave an area, drop a light crumb. They all see what the light crumb sees, regardless of where the rest of them are.
Use them sparingly if you want to prevent potential lag, but ten or so on a dungeon level shouldn't bee to bad.
Hi Stephanie!
Thank you very much for your help!
Stephanie B. said:
Alexandre,
When you download images from the marketplace and then upload them to your library, they take up some of your storage space because Roll20 doesn't have a way to know that what you uploaded was a purchase. When you use them directly from the premium material folder, they do not take storage space. They're available to download because many content creators allow you to use them outside of Roll20.
So, you might find this can help you recover some storage space, too!
Alexandre M. said:
Wow, this is really embarrassing. I had never selected the "Premium Material" option in my library until today.
I swear, I tend to be better than this.
Nick, thank you very much for your help!
Vegas said:
Trying to upload an .mp4 file results in an endless "Uploading" window. It's only 2.2mb.
had this problem as well. Shrunk the video file down and it worked.
Brian C. said:
Marek said:
Any word on when the Ctrl + L issue is going to be fixed? It's been the bane of trying to run my dynamic lighting heavy game, with players that all have darkvision. It's been months now. I'm starting to wonder why I even subscribe to this service...
Until it is fixed, you can run a free test account in whichever of Firefox or Chrome you do not currently use for Roll20. Give the test player a character with normal vision and one with darkvision. You can then run the GM account and the test account simultaneously from the two different browsers. This allows you to make changes on the fly and see them in the test account's browser. It works even better if you happen to have a two-monitor setup as you can see them at the same time.
Hey, you know that problem that's ruining your game? We're not going to fix it, but hey you can add even more time to your prep and sink even more hours into tech support for the service you're paying for.
Brian is offering a workaround to help Marek. This is not a technique that Roll20 is offering as a solution.
Still no changes to the bugs with Dynamic Lighting. All players benefit from light emitted from other tokens. Some work around can be done however this involves allowing characters without dark vision to be given a light source.
If you rely on dynamic lighting for effects and playing through, this bug can be game breaking.
Dungeon M. said:
Still no changes to the bugs with Dynamic Lighting. All players benefit from light emitted from other tokens. Some work around can be done however this involves allowing characters without dark vision to be given a light source.
If you rely on dynamic lighting for effects and playing through, this bug can be game breaking.
Are you verifying this with a separate log-in, or relying on (the broken) Ctrl-L? The latter demonstrates the behavior you are talking about, but the actuality of play does not. (At least not for me).
keithcurtis said:
Dungeon M. said:
Still no changes to the bugs with Dynamic Lighting. All players benefit from light emitted from other tokens. Some work around can be done however this involves allowing characters without dark vision to be given a light source.
If you rely on dynamic lighting for effects and playing through, this bug can be game breaking.
Are you verifying this with a separate log-in, or relying on (the broken) Ctrl-L? The latter demonstrates the behavior you are talking about, but the actuality of play does not. (At least not for me).
So its the control function that isnt working, and just making it seem
like Dynamic lighting has an issue? Is what what you mean?
Dungeon M. said:
Still no changes to the bugs with Dynamic Lighting. All players benefit from light emitted from other tokens. Some work around can be done however this involves allowing characters without dark vision to be given a light source.
If you rely on dynamic lighting for effects and playing through, this bug can be game breaking.
Just verified, the control function does not accurately represent the lighting.
Moving report here:
Mitch K. said:
So, since the last dynamic lighting update a while back, my and my friends campaigns have had a veritable HIVE of bugs. First, everyone in the entire campaign suffers one of two flaws 1; Constant and repeating "A web page is slowing your browser down" This happens across multiple computers, multiple operating systems on any player or GM using Firefox. If using Chrome the error is "you have been disconnected from the server". 2; If the GM refreshes the page, all players get a visual of the map layer as if no dynamic lighting walls are present. 3; There is massive latency. Every player and GM in the groups get lag times of up to several minutes to see rolls, move tokens, or see that tokens have been moved. We have tried every rational action to fix this issue, and have gained no results.
Disclosure: We are not playing 5e, pathfinder or any other premade game. We have no API in the background, but have occasionally used CT and Status premade API'sSummation this needs addressed as currently Roll20 is basically useless for our games and will force us to find another Web Tabletop.
Brian C. said:
Marek said:
Any word on when the Ctrl + L issue is going to be fixed? It's been the bane of trying to run my dynamic lighting heavy game, with players that all have darkvision. It's been months now. I'm starting to wonder why I even subscribe to this service...
Until it is fixed, you can run a free test account in whichever of Firefox or Chrome you do not currently use for Roll20. Give the test player a character with normal vision and one with darkvision. You can then run the GM account and the test account simultaneously from the two different browsers. This allows you to make changes on the fly and see them in the test account's browser. It works even better if you happen to have a two-monitor setup as you can see them at the same time.
That doesn't really help, and would just make things even more complicated if I did something like that while running a game. I'm talking about the simple ability to press Ctrl + L while a token is selected (player's or npc/creature), so I can see what they currently are seeing. It's been bugged for months now. It shows all tokens' vision at once, thus making it useless if you have multiple players or sources of 'has sight' and 'emits light' for something like wanting to see the perspective of someone's darkvision.
Stephanie B. said:
Sam,
Do the tokens which don't Emit Light and can't see have their AFoW View Distance set?
If a token Emits Light and no AFoW View Distance, the AFoW will use that as its sight distance. If a token has nothing in Emits Light and it has an AFoW View Distance set, AFoW will reveal up to the view distance, based on any other light sources around. If a token has neither Emits Light now AFoW View Distance set, then the token cannot see at all.
This is as designed; the AFoW Distance determines how far a token can see if it doesn't have a light source.
Sam T. said:
Sam T. said:
So I have an (apparently) related issue where the advanced fog of war is not being revealed for tokens which do not emit light themselves, despite being able to see due to other light sources.
We're using Advanced Fog of War and Dynamic Lighting. We also have Enforce Line of Sight enabled so that players do not share vision.
The situation we're experiencing is as follows: If a player controlled token emits light, then that token's vision reveals the advanced fog of war as expected. However, for player controlled tokens that do not emit light, but can see in a region because of other light sources (e.g. light sources controlled by other players, ambient light emitting tokens on the dynamic lighting layer or map layer, or global illumination), then their vision does not reveal the advanced fog of war in that region for the controlling player.
Note: Fog of War is not enabled. All player tokens have "Has Sight" checked. All light emitting tokens have the "All players see light" option checked. I have tried both with and without "Dim Light Reveals" enabled. I've been able to reproduce this behaviour in every different game I play in.
By way of example: imagine two player controlled tokens (controlled by different players) are in a dark room. One token emits light (with the "all players see light" option checked), meaning both players can see the whole room. When the tokens leave the room, the advanced fog of war was only revealed in that room for the player controlling the token which was emitting the light.
I'm still experiencing this behaviour after the hotfix. I don't see this issue in the known issue list in the top level post.
Hi Stephanie,
The tokens in my example did not have an AFoW View distance set, because that made the problem worse. You say: "If a token has nothing in Emits Light and it has an AFoW View Distance set, AFoW will reveal up to the view distance, based on any other light sources around." That would be great if that were correct. My experience is that it actually reveals AFoW up to the full view distance regardless of whether there are any other light sources around.
i.e. Imagine a token which has sight, but does not emit light stepping into a new room for the first time. If there are no light sources in the room (and global illumination is off), then they shouldn't be able to see anything. However, if they have an AFoW view distance set, then the AFoW in the entire room is revealed for them, which shows them everything on the map layer (albeit in black and white) even though they should never have been able to see it.
Having no view distance set actually gets closer to the intended behaviour because prevents the entire room being revealed and limits what they can see to only what is illuminated (i.e. if they introduce a light source into the room). The only problem is the one I initially described, which is that none of the AFoW stays revealed after they leave the room.
I hope that's clear, but let me know if you want a worked example with screenshots.
So, I recorded an example of the Jukebox issues I've been having since adding animations to my game. Here we see a 20x20 area, with 4 copies of a 10x10 animated overlay and some scenery. Note that both tracks that are playing (uploaded to roll20 and massively stripped down in quality to limit file size) chug and cut out intermittently.
I should stress that - while the jukebox has never been the most stable part of roll20 in my experience - this problem has only arisen since I added the animations to my game.
I'm using a plugin in the recording (VCC Enhancement Suite) however the same issues persist with it uninstalled. They also persist when logged in as a player.
Good morning, everyone.
This morning we pushed code to fix the issue where Global Illumination is active even when Dynamic Lighting is disabled.
Last night I had a dream that the Dev team fixed Animated Tokens on Rollable Tables. Then I woke up, took a cold shower, and cried myself to sleep again. I’m dying inside. :,(
I was hoping the token bar fix would finally show up.
Gargamond said:
Last night I had a dream that the Dev team fixed Animated Tokens on Rollable Tables. Then I woke up, took a cold shower, and cried myself to sleep again. I’m dying inside. :,(
keithcurtis said:
Brian is offering a workaround to help Marek. This is not a technique that Roll20 is offering as a solution.
I know it's not a technique that Roll20 isn't offering as a solution. And I'm telling him his workaround doesn't help me at all in my situation, Keith Curtis... I don't even know why you are responding for and telling me this. It literally serves no purpose.
It's in the works, but didn't pass QA before the code push yesterday.
Chris S. said:
I was hoping the token bar fix would finally show up.
Movign report here:
Caos said:
Hi
Since last update the cell width is don't save after you deactive the grid.
For example I set the cell width to 2 (140px) beceause the scale of my map is a bit little for my token. I rezise all my token and I desactive the grid. After that, the cell width back to 1 (70px)...:(
It's a problem for the distance, the light, the view etc...
Same for the aura, I set the aura of a token to 1.5m or 3m for exemple. If the grid is active all is ok but without the grid all my aura look like at 0m.
Someone can help me ?
TY
Hi folks.
This is my first time here...so if i am in the wrong place for this pls tell me :) Otherwise let's get started.
I DM-ed for a long time now and allready used the dym light and the advanced fog very efficiently. Now me and my party had a long break (5 months) and now we returned only for me to find out that this awesome feature just doesn't work (the same way as before) anymore. So i am looking for answers / patchnotes / help.
So what is my problem / my settings:
1)
Torches don't work. Players got sight (and sometimes a lightradius) but
they just can't see the torch even when in their light.
2) "ctrl-L"
just does not show the right thing. We had a session where i thought i
had figured it out and tested it with "ctrl-L" but when they joined they
could only see their own light.
3) To emit any light, i had to
create a character (NPC, just controlled by me) and set the torches to
this character. If they are "no character / general token" it just does
nothing.
So what did i try:
3 torches with 12 / 6 light.
One without "all players see light" and "has sight", one with "has
sight" and the last with both. I copied them and made the 2nd three to
the NPC player tokens.
Now the first three don't emit light at all and don't see anything.
The second three ALL see their light.
ps: if i deactivate Afow it works perfect...i know just want the grey allready revealed areas back...
But then there is another issue: all characters with "has sight" can see all emited light even if "all players see light" is deactivated. This occurs on characters and on generall tokens.
Hi André,
You've hit on the workaround for most of the current bugs: Turn off AFoW. It doesn't work well with DL at the moment. As for the torch problem, that is a related issue (came with the same update). Ctrl-L is not reporting correctly. A workaround is to set up a dummy account and log into your game as a player. You can check the sight of any character from there by assigning control to the dummy account from your main account. You can make this quicker by opening the dummy account in a separate, incognito window.
I had another dream last night. That one day, DMs will be judged not by the contents of their characters, but Animated Tokens on their rollable tables. I HAVE A DREAM!
@keithcurtis
Thanks for the answer. Ctrl-L seems to work fine without AFoW but with DL :) Seems like we will just have to play without AFoW for "a while"...
André L. said:
@keithcurtis
Thanks for the answer. Ctrl-L seems to work fine without AFoW but with DL :) Seems like we will just have to play without AFoW for "a while"...
Is it possible it is working correctly even with AFoW in my games? ^^'
Moving for Wolffar:
Wolffar said:
This problem started around 3 months ago, Auras aren't displaying when the grid is off.
if I turn the grid on, the auras work just fine, but as soon as I turn off the grid the aura disappears.
if I use a square aura it will fill the area of the token's selection box, but no further, no matter how big I make the aura size
Alessandro V. said:
André L. said:
@keithcurtis
Thanks for the answer. Ctrl-L seems to work fine without AFoW but with DL :) Seems like we will just have to play without AFoW for "a while"...
Is it possible it is working correctly even with AFoW in my games? ^^'
It's possible, but as of last night Ctrl-L was still showing me the vision of all sighted tokens simultaneously, and I don't use AFoW.
I appreciate all your hard work on this bug, However its almost becoming a deal breaker now. I will reluctantly be looking for an alternative tabletop platform.
Keith Curtis, you've said a few times that one workaround to the current AFoW problem is to disable it and manually reveal parts of the map with regular FoW and DL active. I appreciate this suggestion. However, this is a huge step backward in terms of functionality, and one I'm very reluctant to adopt. Most of why my gaming group and I moved to Roll20 was the ease of use of advanced fog of war and DL. Is it at all possible to tie revealing areas in the map to character tokens, with a token-based command like "Reveal visible areas to token X" showing the player only what the token can see from that position? I could definitely get with that, as it's what my group and I used when we played using maptool -- basically a manual update on vision keyed to a token.
I don't want to pile on or be negative, but it is concerning and disheartening to see one of Roll20's best features broken by the devs in such a comprehensive way that they themselves don't seem to be able to fix it. My commitment to Roll20 as a platform will frankly hinge on how quickly AFoW can be fixed. If it's not fixed very soon, I might have to consider other options besides Roll20.
I agree with you. This is a now-core function that is extremely aggravating to have broken for so long. My suggestions for workarounds are merely so that people can keep playing. I'm fortunate in that I never have used Advanced Fog of War, so the only thing affecting me is the Ctr-L situation. But that's just me. Most of my solution is just DL, no fog at all. Maybe the occasional Light Crumb. But others depend on AFoW. It's frustrating.
As to your suggestions for an API, my suspicion is that those parts of the system are unreachable through the API. If they were, I'm sure we'd have some pretty cools script that use them. Maybe the Aaron, or one of the other script gurus can give a better, more technical answer.
But how do your players explore a trad dungeon, if you're not using fog? They'd be able to see the entire dungeon layout at a glance, even before they've explored a corner of it? Or am I missing something? (I'm probably missing something.)
Also, it's pretty depressing that a feature that has been standard on an open-source, free platform for years (maptool) is likely out of reach for Roll20.
Jay R. said:
But how do your players explore a trad dungeon, if you're not using fog? They'd be able to see the entire dungeon layout at a glance, even before they've explored a corner of it? Or am I missing something? (I'm probably missing something.)
I just use Dynamic Lighting. I drop them in the starting area, and open doors as they progress through the dungeon. They can only see what the DL lines let them see. I drop a light crumb if they need to remember the way back or where another room was spatially.
I use regular fog of war for ad hoc blocking and often for the borders of the map. Hint: If you make your page four squares larger than the map image, and cover those borders with fog of war, not only does it give you a place to store tokens more accessibly than the GM layer, it often can solve the problem of the canvas adding extra spaces at certain magnifications.
I don't use Advanced Fog of War. it's too fiddly for me and I have enough trouble dealing with lag already.
охотник said:
Are the token bars really so screwed?
They are pretty unreadable when tokens are crowded in close proximity. There are some screenshots upthread that display this pretty well. There is also the problem that some folks get used to the way things are and depend upon it. For example, token bar overflow was considered by Roll20 to be a bug. Regardless, it turns out that many people used that display to let them know if someone had extra HP (or other attribute) or a negative value. The current implementation on the dev server has some really nice solutions, but is still somewhat buggy.
Hi Stephanie,
Have we agreed that this is not working as intended? I just want to make sure it is still being tracked as a bug.
You said:
Stephanie B. said:
If a token has nothing in Emits Light and it has an AFoW View Distance set, AFoW will reveal up to the view distance, based on any other light sources around.
Whereas, with those settings, AFoW is actually revealed up to the view distance regardless of whether there are any light sources around.
Thanks,
Sam.
Just pointing that the hotfix mentioned before has't fix it to me. It has in fact worse my situation. When I turn on the AFoW now the whole map is show to the players, I checked it both with the DM view (ctr+L) and using a dummy player account. If I turn off the AFoW it only show what the current light is supposed to show, as expected. But so far, I don't have a option to keep showing the player the areas already seen.
When I put the AFoW, the site crash or almost crash, it became really, really slow. When I see the player view in
Arthur V. said:
Hi,
I'm having a problem with Advanced Fog of War plus Global Illumination.
I and my players are having these problem, in my case I'm running Roll20 in a Chrome Version 73.0.3683.86 (Official Build) (64-bit) in Windows 10. |My players are using mostly Chrome as well, but some use firefox, their OS are either several types of Windows or Linux.
I'm experiencing these problem in my Price of Apocalypse game and in the Sacred Stone map, not sure if I'll notice the same problem in the others maps.
When I set Global Illumination On with AFoW it limits the players view for a small distance, that the in game measured as 35 fts:
the Page settings with both Global Illumination and AFoW on
What the player sees. His view is blocked after a 35 ft distance, the reveled area is square shaped with a 35 ft distance from the token in the center. I tested it, and as move the token the map is reveled still only until 35 ft. And the AFoW keeps, as expected, showing the area already seen by the token
I created a dummy account and gave it a player status and logged in as player to see exactly what the player was seeing.
If I turn of the AFoW in the Page settings
The reveled area to the token is what I expected in a global illumination, but the token loose the sight of the area he already visited, what the token no longer see turn black, again, as expected without AFoW.
What I what is that in maps both options turned on, Global Illumination and AFoW, the token see everything as the last picture but keep showing the area already visited using the AFoW feature.
It is remarkable that we are just a couple weeks away from AFoW not working for a quarter of the year. Nolan's recent post in the Pro section roadmap thread and the linked developer interview seems to indicate the refactor was to open up CPU capacity so animations could work.
The thought that someone would sign off on a change to AFoW so it revealed portions of the map the user could not see via Dynamic Lighting, nullified the page option for dim light to clear the fog of war, and revealed portions of the map through the Dynamic Lighting lines is baffling. That subsequent patches have made AFoW view distance control what dynamic lighting a token can see and cause light sources to make things darker is even more so.
Please restore the correct functionality of AFoW: that what a token can see through DL clears the fog of war. Even if that makes things slower so that animations are impossible to run, let us choose between AFoW and animations.
I am sitting on releasing an adventure for a client because I cannot test it with DL and AFoW. Soon I will have another adventure for a different client that I will have to sit on as well. Features that I built into maps for already released adventures have not been working for 2.5 months, and people who do not read the forums may think that I messed up with the product rather than a significant feature is broken in Roll20 and just abandon the product line.
Just wondering if we will ever see functionality again for AFOW and Dynamic Lighting and CTR-L. I don't use and probably won't use Animations. So, how about creating another layer of pay to play for folks who want Animations and give them a different set of tools. Get the rest of us who have paid for 4 months of Pro without being able to use a majority of the functions we bought Pro to use. Or, Give each pro User an additional month of Pro for each month that we have not been able to use our Pro features, up until you resolve the issues! If it starts to cost you money, then you might be even more motivated to fix this functionality that you Broke! C'mon guys. A lot of us are stuck because we have purchased content from you and cannot take that with us if we go elsewhere. Also, we have a lot of development and creation that we would lose. Fix the Darn System or roll it back to where we were in January and then rethink what you are trying to do. 4 Months is plenty of time for you to have Re-Factored the entire interface to write it properly and get it to work. Instead, we have seen 4 months of Bandaids and patches and hot fixes that don't fix the core things we all use.
Please start considering your customers who have been with your for at least as year or more and who think your system is awesome and are bringing new people to your product. But, I cannot, in good conscience, recommend anyone to go to Plus or Pro if the problems continue to persist. Think about that!
keithcurtis said:
охотник said:
Are the token bars really so screwed?
They are pretty unreadable when tokens are crowded in close proximity. There are some screenshots upthread that display this pretty well. There is also the problem that some folks get used to the way things are and depend upon it. For example, token bar overflow was considered by Roll20 to be a bug. Regardless, it turns out that many people used that display to let them know if someone had extra HP (or other attribute) or a negative value. The current implementation on the dev server has some really nice solutions, but is still somewhat buggy.
I was being sarcastic because it's literally been months
