Does this affect people who are using scripted attachments in a region and then leave the region? Will their scripts still be running there?

Today i disabled all the scripts on the island before the restart.
I restarted the island and then after an hour after the restart more then 30 scripts are deseappeared from it.
actually they are stable on 922 with the same agents on the sim.
all stable atm and the performance on th sim is really better.
let's see

They are everywhere, they are not tiny prims or fast moveing prims. Go to Long Beach , get the top scripts, click on the location colum and
look at this script running << Object >> << Alice Klinger >> <<0.0,0.1,-0.0>>
Beacon it, go to the location and you will see no prim and a dead end beacon location, only the script is there.

Location : Long Beach 0.0/0.1/-0.0

this is only one example, they are everywhere and there are many of them.

I tested in this way:

• disabled all script on sim via estate/region panel
• restart sim
• re-enable script

Sim now list about 1100 running script and "Advanced Border & Performance-Scanner v4.6a (WEAR ME!)" show an index of 3900.

But this isn't a solution, something in server code do something wrong.

Now I do have demo house- and furniture rezzers at the store which would explain the ever increasing script time if the derezzed item's scripts were still running. The more people make use of the rezzers the more script time will increase over time - which was happening yesterday, or at least it looks like it.

Some time today the sim crashed (maybe due to the load?) and afterwards script time was back to what it had been for the last couple of weeks, so it seems the restart has somehow fixed it. I'll keep an eye on my script time to see if it increases again, e.g. with people using the rezzers.

And just out of curiosity - will this also be a problem when people visit a sim, wearing scripted attachments?

I would really like to be given some additional estate tools to be able to handle problems like this when on Mainland as well - very often I can only "hope" for a sim crash when something is wrong (or contact support instead of quickly fixing it myself).

They were also not really tiny prims since the object scanner I made last year can find even the infamous zero-mass prims... if I get close enough.

I have also been seeing dislocated sounds stuck in regions playing continuously. These show up on sound beacons, too.

No change!

Soft Linden, if you search a Sim where this effect is not removed, come to us.

Ron

Dedric pointed this Jira out... d'oh!

it would be nice if this were fixed.

-ls/cm

Please - if you see specific regions with specific scripts, list them below. Absent solid repro steps, this will help tremendously.

I will never figure out what all is ghosting and what is real. not without some filter to that query.
Spent about 5 minutes to find one.

Sim Name
Script Name
Coordinates

and what else?

There's a thread in the forums about this and I wanted to describe exactly what people need to report.

If you don't know how to detected if a tiny ghosted object is there, rez a 5x5x0.5 cube, drop the script below in it, edit the cube over the suspect position then touch it. Should chat any object it finds..

default
{
	state_entry()
	{
		llSetStatus(STATUS_PHYSICS, FALSE);
	}
	
	touch_start(integer total_number)
	{
		if (llDetectedKey(0) == llGetOwner())
		{
			llSetStatus (STATUS_PHYSICS, TRUE);
		}
	}

	on_rez (integer param)
	{
		llResetScript();
	}
	
	land_collision(vector position)
	{
		llOwnerSay ("hit just the ground at " + (string)position);
		llResetScript();
	}
	
	collision_start(integer count)
	{
		integer i;
		for (i = 0; i < count; i++)
		{
			llOwnerSay ("hit " + llDetectedName(i) + " at " + (string)llDetectedPos(i));
		}

		llResetScript();
	}
}

That would actually be funny if you didn't have a history of actually making griefer scripts to exploit bugs. Notably you don't do it to get the Lindens to fix the bugs faster, just to line your own pockets.

This bug has my vote, even as someone who no longer owns or rents estates land I spend a lot of time there so this bug has left me wondering how much time there has been laggy at least in part because of this bug. The sooner they get this fixed the better.

I noticed the same.. i had ghost scripts on my opensim on 1.23
just didnt paid too much atention cause i was busy.. returned them, resetted sim, all was fine - had bad lag later, but LL meant the server would be ok.. havent checked it further. Just noticed that my homestead had 22ms instead of my usual ~5ms.

That was not a very nice thing to say. I really don't think it will help with solving this issue either. As for my history, I have used SL every day since September 2006. If I really was as evil as some people say, would I still be here? I have never even been suspended! Think about it.

