Nova Convair

I checked - the graphics card uses 2 * GlMem (in viewer info panel) plus a little extra of 0.3 GB. So the max. it takes in my case is 4.3 GB. My FS setting is 2 GB.

The GeForce GTX 650 has 1 GB memory. That qualifies for a viewer texture buffer of 512 MB maybe even the 768 MB that you have set. For more memory you need to have more memory in the 1st place. A graphics card with 4 GB for example. With a high draw distance you will have many GB of textures in your viewport and will overload any setting if the sims around you are more than just a desert replication. So listen to Alwin.

I made some load tests a while ago. 250 listens are nothing and if they are only active when someone is using/playing - the alternatives don't convince me enough to avoid the listens. 2500 listens are still nothing - when just listening. (Don't dare to use up that sim resource 24/7 though 😎 ) When sending 1000 messages as a brodcast to trigger all the listens at the same time (thats 2.5 million events - yes) you will notice a shattering of the force - err - the sim of course - only script-wise - but if you don't pay attention you will barely notice it. Depends on sim type and how much it is already under load of course. Self delete of 50 objects has no noticeable effect so I assume 250 makes no difference, 2500 maybe, but that takes only a second or two. I wonder how much load 250 returns will cause.

Many creators have not so much clue of creating. More creators have no clue of SL. Nearly no creator has a clue of scripting. What you expect? You get what you see now. It's not hard to make a script taylored for a specific hud - but only for an experienced scripter. It's surely possible to make a customizable script system for hud development. Big documentation is needed which nobody reads but IM the creator instead. So if there is really none on the market I do not wonder about that. 😎

Side note - if you have only one channel open you don't need to check the channel. For your Problem: just make sure that sender and receiver have the same OWNER not creator. This 2 are often confused. That way a stranger can not send you any command - even if they use one of your senders. default { listen(integer chan, string name, key id, string msg) { if (llGetOwnerKey(id)==llGetOwner()) { llOwnerSay("--------------------------------------"); llOwnerSay("sender's name is: " + name); llOwnerSay("sender's uuid is: " + (string)id); llOwnerSay("the message is: " + msg); } } } In case you really want to check the creator - then use llGetObjectdetails.

If I understood that right it's not too complicated: global: integer gBnumber; list uuid; // fill up with 10*15 uuid's listen event: string menuType = llGetSubString(msg,0,1); if (menuType == "B") { gBnumber = (integer)llGetSubString(msg,1,-1); llDialog( ...show the C menu ...); } else if (menuType == "C") { integer Cnumber = (integer)llGetSubString(msg,1,-1); integer index = (gBnumber-1)*15 + Cnumber - 1; // do something with uuid[index] } else if ..... You need a list with 10 * 15 uuids and the listen event needs to handle the A menu and back and cancel buttons and all the stuff around. But B+C menus can be done simple.

How do the menus look. Is that B1-B10 and C1-C15 on the buttons or are there 150 different texts? What you do with the result. Do you need 150 different script-actions or are things calculated out of the answers or are you just passing numbers?

I once made a rocket and the warhead uses that kind of script: Detonate () { llTriggersound(...); ... llTriggersound(...); llLinkParticleSystem(1,[...]); llLinkParticleSystem(2,[...]); llLinkParticleSystem(3,[...]); ... llLinkParticleSystem(n,[...]); llSleep(x); llDie(); } Overlapping sounds and overlapping particles. One prim per particle effect needed of course. You need to count the particles. How many per second you emit and how long they stay. The overall number needs to be under 4096 - if you think you have full attention on the only particle source around. If you plan a battle - reduce to 1/10th and make the life times of the particles shorter. More that one script is a waste but there is no reason that llMessageLinked will fail. If it does you messed it up. And I wouldn't use land_collision only. Alot of land is covered by a prim.

rez an object on ground right click - edit creator: who made it owner: thats you last owner: that one gave it to you

Guns dont rez bullets out of the barrel. They are rezzed from avatar center plus an offset to get the approx position of the gun and a few m in front of the avatar. (or you hit yourself) The direction will be where you look at in mouselook. You can not point at that position and client side animations absolutely don't match with server side positions. Same for earrings. The server has no clue at what exact position you and anybody else see the earrings but the scripts are server sided. You get the idea. Only rough positioning is possible and you shouldn't move much by using animations. Not sure why you think you need 2 rezzers. One script can rez 10 objects per second and that can be different ones of course. To get out more objects per second you need more rezzer scripts or rez coalesced objects.

I keep this things simple. A vehicle knows where it is and sends a message to the rezzer when it's at the right spot. For multiclick I usually take the time when the task is done and all touches within that time +0.75 sec (time depends on use case) are dumped. Effectively counters twitching mouse-fingers. For rezzers - they send the derez command (by whisper) b4 rezzing new stuff. Vehicles of course usually don't listen for derez commands (maybe they should until moved) - just wanted to mention alternatives - it depends on the special case what makes sense.

The performance of this place "Orchid" is excellent. I didn't notice any fps drops at other places too. Change viewer and drop what you wear, maybe you are the problem - more precise - your avatar.

In child prims: .............///(upper part of script)///..... link_message(integer sender_num, integer num, string msg, key id) { llPlaySound(sound, 1.0); explode(); llSetLinkAlpha(LINK_SET, 0.0, ALL_SIDES); llSleep(3.0); llDie(); } } /////End of Script The root sends a link message by llMessageLinked The childs receive this message in the link_message event So the action needs to be in the link_message event

Oh, good. Then i can block and derender you. No need to waste screen space and computing power. 😎

I see 3 ways - You clicked on something or sat on something - You have RLV active and and have no full control (well, thats one of the goals of RLV :) ) - Experiences - this regions hosts one and you signed in. In all 3 cases you kind of agreed - even if it's probably misuse - but that depends a bit on the location. In all 3 cases you can prevent that it happens again.