Scripting Features

The simulator has a built in function to 'autopilot' avatars to a given position, which many viewers implement. It allows an avatar to walk to a location without the user having to actively control the viewer. I think it would be nice to expose this functionality to scripts. It would be useful for wayfinding systems where a user is likely to get lost, freeing their hands to spend time looking around and orienting themselves. It would also make things like long walks with friends possible, as instead of needing our hands to control our avatar, we can be walking and talking on a set path. Since the functionality already exists server side and is battle tested by clients I imagine it can't be that big of a jump to add a script function to call it. Perhaps put it behind a permission such as PERMISSION_TAKE_CONTROLS to avoid abuse.

I would like to suggest a function to filter llDamage types either by rejecting or accepting the specific type wanted. Possibly functioning similar to llCollisionFilter As a suggestion llDamageFilter(integer type, integer accept); integer type - bit mask, DAMAGE_TYPE_* flags integer accept - TRUE only process types that match, FALSE instead excludes matches this would be useful to prevent unwanted script events for damage_types that we do not want to account for in code

The provisioned features and power of the game_control() event are impressive, and miles ahead of the support available to scripters for processing input events for standard keyboard+mouse usage. Currently there's no way to respond to other mouse buttons (scroll wheel, middle click, right click, shoulder buttons) and there are no vectors for user input aside from the standard movement keys. Thus if someone wants to make a game for users without a controller, they're limited to the interactivity of Quake 1, which is notable as being an aggressively minimalist design (shoot only, all doors open automatically) that was largely abandoned by other games. For SL to really work as a game environment, we need a way to bind a "use" key, or keys for reloading weapons, or for using special powers like a quick melee attack. I'd like to propose the following: - Adding 6 new mouse button bits to control(): scroll up, scroll down, mouse 2 (right), mouse 3 (middle), mouse 4 (shoulder 1), mouse 5 (shoulder 2) - Adding 4 new general-purpose control inputs to control(): action 1, action 2, action 3, action 4 - Adding the general-purpose action inputs to Preferences › Controls - Allow all control() bits to be mapped to controller buttons so vehicles without game_control() can be used with controllers and receive all the benefits of these new features — though this could/should be a feature request on its own The bitmasks for level and edge have plenty of room for these 10 new bits, so I don't think this is too crazy a request.

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".

A function to use left or right aligned hovertext. alignment < 0 results in left alignment alignment > 0 results in right alignment alignment = 0 results in centered alignment, equal to llSetText's behavior This could go along with three new constants: ALIGN_LEFT = -1 ALIGN_RIGHT = +1 ALIGN_CENTER = 0

Currently llGetAgentList() as an options parameter that is unused and the wiki warns of "possible stack/heap collision errors" because of the potential size of the returned list. This is like walking on a razors edge and sometimes forces us to use an extra script just to collect data of the parcel, with asynchronous message exchange with the main script, resulting in lots of complications just to try to avoid this. As already suggested in the wiki itself, there is room for improvement to limit the size of the returned list and hence the risk of stack/heap collisions. My first suggestion is of course to add an option to limit the size of the returned list: AGENTLIST_MAXNUM, with an integer value, 0 (no limit) being the default. Then an option to order the list is of course desirable: AGENTLIST_SORT, with an integer value: AGENTLIST_SORT_BYDISTANCE : sort agents by distance from the scripted object AGENTLIST_SORT_BYNAME : sort agents by (legacy) name AGENTLIST_SORT_BYAGE : sort them by age (to be completed) And an associated option to specify the sorting order: AGENTLIST_SORTINGORDER, with integer value: 0 (default) for ascending, 1 for descending order Other options to filter the list may also be useful: by minimum aga, by maximum age, by minimum distance, by maximum distance, by payment info .... (and possibly other filters).

I often switch back and forth between Firestorm and LL Viewer when helping customers with issues. I have found ways to be comfortable with either viewer BUT the limitation on LL viewer to not be able to derender a neighbor's way too low sky platform, a surround box that blocks my view of the water, or a random chair hanging in mid-air is very limiting. It seems a small thing but can make a huge difference when wanting to be comfortable on one's own mainland plot.