>>This bug has my vote, even as someone who no longer owns or rents estates land

I own three regions. I run an extensive network of vending machines with dozens of products randing from space stations, avatars, teleporters, land tools, terraforming, security gadgets, and oh yeah only 3 weapons. But hay, my desire to have a healthy region is totaly invalid because of those 3 weapons. (shakes head)

@ Linden Labs

I will spend some time this week trying for a repro of this bug and post a how-to if i can get one. I suspect it needs an abnormal deletion of the prim involved. Anyone got a list of offending objects as this might help work out what method the objects were removed from the region. ie. were they temp like bullets, or was it a more permenant fixture like a disco etc?

A possibly related issue might be the recent inter region connection issues. I have noticed email is often not arriving, and some region are appearing and disapearing when viewed from neighbouring regions. A restart of all regions in the estate resolves the issue, but I was wondering if this connection problem could be contributing to objects/scripts not being removed correctly? Especily if the operation involves moving them to the asset server. Izzy Linden took care of a similar issue a few days ago in Quantum where the connection to the neighbour region was unstable.

Darling Brody

After further researching this issue, I have found there are 2 isues happening here, The first is a case of ghost scripts , where the script is still active and running
on the server top scripts and the object that had contained the script is no longer on the sim anywhere, and the second version of this issue is a script for the object is running on the top scripts list and the object associated with the script is still present on the server, but the object and the script are disconnected, the object is not in the same place as the script location they are in very different locations, ( the prim in question was a static, non moveing prim ) and if you view the object contents , no scripts are listed in the object contents (includeing any of the linked prims of the object) , but if you return this object that has no contents it does remove the disconnected script from the server. I only found one of these, it was difficult to find and unfortunately to be sure if what I suspected was correct i had to remove the prim to see of it removed the dislocated script, so I do not have an example to show for it. When I returned the prim the server did remove the dislocated script even though they were in different locations.

For container objects, objects that can "hold" or list other objects including other container objects forming a
tree of sub-objects, maintaining whole object consistency during operations such as complete object
tree create, delete and move in distributed systems can be a challenge.

For example, during delete, if an individual sub-object delete failed, what recovery should be done to
to either go back to the original state or complete the entire object removal? Should the requestor loop trying
to delete it to the possible failed computing system? Should it try and recreate the previously
deleted sub-objects to restore the original state?

This challenge is further complicated if there are different pieces of state on different disconnected pieces
of hardware in a computing grid. No doubt the state associated with a prim, texture and script is
different between simulator, asset server(s) and client viewer.

In a sense, create and delete of complex container objects are like miniture startup and shutdown
sequences but require database like rollback behaviors to maintain whole object consistency
in a many element computing grid. Transactional databases help but don't solve the consistency
problems directly.

Move object (teleport is example in SecondLife) is third challenge since it isn't pure create or
delete since the about-to-be created object is linked to the about-to-be-deleted object
with regards to roll back. Having the object incompletely formed in two places is very undesired.

Hopefully this problem space will be considered carefully and not reacted to.

Some reactive approaches are to lengthen timeouts, add "best effort" retry loops and garbage
collectors. These solutions have drawbacks in terms of performance, scaling and robustness.
For example, the garbage collector approach scans larger and larger lists of objects on one
system comparing items found to lists in other parts of the grid impacting CPU and networking.

I hang in one of the most lag-infested, script-riddled, asset churning sims on the whole grid daily, and I've yet to witness the behavior (aside of the ages old beacons at <0,0,0> when the assets haven't loaded yet) ...it's a full sim, so I highly suspect it's one of the new sim types that causes the issue.

So can people check and see if this is relevant? If it turns out most seeing the issue are seeing it with items that rez temporary scripted prims, It may provide a clue for the Devs.

The solution to make the vendors work again is to visit each apez vendor, reset it, and configure it again.

The only way you can really tell if a restart of your sim is getting rid of phantom scripts is to find the phantom scripts first, then do the restart, and then see if those specific scripts are still there.

