Jumpgate Vision? why? the old way worked?

So I've started up a new campaign for my in person campaign using 2024 ruleset in 5e. I've given my tokens vision, I have both the legacy and new dynamic lighting turned on, and nothing. I am using a test token with no stats except for darkvision 60 ft., and I as a player have permission to view from it, the map has lights on top of the darkvision and I can't see anything through the token. Help? Can I go back to legacy lighting without having to remake everything I've already done on the campaign?

Hi The IvoryChub! On your old campaign, if you had Legacy Vision active on any pages, it should have had a conversion button. That would help you to convert. The legacy system has been deprecated for years, and is not going to be brought forward into Jumpgate. Maintaining two code bases is untenable and counterproductive. Since you have Pro, may I suggest the script Dynamic Lighting Tool? It has a "Why can't this token see?" button that will diagnose many of the most common causes of token blindness, often offering quick-fix buttons for the more common causes. In the meantime, if you make sure your page is not masked (used to be called Fog of War) and post screenshots of the token settings of the token in question, DL settings on the page, and perhaps the light source, hopefully one of us can help you find the cause.

Here's the result for "Why can't this token see?" and it really doesn't explain. I've tried in both daylight and not daylight. The light source I'm using is the default light source stamp that has 20 feet of bright and 20 feet of dim with no edits what so ever.

The light source is directly at the top right corner of the square the token is occupying.

To be clear, the screenshot of the token itself is what you see as a GM without using Ctrl-L, and if you do use Ctrl-L or enter as a player, you see nothing but blackness? And have you confirmed that you do not have the VTT masked? (This is under the masking tool)

I hadn't even touched the masking tool, so I had assumed. After opening it and selecting manual mask, the problem has resolved. That seems very unintuitive, having the area masked by default with the option seemingly unchecked, but the issue has been resolved. I do appreciate the aid, anyway.

To be clear, that's not the default, and you should not have had to deal with this. Perhaps it is a consequence of having converted the page from LDO to UDL at some point in the past? Anyway, glad it's resolved. I'm not sure if masking is exposed in any way to the API, so I don't know if I can add checking for a mask to the script, but I'll look into it.