The function llCustomDialog works similar to llDialog function but allows creating more modern and fancy dialogs. key llCustomDialog(key avatar, string message, list buttons, integer channel, list options); The return value is not used at time. It can be used in future to identify open dialogs (and for example to let the viewer close it). The options parameter allows the scripter to control rendering and behavior of the dialog. I organized it in 3 categories. 1. Dialog symbol options A dialog symbol is a large symbol shown at the side of the text. The actual position and size of this symbol is up to the viewer. This option defines static dialog symbol: [CUSTOM_DIALOG_TYPE, key symbol] The symbol parameter is a key of the image to show as the dialog symbol. Additionally we can define key constants using pre-defined dialog symbols: CUSTOM_DIALOG_TYPE_CONFIRMATION, _INFORMATION, _ERROR, _WARNING, _OPEN, _TRANSFER. The types OPEN and TRANSFER are used to confirm opening of product boxes or transferring items to someone else (usual operations for vendors and product boxes). To animate a user-defined dialog symbol we use this option block: [CUSTOM_DIALOG_TYPE_ANIM, integer mode, integer sizex, integer sizey, float start, float length, float rate] The parameters are quite similar to the llSetTextureAnim so that we not need to describe them. When no CUSTOM_DIALOG_TYPE option is set, the dialog will show no symbol. When a predefined dialog symbol is used, the animation option is ignored. 2. Tab-stop option When I create dialogs I mostly want to provide some information and I'd like to make it look like a table. This option aims to acheive this: [CUSTOM_DIALOG_COLUMNS, string columns, integer softbreaks] The parameter columns is a comma-separated string of column definitions, as "<size><alignment><margin>". The size and margin are given either in pixels or in ratio to the size of the text area. When size is omitted, it dynamically adaptes to fit the content. The alignment is one of 'L', 'C', 'R' and is mandatory. Example: [CUSTOM_DIALOG_COLUMNS, "50 L, 0.75 L 5, C", FALSE] Here we define three columns and forbid softbreaks. How the dialog renders the text? When a text line contains "\t" characters, these segmentate the text line into columns. When a text segment is too large for staticly defined column, it continues in the next column. When softbreaks parameter is TRUE, a text segment which is too large for a column is broken in lines which remains in the same column. When softbreaks is FALSE, the dialog shows a horizontal scroll bar when the text is too wide. 3. Metaoptions These options define the behavior of the dialog and it's lifetime. [CUSTOM_DIALOG_LIFE, integer time] When time is positive, the viewer should clean the dialog away after the given time. The viewer may display the remaining time in the dialog window to warn the user. [CUSTOM_DIALOG_REPLACE, string response] When a dialog is replaced by an other dialog sent from the same device then the viewer should send the response string on the dialog channel to report this. [CUSTOM_DIALOG_IGNORE_BUTTON, integer hide, string response] This option allows to handle the ignore button. When hide = TRUE, then the ignore button is hidden, the response parameter is then ignored. When hide = FALSE, then the response parameter defines a string to be sent when the user presses the ignore button. This option allows scripts to recognize pressing of the ignore button or hide it when it uses a menu button for same purpose. 4. Button symbols This part is controlled by button names. The Idea: I'd like to show certain symbols together with the buttons text. Like this: "🔧 settings". One can do this by using Unicode characters in the button text but I'd suggest to define the symbols logically: The button name should start with the symbol enclosed into curly bracket: "{symbol}button name" The symbol name can be a Unicode character, e.g. "{🔧}settings", Texture key to use, Logical symbol name, e.g. "{CONFIG}settings". It is up to the viewer to choose the symbol, its size, position, and the distance to the button text. Note: When a button is pressed, the viewer will only send the button name but exclude the symbol definition. For example when button "{CONFIG}settings" is pressed, only "settings" is sent. This enforces the scripters to use button names the user will recognize even if the viewer not knows how to show the button symbols. Following symbol names should be defined: OK, CANCEL, ABORT, STOP, YES, NO, IGNORE, UNDO, REDO, RETRY, HELP, INFO, OPTIONS, CONFIG, WHITELIST, BLACKLIST, CLOSE, EXIT. The symbol names are strings, only known to the viewer. The server will not parse the button names for them. This list can be extended in future.

Myself and a few other creators recently have been talking about difficulties of proper camera controls, when avatars of any and all sizes sit on games, or in vehicles, etc. This makes finding the right camera angles very difficult, and often it has to be something where it's a one size may fit most, but not always all. A way to have a viewer recognize an LSL script and essentially hide an avatar from their own view on sit would be a huge help for better camera positioning and faux first person angles without having to focus in mouselook or work around avatars that may clip into the camera. This way, someone can still be viewed by others but the person themselves wouldn't have an obstructed or awkward camera angle to hide them. Possibly, it could also work to add it where it's a mix of "hide from self" and "hide from everyone". Once they stand up, it removes the temporary de-render/hide and they go back to being seen as is. A simple change like this would offer a unique amount of new options for builds and scripts that doesn't require a consideration of clipping, either within the object or with the camera, being an issue. Thanks!

Very simple request, a infinity constant. "INFINITY" { count(); yylval.fval = INFINITY; return(FP_CONSTANT); } Support for negative infinity is implied by doing -INFINITY