Scripting Features

  • Search existing ideas before submitting
  • Use support.secondlife.com for customer support issues
  • Keep posts on-topic
Thank you for your ideas!
Updates to Particle System (Increased Particle Size. Parameter Curves. Modulate Bounce and Wind)
Suggestions to address four particular issues I have repeatedly come up against during extensive work with this system over many years. I am aware of another extensive Canny concerning improvements to the Particle System and support those too, so I have tried not to duplicate too much of that here. ISSUE 1 : Increase in maximum particle size Currently this is 4 metres, but if large scale world effects such as volcano exhaust or storm formations are needed, this creates unpleasant granulated effects with excessive particle count (see the ocean storm in the Dannielles region for just one example, or many of SL's volcanoes) I would like to see a maximum size of perhaps 20 metres for PSYS_PART_START_SCALE and PSYS_PART_END_SCALE. ------------------------------------------ ISSUE 2 : A means of better controlling certain particle parameters between start and endpoint to adjust behaviour during their lifetime. This would avoid situations when, for example, you need particles invisible at both ends of their existence and have to 'fudge' things with alpha and scale or dropping sprites into the ground One idea is additional tracking points along the lifetime curve of certain parameters between START and END. At the very least a MID point so particle parameters can be zero at both beginning and end with a peak in the middle for the following : PSYS_PART_MID_ALPHA PSYS_PART_MID_SCALE PSYS_PART_MID_SPEED PSYS_PART_MID_GLOW As an extension, perhaps also a means of setting a function curve flag to define the motion over the parameters lifetime so you can tailor the way the parameter behaves between START and END points with a maximum excursion at MID for appropriate functions such as parabolic curves PSYS_SRC_PART_FUNC_LINEAR_MASK; (what we have now in effect ) PSYS_SRC_PART_FUNC_LOGARITHMIC_MASK; (what we have now but log curve ) PSYS_SRC_PART_FUNC_TRIANGLE_MASK; ( linear up/down or down/up ) PSYS_SRC_PART_FUNC_QUADRATIC_MASK; ( parabolic curve up/down or down/up) PSYS_SRC_PART_FUNC_GAUSSIAN_MASK; ( bell curve up/down or down/up PSYS_SRC_PART_FUNC_EXPONENTIAL_MASK; ( sharp increase, or decrease curve ) (not an exhaustive list) ------------------------------------------ ISSUE 3 : Modulate influence and position of particle bounce Bounce is very situational in its usage, it can only really be influenced indirectly by velocity, acceleration and emission angles, and is limited by having a fixed bounce plane at the emitter altitude Would like to see : PSYS_PART_BOUNCE_OFFSET : a FLOAT value for offset in z-axis relative to the emitter defining the plane where particles will bounce PSYS_PART_BOUNCE_FACTOR : which is a simple FLOAT value 0 to 1 to influence the degree of bounciness (restitution) as presently applied on impact Or perhaps more interestingly, rather than a simple bounce factor the particle could have a full set of FLOAT value physical parameters like a prim, but I am not sure how the system treats them to allow this. PSYS_PART_BOUNCE_GRAVITY PSYS_PART_BOUNCE_FRICTION PSYS_PART_BOUNCE_DENSITY PSYS_PART_BOUNCE_RESTITUTION ------------------------------------------ ISSUE 4 : Modulate influence of SL wind Wind on/off is rather unsatisfactory as it stands because in extreme cases it can unexpectedly create effects like smoke particles streaming crazily out in a horizontal line, dependent on SL wind. It would be desirable to have a limiting parameter to control the magnitude of influence of SL wind such as : PSYS_PART_WIND_FACTOR where the parameter is a FLOAT value defining amount of influence of SL wind on a scale between 0 and 1
2
Give Estate Managers/Sim Owners the Ability to Set RezObject Delay
This request is to grant estate managers (EM) and sim owners the ability to change the rez delay from the standard 0.1 second delay via the region settings. This delay is currently built into the following functions. llRezObjectWithParams llRezAtRoot llRezObject This proposal is to grant EM the ability to change this delay by either increasing or decreasing it as needed. And if possible the option to specify the delay from attachments, or rezzing from objects that are already out. This request comes from the current requirement in combat role play communities, where to achieve a higher cyclic rate than what the current script can handle with one of the above mentioned Rez Functions, the creation of Rez Nodes, or Rez Slaves, is required. With the current delay, it takes the time of one frame, plus a 0.1 second delay, to rez an object. For example, when holding down the left mouse button in the control event, it will run the llRezObject function theoretically 540 times in the span of 1 minute. If a higher number is needed, the control event would need to relay the user input to the Node scripts in order to circumvent the 540 RPM limitation. Unfortunately this has caused complications with the end result, which includes: 1) Cyclic de-synchronization, ie, the rezzed object or bullet doesnt rez at close timing, when it cycles through all available rez nodes. This produces an effect where the objects fire in bursts instead of a steady stream. 2) Linkset Crosstalk, where the method to trigger the nodes to fire is a broadcast to the prim they are located, and all scripts pick up the traffic when it should be just one. 3) llResetOtherScript(), this method is useful to keep a high cyclic rate, however it will not retain settings from the master script due to llRezObject being used in state_entry of the node. 4) Adds onto the script count on the simulator it's running in, in addition to the control that manages the rez nodes. The idea is that EM could have the ability to tailor their rez preferences, or the community they are involved in. The default should remain 0.1, however if the EM needs to have the delay changed to suite what the sim is being used for, like a combat sim, they can lower it to reduce the need for multiple nodes that were programmed by the developers. There should be an option available to change the delay of prims being fired from attachments, as well as from objects. A plus side for its use of outside the community is to be used as an anti griefing measure, where in a sandbox for residents to open purchases, griefers cannot exploit this area. As for what minimum to allow Estate Managers to set to, we're hoping to allow the delay to be set to be as low as possible. Even with the minimum being set to 1 frame, it would allow 1350 objects per minute and would cover 95% of all applications of being below that. This would virtually eliminate the need for these nodes are non exist Please note that this is NOT a request to change the Grey Goo protections for a region, nor to make a universal change from the 0.1 delay. This would allow owners and their estate managers more options on how to operate their sim and can potentially reduce the number of scripts required. I thank you for your time in reading this proposal. Edit: To give a few examples on how this is being circumvented, one method is by using llResetOtherScript. Below uses this method and it forces the node to fire a bullet on a forced script reset. This is considered to be the highest rez per script, however you are not able to retain any options or settings in the script. Control.lsl integer node = 0; integer NODE_COUNT = 3; Fire() { llResetOtherScript("Rez Node " + (string)(++node % NODE_COUNT)); } Rez Node #.lsl key uuid; rotation calcSpreadOffset(float spread_in_radian) { float y = llFrand(0.5) * spread_in_radian; float x = (llFrand(1)-0.5)*PI; return (<0,llSin(y),0,llCos(y)> * <llSin(x),0,0,llCos(x)>); } key uuid; default { state_entry() { uuid = llGetOwner(); llRequestPermissions(uuid, PERMISSION_TRACK_CAMERA); vector color = llGetColor(0); llRezObjectWithParams(llGetObjectDesc(), [ REZ_PARAM, (integer)llLinksetDataRead("rezSlaveParam"), REZ_POS, llGetCameraPos()+(<2,0,0>*llGetRot()), FALSE, TRUE, REZ_ROT, calcSpreadOffset(0.05), TRUE, REZ_VEL, <200,0,0>, TRUE, FALSE, REZ_DAMAGE, 100, REZ_LOCK_AXES, <1,1,1>, REZ_FLAGS, 0 | REZ_FLAG_PHYSICAL | REZ_FLAG_TEMP | REZ_FLAG_DIE_ON_COLLIDE | REZ_FLAG_DIE_ON_NOENTRY | REZ_FLAG_NO_COLLIDE_OWNER | REZ_FLAG_NO_COLLIDE_FAMILY | REZ_FLAG_BLOCK_GRAB_OBJECT ]); } } Another example is using a link_message broadcasts, however it will force the link_message events to trigger in all the rez slaves in each broadcast. Control.lsl integer node = 0; integer NODE_COUNT = 3; Fire() { llMessageLinked(LINK_THIS, (++node % NODE_COUNT), "", ""); } Rez Node #.lsl integer node_number = 1; //change to a unique number default { link_message(integer source, integer num, string str, key id) { if(num == node_number) { llROWP.... ) } } Another example is using a color_change event, However this will rapidly update all the viewers in range. Control.lsl integer node = 0; integer NODE_COUNT = 3; Fire() { llSetColor(<(++node % NODE_COUNT)/4,0,0>,0); } Rez Node #.lsl integer node_number = 1; //change to a unique number default { changed(integer change) { if (change & CHANGED_COLOR) { if(llGetColor(0) == <(0.25*node_number),0,0>) { llROWP.... } } } } There are also method where the node gets kicked into a while loop until the while statement is no longer met. (Usually a primitive param, as well as a linkset variable/kvp
0
PBR llFunctions
I've spent about the last week updating some scripts to handle both PBR and Blinn-Phong updates simultaneously. The scripts work fine, but the current way you have to update PBR values - through llSetPrimitiveParams and the full list of values - is not ideal. In order to avoid overwriting your existing values with blank or incorrect data, you have to have a way to know and store your existing values, modify those values, and send the whole list back in. Adding in some llFunctions for PBR values, so you don't have to modify the entire parameter array to change one value, would make scripting PBR modifications much more pleasant to work with. If llFunctions are not feasible, a way to update individual values in the parameter arrays without data loss (e.g. being able to pass a blank string as a texture and have it skip the value instead of applying it) would be appreciated. I've compiled a list below of how I would personally pop each value out into a Set function (they would have matching Get functions, a la llGetColor and llSetColor): --- For PRIM_GLTF_BASE_COLOR: llSetGLTFBaseTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFBaseColor(vector color, integer face); llSetGLTFBaseAlphaMode(integer gltf_alpha_mode, integer face); llSetGLTFBaseAlpha(float alpha, integer face); llSetGLTFBaseAlphaMask(float alpha_mask_cutoff, integer face); llSetGLTFBaseDoubleSided(integer double_sided, integer face); --- For PRIM_GLTF_NORMAL (this really only has one function): llSetGLTFNormal(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); --- For PRIM_GLTF_METALLIC_ROUGHNESS: llSetGLTFMetalRoughTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFMetallicFactor(float metallic_factor, integer face); llSetGLTFRoughnessFactor(float roughness_factor, integer face); --- For PRIM_GLTF_EMISSIVE: llSetGLTFEmissiveTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFEmissiveTint(float emissive_tint, integer face);
2
·

