steph Arnott

Sorry but i see nothing you have produced. The one i did release to the marketplace i was pushed into.

No LSL scripter has the skills to write real code. Rollig does. I do not and you certainly do not. BTW SL is not my life, scripting is nothing more than a logic puzzle to me. As for Lua i was writting code in that seven years ago.

New one on me. I wonder if another account holder on a different computer sees the same results. That code is client side so be interesting if other clients see the same as you do. I suspect it is only you that sees it.

Not even sure it valid for non LL viewers.

Knock? You talk about LSL as if it is not a library based top down, cut down basic scripting language. 'Like something being "memory hungry" is somehow less of a concern when you've got four times the memory to spare post-mono than before' that is drivel. Mono was set at 64k because some LSO used four time more memory when converted to mono. Mono uses double memory than 80% of LSO scripts. Mono was implimented because the asset scripts can be shared by multiple objects where as LSO did not. ' no, you claimed that LSL was open source and client written code was the clients copywrite. I stated that LSL is the copywrite property of Linden Research and as such any code using their library created code belongs to LR inc. The rest of your comments are basically ignorance. As for fireing me, you have never owned any company. I own seven, two in Japan.

What has any of that got to do with writting code in LSL? And no you are not going to gain a place on any professional team knowing LSL. LSL is ancient, klunky and outdated. Lua crushes it into the dirt.

'Code maintenance' is correcting faults and/or improving performance. In short not written well in the first place. That is why testing is done before release. Adding code is a modification that was never in the code in the first place. Very few in SL write code which does not glitch, most rush it out and then blame the client for the faults and/or the sim server. The issues are never their fault. This is only LSL.

' Branching menu systems are memory-hungry. ' uses no more memory than a single list. Was the case pre Mono. 'memory-hungry. ' are caused by inefficient script structuring. If code maintaince is needed after being tested then the code is poorly written. Only thing i do after my code is released is use it as a base for something else, or add something a client requested. Last thing i need is clients being uptight because of code faults. Was the reason i started writting code, I got sick and tired of the garbage so called experts produced. As for using secondry scripts for lists, you do that as a last resort because the data passing can cause issues if not done correctly.

It is server subjective. That means the server triggers capping by server load. The stated limit is the max alowed.

Bursting is when you accumilate multiple and send it in one. Rather than individually. The script should be timer based so that data never exceeds the penalty limit. In other words do not send every single piece everytime the script recives it. Stack it and then send it when the timer triggers.

Look LL implemented a safe guard to stop bad people crashing the sims. It is crude but it works.

The more you go over the lower the limit gets. You should halt all for at least twenty seconds to clear. If not it will keep adding to the rejection.

Would make more sense doing this. listen(integer channel, string name, key id, string message) { if(name == "whatever_it_called") { llOwnerSay( (string) id );//use this data for whatever purpose. Make it a global variable if you want to. } }

The odds of that are higher than you being the first woman on the moon.

But what is the point? Maybe i am half asleep because i just do not get it.

What does this do? listen(integer channel, string name, key id, string message) { if(llGetPos())

Am somewhat confused at the OPs request myself seeing as that is what the object_rezz event is for.

LL does, it is called land settings. It maybe that where you are the parcel/land is set to a group in which case you would have to deed the object to the group in the object perms. And BTW once you deed it, it is no longer yours.

You should also add ' if (llDetectedType(0) & AGENT) ' so the event only runs the branch code if an agent.

That LSL wiki example will push any agent that the collision event detects. But if the parcel/land is set to no push it will only work for the parcel/land owner. You need to see what the parcel/land settings are.

This threads problems have not been sorted out by the OP. Another problem on top is Titanic time.

Just make it non copy and die on detatch. That way it will not be in the agents inventory. But why would somene go to the effort of getting it off the MP for that to happen?

Two ways either a non copy item or llRemoveInventory( ); Though reading that again i am not sure if you mean delete the HUD.

Well not to be a party pooper but you need to write your own work. Using others just instilles all their poorly coded work. Which they probably kludged together using others poorly coded work. When i started i did the same and then decided to start with clean slate.

The prime part of your script is list manipulation. Lists are fundimental in many scripts. From object givers, yours, rezzers etc. The scanner data in this script is a data gatherer. If you kludge someone elses scripts you will never get anywhere because you are just hammering code with no understanding.