Thank you for taking an interest in this JIRA.

I don't agree that it is a new feature.

The fix for URL spam did not intend to delay scripts giving URLs to the avatar wearing the script. (ie. owner). The fix for the URL spam intended to block one person from overloading someone else with URL spam.

As the delay to the owner of the script was not required for the anti-spam fix, and breaks previously documented behaviour, I say this is a bug resulting from the fix applied to block URL spam.

I have not returned this JIRA to a bug status, however I encorage you to do so.

I hope it gets fixed soon. I use URLs for popping up help pages and the delay is very anoying!

Once again, thank you for looking at this JIRA.

Darling Brody

Right now, without needing any permissions at all, an attached object can delete all the objects on your land, totaly mess up all your land heights too, launch a self replicating attack over all the neighbours regions that continues to stread to the regions next to them, and attacks everyone in the current region and all the neighbouring ones, and.. and..and... they are just the things i am comfetable talking about in public.... don't want to give people ideas! End result, the person who put on that object will be banned if you didnt quickly file an AR against the perosn who gave them the object.

Now to talk abotu this function only....

If you put on an object that spammed you, you will take it off and report the person who gave it to you. This is not the same as an object owned by someone else that you cant stop.

Make it nice and simple. If object is attached to the avatar it is giving the dialog to, it will not sleep afterwards. Then you dont have to worry abotu a gag object rezzing a second object to send the spam.

Anything that lets us send a URL to the owner without delaying the script would be great.

If the delay is 10 seconds then why not a throttle of 6 per minute? That would retain the same max speed without delaying the script.

One of the ways people work around these built in delays is by using extra scripts, which only adds to current problems of memory use on the servers running the regions.

Functions like llLoadURL and llEmail with these huge delays are often compensated for by having 10-20 slave scripts. Clearly sleeping a script is not effective and leads to workarounds that waste the regions resources.

Do you think the overhead in throtteling will have a big impact when you take into account the benefits of being able to remove all the slave scripts running that people currently use?

There are probably a lot of products that could save memory in the servers if their sleeps were converted to throttles. NonPhysicalVehicle scripts come to mind, where 16-24 scripts are used to overcome a 0.2 sleep after a llSetPos/llSetRot.

Food for thought....

Darlign Brody

Newer methods to block spam use thottles, while a lot of the older script functions have a delay built in as an anti spam protection. This jira is about fixing the old ones so they still block spam, but dont delay scripts, resulting it people making memory hungry multi script solutions.

Soft Linden's change to the jira description is a good idea. Any function that currently has a delay after sending information should replace the delay with a throttle. BUT there is a problem.....

Current scripts expect the data to get through even if delayed, not be dropped like a throttle does. So how about a hi-breed. when the throttle level is reached, the delay is implemented after each call. This way all information is sent for legacy scripts, while not imposing a delay on well behaved scripts.

The effect will be that all scripts will run as if they dotn have a delay, and if they shoudl send too much information, they will behave as they previously did with the delay.

This will not stop multi script spammers, but this jira is not abotu multi scritp spammers, it is about making the functions work properly and lowing the memory being used in workarounds that involce slave scripts.

Multi script spammers will die with the memory and cpu limitations being implemented this year, and the viewer's better mute abilities will take care of anything else.

IMPORTANT :
llEmail is an exception. It sends information to the live internet and needs to be handled differently. Dropping Email's using a throttle would be devistating to inter region communications! llEmail is a very good candidate for the throttle that turns on the delay. ie. more than one email being sent within 20 seconds will force a delay after the email. However sending only one email will have no delay. This model would work well with all other delay based functiosn too.

EDIT:

I have altered the description of this jira to reflect Soft Linden's idea, and to combine it with one of my own which i think will better sever all situations where we currently have throttles and delays.

For example, user Joe Avatar is currently getting way too many dialogs at once from a few different sources, all new dialogs from all scripts from all objects from the sender will be delayed until he falls under the throttle?

Spamming only works if you hit the same receiver person lots of times. therefore a per-receiver-person throttle will stop spamming while still letting scripts fire off non-repeated urls without delay.

Sorry if I'm stating the obvious, here, just clarifying how it would work.

The throttle should be on the UUID of the person getting the dialog box. So that Darling Brody can only send 1 dialog box every xx seconds to Adeon Writer before the throttle kicks in. But Darling Brody could send one dialog box to 10 different people without a throttle.

So this lets a script send 1 dialog to someone without any delay, but if they script decided to send mroe than one dialog to the same person it will have to send them slowly or else it wille be blocked.

When i say dialog i mean llLoadURL, not menu dialog boxes which should never be blocked or else menu systems will all break.

I can't think of any use-case scenario where a script would need to send many dialogs to one user at the same time before they had a chance to respond to any of them, so I don't think it would break any currently well-intended menu systems.

That said, a limit of say, 5 unresponded dialogs in one minute would be an effective limit, or in the ballpark thereof, and once hit works like grey goo: They can't send any more until they fall under the limit, further attempts not working but still counting against the throttle.

One could even go further that user interaction (I touch the object, I might want a menu) could reset the throttle as well. The point here being things you don't interact with shouldn't be able to send you countless dialogs/loadurl's, unless you are responding to them or directly interacting with said object. If you are doing neither, then they should be limited to a strict per-agent throttle.

now we go into the endless rounds of yelling at LL to make the function usefull for people who are doing the right thing.

And yes. those morons who are yelling griefer dont manke anything, sell anything, or even have a paid membership most of the time.

This must be fixed. I am furious it has not been fixed since 2007, when this bug originally reared its head.

The best solution I had was the Gemini viewer which was able to just block all llDialog dialogs completly when pushed a hotkey. Unfortunetly that viewer did also block dialogs sent by own objects.

Maybe LL should consider not only to throttle dialog spam not only server sided but client sided, too. But therefore they would have to send the sender key with all dialog types. There are some dialogs like llMapDestination that don't even carry the sender's key, so a client cannot decide if this dialog has to be blocked or not. (It's clear that I want all dialog types send by my own objects to be spawned without any delay).

It will if it is the victims viewer that is imposing a throttle on incomming packets =)

The idea is to throttle the victim's viewer (as Darling already said). The 3rd party viiewer "Gemini" had this already. "Emerald" has only a weak throttle, that can be easily overrun by dialog crashers. At this point we need the LL engineers to implement a really working throttle.

I don't think throttling is the right idea. Give the viewer an option to block ALL dialogs (except that one's send by own uuid and can be identified).

And for gosh sakes give my objects the right to spam myself as much as I wish.

The viewer slows down so much I even cannot abuse report that.

It's time to do something: Please implement a simple complete dialog blocker that can be toggled on/off by a key combination. Skills Hak had it already in her Gemini viewer. A very efficient solution.