Please fix BUG-8902 (from 2012) or explain why it was closed in 2024
tracked
Qie Niangao
Please see https://github.com/secondlife/jira-archive/issues/16470 for historical details, and forums post https://community.secondlife.com/forums/topic/524159-how-the-heck-did-this-get-fixed-in-2024%E2%80%94but-only-in-the-linden-viewer/#findComment-2926692 with background research by Henri Beauchamp (thanks, Henri!).
Log In
Maestro Linden
tracked
Hi Qie, the 'closed' state of the original issue in jira-archive is due to the repo being in an archived state. A copy of this issue is open in the SL server team's internal repository.
Qie Niangao
Maestro Linden Thanks. Bug Tracker Bingo is less fun than it sounds… for everybody, I realize.
Qie Niangao
[These parts don't seem to show up in the issue, so repeated with apologies to those for whom they're redundant]
Details *
Briefly, because there's much more detail available in the links above: upon server restart, the Linden plants that conform to terrain contours—grasses and a leafy ground cover—all revert to the default "grass - tall 1" which is species_id=0 in app_settings/grass.xml
If a decision has been made to not support these grasses properly, the assets should really be removed completely, including in-world, so they aren't subject to this bug. They were widely used by Moles and early Lindens in Mainland creation, and they have that unique terrain-fitting property. But checking their names, many were originally rezzed with other than the default species, so arguably those are "wrong" and have been ever since the first restart after they were rezzed.
Steps to Reproduce *
- Rez a Linden grass or ground cover other than "grass - tall 1"
1.5 Admire how the individual "tufts" conform to steep and rough terrain
- Restart the region
- Note that the grass now looks like "grass - tall 1" instead of whichever was rezzed
Henri Beauchamp
Qie Niangao
Rather than removing grass objects (which would definitely "break" (further) some scenery, especially on old main land), I suggested some options in my post on the forum (*):
Unless that bug gets fixed and all grass objects owners check and fix the species afterwards (to replace the corrupted grass objects with what they intended to get in the first place), Linden grass would be best restricted to species 0 from now on in SL, and the viewer-side code changed to cope (3). Alternatively, a partial (and one-shot only) server-side fix could be deployed (after the "attachment state resetting" bug is itself fixed, of course), that would consist in restoring the species Id based on the grass object name: the grass objects rezzed from the inventory Library do bear a non-default (non "Object") name that would allow to restore their species from it (4), but this won't fix any of the objects rezzed from the viewers (which all have a default "Object" name)...
.../...
(3) And maybe add a SL-specific render setting to let the user choose what type of grass they want to see rendered in SL, instead of the default type ?... Or perhaps add a hack to let that type become parcel-specifc, like what FS did in the past for Windlight environment settings via the parcel description text (for example with a ”[gN]” keyword, with N = grass species id) ?
(4) And before you ask, no, rendering the grass objects species based on their name via a hack in the viewers would not be a wise course of action: objects names are not transmitted in the ObjectUpdate messages, and the viewer must query the server for each object it wants to know the name about (this is done via selection manager calls), which is an asynchronous operation and would incur a higher UDP traffic with the server.
---