Open sl-service-account opened 3 years ago
Kyle Linden commented at 2021-02-11T17:48:38Z
Hello Contagious,
Will you please provide all of the information from Help > About Second Life in the Environment field. You may for example have older Intel GPU drivers and without these details we cannot verify if the issue is widespread or unique to specific hardware and software configurations.
Thanks!
Contagious Republic commented at 2021-02-16T17:21:25Z
The problem can be shown to be fixed via this script line: llSetPrimitiveParams([ PRIM_ALPHA_MODE, ALL_SIDES, PRIM_ALPHA_MODE_BLEND, 130 ]); // someone test a llGet version I guess? But other calls to the same function not dealing with PRIM_ALPHA_MODE will not cause the prims to be fixed because the prim already had ts alpha mode changed server side.
This is why I think once the viewer damaged the server-side prim, every viewer who looks at the prim (or a refresh of the prim, if they refresh lag) will see the problem permanently until the prim is manually or script-wise changed back(where permissions and patience with the bug allows).
P.S.: some people claim it only happens to mod prims, but I have seen 2 examples of no-mod prims so far. There may be several bugs that are similar but share some code quirks.
POSSIBLE BUG CAUSE (it's a hunch, someone with time on their hands test it?)
1- Someone creates a prim with an alpha mode that is other than PRIM_ALPHA_MODE_MASK, but sets a mask_cutoff value anyways even if only PRIM_ALPHA_MODE_MASK has an use for it. (PRIM_ALPHA_MODE_BLEND will break often. Set various values in the mask_cutoff using scripting in some prims to see if it makes a difference?)
2- Some over-optimized bit of (viewer?) code sees a mask_cutoff value has been set where it is not expected to need or have one (not even a zero), and decides to compact the data for efficiency — incorrectly. Or the data is just having an overflow-overwrite or blind-truncate-wrong due to data not fitting the space for it without optimisation intent being at cause. In any case, the changes become somehow saved server-side without going to edit mode with the prim (or probably, without going to edit mode at all? As a coder I'm always having a prim edited, lol).
3- in some cases, permission checks do not stop the bug. Suspected: prims rezzed at certain weeks affected, prims rezzed on other week unaffected, from the same no-mod merchant-obtained single object that was rezzed in the same sim at different weeks(alternate explanation: the first set was drag-copy damaged from the original prim, the other sets copied into inventory as a group and re-rezzed as a group, and somehow when the bug became visible weeks later that made a difference).
—
(my own computer)
Firestorm 6.4.12 (62831) Dec 3 2020 22:34:49 (64bit / SSE2) (Firestorm-Releasex64) with Havok support Release Notes
You are at 102.9, 118.3, 3,951.1 in Tortuga located at ec2-54-189-109-244.us-west-2.compute.amazonaws.com SLURL: http://maps.secondlife.com/secondlife/Tortuga/103/118/3951 (global coordinates 128,103.0, 259,190.0, 3,951.1) Second Life Server 2021-02-01.555570 Release Notes
CPU: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz (1995.37 MHz) Memory: 16283 MB OS Version: Microsoft Windows 8.1 64-bit (Build 9600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GT 750M/PCIe/SSE2 Graphics Card Memory: 2048 MB
Windows Graphics Driver Version: 25.21.14.1735 OpenGL Version: 4.6.0 NVIDIA 417.35
RestrainedLove API: RLV v3.3.3 / RLVa v2.3.0.62831 libcurl Version: libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.8 nghttp2/1.40.0 J2C Decoder Version: KDU v8.0.6 Audio Driver Version: FMOD Studio 2.01.05 Dullahan: 1.8.0.202007261348 CEF: 81.3.10+gb223419+chromium-81.0.4044.138 Chromium: 81.0.4044.138 LibVLC Version: 2.2.8 Voice Server Version: Vivox 4.10.0000.32327
Settings mode: Firestorm Viewer Skin: Firestorm (Grey) Window size: 1920x1017 px Font Used: Deja Vu (96 dpi) Font Size Adjustment: 0 pt UI Scaling: 1 Draw distance: 66 m Bandwidth: 500 kbit/s LOD factor: 2 Render quality: Medium (3/7) Advanced Lighting Model: No Texture memory: Dynamic (512 MB min / 10% Cache / 10% VRAM) VFS (cache) creation time (UTC): 2019-2-25T11:51:25 Built with MSVC version 1916 Packets Lost: 3,252/12,357,243 (0.0%) February 16 2021 07:59:32 SLT
P.S.: I expect this bug to be hell to repro and debug, but keep in mind it slows down sim decorating DRAMATICALLY and some paid-for items can no longer be trusted and have to be replaced (without knowing if replacement product will break) on a scale that may cause some people to stop paying for certain sims rather than fix them.
Kyle Linden commented at 2021-02-19T18:51:26Z
Hi Contagious,
Indeed this issue has proven very hard to reproduce historically. I am going to set this issue as Needs More Information and the second you see this happen again (a fresh occurrence) please reopen this BUG report and provide a SLurl to the object in world.
Then we can come inspect and check logs to see if we can catch how this happens.
Thanks!
priestesstwilight.xue commented at 2023-07-20T17:16:06Z
I suppose I could add to this I see this happen almost every time the sims restart on Tuesdays I live on mainland and I have essentially given up repairing them because I live in a forest and have so many plants to reset every time it happens I used black dragon viewer as well and here are my pc specs just updated Nvidia drivers two days ago as well
Black Dragon 6.6.9.50830 (64bit) 4.3.2 - Kneading Dragon Release Notes
You are at 136.8, 51.0, 33.6 in Garland located at simhost-0b6bcca505946177f.agni SLURL: http://maps.secondlife.com/secondlife/Garland/137/51/34 (global coordinates 465,801.0, 304,691.0, 33.6) Second Life Server 2023-06-09.580543 Release Notes
CPU: 11th Gen Intel(R) Core(TM) i9-11900K @ 3.50GHz (3503.99 MHz) Memory: 32597 MB OS Version: Microsoft Windows 10/11 64-bit (Build 22621.1992) Graphics Card Vendor: NVIDIA Corporation Graphics Card: NVIDIA GeForce RTX 3090/PCIe/SSE2
Windows Graphics Driver Version: 31.0.15.3667 OpenGL Version: 4.6.0 NVIDIA 536.67
Window size: 2560x1009 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 96m Bandwidth: 3000kbit/s LOD factor: 2 Deferred Rendering: Enabled Max Texture memory: 0MB
RestrainedLove API: RLV v3.3.3 / RLVa v2.3.0.50830 J2C Decoder Version: OpenJPEG: 1.5.1, Runtime: 1.5.1 Audio Driver Version: FMOD Studio 2.00.07 Dullahan: 1.12.4.202209142021 CEF: 91.1.21+g9dd45fe+chromium-91.0.4472.114 Chromium: 91.0.4472.114 LibVLC Version: 3.0.16 Voice Server Version: Vivox 4.10.0000.32327.5fc3fe7c.571099
Packets Lost: 0/50,163 (0.0%) July 20 2023 10:13:11
altcake commented at 2023-07-21T00:09:40Z
Hi, I know this is an older Jira, but I hope that by providing this SLURL it can help diagnose the problem
http://maps.secondlife.com/secondlife/Arang/9/73/88
The little plants on the ground in this area were affected by this bug and the plants in this area tend to do it after simulator restarts.
Here is my help about second life:
Alchemy Project PBR 7.0.2107 (64bit) Release Notes
You are at 8.7, 72.5, 87.7 in Arang located at simhost-0ee637a191646716c.agni SLURL: http://maps.secondlife.com/secondlife/Arang/9/73/88 (global coordinates 261,385.0, 230,985.0, 87.7) Second Life Server 2023-06-09.580543 Release Notes
CPU: AMD Ryzen 7 1800X Eight-Core Processor (3593.25 MHz) Memory: 65447 MB Concurrency: 16 OS Version: Microsoft Windows 11 64-bit (Build 22621.1992) Graphics Card Vendor: NVIDIA Corporation Graphics Card: NVIDIA GeForce GTX 1080/PCIe/SSE2
Windows Graphics Driver Version: 31.0.15.3623 OpenGL Version: 4.6.0 NVIDIA 536.23
Window size: 1920x1009 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 64m Bandwidth: 6000kbit/s LOD factor: 4 Render quality: 5 Advanced Lighting Model: Enabled Texture memory: 8073MB Texture cache: 1233MB / 1310MB (94.1% used) Disk cache: 3851MB / 4096MB (94.0% used)
RestrainedLove API: RLV v3.4.3 / RLVa v2.4.2.0 libcurl Version: libcurl/7.54.1 OpenSSL/1.1.1u zlib/1.2.13.zlib-ng WinIDN nghttp2/1.52.0 J2C Decoder Version: OpenJPEG Runtime: 2.4.0 Audio Driver Version: FMOD Studio 2.02.14 Dullahan: 1.12.4 CEF: 107.1.7+g59a795c+chromium-107.0.5304.88 Chromium: 107.0.5304.88 LibVLC Version: 3.0.18 Voice Server Version: Vivox 4.10.0000.32327.5fc3fe7c.571099
Compiler Version: MSVC 193632535 Packets Lost: 534/213,045 (0.3%) July 20 2023 17:09:22
priestesstwilight.xue commented at 2023-07-30T05:41:09Z
I have had this issue happen again and this time its basically destroyed my entire forest it will take literally hours to replace every single plant as all of them have all simutaniasly broken i after I teleported home today. please figure out what this is because at this rate why do i even pay for land if my entire forest is going to break constantly im about ready to cancel my land and premium because i can't have a nice home when it is breaking every other day my entire home and my neighbors home wich i decorated are ruined because of this bug i am attaching tons of images of all of the work i have done that is now broken becuase of the bug hours and hours worth of work has to now be redone days even
What just happened?
Plants (or generally = prims with intended transparency in the texture) that were alpha mode= blending became alpha mode= masking or alpha mode= none and became fully nontrasparent so they are ugly rectangles as a result.
~~Bug appearsed approx 4 weeks ago according to some, and while a stable repro is maddeningly difficult, encountering the bug when NOT trying to repro it and just build or rez bought plants the bug is seen a LOT. -Problem only affects some plants not others despite being the same plant in the same sim with the same viewer, but only one quarter of the sim was affected because maybe rez date matters? -Alpha mode change can become none, but also can become masked. Neither is what the creator intended. -Much tested -~~- no other settings change. -Multiple no mod items bought from various creators (who are not in the sim) are affected, so it's not a case of people having the https://jira.secondlife.com/browse/BUG-11333 or https://jira.secondlife.com/browse/BUG-8715 bug where mod permission having people just hanging around change the prim property on the prim (for everyone present to see irrespective of viewer) by their mere inactive presence. -While BUG-216116 is similar, this appears on non-bakes-on-mesh nonworn mesh or sculpts as well. I have not seen it on regular prims yet, but perhaps because no one builds much transparent with them anymore? -Fixing or changing sim or viewer versions won't help already broken no-mod prims and they'll have to be re-rezzed from no-mod original prim (and perhaps that will break again later)
What were you doing when it happened?
walking in http://maps.secondlife.com/secondlife/Tortuga/216/83/17
seeing plants being blocky rectangles with transparency previously present (with same viewer version) in mod and no-mod plants alike.
We have many plants in tortuga, look around, you'll find some that break not only in that specific area of the sim.
What were you expecting to happen instead?
Alpha mode should not randomly change from alpha blending to none (or vice versa) without manual editing by the object owner or those with object rights or using scripts.
Very clearly for everyone to see, these settings change on certain no-mod objects while other no-mod objects that are the same but rezzed on a different week in the same sim using the same viewer (and seen by the same viewer) can be unaffected.
Other information
WORKAROUNDS:
1- Creators can keep their object transparent by setting transparency value to 1 in SL, so that bug-caused change from the creator's alpha mode choice to "masked" does not remove transparency. (it won't help if the bug changes the alpha mode to none, it will still be broken).
2- rez time of the prim might matter, so if you can easily do so, re rez. Or re rez only half and tell us of the results. (re-rez methods to try: drag-copy, take in inventory and rez again, and use a prim copy script on full perm objects to obtain a prim whose creation date or first rez date is different).
3- Get latest viewer, which may help avoiding breaking mod prims in some OTHER variants of this bug which apparently does not break no-mod prims. You'll still get THIS bug, tho.
Attachments
Links
Related
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-230211 | | Summary | Alpha mode changes to and from several settings, even in no mod objects | | Type | Bug | | Priority | Unset | | Status | Needs More Info | | Resolution | Unresolved | | Reporter | Contagious Republic (contagious.republic) | | Created at | 2021-02-11T12:51:09Z | | Updated at | 2023-07-30T05:41:09Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2021-02-11T11:48:38.340-0600', "Is there anything you'd like to add?": 'WORKAROUNDS:\r\n\r\n1- Creators can keep their object transparent by setting transparency value to 1 in SL, so that bug-caused change from the creator\'s alpha mode choice to "masked" does not remove transparency. (it won\'t help if the bug changes the alpha mode to none, it will still be broken).\r\n\r\n2- rez time of the prim might matter, so if you can easily do so, re rez. Or re rez only half and tell us of the results. (re-rez methods to try: drag-copy, take in inventory and rez again, and use a prim copy script on full perm objects to obtain a prim whose creation date or first rez date is different).\r\n\r\n3- Get latest viewer, which may help avoiding breaking mod prims in some OTHER variants of this bug which apparently does not break no-mod prims. You\'ll still get THIS bug, tho.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': "Plants (or generally = prims with intended transparency in the texture) that were alpha mode= blending became alpha mode= masking or alpha mode= none and became fully nontrasparent so they are ugly rectangles as a result.\r\n\r\n-Bug appearsed approx 4 weeks ago according to some, and while a stable repro is maddeningly difficult, encountering the bug when NOT trying to repro it and just build or rez bought plants the bug is seen a LOT.\r\n-Problem only affects some plants not others despite being the same plant in the same sim with the same viewer, but only one quarter of the sim was affected because maybe rez date matters?\r\n-Alpha mode change can become none, but also can become masked. Neither is what the creator intended.\r\n-Much tested --- no other settings change.\r\n-Multiple no mod items bought from various creators (who are not in the sim) are affected, so it's not a case of people having the https://jira.secondlife.com/browse/BUG-11333 or https://jira.secondlife.com/browse/BUG-8715 bug where mod permission having people just hanging around change the prim property on the prim (for everyone present to see irrespective of viewer) by their mere inactive presence.\r\n-While BUG-216116 is similar, this appears on non-bakes-on-mesh nonworn mesh or sculpts as well. I have not seen it on regular prims yet, but perhaps because no one builds much transparent with them anymore?\r\n-Fixing or changing sim or viewer versions won't help already broken no-mod prims and they'll have to be re-rezzed from no-mod original prim (and perhaps that will break again later)", 'What were you doing when it happened?': "walking in http://maps.secondlife.com/secondlife/Tortuga/216/83/17\r\n\r\nseeing plants being blocky rectangles with transparency previously present (with same viewer version) in mod and no-mod plants alike.\r\n\r\nWe have many plants in tortuga, look around, you'll find some that break not only in that specific area of the sim.\r\n", 'What were you expecting to happen instead?': 'Alpha mode should not randomly change from alpha blending to none (or vice versa) without manual editing by the object owner or those with object rights or using scripts.\r\n\r\nVery clearly for everyone to see, these settings change on certain no-mod objects while other no-mod objects that are the same but rezzed on a different week in the same sim using the same viewer (and seen by the same viewer) can be unaffected.', } ```