Scripting Features

The midi_input event would allow objects in Second Life to react to MIDI signals in real-time. By introducing this event, creators and developers could integrate MIDI devices (such as keyboards, controllers, and sequencers) into their virtual creations, enabling a whole new level of interactivity and creativity. Event Parameters: channel (integer): The MIDI channel number (1–16), indicating the source channel for the MIDI signal. message_type (string): The type of MIDI message being received, such as NOTE_ON, NOTE_OFF, CONTROL_CHANGE, PROGRAM_CHANGE, etc. data1 (integer): The first data byte, which might represent a note number, controller ID, or program number, depending on the message type. data2 (integer): The second data byte, representing additional data like velocity, control value, or other relevant information. Benefits of the MIDI_INPUT Event Real-time Interactivity: This event would let objects in Second Life respond instantly to live MIDI input, making it ideal for performances or interactive installations where the environment needs to change in response to music or MIDI controllers. Enhanced Creativity: Creators would have the ability to control various aspects of objects—like animation, color, movement, and sound—based on MIDI input. This could be used to create dynamic, music-driven experiences or interactive art. Musical Integration: Musicians could perform live in Second Life and control animations, effects, and objects using their MIDI devices. This would make the platform more appealing for musicians, sound designers, and other artists working with music. New Possibilities for Interactive Content: The midi_input event would provide a new way for users to interact with their virtual world, allowing them to trigger changes in objects based on MIDI controllers or sequencers. This could be especially useful for game mechanics, virtual performances, or educational content. By adding the midi_input event, Second Life would gain a powerful tool for anyone working with music, sound, or interactive art. It would provide a seamless way to bring real-world MIDI control into the virtual world, offering more opportunities for creativity and interactivity. This would also open the doors for new LSL sound functions and features that would allow for things such as pitch bending, oscillators and pressure from our inputs from keyboards and MIDI controllers. The full list of paramiter options can be viewed in the attached image.

Hard coding link numbers into scripts is usually bad practice. So it's often best to search for something more concrete like the name of a linked prim and assign it to an integer using a loop by using llGetLinkName and comparing it to the link name you want to find. This isn't very friendly to new scripters who want to work with linked prims. A function that checks all of the prims in a linkset and finds the first instance of a specified link name would make scripts like this much easier. If I wanted to find the first instance of 'door left' in a linkset this could look like; llFindLinkNumber("door left");

With Lua becoming a thing on the viewer, having a way to directly communicate with a object or script would be nice. We do have game_control, and others have suggested midi. It'd be nice if we just had a general purpose "send a object / script some data as part of a ingest" or "send the viewer a message". For example, one of the major issues with RLV is that you have to "ask" the viewer in llOwnerSay, in which the viewer may or may not have RLV implementations. Asking it over a Script Message would be very useful. Or if you want to control more than just 6 axises. This provides a universal approach for developers to interface viewer side scripting with server side scripting. For example, I tried using my leap motion controller in Second Life using the new game_control messages: https://www.youtube.com/watch?v=wsmbyWWvQG8 A problem I encountered is I am limited to 6 axises. Being able to specify (N) number of data entries would allow me to add information such as finger positions/rotations as well, instead of just the palm position. Another example I did was a voice visualizer: https://www.youtube.com/watch?v=ytx-g2j-Y_Q Again, the limit of 6 axises limits what can be done here, being able to stream 8-bit bytes would reduce bandwidth, as well as let me specify additional frequency bins. This can very easily contain other types of user supplied information, such as midi notes, RLV commands, etc. A channel UUID might be useful, but that can also just be the first argument as a signature or something. I'm thinking along these lines: { ScriptMessage Medium ? NotTrusted Zerocoded { AgentData Single { AgentID LLUUID } { SessionID LLUUID } } { MessageTarget Single { TargetType U8 } // 0 = Script, 1 = Object, etc { Target LLUUID } } { MessageData Variable { Type U8 } // LSL Type { Data Variable 2 } // Binary data } } default { state_entry() { llMessageViewer(llGetOwner(), ["Hello, world!", llGetKey()]); } viewer_message(key agent, list params) { } } IN theory, this can be extended to avatars, say like having a target of type avatar and sending it there to allow script to script communication.

Now that we might have scripted agents chatting in group chats and IMs, it would great if we could do lookups on avatars that are not in the same region so that we can decide if we wish to interact with them. Currently the only way to get this information is via llGetAgentInfo() which requires the scripted agent to be in the same region.

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 ); } } } }

I full well understand why llEmail - which can be used to send emails to inside AND outside of SL - has a 20 seconds forced delay. However, when used only inside of SL, using the lsl.secondlife.com namespace for object-to-object communication, the delay seems excessive to me. llEmail is basically the only(!) way for object-to-object communication that is reliable over long periods of time without the need to cache ephemeral URI's like we need with llHTTPRequest, where the URI changes with each restart. llEmail used in conjunction with an object UUID will run come hell or high water. Making llEmail in the lsl.secondlife.com namespace run with the typical 2 second delay (or less even), would allow scripters to keep more communication inworld and rely less on external servers. /me waits for the bot to turn it to "tracked"