Turning scripts on and off and restarting the sim does not actually reset the scripts, and should not change the running state of the scripts. Therefore the kind of programmer error you mention should not be affected by the proposed workaround. Unless there is some sort of memory leak or something in the run-time engine itself, of course. That would be as serious a problem as "phantom scripts" if not worse. So a dramatic change after restarting the sim SHOULD be a good indication that something is seriously wrong, not simply that a scripter wrote some bad logic. The exception might be something that depends on elapsed real-time, such as scripts that depend on the value of llGetUNIXTime(), getTimestamp() and their like for their timing. Some of those might vary their behavior significantly if they see a large period of missing time.

Is there a potential problem due to the issue:
http://jira.secondlife.com/browse/SVC-1853

Thank you,
Ellen

Also will disabling scripts in your parcel turn off ghosts scripts?

A lot of attention has to go into developing, testing, and deploying code. There are literally hundreds of JIRA issues involved in each server release. To rush development and skip testing in order to get this out the door would put a lot of content at risk.

attaching a screen shot of this.

@Jandai Writer and others: This is yet another case where the Horizions Holodeck or similar items has been brought up as a source of these Ghost Scripts. What I am unclear about from reading about Horizions is if it is Temp rezzing these scenes or rezzing them as normal prims. Can anyone that owns one comment on how it works?

The requirement is that a script cease if it's parent (object) has left the sim/region.

Therefore there is a requirement for a garbage collector to run from time to time and if a script is found running with no parent then it is removed.

This requires that each running script have a metadata field in it's runtime properties containing the UUID of the parent that rezzed it.
Then if the parent UUID is no longer rezzed in the sim then the script is killed off.

Seems trivial on the surface. Under what conditions would a script need to be left running with not parent left in the sim/region? If none then it needs to be cleaned up.

Edit: I routinely saw these ghost scripts get left in sim when the parent object went off world or was physical and was removed.

But, in this particular case, it looks like it's the Horizon's object itself with the script, not a particular scene. The creator has already commented at least once on this issue. The main extra features of the "pro" version are that it has the capability of recording. It's still just an object with a bunch of scripts in it, though. Generally, it would be deleted with the scene is completely derezed, but it isn't associated with the scene anyway, other than communicated with it.

It sounds like the ghost scripts are coming from a lot of different ways of the object being deleted, so I'm tempted to agree with the thought someone mentioned about this stemming from a failed transaction between the sim and asset server while trying to remove the item from the sim. However, I'd prefer to see actual reproductions/stats to support a better conclusion

I've seen a few lists of deletion conditions to test, but I'm adding a quick list here too... maybe we can at least rule out something that isn't causing the problem? lol

Prim Status:
Normal
Physical
Temp-Rez
Physical and Temp-Rez

