steph Arnott

I have scripts that do that every day. None have ever failed. They turned off when LL run their weekly restarts. Have a nice day.

The issue is your data. END OF. And BTW no i have never had that issue in 8 years.

Your issue is your database. It is NOT an SL issue.

No, you are using an external database which is not an SL issue and under EU law you are not allowed to use that database in SL. And LL are legally bound to abide by EU law. Fully on topic.

'sql database table' is external. And under EU law and Russian law they are not legal.

There are two types of lists. Semi-permanent and temporary. Semi-permanent are used when that data needs to be kept and re-used. Temporary are for a code blocks that need data held for a local operation. Clearing a semi-permanent list with data that will have to be re-populated uses more memory at the time of re-population. Clearing that list for no valid reason is pointless. Deleting a value in that list that is no longer needed is the usual action. Sorting lists into a logical order uses less memory when data is searched for and an operation jump out is used. When lists are searched or updated etc a temp copy is made for camparison purposes. That temp allocated memory has no effect on the scripts allocated memory. To be clear lists are a minor memory issue if correctly managed. Nearly all memory issues are caused by poor code structure. Using user created functions for two lines of code which are allocated 512bytes is a common example of gross memory wastage. Not sorting if conditionals in to releivent blocks or a pile of if conditionals that should be else if conditionals is another. ETC. Concentrate on efficient scripts first before worrying about list contents. If you are filling a list with junk then you are not managing the lists very well at all.

The more i look at your pic the more i get the impression that the blue pyramids are for moving that box. I.E direction arrows. Is this the case?

Try this it will at least give you a start http://wiki.secondlife.com/wiki/User:Tapple_Gao/3D_Spinning_Pendulum_Motion

Hmm well you could fudge it by creating a hollow cylinder with a cut path and scaling the cylinder size down and up.

Well it is not, but you are rotating them as well. The server has to crunch numbers because you are not snapping the objects from start pos to end pos. You are moving them in and out on a timer . What you want is likely to stall which is why i suggest you use the keyframe function. But i am not entirely sure if that works with vectot movements. http://wiki.secondlife.com/wiki/LlSetKeyframedMotion

Think you need to use llSetKeyframedMotion instead.

What is this script for. It helps to know.

You can not test for speed unless you are in a controlled sim for that purpose.

Variables and lists are two entirelly different things. Variables can be global or local. Lists can be global or local. Variables are limited, lists are for more advance data storage. As for speed and efficiency that depends on how you use variables and lists. Memory wise scripts are allocated 64k unless script capped. Put it this way you do not use a list when you can assign a variable.

The dialog box is client side and can not be auto closed. That is why the 'ignore' button is there. Creating a dead dialog box to close another is pointless. People will soon get irritated by the one present that they will just click ignore. This is not an issue created by LL, it is a client OS protocol.

The Particle lab shows examples and also has free scripts for anyone who wants to learn. http://maps.secondlife.com/secondlife/Teal/180/74/21 On a caution note, excessive particle emitters can be lag inducers. They are constantly updating the clients viewers.

I left the code for you in my last post.

Can not tell from that lack of information. One thing that looks odd is that the HTTP is being stored with no clean up operation. This should be trimmed before each seperator and then tested. list temp = llParseString2List(body,["&"],[""]); string temp0 = llStringTrim(llList2String(temp, 0), STRING_TRIM); if( temp0 == "fnop" )

Li and prim count are roughly the same. The issue is whether the prim object is optimized as one object or in sections rather than a collection of prims. The internal vertecies in a multi prim object are still active to the physics engine, simply converting it to a convex hull can reduce the count by a lot. Of course the Li count of mesh is subject to the creators optimization before uploading. There are some pretty heavy Li meshes around. Most multi prim objects can be converted.

The edit is disabled after logging off or it is time limited, am not sure which. The delete option was set to admin several years ago. The Firestorm area search has been a feature for years but like many things LL point blankly refuse to use it on their viewer. Other plateforms use portals and SL is still using the awfull map, which was valid a decade ago but certainly not for at least nine years.

Is the surface fairly level?

integer side = ALL_SIDES; //ALL_SIDES or any face number 0 through 5 list texture_list; list texture_list2; key user = NULL_KEY; composelist() { integer currenttexture = 0; integer totaltextures = llGetInventoryNumber(INVENTORY_TEXTURE); if(totaltextures > 0 & totaltextures <= 12) { texture_list = []; do { texture_list = texture_list + llGetInventoryName(INVENTORY_TEXTURE, currenttexture); currenttexture++; } while (currenttexture > 0 & currenttexture < totaltextures); } if(totaltextures > 12 & totaltextures <= 22) { texture_list = ["Next Page"]; do { texture_list = texture_list + llGetInventoryName(INVENTORY_TEXTURE, currenttexture); currenttexture++; } while (currenttexture > 0 & currenttexture < 11); texture_list2 = ["Last Page"]; do { texture_list2 = texture_list2 + llGetInventoryName(INVENTORY_TEXTURE, currenttexture); currenttexture++; } while (currenttexture >= 11 & currenttexture < totaltextures); } if(totaltextures > 22) { llWhisper(0, "You may only have a maximimum of 22 Textures. Please remove any extra ones."); } if(totaltextures == 0) { llWhisper(0, "Please add up to 22 Textures inside this object."); } } //The Menu integer menu_handler; integer menu_channel; menu(key user,string title,list texture_list) { menu_channel = (integer)(llFrand(99999.0) * -1); //random channel menu_handler = llListen(menu_channel,"","",""); llDialog(user,title,texture_list,menu_channel); llSetTimerEvent(30.0); //menu channel open for 30 seconds } default { state_entry() { composelist(); //make list from inventory textures } touch_start(integer total_number) { user = llDetectedKey(0); menu(user,"nnPlease select one below.",texture_list); } listen(integer channel,string name,key id,string message) { if (channel == menu_channel) { llSetTimerEvent(0.0); llListenRemove(menu_handler); if(message == "Next Page") { menu(user,"nnPlease select one below.",texture_list2); } else if(message == "Last Page") { menu(user,"nnPlease select one below.",texture_list); } else { llSetTexture(message, side); } } } timer() //Close the Menu Listen or we'll get laggy { llSetTimerEvent(0.0); llListenRemove(menu_handler); } changed(integer change) { if (change & CHANGED_INVENTORY) //inventory has changed { llSleep(0.5); composelist(); //rebuild the list } } } Some basic modding of the script will do what you want.

I am not getting involved in a despute over a user not reading the parameters reqiured. There has been no issues in all these years with that function.

There is no point. The issue decribed is user induced. The sanity check is simply reading the functions parameters.

Screen resolution has nothing to do with what the poster claimed. It is caused by using non-default values.