🪰 Viewer Bug Reports

I tried several uploads, the only option for me to make portals like this is to make it phantom. Even when uploading the correct physics, its not working. I even tried to resize its size (it used to be an old bug) but it didn't work either. https://gyazo.com/587026e3a7c56e7a5d71baa5d47bafbd https://gyazo.com/6a6252c954a7c14d18925e1b90c89ea6 https://gyazo.com/ef1e460582168c4c4b4de9874e679113 https://gyazo.com/b60638204aea83db2edc56c3d7d6246e the uploaded physics https://gyazo.com/1330d6c54d86cf1927d5165178aaaf3e

Single stray flash observed at initial emission when PSYS_PART_FOLLOW_SRC_MASK flag is set, and the PSYS_SRC_BURST_RADIUS rule is therefore disabled, i.e. zero, as per the wiki, no matter whatever value is found in this latter parameter. Perfect coding practise would see the radius explicitly set to zero, but in the event that the the value has been left non-zero and simply relied upon as being disabled, there is a single emission at initial burst which results in a flash at a distance of the radius set. When a timer is running this will occur once at each tick of the timer. Ideally, the radius should indeed be set to zero, which removes the problem, but as the radius value is disabled for the case where the PSYS_PART_FOLLOW_SRC_MASK is set, and correctly does so generally, the initial flash emission should not be happening either and is likely causing visual glitches in-world. To Repro : Drop a simple particle emission into a prim such as: default { state_entry() { llSetTimerEvent(0.25); } timer() { llLinkParticleSystem(LINK_THIS, [ PSYS_PART_FLAGS, 0 | PSYS_PART_EMISSIVE_MASK | PSYS_PART_INTERP_COLOR_MASK | PSYS_PART_INTERP_SCALE_MASK | PSYS_PART_FOLLOW_SRC_MASK | PSYS_PART_FOLLOW_VELOCITY_MASK, PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_EXPLODE, PSYS_PART_MAX_AGE,0.5, PSYS_PART_START_COLOR,<1.0, 1.0, 1.0>, PSYS_PART_END_COLOR,<1.0, 1.0, 1.0>, PSYS_PART_START_SCALE,<0.5, 0.5, 1.0>, PSYS_PART_END_SCALE,<0.8, 0.8, 1.0>, PSYS_SRC_BURST_RATE,0.1, PSYS_SRC_ACCEL,<0.0, 0.0, 0.0>, PSYS_SRC_BURST_PART_COUNT,1, PSYS_SRC_BURST_RADIUS,0.5, PSYS_SRC_BURST_SPEED_MIN,0.1, PSYS_SRC_BURST_SPEED_MAX,0.2, PSYS_SRC_TARGET_KEY,(key)"", PSYS_SRC_INNERANGLE,0, PSYS_SRC_OUTERANGLE,0.5, PSYS_SRC_OMEGA,<0.0, 0.0, 0.0>, PSYS_SRC_MAX_AGE,0.00, PSYS_SRC_TEXTURE, "dcab6cc4-172f-e30d-b1d0-f558446f20d4", PSYS_PART_START_ALPHA,1.0, PSYS_PART_END_ALPHA,0.0, PSYS_PART_START_GLOW,0.0, PSYS_PART_END_GLOW,0.0 ]); } } Observe the stray emission at each tick of the timer: https://gyazo.com/5f8a6b9a8e4c5a657d3d3d0aaa13ce36 Set PSYS_SRC_BURST_RADIUS = 0.0 Observe correct behaviour https://gyazo.com/1a5612c42c44afb0f50ec06b79fe262d

Noticed today in a room full of animesh characters, the closest to my camera and lowest complexity character had the highest ranking and was impostored. This hasn't been an issue since the Animesh beta period in 2018. This does not affect user impostor ranking as that is still based on closest to camera order.

I present the same model (a small avatar accessory) with 2 different sets of LOD models. In each case the lowest LOD model has been 'zeroed out' to 18 tris as is typical in this use case. Triangle counts are as follows. * Model 1 - High 63040 (36k virts), Med 15760, Low 3940 * Model 2 - High 15760 (10k virts), Med 3940, Low 3940 Both of these models are visually indistinguishable in use. The DAE files prior to upload are sized as follows. * 63040 tris - 9.2mb * 15760 tris - 2.2mb * 3940 tris - 500kb Working on the dae sizes alone ... * Model 1 - 11.9mb * Model 2 - 4.9mb However .... * Model 1 - Download weight 0.7 * Model 2 - Download weight 3.1 When worn ARC is equally broken (as reported in firestorm) * Model 1 - ARC 319 * Model 2 - ARC 672 Objectively Model 2 is better for performance. Duplicating the mesh for 2 detail levels is punished to the point that using a sub division surface modifier to generate an insane 63k tris high model results in 'better consumer numbers' at intended object scale (it's also cheaper to upload). In addition to model duplication being unnecessarily punished, the scale component of Li accounting is fundamentally flawed and pushes creators into a situation where large items need to be low poly and tiny (often worn) items are best high poly! No wonder everyone's avatar is solid in wire-frame. This model is a small avatar accessory. Obviously the example mesh is over detailed, 'unoptimized' and created using techniques best suited to slow rendered content rather than real time. The point is why should anyone bother with 'low poly' when this gets the-job-done and is predictably rewarded.

Made the switch yesterday to the Firestorm PBR . The water, eesh. Everything I have under the water is visible whereas before it just blended under. Like one of those teal colors to make the water look tropical, it just is so prominent from above. I can turn off translucent water but then I dont see them at all. Is there a setting im missing that can blend the stuff underwater like the older versions? Its blotchy and in your face and from a distance the water looks very glitchy. The loading screen is PBR (I know it says to download the latest version, but this was after I re-installed the older version, with the PBR still in the cache. The other screen is prior to the PBR install.

Unlike everywhere else in the UI, in item descriptions, the server is not treating Enter/Return usage as inputting, but as an attempt to insert a carriage/line return character. This repros in user inventory, rezzed object inventory and attachment inventory. Repros on SLV and FS.

FIX EEP, Mainland environment cycle are way too dark, see my forum post https://community.secondlife.com/forums/topic/428374-environmental-enhancement-project-aka-eep-feedback-thread/page/41/#findComment-2861867

This is happening more frequently in the past couple of days. When I log in on the Linden viewer, I find myself inworld. I can see group notices, my inventory, local chat window, friends list, and SURL location bar. But I can't see my inworld surroundings because it's stuck on the login screen. The login screen didn't go away when I teleported to another sim/region. My alts have experienced this bug too. Screenshot is enclosed.

upon initial log in after installing the block list is fine block list is empty upon a new log in every log in after that the block list remains empty even after adding avatars to the block list again after clearing cache block list comes back but empties once relogging and letting inventory load completely also happens on the latest firestorm release edit: cannot update to add photo of empty block list

The flyout button control still uses the old 3D-style textures and did not yet get updated with the flat design update. The button is currently used in panel_snapshot_local.xml - see attached screenshot.