Nova Convair

You can send emails to objects. So rez an object and put in a simple script that relays incoming emails to im's.

Only one detail is missing: a state change removes all listens. So - if you have no clue which of your many listens are open - you could change state and change back - all closed. But of course a real scripter always knows what listen is active and don't needs that big wipes.

llRezAtRoot can shoot out a rezzed object with the defined speed - but only a physical object can move. If your rezzed object uses KFM (KeyframedMotion) then it's non physical and the rezzer has NO influence on its movement. Keep in mind that the KFM vectors are relative. <10,0,0> will make it move 10m forward on its own positive x-axis.

To be more precise: I'm parking on the Lagrange point over Lagrange Point - which is not easy in SL - the gravity is everywhere. But since it's a cheated gravity I defy it by cheating.

It's dark and quiet here in a high orbit over Lagrange Point.

36k atm. Once it reaches 40k I delete a few 1000. And I always find a few 1000 to delete

Easy to solve. Just allow the owner to set the priority. no mod permissions have no effect here of course. Problem solved once and for all.

Voice and public chat is switched off when you block them. They are rendered as grey jelly babe or particle cloud - depending on your viewer and settings. Or not rendered at all if you additional derender them. You don't see any IM's they may send you but they can send you money and - I've heared - objects too. The blocked avatars will see no difference, so they don't know if they are blocked.

Does not work The object you want to drop something into needs to be MOD The object that is dropped needs to be TRANS - this seems to be the case according to your description

Just do it the other way around and use llGetUsedMemory and your questions you can answer yourself by using a test script. string test; default { state_entry() { llOwnerSay(llDumpList2String(["A",llGetUsedMemory(),llGetFreeMemory()],"\n")); } touch_start(integer total_number) { test = "djdjdjdhfgsdgsgsazezehehegegetetgdgdgdddddddddddddddddddddddddddddddddddddddddddddddd"; llOwnerSay(llDumpList2String(["B",llGetUsedMemory(),llGetFreeMemory()],"\n")); test = ""; llOwnerSay(llDumpList2String(["C",llGetUsedMemory(),llGetFreeMemory()],"\n")); } } As you can see - if you run it - llGetUsedMemory shows code+data llGetFreeMemory shows the free data but does not take unused and freed memory into account. There is no documentation about the compiler and the runtime environment of the scripts but it seems there is nothing too fancy. So I assume global variables go to the heap which will be fragmented over time. (Can be avoided by allocating data with a plan in mind) Local data used in functions goes to the stack. And the stack pointer is reset to the old value when you leave a function. So all local data in functions is 100% freed once you leave a function. That does not help you if you need persistent data though.

According to the wiki llGetFreeMemory does not return the free memory. It returns the free memory prior to the garbage collection. That means if you have unused and freed data on the heap llGetFreeMemory will not count that. Quite a while ago I've read (don't know where anymore) that mono executes the garbage collection only if it's needed - that's when you exceed the 64k limit. It will execute the operation even if you exceed the 64k and will run a garbage collection after that. llGetSPMaxMemory only makes sense if used with llScriptProfiler and will return the most memory used during or after profiling. You can use that to find out the how much memory a function uses for example. A fresh compiled script has never used any memory so llGetFreeMemory will return the highest possible value for that script. A reset should have the same effect by my opinion but I never tested that.

Oh, it does listen. llListen(-99, "", llGetOwner(), ""); It listens on channel -99 to the owner. Who is the owner? Only your avatar. Your objects don't have your uuid so they are filtered out. You want to have it listen to objects that are owned by you. It's not possible to set that in the listen parameters, so you need to change that line to: llListen(-99, "", "", ""); The other filter in the listen event you have already installed: llGetOwnerKey(id)==llGetOwner() that gives TRUE if the uuid is your avatar or one or your objects - so that will work fine. All you need to do is change the llListen.

Yes, of course. For non premiums its alot more difficult to hammer yourself into a full sim. That seems to be a problem for some or even many people. So LL made a reason for the shopaholics to become premium. Mission accomplished

That has nothing to do with the viewer. You either wear it or it's rezzed - the thing that repeats you.

LL is pushing premium for quite a while now. Maybe they got inspiration from free to play games? All the advantages (including this one) I don't care. But the more they add they will hit the "soft spot" of more and more people. The effect on SL - don't know - only LL has statistics.

The reserved spots are added! If a sim holds 100 avatars it holds 110 now and the additional 10 are reserved. For non premium user it changed NOTHING they have still 100 free spots as they had b4. So most complaints here make me kind of laugh. If a sim owner reduces the # of avatars they need to add the 10% on their own. If they dont do it they maybe are too stupid or maybe not - however - it's their sim and their rules. From my point of view, I don't care.

LSL is not officially documented. Most info's about it you find in the wiki and thats user made. Scripts remain on the server, you can only upload source code and the server will compile and save it. You can not compile it yourself. There is an LSL plugin for Eclipse that includes syntax check and can simulate an environment with running scripts. So someone has build at least an interpreter. The plugin name is lslforge - besides of that I doubt that you will find much info about LSL.

There are 3 separated worlds. 1st life, 2nd life and some roleplays inside of SL. I don't have connected them, just in my dreams things mix up because the firewall is down there. I don't see that as a problem as long as I still know who I am when I wake up. But a background story for SL as a whole? I don't need that. Well, in case that one of the poor people that can not separate RL and SL wants to know everything about my RL then I can quickly draw out a background story and point them to my RL profile picture. That will make them run fast.

I can edit a mesh object in a way that it is not selectable anymore. If I make it invisible using alpha mask its a nice blocker that will baffle most people. But I can always select everything on the sim by using Pathfinding/Linkset and then I can delete/return it. Only the old ghost prims require a sim restart but I haven't seen that in the last few years.

The position of the root prim counts. So its no problem to rez something outside of your land that will encroach into your parcel and is not rezzed on your land. You should be able to return it though.

A script can detect anybody anywhere on the sim. There are no limits. Only if the orb is outdated then it's limited in range. Did it message your neighbour? Absolutely possible. Nobody but your neighbour can tell. I suggest to check your orb settings. Most have a setting that restricts their activity on your parcel and have an eye on the range too. If it continues to message avatars out of scope it's buggy.

I never got this bug in all the years but of course I always wear one item per attachment point. I noticed that there is a lot of stuff that defaults to the same attachment point. I always shift that immediately.

The animation script error is easily avoidable. Looks like a bad free script here. There is no way for a script to check your groups. It's only possible to see if you wear the same group tag as the scripted object. Most scripts don't even check that. You need to run and maintain your own database of your customers and you need a bot that constantly keeps the database updated (to catch entry's and exits). Way too much for most merchants. Same applies to the LM giver - usually a simple free script and no database behind it. Keep in mind that the merchants are no professional organisations and are usually not able to handle this stuff and if they can they don't want to. Sending boxes instead of a folder is annoying for everybody I think, but only this way the merchant can pop up all the garbage and info that we have to click away. For the traffic: I'm pretty sure that LL's expensive servers can handle that little extra traffic with ease.

You need to log in to see that of course

No it's not a matter of textures permissions but object permissions. I didn't analyze the script and don't know why it reads out the textures. Maybe it's sufficient to set some global variables with the texture uuids and use this variables instead. If you don't have the textures you need to ask the creator or make your own. But llGetTexture or llGetPP are not able to read textures on no mod objects, no matter who owns the texture. It's mentioned in the wiki and I found it out the hard way some years ago.