Rezzing delays affect all scripts in an object
expected
Infrared Starlight
When rezzing multiple objects from another object,
all
scripts in that object are delayed by some variable number of milliseconds. This makes a lot of vehicle-based gunnery solutions untenable without very silly workarounds, such as temp-attach HUDs. This is a pretty bad bug that affects anything that has some amount of cooperative play of this nature. This also affects guns in general with at least three rez nodes, which can cause other inputs to be delayed for up to a second.Some scenarios:
Helicopter has a nose gun, as well as two door guns. When the pilot fires the nose gun and at least one door gunner fires, all scripts in the object are delayed per shot. In this example, it is split into: movement, gun movement (for each seat), and rezzers for the guns.
Tank has a driver/operator and commander. Commander operates a smaller gun atop the tank. When the tank fires a canister (coalesced linkset "shotgun"), all scripts in the tank pause for about 0.25-0.5 seconds. When the commander fires at the same time as the driver/operator firing the coaxial (machine) gun, it causes massive event throttling on every script in the object, similar to the above.
Log In
Rider Linden
I did quite a bit of digging about what was going on here. I was seeing a delay in the other scripts in the object of roughly 0.066 seconds. As it turns out, this is expected and caused by the object using up all of its energy during the rez. If the object is out of energy, it will skip all scripts until it recovers some of it.
The llRez functions are on their own fairly expensive energy-wise, but additionally the rezzing object will transfer upto 25% of its maximum energy to the new object.
Rider Linden
expected
Rider Linden
I did quite a bit of digging about what was going on here. I was seeing a delay in the other scripts in the object of roughly 0.066 seconds. As it turns out, this is expected and caused by the object using up all of its energy during the rez. If the object is out of energy, it will skip all scripts until it recovers some of it.
The llRez functions are on their own fairly expensive energy-wise, but additionally the rezzing object will transfer upto 25% of its maximum energy to the new object.
This post was marked as
complete
Maestro Linden
tracked
Maestro Linden
under review
Maestro Linden
I can reproduce this by doing the following:
- Visit a region with plenty of spare time (so that scripts will generally be run every frame)
- Rez a box, and create the 2 scripts shown below in it. One script rezzes an object on touch, while the other script runs in a tight loop and reports any jumps in the simulation frame number
- Place an unscripted prim in the box's inventory - this will be rezzed
- Duplicate the box, and give the duplicated object a different name
- Touch either object a few times, and note if any skipped frames are reported
Expected results:
Per the wiki pages for llRezObjectWithParams() and similar functions, "This function causes the script to sleep for 0.1 seconds." - there's no mention of other scripts in the same object sleeping. Thus
Actual results:
On each touch event the touched object's script will report a 'skipped frame' message, like this:
[09:47] rezzerA: Skipped ahead 3 simulation frames since last iteration.
In my test region, each of these events was for the frame number incrementing by 3 - so about 2 more frames (44ms) than if the script were running at full speed. The script in the object which _wasn't_ touched does not report any skipped frame events.
default
{
touch_start(integer total_number)
{
llRezObjectWithParams(llGetInventoryName(INVENTORY_OBJECT, 0),
[
REZ_POS, <1, 0, 0.5> * llGetRot(), TRUE, FALSE,
REZ_VEL, <8, 0, 0>, TRUE, TRUE,
REZ_FLAGS, REZ_FLAG_TEMP | REZ_FLAG_PHYSICAL | REZ_FLAG_DIE_ON_COLLIDE
]);
}
}
// Sample the frame number of the running simulator and report if there was an apparent jump
default
{
state_entry()
{
integer frame;
integer previous_frame;
integer report_delta = 2; // when to report jumps
while(1)
{
frame = (integer)llGetEnv("frame_number");
if(frame - previous_frame >= report_delta)
{
llOwnerSay("Skipped ahead " + (string)(frame - previous_frame)
+ " simulation frames since last iteration.");
}
previous_frame = frame;
}
}
}
Infrared Starlight
Maestro Linden My personal test case (the helicopter mentioned) does not use ROWP and still experiences the same thing -- just normal llRezObject, but the second (tank) test case uses ROWP and I can confirm that it does also experience the same issue. My test cases aren't particularly scientific, but with two of the guns going at the same time, it is
very
noticeable, especially because one of the scripts is responsible for using KFM to follow a physical object. (pre-combat 2.0 damage mitigation workaround)