Scripting Features

Simple one this. Add a new flag to the llGiveAgentInventory command: [TRANSFER_IMG,key] This would allow a folder to be given with a pre-determined folder image. That would be great for unpacker huds as typically used in clothes purchases. Shops that used this would be giving a useful service to customers and the servers wouldn't have to store a unique image for each person updating that folder with their own folder images.

What I want is a region-wide datastore, a very simple API like llLinksetData*. It is not required to be persistent -- scripters could reinitialise it on region restarts. It's ok if it's attached to an object (and therefore acts like a remote llLinksetData). It needs to support high read and high write usage and be synchronous. The usecase is for sharing data between objects at a higher level of abstraction. For example large region projects like games, weather systems, procedural life like pedestrians and cars / NPCs, etc. For example a game would often need to share a lot of data between scripted objects, such as vehicles, players, interactive objects, HUDs and temp attach objects. This often means the data also needs to shared across different objects of different ownership or active group settings securely. The security should be tied to a "project" (RSA keys, passwords and/or pins) or even experience compiled scripts. If the datastore is tied to an object or an avatar maybe all you need to know is the objects or avatar key and a script compiled to an experience to access and read from that region-wide datastore tied to that object or avatar. (E.g. like having a "mana" resource on an avatar and being able to actively manipulate that resource for passive mana regeneration or active/maintained spells from rezzed objects, HUDs or across multiple attachments, e.g. a wand that casts spells which drains the mana and a hud that shows current mana and has passive mana regen) Sometimes higher level of abstractions are needed for projects, such as a game manager that controls the overall state of a game and information such as who the players are and on what team they are / what teams there are, as well as objectives and resources. You should be able to make many of these region-wide datastores as you need in a project. Maybe several game managers/directors. Maybe one per avatar. Maybe one per major game object. Same limit of 128KB of LSD per datastore would be fine. Note that Experience Persistent Storage completely fails the above criteria: It's not high write / high read (I think it would be a bad idea to massively spam exp storage with fast timer reads to make sure to show an updated value on a HUD; What about small constantly changing updates like position, acceleration that may need to update at a very high frequency and be read immediately?) It is not fast / synchronous (how am I supposed to read/write a resource changing at milliseconds by multiple objects in a realtime game? Exp would keep accidentally overwriting values at critical moments as realtime games have action happen in bursts) It is an external server instead of in-memory (there is no reason for this complexity, latency and storage, I just wanted to share critical data (0.5-128KB) between objects in the same region or at least direct neighbouring regions/estate) Nice to have: Datastore being able to optionally/opt-in work cross-region or Estate-level / direct neighbours or 1-2 regions away, e.g. 3 regions in a line or a 2x2 square, just like how some data can be shared across region borders like llGetObjectDetails. This also avoids users having to create overly complicated/engineered systems of scripts to synchronise data between regions if they are all part of the same game/experience

I feel this has to have been discussed before.... but can we get a version of llGetTimestamp() that returns SLT so we're not reduced to adding 70+ lines of code and the associated overhead just to get the same timestamp that's showing up in every viewer?

Add the ability to receive input from game controllers such as joysticks, Xbox controllers, etc. This will allow the creation ofhHelicopters and planes that use analog input from console controllers, attachments that control drones, arcade games, cranes, machinima puppetry, etc. This new feature will be implemented by adding a LSL event game_control(...) which script authors can use to capture and respond to input from users. For further details, see https://wiki.secondlife.com/wiki/Game_control

I'm not 100% sure of the implementation, but maybe something similar to llSetAnimationOverride: First off, you need to request a permission such as llRequestPermissions(target, PERMISSION_CONTROL_PLAYER) llSetPlayerController(list params) Where params is a list of PLAYER_CONTROL_* followed by data. Suggested PLAYER_CONTROL_* settings: PLAYER_CONTROL_JUMP_HEIGHT, (float)percent - Modifies the current jump height by percent. Some upper limit could be added. 0 would disable jumping entirely. This would be useful because the default jump height is so unrealistically high that most games end up disabling jumping altogether. PLAYER_CONTROL_RUN_SPEED, (float)percent - Modifies the base run speed by a percentage. Some upper limit could be added, 0 disables running. PLAYER_CONTROL_WALK_SPEED, (float)percent - Modifies the base walk speed by a percentage. 0 could disable walking entirely. An upper limit could be set. These two would be useful for games and roleplays where a player could get a temporary speed boost, or perhaps slow players down while carrying heavy objects. The one concern I can think of is running/walking animations going out of sync, but that would be up to the dev to supply appropriate animations. PLAYER_CONTROL_CLIMB_RADIUS, (float)radians - Modifies how steep inclines the player can walk up. This would be useful because right if there's just a minuscule incline to a wall, players can walk right up it. The angle players can walk up in SL is very small.

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!

Particle system sorely need an overhaul and additional settings to make the best use of it. I've broken up a list of features to make tracking for each one easier for the devs. Texture Animation for ParticleSystem Easing Interpolation for ParticleSystem Alpha blend mask mode for ParticleSystem Color Noise for ParticleSystem Reverse Target for ParticleSystem Emissive Interpolation for ParticleSystem Select Sprite for ParticleSystem Offset Position for ParticleSystem PBR for ParticleSystem "MID_" Flags for ParticleSystem Follow a chosen attachment point

There are many animations out there which were uploaded with a low / default priority. These are fine provided other overlayed animations running at the same time don't override their actions. It would be useful to be able to change that priority when starting the animation. eg: llStartAnimationPriority("animation", 6);

Since texture transforms aren't part of the PBR asset, we can't just use the "" hack in llSetLinkPrimitiveParamsFast(...) to preserve their values. Instead we need to record the transforms (offset/repeats/rotation) for each face and reapply them with the new alpha value. A function like llSetLinkPBRAlpha() would be very much appreciated. Coming to think if it, most use cases (except for fading) could actually be addressed by having something like llLinkVisible(LINK_THIS, ALL_SIDES, TRUE) - llLinkVisible(LINK_THIS, ALL_SIDES, FALSE) - taking the usual LINK_* constants and face numbers.

Something I've had issues with is making stuff that communicates with other stuff easily configurable. It'd be nice if we could utilize build tools in conjunction with LSL to do this. The simulator is already aware of what is selected, so it shouldn't be too difficult to expose it via LSL. Think of the following: I make two teleporters, instead of going through making the resident copy UUIDs or set up channels, they can just select the two teleporters then do /1234 link and they are linked automatically. Ideally, it would return a list of objects (up to a limit, I'm aware large amounts of objects can be selected at once, enough to cause a stack heap collision), with the first entry being the last object someone selected, and the last being the first selected. As for the function signature, maybe something like llGetSelectedList(key agent, list options) . Might want to put it behind some sort of permission though if it is someone other than owner. Might be useful to have a singular llIsSelectedBy(key agent); as well, to avoid having to do loops / list index checking in timers / events.