As of right now, if you want to test that someone is member of a group, you need this person to be actually wearing the group. Which is fine when dealing with vendors or fidelity. However there are scenario where you want to be able to test if a person is a member of a group without them actually wearing it. For example, accessing something or security or special functionality. In the same fashion as llSameGroup(uid) works, we should have a llHasGroup(uid) which would let you test if someone has the group even if not explicitly "wearing it".

This is a refiling of BUG-5307 New parameters which would further manipulate the texture displayed on the particle polygon. Note that the SCALE of the particle itself is still in effect. It is analogous to the scale of a prim. At the same time, the texture repeats/offset of this suggestion is analogous to the prim's face. They would interact in the same way which currently happens with textured prim faces. Static texture manipulation set: PSYS_SRC_TEXTURE_REPEATS : (vector) repeats. XY range +/-0.0 to +/-100 (Negative value flips, and Z is ignored) PSYS_SRC_TEXTURE_OFFSETS : (vector) offsets. XY range from -1.0 to 1.0 (Z is ignored) PSYS_SRC_TEXTURE_ROTATION : (float) rotation expressed in radians Static texture parms act like those which govern the texture repeats/offset/rotation on a prim's face. In essence, it would allow a particle's displayed texture to be a subset of a larger image file. Same limitations as with prim faces, see http://wiki.secondlife.com/wiki/PRIM_TEXTURE . Note that there are no start/end variations of these parameters because that would be better suited by supporting animated textures in particles. Animated textures have been suggested countless times before, but I'll briefly summarize them here (because I think under this implementation they would be very similar or related to what's proposed above). Animated texture manipulation set: `PSYS_SRC_ANIM_MODE: (integer) ANIM_ON | LOOP | REVERSE | PING_PONG | SMOOTH | ROTATE | SCALE PSYS_SRC_ANIM_SIZEX : (integer) horizontal frames. Ignored for ROTATE & SCALE `PSYS_SRC_ANIM_SIZEY: (integer) vertical frames. Ignored for ROTATe & SCALE PSYS_SRC_ANIM_START : (float) start position/frame number or radians for ROTATE PSYS_SRC_ANIM_LENGTH : (float) number of frames to display or radians for ROTATE PSYS_SRC_ANIM_RATE : (float) rate of frames per second This set largely resembles the existing texture animation function calls for prims, though without specifying any sort of face. See http://wiki.secondlife.com/wiki/LlSetTextureAnim . The animation mode parameter could accept the same flags used by llSetTextureAnim's mode parm. An important distinction to make: particles should not be synchronized, each burst's animation should play independently from the next. Alternatively, an additional PSYS_SRC_ANIM flag could be provided to toggle this behavior. This feature is important to me because it expands what can be possible with particle effects. Additionally, it removes the implicit restriction that particles cannot reuse textures that were not explicitly designed to be used as particles. At the same time, it also has the potential to significantly reduce asset server load by encouraging consolidation of particle textures into one asset. With this feature, users would be able to combine related images into a single asset and still allow different particle emitters to pick out unique looking texture data from that same asset. An experience within Second Life that uses multiple different particle textures could lump them into one asset and reduce the calls to the asset server to load them all. Even more interesting is the notion that these particle "sprite sheets" could themselves be subsets of an image file that includes other non-particle textures. For example, under this suggestion, a single texture could hold imagery for an experience's HUD, game pieces, and also particles. All within one asset!

This is a refiling of BUG-233266 A new PSYS_PART_FLAGS mask value that when set, would cause particles to be drawn on 2D planes that aren't locked to facing the viewer's camera. Instead, each particle would be given a random rotation to spin on at a constant rate throughout its lifetime. As the name implies, the intent is to mimic pieces of confetti tumbling randomly through the air. Ideally this would be compatible with most other existing particle parameters, perhaps with the exception of PSYS_PART_RIBBON_MASK. If the ribbon mask is set, it should probably override the confetti mask's effects. When combined with PSYS_PART_FOLLOW_VELOCITY_MASK, it may be interesting to limit the spin to occur around the particle's local Z axis, while still having the particle's "top" orient itself in the direction of movement. If this is too performance intensive, then it might be best to also ignore this mask when the confetti mask is set. Two additional PSYS_SRC_* parameters are optionally suggested to allow the user to specify a minimum and maximum speed at which the confetti particles will spin. I assume these would be ignored if PSYS_PART_CONFETTI_MASK is not set... unless others find it useful to be able to spin classic particles (since those always face the camera, they would in effect only be able to spin clockwise or counterclockwise). Setting spin speeds of 0 would be valid, causing the particles to not continuously spin, but sill have a random initial orientation at the time of their creation. PSYS_SRC_SPIN_SPEED_MIN : Specifies the minimum float value of a random range of values which is selected for each particle in a burst as its initial spin speed upon emission. PSYS_SRC_SPIN_SPEED_MAX : Specifies the maximum float value of a random range of values which is selected for each particle in a burst as its initial spin speed upon emission. I feel this could be useful to content creators as it expands upon the visual effects possible with particles. Just as interesting new effects were created with ribbon particles, I think it would be valuable to bring some of that semi 3D feel to be used with the other existing patterns without the constraint of joining the particles together as ribbon does.

This is a refiling of BUG-233175 I would like to propose a mechanism for users to modify and customize some of their agent's attributes including (but not necessarily limited to) the various movement speeds, jump height, and scale of the agent's physics shape. My initial thought is for a set of three functions: llSetAgentParams llGetAgentParams llResetAgentParams The setting of these agent parameters could behave similar to llSetAnimationOverride: where once an attribute is set, the customization will persist until explicitly overridden, reset, or the user logs off. Also like the animation override, this would require a new runtime permission: PERMISSION_CHANGE_AGENT_PARAMS Action: configure the overriding of default agent parameters Category: Agent Granter: Anyone Auto-granted when: Attached llSetAgentParams(list params) Sets the agent parameters specified in params. Survives script reset/removal, attachment removal, changing regions and teleporting - but not relog. Setting a zero/null/etc value is the same as resetting it to default. Invalid inputs cause the function to shout an error on DEBUG_CHANNEL. The function will still accept and act upon valid inputs that preceded the invalid one(similar to llSetPrimitiveParams). Requires new permission: PERMISSION_CHANGE_AGENT_PARAMS. [AGENT_WALK_SPEED, float speed] : Agent's walking speed [AGENT_RUN_SPEED, float speed] : Agent's running speed [AGENT_CRAWL_SPEED, float speed] : Agent's crouch-walking speed [AGENT_TURN_SPEED, float speed] : Agent's turning speed [AGENT_FLY_SPEED, float speed] : Agent's horizontal flight speed [AGENT_FLY_UP_SPEED, float speed] : Agent's hover-up speed [AGENT_FLY_DOWN_SPEED, float speed] : Agent's hover-down speed [AGENT_JUMP_SPEED, float speed] : Speed at which agent achieves apex of jump height [AGENT_JUMP_HEIGHT, float height] : Agent's vertical jump height [AGENT_STAND_PHYSICS_SIZE, vector size] : Scale applied agent's standing physics shape [AGENT_SIT_PHYSICS_SIZE, vector size] : Scale applied to agent's sitting physics shape [AGENT_GROUND_SIT_PHYSICS_SIZE, vector size] : Scale applied to agent's ground-sitting (ALT+Shift+S) physics shape Min/Max values up for discussion. I imagine minimum size would mimic prims; no single dimension being smaller than 0.010 meters. list llGetAgentParams([list params]) Essentially same as llGetPrimitiveParams. Only accepts the AGENT_* flags as listed above. Requires PERMISSION_CHANGE_AGENT_PARAMS. llResetAgentParams([params]) Reverts specified parameters back to their system defaults. Only accepts the AGENT_* flags as listed above. Additional param: AGENT_ALL_PARAMS as a shortcut to reset all (or alternatively: supplying an empty list?). Requires PERMISSION_CHANGE_AGENT_PARAMS. Since llSetAgentParams and the persistence of its effects are modeled after the llSetAnimationOverride functions, it would have similar (if not higher) potentials for abuse, given the fact that these would go beyond cosmetic changes and could impact user navigation throughout SL. For that reason, I also suggest some additional viewer/server components to go alongside with this feature as defined below. If there is still concern, perhaps adding a throttle to how many times attributes can successfully be changed in a given time frame (in which case having the set function return a status integer would be warranted). Or perhaps removing the auto-granting of the permission on attach - though Experiences should still function as normal. Additional viewer support functionality: A UI toast/popup that appears whenever an agent parameter is changed, similar to the ones that show whenever the avatar complexity changes. At minimum, this popup should have a clickable link to a knowledge base article that explains this feature - and most importantly, how to reset it. This toast/popup can also be disabled by the user in Preferences > Notifications. A new menu item " Avatar > Reset agent " to immediately reset all agent params and revoke PERMISSION_CHANGE_AGENT_PARAMS to any unattached objects in the same region (similar to " Avatar > Stop animations "). Also, a " Develop > Render Metadata > Agent Physics Shapes " would be useful for users to visualize the altered (and default) agent physics shapes. Additional land support functionality: A new land option which could disallow changing agent params and/or ignore custom params and only use agent defaults while within the parcel/region (similar to no-fly zones). This would be beneficial to established games which rely on using the agent's default attributes and would consider alterations cheating (similar to the prohibiting of user made movement enhancers). Also consider letting experiences still perform such overrides over allowed land. Justification moved to comments due to 5k character limit...