Scripting Features

  • Search existing ideas before submitting
  • Use support.secondlife.com for customer support issues
  • Keep posts on-topic
Thank you for your ideas!
Add the ability to set an avatar's hover height through a scripted command.
Several of the body vendors include scripts to change the shape of the foot to match the shoe being worn from flat footed to on tip-toes. But when the foot shape changes, the avatar is left hovering in the air, or sinking into the ground and the hover height needs to be manually changed to reflect the new food position. I suggest adding a new LSL command to alter the hover height of the avatar. Thus: llSetAgentHoverHeight(key Agent, float Distance) ( edit to add a key field to the command. Not surf if it would needed or not. but the the behavior that if the agent key is not also the owner key that the command is either ignored, or an error is shouted on the debug channel ) The distance can either be a fixed value, or a relative value based on the current hover value. Examples. When I stand barefoot, my hover height is "0.06" -- as shown on the "Avatar > Hover Height > Set Hover Height" slider. But when I'm wearing heels my hover height is "0.170" So the "llSetAgentHoverHeight" would either need to set the static values of 0.06, 0.170, and any other needed values for the shoes in question, or adding (+0.102) to the "current' value when putting on heels, and subtracting (-0.102) from the 'current' value when putting on flats. The actual values, either static or relative would need to be established either by the shoe maker, or the shoe wearer, depending on how the script maker decides best of course.
12
·

tracked

llLinkSetDataBytes/ llLinkSetDataBytesFound
note: I didn't set the title to "LinkSet" and I have no clue why it's doing that, considering it's "Linkset" in the editor! weird! This suggestion was brought up a year ago and closed a few days later. I think, with respect to Spidey & Lucia, it deserves a second crack with a more well-defined spec, because we are actually missing an important function here. Problem There is currently only one function that returns any useful data regarding the memory usage of the linkset datastore - llLinksetDataAvailable , which only returns the bytes remaining for the entire datastore. It is currently impossible to measure the bytes used by any specific pair(s) without either reading them and running a base64 count (expensive, risky) or deleting them and measuring the change in available bytes (pointless). This is a problem because there is no limit on the size of linkset data pairs. Unless you only have a single pair in the datastore, it is currently impossible to tell if the pair you are about to read will be too large and crash your script. To that end, it is trivial to come up with an extremely tiny script that creates a pair so big that it is practically guaranteed to crash any script that tries to read it. Nor is it difficult to imagine scenarios where this could occur unintentionally. This will become even more likely with Luau support as Lua scripts (and, AIUI, Luau-compiled LSL) will switch back from UTF-16 to UTF-8, changing how strings count against script memory and facilitating bigger pairs. Proposal llLinksetDataBytes( string name ) string name - The key of the linkset name:value pair to count the bytes of. Returns an integer with the number of bytes used by the pair (including its name and 32-byte passphrase hash, if used), or 0 if it does not exist. llLinksetDataBytesFound( string pattern ) string pattern - A regular expression describing which keys to sum the bytes used of. Returns an integer with the number of bytes used by all keys matched by the regex. The point of these function names is to avoid confusing them with counting length as opposed to bytes . Also, linkset data storage is not "memory" per se, so I don't think the previous suggestion of llLinksetDataMemoryFound is semantically correct. Use Cases llLinksetDataBytes can get the bytes used by a linkset data pair without needing an expensive, risky, or destructive workaround. This is a separate function from llLinksetDataBytesFound because LSL lacks a regex escape function (although it can be done manually, just inefficiently) so it is more efficient if you want to check a single pair immediately before reading it. llLinksetDataBytesFound allows you to measure all pairs matching a certain regex at once. For example, say you have two concurrent data schemas in a single object - some pairs start with "array" and are used for a large array-like structure, some start with "config" and store notecard values, whatever. Trying to actually measure the bytes used by either of these schemas individually is potentially memory-intensive and slow, even though we already have llLinksetDataFindKeys and llLinksetDataDeleteFound . The only current practical solution is to run the aforementioned base64 count on every value you write, modify, or delete, and maintain a byte total manually. Additionally, llLinksetDataBytesFound makes it possible to calculate the entire space available to the datastore (128kB as of this writing, though it was once already raised from 64kB). This is currently impossible because there is no function that returns the complement of llLinksetDataAvailable , nor is there a function that returns the entire capacity, à la llGetMemoryLimit . This function fills that gap without needing to provide a function to return what may well be a constant (but not guaranteed!) 131072 forever. Caveats It is possible that someone could consider the bytes used by a protected pair to be sensitive information that this function shouldn't disclose; however, since llLinksetDataAvailable can be used to do this already, the novelty of this risk would be negligible. Since the bytes within the linkset datastore are UTF-8 but get read into Mono-compiled scripts as UTF-16, the bytes reported will not exactly match the bytes the value would use once read, although any value is better than nothing. (This won't be a problem under Luau, and wasn't a problem under LSL-2, just Mono.)
0
Problem with Vsync and close all game
Hello. I am reporting a persistent and critical instability issue with the Second Life Viewer (this occurs on both the Official Linden Lab Viewer and Firestorm Viewer). The application experiences an immediate crash upon the very first launch after a system boot. The Viewer then runs completely stable on the second attempt without any system changes. This bug is consistently reproducible across different Viewer versions. This issue occurs on the following system configuration: Operating System : Windows 11 Pro 64-bit Processor AMD Ryzen 5 7600 Graphics Card : NVIDIA GeForce RTX 4060 NVIDIA Driver Version: 555.99 System RAM: 32 GB DDR5 Windows Power Plan: AMD Ryzen Balanced. To achieve any kind of stability upon initial launch, two specific workarounds must be applied simultaneously: VSync Must Be Disabled: Vertical Sync (VSync) must be explicitly DISABLED within the NVIDIA Control Panel for the Viewer application. Run as Administrator: The Viewer client must always be launched with Administrator privileges. All standard and advanced troubleshooting methods have been exhausted. The following critical tests confirm the issue is software-based: Hardware Stability Confirmed: Power Supply Unit (PSU) and GPU stability have been verified. The computer successfully passed a full 15-minute GPU stress test using FurMark (running at 100% usage, even with VSync on) without any system shutdown or crash. This rules out hardware failure (PSU/Overheating). Software Scope: The problem is confirmed to occur on the Official SL Viewer, Firestorm Viewer, and older Firestorm versions. Other Steps: All drivers/OS are updated, cache has been cleared multiple times, and various graphics debug settings (VRAM detection overrides) have been attempted without success.The issue appears to be rooted in the Viewer's core initialization process (likely VRAM allocation or system file access) during its initial cold start on this specific hardware configuration.I have included the Crash Logs from a failed first launch attempt. Please use this information, particularly the log files, to diagnose why the core Viewer code is unstable upon initial launch on a system running the NVIDIA RTX 4060. I didnt do picture. because dont show me only just close me all game and computer. i have that from one week, before did work normal and without problems. A rigorous, clean reinstallation of the NVIDIA drivers (using DDU) has been performed. Following this process, the complete computer shutdown issue has been resolved, but the game still crashes on the first launch attempt. I must use the workaround (Run as Administrator + VSync OFF) for stable operation. This definitively confirms that the bug lies deep within the Viewer's core code and requires your intervention. With close Vsync and I'm starting as an administrator game close too. close me again but after 3 h. i did try too take off my all avatar and wear old from firestorm but is same. i send one picture what show me after close game.
0
Load More