Katie Mae said: Hi there! We're back after a wonderful holiday break with more UDL updates, and this one is important! Thanks to your feedback, after our latest updates we are now considering UDL to have reached 1.0. To learn more about what that means to us, you can visit this blog post. In the coming days, we will be closing this thread and creating a new one as we look toward the future of UDL. As always, your feedback will be essential in the process of improving our platform! Until this thread closes, feel free to post feedback about UDL as it stands, and where you would like to see us go from here. Happy new year! This is more tone deaf announcement about UDL than usual. Announcing that a piece of software is "1.0" communicates that it is feature complete and relatively bug free. UDL is neither. The time since the last announcement of a code push on December 31 has been filled with a stream of complaints and bug reports on this thread. Nobody has said, "Great, it works now!" Emphasizing that LDL is going away reinforces the push to UDL by presenting the stick alongside the carrot (Look at all the great new features! LDL is going away, so you better move on. . . ). This follows the pattern over the last 9 months of repeatedly telling customers that "UDL is ready, and it's never been a better time to switch your game over to UDL!" each time just weeks after massive, game-breaking bugs are reported. Since UDL still isn't ready and is constantly being refactored, fixed, and changed, people keep popping up after code pushes saying, "Hey my game had been working on UDL for the last several weeks/months, and now this happened. . . ". Meanwhile, core issues have never been fixed since April 8, 2020, or when other significant changes to UDL were made. This constant push of UDL when it is so demonstrably not ready communicates a disdain for Roll20's customers: that their customers' limited gaming time means so little that Roll20 is not willing to make sure the system is bulletproof before announcing the feature and telling their customers to use it. Roll20 then apologizes. . . and does it again and again and again. Roll20 could have adjusted the schedule to announce 1.0 until the newly created spate of bugs were dealt with, but Roll20 has again demonstrated that they value adhering to a schedule over their customers' time and resources. I want UDL to succeed. I have wanted DL fixed ever since two years ago the AFoW rewrite restricted clearing fog of war to light sources the player controlled and took away our ability to restrict how far from the token the calculations were done, causing a loss in performance. We were left with a system that did less than its predecessor and had worse performance. Currently, UDL does not do everything LDL does, and it does it worse. I will continue to help how I can, by testing the feature and posting pictures and video showing the results, but it is exceedingly annoying to see myself and others bring up issues and have them not fixed for half a year or more. These are not just "obvious" bugs that appear with a few minutes of kicking the metaphorical tires but fundamental design choices that are different from LDL and have made the gameplay experience worse. These include: Changing the light origin point and collision box on tokens from a single point to an area. This has caused light to bleed over to the other side of DL walls on some converted maps and changed the distance that light is emitted from tokens to be larger than the specified distance. Changing dim light to shift from bright to darkness the further from the token you look rather than using a uniform dim light level across the area. This causes tokens that cast dim light over long distances to emit bright light for the first portion. Changing DL lines to block from the edges of the line instead of down the middle of the line. This was added (along with the expanded bounding box) because early on in UDL someone had vision start further out from the center of the token while the collision was checked at a pixel at the center. In June, the vision/bounding boxed were matched up, but this change was retained. This causes existing maps to change how much of walls and doors are occluded by DL lines with any thickness. Some maps have thin walls and doors that can be approached from both sides, so the line has to run down the middle of the wall or door. Thin lines cannot be easily selected (or at all in some cases), which makes them bad candidates for doors, but under UDL thick lines block players from even being able to tell there is a door there in certain situations. The change has also caused secret doors on walls to jut out from the wall. In LDL, if we want a DL wall to block vision from the edge of the line, we can Switching to raycasting to tell what a token can see. The jagged lines it causes look horrible. It blocks the player from being able to see up to the DL line in some cases. That the darkvision implementation in UDL does not properly interact with dim light, whereas it does in LDL. Nobody cares about the excuse that it was not intended behavior, especially when it has been a core part of DL for years (and described on the wiki). This could have been quickly and easily handled by implementing Night Vision as a second light that only the controlling players and GM could see. This would have reduced code complexity, produced the desired darkvision behavior, given bright and dim Night Vision options, and avoided a number of game-breaking bugs. It would have even been simple to add a second light for darkvision in LDL to buy extra time for UDL's development. Your customers would have been singing your praises for such a simple addition instead of leaving the platform. tl;dr It was disingenuous for Roll20 to announce that UDL is at 1.0. It is my opinion that UDL should not be considered to be at 1.0 until it can do everything that LDL (and original DL/AFoW) can do at least as well as the previous systems and is relatively bug free.