tracked

Add a Text Rendering Method
Add a new function LSL function named llRenderText or similar, which allows users to dynamically render text, with limited but flexible formatting, onto the face of their choosing. Concept: // Signature llRenderText(integer face, string text, list params); // Basic example llRenderText(ALL_FACES, "Lorem ipsum...", [ FONT_ALIGN, "right", FONT_WEIGHT, "bold", FONT_FAMILY, "sans serif" ]); Rationale Text is ubiquitous, yet Second Life has no way for users to display text other than uploading a texture, setting floating text using llSetText , or using relatively resource intensive solution such as XyText/Furware/et al. This absence precludes interesting features, such as being able to create a responsive interactive terminal in Second Life, HUDs with dynamic text, etc. A scripted and efficient text solution that displays on the face of a prim/mesh would give Second Life the biggest bang for the buck: Limited in scope (easier to implement than grand UI-creation ideas) Easy to kitbash into existing and new creations For inspiration, you can look to how the Text Display widget is implemented in the Playstation game Dreams. It has limited options: a finite number of fonts and formatting options, but the fact that it can be combined with other content makes it rather powerful. Other details Font color, opacity, glow, etc are controlled by prim properties (Example: setting face color to red sets font color to red) Questions Should the background always be transparent? Creators could put another prim behind the text display face to give it a background, or it could be a property of the render params. Possible Parameters FONT_WEIGHT FONT_STYLE FONT_FAMILY FONT_VERTICAL_ALIGN FONT_HORIZONTAL_ALIGN FONT_TEXT_WRAP FONT_LINE_HEIGHT FONT_SIZE Possible Features Markdown / rich text
13
·

under review

Load More