Nova Convair

One of my alts could use a name change but the fee plus premium plus tax - that makes over 60$. This feature is obviously completely useless for me - at least I do not consider that for even a fraction of a second for an alt. 😎

Hmm .. my doors and other stuff does a channel calculation based on owner uuid and some math and a number that defines a logical block so I can have more than one communication cell in a sim. And I always have at least open/close/toggle commands - abbreviations like O,C,T - no need to waste space by writing whole words. Toggle is often not useful in my case. If you try to open an already open door with toggle you will see why. Of course I only switch that on for doors that need a remote and thats few. Other scripters will surely have all their own fancy ideas what kind of channel and what kind of comands are implemented. A door script is no black magic, make your own and add the remote function.

Probably not quite simple 😀 In your build is a controller-prim that is able to gather all data of the finished build. That is the relative position and rotation, size, shape, additional shape parameters, colors, whatever is used. The data needs to be retrieved for every prim in the build. Then your visitors can get a rebuild-prim. They can rez or wear it and this rebuild-prim will send a request to the controller-prim and the controller-prim will answer with the list of all the child prim data and it's own height over ground. At home your visitors can rez the rebuild-prim. The rebuild prim will move to the proper height over ground (so the model will fit - space to the sides I'd leave to the visitors - stupid placement will be punished) The rebuild prim contains a single build-prim with a script - it rezzes that build-prim and sends it the stored prim data - for one prim - the relative position and rotation is re-calculated into absolute pos/rot before sent to the built prim. The build prim positions/rotates itself and performs additional operations for resize, reshape, recolor, retexture, whatever. The rebuild prim will repeat the rezzing of build-prims and send each one one set of data from one prim of the original bild. Once all prims are rezzed there will be a rebuild of the original. Now the prims can all be linked by script and the scripts inside each prim can self delete. The visitor now has a copy of the original build and can take it into inventory - or use the build-prim again since that looks way cooler 😎 Some things to consider that can all be solved if it becomes a problem: - size of the data-list in memory - size of the messages when transfering data - communication to the build prims - you can rez 10 per second but it will take a while until they respond and process their data - so you need to send every build-prim a different data package and will have to manage a stack of open requests/commands 😎 - or send one by one but that will take a long while until the rebuild is finished.

From your description a notecard is completely unnecessary. It's very easy for a script to manipulate all childprims with the name "A". And it's dynamic and adapts immediately to all changes without creating a new notecard. To generate your notecard: - loop through all prims - for every prim: primlist += [name,link#] - primlist = llListSort(primlist,2,TRUE); now you have a list like: A,2,A,3,A,4,B,6,B,7, ... ,object,20,object,21 ... whatever loop through that and for every name change add a @@name: to a string

With llAttachToAvatar you need to be the owner of the object. Only llAttachToAvatarTemp allows to switch ownership - but you can not keep the object then and get no copy in inventory Another way is to rebuild The central controller prim stores the relative pos/rot/whatever of every single prim and contains a prim with a script that can execute pos/rot/reshape/whatever. Once the structure is stored - you only need to take the controller prim. The controller prim is able to rebuild the complete structure then - at the end linking and/or self deleting of the scripts can be performed.

Thrusters https://gyazo.com/741fc40a11cdf1b0fcd4c7560c208a47

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.

I don't know what you want to find out, so no suggestion here. When looking at your compass - are you aware that East is 0° in SL? North is -90° or 270° so whatever you do you need to compensate that.

llLoopSound use the wiki to find out about the details.

It can't work because it listens only to the owner and not to a hud. 😎

If you script you'll need to get used to check the wiki. http://wiki.secondlife.com/wiki/LlGetEnv