Deletion/Removal methods:
Deleted by owner (single object)
Deleted by owner (coalesced objects)
Deleted by person with mod-perms (single object)
Deleted by person with mod-perms (coalesced objects)
(is there a major difference between an object being deleted or returned by someone else?)
Parcel Auto-Return
(is there a difference between a "coalesced objects" return and a parcel settings return of a person's objects?)
Object went off-world with llSetStatus(STATUS_DIE_AT_EDGE, TRUE);
Object went off-world with llSetStatus(STATUS_RETURN_AT_EDGE, TRUE);
Object self-deleted by llDie();
(for Temp-Rez objects) Object's lifetime expired

If I've missed any likely condition, please mention it. I'm not an estate manager anywhere, so I can't see the top scripts listing, but I haven't noticed any major fluctuation in the script count/time at the places I frequent.

list test;

default{
state_entry(){
test=[llGetKey()];

while(TRUE){ test+=test+test; }
}
}

put this into an object, then shift-drag the box around. After few repetitions I got the one of the scripts to clock at 5.5ms (others were around .6ms which is what I'd expect).

NOTE I've not read the whole thread so if someone else reported this, I apologise, just going by Smiley's list. Not sure if this is a new, or separate condition but I'd expect a dormant or "dead" script to take a bit less time than 5.5ms

Post disabled scripts restart:
Estate manager top scripts screen shows 1040 scripts for 6.9 ms.
Statistics bar shows 5989 scripts for 17.2ms

About 30 minutes later the statistics bar shows 3750 scripts and 19ms.

Over the course of a day the lag builds and builds along with scripts in the statistics bar.

It appears to me that when avatars teleport in and then teleport out they are leaving their AO's, mysti tools, scanners, and a million badly behaving script time intensive prim attachment resize scripts behind running orphaned in sim memory.

But we have no way to tell since we cannot see the scripts avatars carry in. This is a security violation to not have an estate manager tool to observe avatar script activity btw. Idiots can go from sim to sim carrying hundreds of bad scripts leaving them running in memory and we can't see them nor can we see who depositied them in the sim. This condition needs to be corrected. We need to see all scripts in sim and carried by avatars in the sim so if we see someone carrying a huge load we can AR them.

And why such a difference between the estate scripts window and the statistics bar data? Does anyone know?

So At the moment I get to spend hours a day cleaning up after LL sim code that has no GC subsystem to cleanse off orphaned scripts. After the disabled scripts restart it is necessary to go around the sim resetting all the scripts of various types because they no longer function correctly after such a restart.

This defect needs immediate attention.

I won't hold my breath. After all LL staff and execs gets paid whether the grid and it's economy fails or not.

One odd thing that I've noticed is that sometimes the total script time listed in the Top Scripts window is higher than the script time listed in the statistics window. Is the Top Scripts time showing the amount that the scripts are actually taking, or the amount that they would be taking if the sim wasn't throttling them down.

they don t need to be ghost to become so slow and making the total so heavy..

https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.25

"Fix a performance-lagging problem that occurs when the apache2 process on a sim is overloaded "

things that make you go Hmmmmmmmmmmm.

[2009/03/06 15:55] Periapse Linden: Ok, it is now assigned to Andrew (Linden)
[2009/03/06 15:55] Periapse Linden: he has observed some weirdness in a session with QA Dan (Linden)
[2009/03/06 15:56] Periapse Linden: basically "objects with PENDING_OP_DELETE set are not getting deleted"
[2009/03/06 15:56] Periapse Linden: so it appears that some scripts are truly not getting deleted when they should be
[2009/03/06 15:56] Periapse Linden: and this isn't just a metrics flaw

So patience everyone, they are working on it!

"Include avatars in the list of "top scripts" in estate tools"

see http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Server/1.26.

I've tested this on Aditi and you get one line per agent showing the combined time for their attachments.

What the viewer is showing as Script Time is actually a new statistic called "Total Frame Time" or something to that effect. I could be wrong, but I suspect that is what you are seeing.

http://wiki.secondlife.com/wiki/Statistics_Bar_Guide

Total frame time is at least 22ms since some weeks ago, even though the other frame times probably don't sum to that number... It's probably like Darien said, and just a display anomaly until the "Spare Time" statistic is in mainstream viewers. (note the comment on that in the above link, at the end of the page).

Your statistics image as posted does look pretty horrible however. Script and physics times being as high as they are i'd suggest looking for runaway vehicles, or people using volumedetect scanners as part of a hud.
...But lets not digress from topic.

@ Darien and BETLOG, sure i bought that for the first day, so to speak however i seriously doubt that is whats happening. BETLOG , thanks on the child agent thing though guess you still can learn new things here. Never looked into that before!

still getting ghost scripts, still have script times off the damn chart, still have tenants leaving due to lag and constant restarting of the sims, even after they read this and SVC-3819 , still cant understand why this and SVC-3819 are not fixed yet.

As you can see , just these 6 ghost scripts are useing up almost one full millisecond of server script time, its a huge
waste of server resources.

TB

I know this sounds like a conspiracy theory, but that does not mean it isn't right. Last year Linden Lab did the same thing. They introduced a bug which generated faulty metrics, then used that data to justify a massive price increase on OpenSpace sims, causing many land owners to abandon property they could not sell.

The rogue script bug smells of the same tactics.

I brought this up at Periapse Linden's Office Hours yesterday. He looked it up and had this to say:
[2009/03/06 15:55] Periapse Linden: Ok, it is now assigned to Andrew (Linden)
[2009/03/06 15:55] Periapse Linden: he has observed some weirdness in a session with QA Dan (Linden)
[2009/03/06 15:56] Periapse Linden: basically "objects with PENDING_OP_DELETE set are not getting deleted"
[2009/03/06 15:56] Periapse Linden: so it appears that some scripts are truly not getting deleted when they should be
[2009/03/06 15:56] Periapse Linden: and this isn't just a metrics flaw

A later followup meeting they said the issue was going to be fixed in 1.27 along with the new Scheduler for Mono memory, however now that plans to introduce the scheduler have been scrapped, I don't know how this will effect the rollout of this particular fix.

People should know by now that given the long release queue LL has, it takes about 6 months for any fix to any particular bug to be rolled out, once it's solved. So just have patience.

For that matter I would oppose any roll back for a bug with a low impact overall.

I occasionally hear from support that my island is unstable because it has over 9,000 scripts. Perhaps if this was fixed, the metrics wouldn't show that many scripts.

That announcement has caused unknown harm, as I have no idea which if any of my own products will be affected. I do know that content providers will have a LOT of technical support calls when it goes live, because products will fail to rez and we will be blamed for Babbage's decision. I might feel better if we had even a vague idea of how much memory/prim will be allowed. The rumor that's being spread is 1 script per 6 prims a parcel supports. If so, every sim on the grid is doomed, so I hope that's just a bunch of hot air.

https://lists.secondlife.com/pipermail/secondlifescripters/2008-June/003166.html

A quick summary of it is in this post by Kelley Linden from that thread:

https://lists.secondlife.com/pipermail/secondlifescripters/2008-June/003188.html

The who was M Linden, CEO of Linden Lab. And he was not wrong; he was lying. During the huge fiasco that was the Openspace price increase, M Linden wrote a public letter stating that Openspace and Homestead regions would be limited, but full sims would not be changed. This is clearly a lie.

That is not, however, the subject of this JIRA. The relevance between the two cases is simply this: the ghost-script problem MUST be resolved before going forward with proposed script restrictions. Otherwise residents will be penalized for something Linden Lab did, and griefers will create ghost scripts deliberately with the intention of shutting down sims.

@ellen
Thankfully the disabling of the scripts and restarting has not been a issue for me. I do know that others have had issues. In my case it is difficult (if not more than) to search oh say 8,000 scripts for ghosts. If they taking a lot of script time and standing out, that is one thing.

@Chesyr, I agree it does seem odd that they don't fix such issues. :/ Seems like they should halt everything till such a BAD bug is fixed. Why they don't is very odd. They are alienating their clientel by doing this, unless they have a reason for doing so. But they have showed slowness in other areas when they should be moving heaven and earth to fix it......odd indeed.

Do we im them and tell them I dont know what scripted item you are wearing that is useing excessive server resources,
so could you please start takeing off all of your scripted items and huds ?

Do we use the region controls and just send them home , telling them sorry i dont know what you are wearing thats useing too much
server resources, but if you can figure it out on your own , you can come back.

Do we start makeing abuse reports for abuse of resources on a poor person who is totally unaware of their high script times,
when we cant even detirmine what it is ?

Or do we just start turning off all scripts for visitors to the sim ?

We cant even help them by letting them know how to solve their high script time prolbem.
I can see many people being sent home from sims , fustrated and upset, not knowing how to properly resolve their high
script time prolbem.

This can ruin the experience for many sl residents, none of them are really aware of their script times of their attachments or huds.

And yes it will be a lot of educating that has to be done. But most people have been badgered into the arc is evil arc is bad must ban anyone with over 100 arc so a lot of people are simply going to be AR griefed for something they are unaware of. LL built this problem so LL needs to step up and commence the education process. LL needs to not only add the visibility of script time and memory usage to avatar displays so we can see it but they need to add a parcel or sim render cost to the viewer so we can begin avoiding awful builds like most of the mainland because they are poorly done and cause lag. In addition we need a way to turn off the sky and water polygons to get rid of the windlight polygons lagging all the viewers to high heaven.

Good luck. LL just throws the sharks in the pool. Up to us to saddle them up and tame them and deal with the fallout and collateral damages so start blogging and notecard spamming.

OR ...

They could dedicate two cpu's to every full sim instead of one, that would work too.....lol

Schmu Abdallah added a comment - 03/Mar/09 01:21 PM
i dont know how you could not pick up this up in testing..?!
every homestead owner i have spoken too has noticed the same, script times are anywhere from 5x to 20x times higher then they used to be, affecting sim fps and time dilation.
turning off scripts and restarting the sim did fix it for me but only one time, after the next restart by LL it went back to bad.
if i do it again now it does not help anymore. sometimes i see a simple (unused) poseball in the top scripts using up to 3ms!

so if someone know who opened a jira about that and not only about ghost scripts i d be happy to be directed there..

thx

Thanx

Thanx

In addition even the well behaved resizer scripts will add to time and memory usage when they are literally not necessary.

It is the designers that need to stop putting scripts in attachments unless it is clearly needed. This includes color and texture changer scripts. So what it takes more prims or a scripted vendor? If you can't afford to be in business then you can't afford to be in business period. Buy the prims/parcel you need or downsize your available stock of merchandise. Put it all on XStreet till LL sees this and starts charging a fee for people listing more on XStreet than they have out for sale in world.

I am as guilty as anyone else for falling for the "products must be scripted out the kazoo to be competitive" myth. I now script only for artistic effect. All of the stuff that has been resize/texture/color scripted in the past is probably going to become obsolete real soon now when people cannot even use it. There will be much anger and the anger will be redirected to Linden Lab so they best have an educational program in place before they roll out the limits.

I am concerned that scripting for artistic effect will be destroyed by Linden Lab. This concern will remain in place until Linden Lab proves it won't by way of getting the code onto aditi so we can evaluate it and provide feedback. This will include having complex region configurations set up for parcel and avatar script limit testing.

But as for this JIRA issue that LL needs to address yesterday, these stupidly written resizer scripts, texture/color changers, AOs, Huds, who know what the purpose is scripts all wind up being left behind in the sim memory when people leave so the sim has to be restarted daily. Waiting 6 months for this to be fixed represents utter incompetence IMHO.

I understand what you are saying about privacy, but allowing sim owners to view the individual object names script times for the attachments avatar's
are wearing is not really a privacy issue currently. The current "strip search" feature linden provides for everyone to use , makes privacy reguarding being
able to view object names and their script times of avatar attachments a non issue.

There is more privacy by allowing only sim owners and sim managers to view object names and script times of Avatar attachments on only their sims for
performance and diagnostic reasons then the Inspect feature ( strip search of avatar attachments , which any resident , without any reason has permission to do ).

If you are not aware of the Inspect feature, please try it out, right click on an any avatar's attachment and then click Inspect from the pie, you will get the name of the
object , the name of every prim in the object, the owner's name, the creator(s) name(s) and the creation dates, while in this mode , just keep left clicking all over the
Avatar on any attached objects and you will every last detail on that attached object , execpt for the script time and attachment point. Anyone can basicly strip search
any avatar of the objects they are wearing, so currently, there is no privacy.

Along with llSetLinkScriptState, there are some companion functions that would also be desireable:

llGetLinkScriptState
llLinkResetOtherScript

THIS IS NOW AN EXTREMELY SERIOUS ISSUE .

If any LL employee is monitoring this JIRA, can you please find a way to remove the script from the ghosted object " female poseball " owned by " Alice Klinger"
Thank you,
Ellen

*Update, the object was just returned today with an object went offworld notification, so I am not exactly sure what the glitch was.

The only way you might possibly repo this is to cause an avatar that is wearing many scripts to have a viewer crash.
90 % of these ghost scripts on the sims are a result of an avatar haveing a viewer crash, and their scripts remain
running on the sim even after they have been logged out by the system after they crash. Look on busy sims, for scripts
located around 0/0/0 or way up in the sky these are the most repetitive locations, you have to start beaconing the scripts,
go there, and make sure that is is not an alpha transparent prim. Finding them would be much easier if we could sort
the top scripts position coloum by the z position, right now the coloum can only be sorted by the x position.
If you can do that it would be more helpfull for diagnostics.

Ellen

http://www.flickr.com/photos/14310679@N05/3774831187/

You have beaconed a script in your top scripts and have arrived at that location, only to find out, you see no visible object there.
Do you have a ghost script ?
Please check the following to diagnose this issue:

First : Highlight Transparent in your view menu, if you now see the object at the end of the beacon, you do not have a ghost script
you have a scripted prim with a transparent texture.

Second: Go to edit mode, draw a selection box ( select by surrounding) around the location of the script, if it selects an object it is a tiny prim,
or possibly an iinvisiprim and not a ghost script

Third: Refresh your top script list, is the suspected ghost script still in the same location ? If not, it is a fast moving prim that has already
moved before you were able to reach the beaconed location ( like the scanner prims that are sent out from a Phenom hud avatar
attachment, you will only see them on the top scripts list by looking for scripts called Azora Sim Grid , unfortunately we have no flag
on child prims that were rezzed by a parent prim to be able to determine what object was responsible for creating the child object/prim,
this is still quite an issue here in sl ), or it was a temp object that has "died" before you arrived at the location and you do not have a
ghost script.

Fourth: Open your Region/Estate menu and now disable all script on the sim.First note the exact location of the suspect ghost script. Now
restart your sim. Return to the exact location of the suspect script ( you can not beacon the location from the top scripts list, the script
is no longer running ) if you now see a prim or object it contains an invisiprim script in it and is not a ghost script, if you still do not
see anything at the location, go back to the second step here and try drawing the selection box around the area ( select by surrounding)
if a prim is now selected, it is usually a tiny invisiprim, and you do not have a ghost script.

Fifth: You truly have a ghost script. Please take a screenshot and upload it here and add a comment here listing the sim name , the script
name, the ( x,y,z ) location of the script, and any other relevant information you can provide. Pleas do not remove the ghost script, please
allow someone from Linden Labs to investigate it further.

Thanks
Ellen

Note : the sim cleaning routine that some people are doing currently I do not recommend. You can damage scripts/objects and it gives you a false
result at first when you re-enable scripts after the restart, When you re-enable scripts on the sim, you need to wait quite a while for the server to
report the stats accurately, not all scripts start as soon as you re-enable scripts , there is a build time till they are all at their stable levels, keep in mind
some scripts do communicate with other scripts and outside sources, resources and servers. So dont be fooled by lower script numbers and shorter
script times, come back an hour later and check, when everything has pretty much stabilized.

2) Advanced > rendering > fast alpha > OFF
With fast alpha on, my graphics does not render (as red) any transparency based on 100% alpha textures.
Totally Transparent : bd7d7770-39c2-d4c8-e371-0342ecf20921
totallyclear : f54a0c32-3cd1-d49a-5b4f-7b792bebc204
and probably TEXTURE_TRANSPARENT

Now what is intersting is the script was for a bed pose ball. And where the beacon lead me there was a bed in that location over a year ago. So it was not a case of a scanning prim moving around the sim why I didn't see it when I went to the beacon. It would appear that the prim can be totally invisable yet still there with the script. Or at least still show in the about land as a prim. And has been this way for a long time.

This makes the situation much worse as we are always looking for more prims. In hindsight I wish I had kept it, for LL to inspect.

-DB

Its too bad you deleted it.
Most likely the poseball was left behind in the hide mode when the bed was taken. Most poseballs have a show and
hide mode, if it is in the hidden mode, you should be able to see the poseball when you are in the highlight transparent mode.
Its most likely not a ghost script and the prim was still present there. Usually to have a poseball show again when it is
currently in the hide mode, you say one of the following in open chat, while you are within chat range, or just shout it.
"show " , " / 1 show ", " /2 show "," /7 show "," /8 show " or " /9 show ", (without the quotes) these are the most common ones
some poseballs may be set to a different private channel, respond to owner only or respond to a different command. The beds and the poseballs
are not linked, so it is quite easy to "take" the bed back into invertory or delete it, and forget about the poseballs , if they
are in their hidden mode.

The pose ball was part of a bed, a sexbed with a menu system and this particular system does not have a "hide mode" for the balls anyway. Rather when you turn it off, it derezes the ball in question. So again this is not the reason. I already checked for such instances of what you suggested. It was obviously a case of something not working properly on the server side. The lindens can still examine the saved state of the sim (if they do so today). Though I doubt they will as most consider this issue "fixed". Which is better yes, but clearly not 100% "fixed".

-DB

For Linden :

Please send a tech to look at the following sim:

http://slurl.com/secondlife/Starlight%20Beach/190/130/22

look at all top scripts owned by MzTeNnaKeY Queenstown and beacon them

Check the Parcel Object Tab on parcel " Starlight Beach SVC-3867 Bug "

click on refresh list on that tab and see what happens.

Please check it as soon as possible, I am keeping the land not for sale so you may research the bug.