🪰 Viewer Bug Reports

Set up camera, store preset, take some photos, mess with your scene, suddenly the camera zooms into the horizon and recalling the camera preset from the 'My Camera Preset' menu sends your viewpoint back to the horizon and not the stored preset. A real bummer for taking photos.

I recently upgraded Firestorm from v6, noticed certain unicode characters in chat and hover text exhibit the bug, installed LL's viewer, saw the same issue. I was told by Monty Linden in the last server meeting to file a bug report for the viewer to get a font pack update. Here are a few out of many problem characters: [2025/04/29 05:36:35] llOrd(textbox): llOrd('🗕',0) = 128469 (0x1f5d5) [2025/04/29 05:36:46] llOrd(textbox): llOrd('🗙',0) = 128473 (0x1f5d9) [2025/04/29 05:36:51] llOrd(textbox): llOrd('🞁',0) = 128897 (0x1f781)

These issues appear to occur with a High DPI monitor with Viewer UI scaling or Windows UI Scaling: Cursor disappears in any text box, including on login screen, script window, search boxes, and chat windows. Shift-tab to un-indent, or pressing enter to auto-indent to next line in script editor is awkward. Shift-tab pulls more lines than it should back. Shift-Up to select a prior line off by 1 space making things misalign. Trying to shift-tab a single line erases it. These may seem unrelated but I've had the issue occur over UI Scaling as well, so I avoid that now. Well, now Windows is UI scaling, and the same issue occurs. Temp fix: Properties on the viewer shortcut, Compatibility tab, Changed High DPI Settings, and Override high DPI to System. This slightly blurs fonts (ClearType is no longer active) but fixes the cursor issue. The text editor issue Ive seen occur from using any viewer UI scaling and trying to edit scripts. If there was any doubt about it being a High DPI thing, my main monitor is 2560x1600 w/ 150% scaling in Windows. My secondary is 1920x1080 with 100% scaling, and just moving the window from main to secondary fixes the cursor issue. In the mp4 added: 00-08s: I cant see my mouse so I'm moving it around between the UI and Input field showing it disappearing. This doesn't show in the recording. 08-12s: I pressed enter at the end of the llSay line to make a new line, and pressed Shift-Up. It should have selected right before llSay, but catches an extra space in front of it. 15-17s: Using keyboard again (cant see the mouse after all) copy several llSay lines and then select lines 4-8, Shift-Tab affects lines 4-12. Pressing again selects even more, and Shift-Tab operates on those as well. 17-27s: Undoing the extra lines to restore to new script default 27-32s: Select line 4 and Shift-Tab. It erases the line entirely. Undo, End, Shift-Home, Shift-Tab, does it again.

* Enter an "about" URI for a parcel into local chat via paste/script/whatever: e.g. secondlife:///app/parcel/c6bb43c1-86d6-cbe2-7483-03a99f8b3862/about * Right-click/control-click on the displayed link to see available options RESULT: Menu appears with commands Show Parcel Information / Show on Map / Copy SLurl to Clipboard * Choose "Show on Map" RESULT: Nothing happens EXPECT: World Map should open with a beacon to the parcel's location NOTE: "Show Parcel Information" works and contains a functional Map button.

Using Region Terrain chooser. Select new PBR terrain material. The 'Apply' button remains greyed out until any other value field is changed (eg Water Height). This was working on previous PBR releases

Cleaning out my block list I noticed a couple entries that appear to point to avatars, but don't display proper names: instead the entries read hindare20completeparam1l1n02.lindaprivat… and lindar011487302797692204159.lindaprivat… If I right-click them I get options to unblock, but trying to open the profile fails. (See screenshot.) I'd be curious what these entries represent. Deleted accounts? Banned accounts? Corrupted data? Something else?

World > Show > Land Owners - regardless of type (e.g., group, for sale, etc.) all owners are colored red.

On Mac laptops, when using the WASD keys for movement, using the A and D keys (to turn your avatar, etc) will cause a small character accent menu bubble to appear near chat menus or the cursor. This does happen in Firestorm as well, but does not happen on Mac desktops so I suspect some sort of keybinding conflict unique to an Apple laptop default. I can recall this going back a few years, on older Intel macbooks and persists on modern M4 MacBook Pros. This may be a repeat of another feedback post but thought I'd bump it with this posting.

Ever since the first Emoji and PBR viewer versions came out the default Deja Vu font changed in the UI, resulting in the spacing around numbers basically missing now. As a Firestorm user stuck with a pre-PBR version due to the multitude of rendering issues in PBR builds I hadn't paid much attention to UI elements as the entire viewer was mostly only good to cause massive headaches. I have only realized recently that most of the "headache factor" in these new viewer versions is the missing spacing between numbers. As you can see in the screenshots below I have created a test notecard and opened it with Firestorm 6.6.14, Firestorm 7.1.12 and the latest SL Viewer release 7.1.12. The FS 6.6.14 screenshot shows what the font used to look like with decent spacing between numbers. As you can see letters and special characters appear with the exact same spacing still, but numbers have basically no spacing now, so a string of numbers regardless of its length becomes an unreadable soup. The asterisk is also smaller than it used to be for some reason, however that is obviously not a significant problem. This doesn't only exist in the notecard editor, the spacing from numbers is missing throughout the entire viewer UI. Chat, textboxes, address bar, landmarks, all UI floaters, everything. I have compared the DejaVuSans.ttf file to its original version and apparently it is the same. Then I replaced the file in the new viewers' fonts folders with the original file, but upon launching each viewer again, no change occurred, the spacing between numbers was still missing. (Switching fonts in preferences in Firestorm, restarting the viewer, switching back to Deja Vu and restarting again also didn't change anything.) Apparently the source of this is either hidden in a .xml file (however after spending some time searching for it, I couldn't find anything that would control this behavior) or it is somewhere in the viewer code. I don't know if I'm alone with this but for me this renders new viewer versions unusable if I can't read numbers. Getting a headache after about 2 minutes because of the missing spacing is not part of the normal user experience even in SL so I assume this is a bug. I would appreciate it if the normal spacing around numbers could be restored. Additional info: I figured out it is apparently the right side bearing that is missing or scaled down and only for numbers. Having each number's right side bearing set to 125% of its normal scale brings back the exact same spacing it used to be. This is not a good solution to the problem however as it can result in UI element glitches if certain texts on buttons, tabs or panels overflow because of the modified spacing. It does show however that the viewer doesn't ignore the bearing but rather scales it down for some reason.

I began with a fresh Avatar floater, fresh from a login. I filtered for "Tori" and got a complete list of the outfits with "Tori" in the name of the outfit or contents with "Tori" in the item name.: https://gyazo.com/5e829bdd1789d74865d31b83f48845b6 If I clear the textbox using the X tool at the right end of the box and type in "!L", the result will be the complete list of the 100 or so outfits including those characters in the name (or contents). If I then type over the text in the now yellow textbox (not clearing first with the X tool), typing "Tori" I get at subset of the complete list. A list containing only those items in the previously filtered list. https://gyazo.com/64c893f0eb2f1c56918d852b039f3226 This is an example of a case that is easily reproduced. However there are numerous cases I cannot explain. For example when starting with a new filter after clearing the textbox and not getting the complete list of known instances. [2025-03-29: in some cases when known items exist in outfits and are not found in the filter, relogging occasionally corrects the issue. However I've got 46 outfits that contain an item, none of which are found using the filter; even after multiple relogs.] This has also been occurring for months in previous releases of the SL viewer. I see the same failure scenario in a recent release of Firestorm.