Give Estate Managers/Sim Owners the Ability to Set RezObject Delay
SamanthaTekcat Resident
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
Log In