[#SVC-3443] Allow llSetPrimitiveParams to reset the TEMP_ON_REZ timer in the server.

2. Second Life Service - SVC

Allow llSetPrimitiveParams to reset the TEMP_ON_REZ timer in the server.

Created: 20/Nov/08 11:43 AM Updated: 21/Nov/08 10:22 AM

Return to search

Component/s:

Scripts

Affects Version/s:

None

Fix Version/s:

None

Issue Links:

Relates

This issue Relates to:

SVC-22 Vehicles crossing region borders aren't always treated as vehicles and can get incorrectly returned if the destination parcel is no-entry or parcel-full

Description

« Hide

Setting PRIM_TEMP_ON_REZ to FALSE using llSetPrimitiveParams should clear the doomsday timer.
Setting PRIM_TEMP_ON_REZ to TRUE should restart it from zero.

Why?

Thanks for asking.

Vehicles are fragile. My blimp can now cruise across regions typically for 30 minutes or more without crashing.
When it crashes (usually because rider and vehicle got separated in a region crossing) or is abandoned by the rider (Stand up) and it no longer has vehicle status I have a very dramatic explosion, crash and burn sequence.
After the fire subsides it then self destructs a few minutes later under script control.

Problem 1. Sometimes separation occurs in a NO-SCRIPT area so the crash and burn can't work. To be fair to the parcel owner I should rely on TEMP_ON_REZ to remove the dead vehicle but if I enable TOR I don't have time to finish my crash and burn sequence.

Problem 2. Sometimes, although scripts are permitted, during the crash the blimp (Physicsl) will land or roll across a parcel boundary into a no script area where it freezes and no way to clean up the mess.

If I could restart the TOR timer by turning it OFF and back ON every 10? seconds then so long as the script is running the TOR does not time out. If it enters a no-script area, the script can no longer turn TOR off and it will time out.

Alternatively a new function could be made llResetTOR() but I can't see any reason why changing the existing function(s) would cause any legacy problems and correcting how it works has more chance of implementation than adding a new function.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Maggie Darwin added a comment - 20/Nov/08 09:03 PM

It's always wise to cruise a flying vehicle above the no-script limit.

Unfortunately this usually means being above the cloud layer, restricting sightseeing. Another hazard is full parcels, which should not trouble a vehicle but do anyway. Also no object -entry...no entry parcels you cant see the ban lines for soon enough, Expired_region_handoff, etc.

See litany of woe in SVC-22 and related.

Basically a land owner who turns scripts off needs to set a reasonable autoreturn or expect vehicles to accumulate.

Unfortunately, temp-on-rez with a script resettable limit strikes me as an invitation for making temp-rezzer abuse even worse than it already is.

[ Permlink | « Hide ]

AnnMarie Otoole added a comment - 20/Nov/08 10:00 PM

Cruising in the clouds is not acceptable. My blimp cruises most of the time at about 15m unless it is necessary to go over restricted areas.

No-script access by vehicles was specifically intended to be viable. While the object remains a vehicle (passenger sitting) it is supposed to be able to cruise a no-script area but I can't stop a passenger standing up at random. The catch 22 is I can't llDie() it or make it temporary if scripts are already stopped. I agree if no-script is activated then they should have a timed object disposal although most may not be aware of it. I was trying to find a way to be courteous.

The only region crossing problem I have remaining is a known bug when a parcel is at its prim limits and it sits right on the region boundary. Due to timing differences between the avatar and the vehicle handing off, when the vehicle arrives it is returned to inventory. When the rider arrives with nothing to ride on they fall to negative altitude at a rapid pace. I've been as low as -1,000,000 meters. It can take up to 5 teleports to different remote regions to recover.

If temp-on-rez abuse is a problem I don't see why it would be any worse if the script has the ability to reset the timer. The script currently has the ability to turn it OFF which would allow more specific abuse than the lesser act of extending the timer by resetting it.

[ Permlink | « Hide ]

Maggie Darwin added a comment - 21/Nov/08 04:54 AM

Yes, the full-parcel-on-region-boundary bug is still...a bug. My inter-sim starship jump drive doesn't have a way to deal with that yet either.

Can you cite support for the "No-script access by vehicles was specifically intended to be viable" argument? Because as a vehicle scripter I support that, and think it should be pursued as a bug. If the spec is that vehicle scripts should continue to run in no-script, then I would in general argue against a feature that's intended to circumvent a bug in favor of fixing the frakking bug.

Ordinarily you'd think bugfixes would be prioritized over new features, but sadly the recent history of Windlight, H4 and Mono shows that not to be the case. If we can't get actual bugfixes then this sounds like a relatively innocuous feature.

I still haven't figured out how to tell when scripts in a HUD will run or halt in no-script land. No-script at the parcel level is a severe misfeature, IMHO.

[ Permlink | « Hide ]

AnnMarie Otoole added a comment - 21/Nov/08 10:22 AM

To quote from conversation with Kelly Linden:-

"No Script" has a fun loophole. If your attachment or vehicle has taken your controls and is running prior to entering the No Script parcel, the attachment or vehicle will continue to run. I would not recommend getting off the vehicle at this point though, since it will not start up again within that parcel.

It is described as a "loophole" so I'm not sure if it was intended however it has always been a goal in SL to allow vehicles to traverse regions so I'm assuming it was deliberate. Having the T-O-R timer reset would be a very simple change with no legacy ramifications that I can see and would allow a method of removing dead objects.

In fact, the vehicle does not have to have taken controls for the script to continue on entering a no-script area. All you need is for it to be still classified as a vehicle = sat-upon.

Another quote regarding the full prim adjacent to a region boundary:-

Yeah that is a known bug. It is a race condition that I was never able to fully track down. The problem is the vehicle gets serialized over to the other region before the rider, so there is some short time when it isn't a "vehicle" and if the wrong check happens then things go badly. It actually doesn't happen 100%, although it has been a long time since I looked into it, so maybe it is 100% or close enough now.

Kelly

What is disturbing about that bug is the avatar is disrupted severely. So far, short of log out/in, the easiest way I've found to recover is to start teleporting to different random regions. After 3 to 5 teleports it stabilizes. If anyone knows an easier way to stop the avatar shooting to hell at 10,000 m per second, please let me know.