Scripting Features

  • Search existing ideas before submitting
  • Use support.secondlife.com for customer support issues
  • Keep posts on-topic
Thank you for your ideas!
Feature Request: Dynamic Audio Propagation & Adaptive Audio Physics for Second Life
I would like to propose the introduction of a Dynamic Audio Propagation and Adaptive Audio Physics system within Second Life's scripting capabilities. Second Life has evolved considerably over the years, with creators developing increasingly sophisticated environments, vehicles, combat systems, military simulations, roleplay experiences, and interactive communities. However, one area that could significantly improve immersion is environmental audio simulation. Currently, audio experiences are largely limited by conventional positional audio and distance-based attenuation. While these systems provide basic spatial awareness, they do not fully replicate how sound behaves in the physical world. Introducing advanced audio propagation through scripting would give creators the ability to develop environments where sound interacts dynamically with the surrounding world. The objective would be to make audio a physically responsive component of Second Life rather than simply an effect played at a particular location. Dynamic Environmental Audio Propagation The proposed system would allow scripted sounds to interact with environmental geometry and surrounding objects. Potential capabilities could include: Sound Occlusion: Walls, buildings, terrain, doors, and other solid objects would reduce or block sounds depending on their physical properties. Sound Attenuation: Audio volume would dynamically change based on distance, environmental obstructions, and surrounding structures. Sound Reflection: Interior environments could simulate basic sound reflections and reverberation. Sound Absorption: Different materials could influence how much sound is absorbed or reflected. Directional Audio: Sounds could originate from specific directions, allowing listeners to identify the approximate location of events. Environmental Reverberation: Large buildings, tunnels, hangars, underground facilities, and enclosed spaces could have distinctive acoustic characteristics. For example, a vehicle engine operating outside a hangar would sound noticeably different to someone standing inside the building compared to someone standing directly beside the vehicle. Likewise, gunfire occurring inside an enclosed structure would have different acoustic characteristics from gunfire occurring in an open field. Adaptive Audio Physics for Vehicles One of the biggest potential applications would be vehicle development. Second Life has an active vehicle development community, with creators producing everything from automobiles and motorcycles to aircraft, helicopters, naval vessels, and complex military vehicles. Dynamic audio propagation could substantially improve these experiences. Potential applications include: Engine sounds that dynamically attenuate based on distance and environmental obstructions. Aircraft engines that become progressively quieter as aircraft gain altitude or travel away. Helicopter rotor noise that can be heard across considerable distances, with appropriate environmental attenuation. Vehicle interiors that provide a different acoustic experience from the exterior. Engine sounds that are muffled when heard through vehicle body panels. Realistic reverberation when operating vehicles inside garages, tunnels, hangars, and enclosed facilities. Doppler effects for fast-moving vehicles. Directional exhaust and engine audio. This would allow vehicle creators to develop much more convincing audio experiences without having to rely entirely on complicated workarounds or multiple overlapping sound emitters. Applications Within the Second Life Military Community (SLMC) The Second Life Military Community (SLMC) is another area that could benefit tremendously from this functionality. Military communities frequently develop elaborate combat environments, military installations, training facilities, vehicles, weapons systems, and simulated battlefield experiences. Audio is an important component of situational awareness and immersion. Potential applications include: Combat Environments Gunfire that sounds different depending on whether it originates indoors or outdoors. Explosions that produce environmental reverberation. Muffled gunfire heard through building walls. Distant artillery and aircraft sounds with appropriate attenuation. Directional audio that allows participants to identify the general direction of incoming sounds. Different acoustic characteristics for enclosed rooms, corridors, and large industrial spaces. Military Vehicles Tank and armored vehicle engines that sound different from inside and outside the vehicle. Helicopter and aircraft audio that changes based on distance and environmental conditions. Interior vehicle audio that accounts for insulation and structural obstruction. Naval vessels with distinct interior and exterior acoustic environments. These additions would make military roleplay, organized operations, training exercises, and simulated combat environments significantly more immersive. Benefits to Other Second Life Communities Although military communities and vehicle developers would benefit substantially, this feature would have applications throughout Second Life. Roleplay Communities Cities, police departments, emergency services, hospitals, and other roleplay environments could implement realistic sirens, dispatch systems, public announcements, and environmental sounds. Entertainment and Events Concert venues, clubs, theaters, and live entertainment locations could benefit from improved acoustic environments, directional audio, and simulated room reverberation. Residential and Architectural Development Builders could create homes, offices, industrial facilities, and commercial environments with more realistic acoustic characteristics. Horror and Exploration Experiences Creators could use sound propagation to create suspense, environmental awareness, and more immersive exploration experiences. Aviation and Naval Communities Aircraft, airports, ships, ports, and other transportation environments could benefit from distance-based audio propagation, Doppler effects, and environmental acoustics. Proposed Scripting Functionality Ideally, this functionality would be exposed through new LSL scripting functions or an expanded audio API. For example, Linden Lab could consider introducing functions conceptually similar to: llSetSoundPropagation() – Enables or disables advanced environmental audio propagation. llSetSoundOcclusion() – Controls how surrounding geometry affects sound transmission. llSetSoundReverb() – Configures environmental reverberation. llSetSoundAbsorption() – Configures sound absorption characteristics. llSetSoundDoppler() – Enables or configures Doppler effects. llSetSoundAttenuation() – Configures advanced distance and obstruction-based attenuation. These are proposed function names, not existing LSL functions. Creators could potentially configure different audio profiles for individual objects, vehicles, buildings, and environmental systems. An additional possibility would be allowing objects to define acoustic properties such as: Concrete Metal Wood Glass Fabric Earth Water Insulated materials The viewer could then calculate how these surfaces affect audio propagation. Performance and Implementation Considerations I recognize that implementing advanced audio physics across a virtual world with potentially thousands of simultaneous users and objects would present technical challenges. However, this functionality could potentially be introduced through an optional, scalable system. Possible implementation approaches include: Client-side audio calculations to minimize simulator workload. Configurable audio propagation distances. Limited sound-ray calculations or simplified occlusion checks. Optional acoustic zones established by creators. Performance limits on the number of simultaneously simulated sound sources. Compatibility with existing LSL audio functions. Viewer-side controls allowing users to disable advanced audio processing if necessary. An incremental implementation would also be perfectly reasonable. Even basic sound occlusion, environmental reverberation, and improved distance attenuation would represent a substantial improvement. Why This Matters for the Future of Second Life Second Life is a platform where creators are constantly finding new ways to push the boundaries of what is possible through scripting, building, and user-generated content. Communities have developed sophisticated vehicle systems, combat frameworks, military organizations, interactive environments, and elaborate roleplay experiences. However, audio technology has considerable room for improvement compared to the complexity that creators are now achieving in other areas. Dynamic audio propagation would open the door to entirely new possibilities for content creation. It would allow creators to develop environments that not only look and function realistically but also sound realistic. This would benefit existing communities while potentially attracting new creators interested in simulation, vehicle development, architectural design, military roleplay, and immersive entertainment. My recommendation is that Linden Lab consider introducing an optional Dynamic Audio Propagation and Adaptive Audio Physics API as part of Second Life's future scripting development. This would be a meaningful expansion of LSL's capabilities and another step toward giving creators greater control over the virtual environments they build. Second Life has always been defined by what its residents can create. Giving those residents more advanced tools to simulate the world around them would only strengthen that philosophy.
0
Combat 2.1 Simplified Teams Spec
This is an intentionally separate request from the full Combat 2.1 Teams request at https://feedback.secondlife.com/scripting-features/p/combat-21-teams For a reduced/simplified API surface. We don't really need the entire draft spec that Rider came up with, the core items that we truly need are: integer llGetTeam(key task) llSetTeam(key task, integer team) list llGetTeamMemberList(integer team) llGetTeam returns the current team assigned to the AVATAR or the OBJECT. Default is 0. llSetTeam sets the team for the AVATAR or the OBJECT. It requires objects owner to own the land, deeded to group owned land or simply be set to that group (land management group). Otherwise any participant could switch teams mid-combat OR access special teams they might not be privy to. llGetTeamMemberList returns a list of AVATARS in the region assigned to that team. Teams are inherited from their rezzer (whether avatar or object). OBJECTS and AVATARS crossing a region neighbour can carry their team assignment with them into the next region. AVATARS teleporting into another region can carry their team assignment as well. Following in the footsteps of Combat2 and llDamage with damage type: "The goal is a coherent set of tools that lets residents create complex and compelling combat systems using a common and easy to use framework." -- Therefore like damage type, a team number can match a default TEAM_* constant or a custom integer. Additionally the field may be repurposed. TEAM_UNASSIGNED 0x0 TEAM_RED 0x1 TEAM_BLUE 0x2 Nice to have: REZ_TEAM for llRezObjectWithParams (llSetTeam-requirements, e.g. system generating NPCs/Vehicles assigned to teams) CHANGED_TEAM for changed event (object or avatar) Team configuration would be nice to have still of course but it is more optional, for HUDs and scripts to get the names and colours of a small set of configured teams per list llGetTeamDetails(integer team). If the object or avatar is assigned to a team number outside the team config range that is OK it might be a custom or repurposed number for a system, they just won't be able to have team details. llSetTeamDetails(integer team, list params) should exist and have same requirements as llSetTeam. Team config would be simplified as these two functions.
1
(Web)sockets
As a high-performant and modern alternative to the llHTTPRequest and llRequestURL , (web)sockets would be a great addition. It will allow objects and HUD elements to have direct bi-directional communication with back-end server software. The same can be achieved with the existing HTTP methods, but it requires a lot of effort to implement. The (web)sockets would have to be proxied through the Linden Labs servers just like the HTTP requests to avoid the leaking of IP addresses. If websockets are to be used, the benefit of HTTPS certificates exist for a secure connection. I am not requesting (web)sockets in the script to act as a server like llRequestURL , but for the script to always be the client to an external server (though feel free to implement that as well!). The functions could look like: key llSocketOpen( string url /*, Other options... */ ); llSocketSend( key id, string data ); // llSocketSend does not need a 'key' to return; packets identify themselves llSocketClose( key id ); The events could look like: socket_receive( key id, string body ) {} socket_close( key id, integer code ) {} // Code would follow the standard, but code '0' could be "closed by own script". There could be events for when the socket is opened or errors, too. In that case the llSocketOpen function can be non-blocking. Example code: key handler; default { state_entry() { handler = llSocketOpen( "wss://example.com:8081" ); llSocketSend( handler, "Hello world!" ); } socket_receive( key id, string body ) { if( id == handler ) { llSocketClose( id ); } } socket_close( key id, int code ) { if( id == handler ) { if( code == 0 ) { llSay( 0, "The socket was closed by us!" ); } elseif( code > 0 && code <= 99 ) { llSay( 0, "The socket was closed by the Linden proxy with code: "+ (string)code ); } else { llSay( 0, "the socket was closed by the remote server with code: "+ (string)code ); } } } }
5
·
tracked
Load More
→