While trying to TP away, after a time-out, client disconnects. This is a kind-of client crasher problem and not acceptable.

Unfortunately I'm not sure how to stop it. Part of the reason why megaprims are not officially supported is because this kind of thing can happen. I suppose one option might be to prevent megaprims from running scripts, but I'm not sure how that would work. Another possible option would be to add an option in the Advanced -> Rendering menu to disable the rendering of megaprims, which might stop it.

Thanks for reporting this, I'd never heard of it before.

>> Jahar Aabye - 17/Nov/08 04:29 PM
>> Another possible option would be to add an option in the Advanced -> Rendering menu to disable the rendering of megaprims, which might stop it.

Even disabling the rendering of all prims by Advanced - Rendering - Type
-Simple and -Volume
doesn not stop the client lag.

We cant ban the megaprim because the griefers doing it are using the same megaprim which private region owners love to use for artificial horizons. Soft Linden was the one to blog that the horizon is cool and should be retained when they were considering killing all the really big megaprims under havok4.

I have also seem a similar device that uses only 10m prims to obtain the same amount of lag. [ deleted how to do it with 10m prims -Ed ]

There is little we can do about it, unless we able able to MUTE objects server side, in that their information is not sent to the viewer.

Now I say again. Griefing is a social program, not a technological one. I say ban the griefer, not the prim I use for my horizon! My prim didnt do anything wrong.

Darling Brody

You know, LL can't ban the griefer's using one-day accounts and hiding their MAC and harddisk id. And if it's technically too easy, people will grief, so it's a technically problem, too. But I see your point regarding artificial horizon, didn't thought of them.

But at least we need a technically solution for this issue because the public sandboxes are targetted by this griefing tequnique too often, that is not acceptable. Solution could be to disallow these megaprims only in public sandboxes.

Best solution would be to fix the client so these megaprims wouldn't lag it anymore. E.g. by suppressing the rendering of rotating, very large megaprims.

One thing that I wonder about is whether these are being rotated using llSetRot() or llTargetOmega(). The difference could explain why Ezian felt lag while Harleen did not. Constantly using llSetRot() could be what is contributing to the lag (in addition to the fact that they're megas, of course). On the other hand, if they're using llTargetOmega(), it could be that the reason for the difference between Ezian's observations and Harleen's observations is simply that the megas that Ezian observed were made physical, while the ones Harleen observed were not, since nonphysical objects set with llTargetOmega() are only rotated clientside.

Darling's description makes it sound as though the lag was serverside and not clientside. It would be good to know what the sim stats were when this thing was being used. Was it only a drop in client FPS without a concomitant drop in sim Time Dilation or simulator FPS? Or were the sim stats similarly slowed. I know it sounds like I'm splitting hairs, but it really is important to know whether the problems this causes are clientside, serverside, or both.

I don't know. I tried a simple llTargetOmega in a megamega prim, but that single one didn't caused any lag for me, and I deleted it almost immediatly cause I was afraid to be the target of abuse reports in the sandbox. Somebody should test that with either a single island in the void, or the surname Linden.

Unfortunetly my client's performance is so bad when I am around these megaprims, that I even cannot read anything by Control-Alt-1.

Normally if I or others abuse reports these megaprims the G-Team does not do anything with them. Maybe it would be a good idea, if they eventually come and copy the script out of one of the prims and send it to one of the developers.

But sliding down Drawing distance to 64m is no solution.

Now I was able to take a screen shot with statistics. The parameters show, that the sim server is really healthy, time dilation 1., Sim FPS 45, Total Frame Time 15.4 ms. But the viewer FPS is at 0.3, that's the problem.

Right now a megaprim attack by a 'faxblaster Quandry" is running in Sandbox Goguen, I saw it 12:30 PM PST, client frozen, with lot of difficulties, took 10 minutes, was able to abuse report it. I asked the G-Team with this jira issues URL to please take a copy of the megaprims. Now it's 1:38 PM PST, megaprims still there and griefing and rotating, nothing happened. I fear without the support of the Lindens we won't find a solution here. I think the G-Team is tired of my boring tech abuse reports, so I will stop them - Griefers have won.

Also I appologise for linking this wrongly to the g-team issue , I meant to say relates to rather than label it a duplicate.DuH !