Wulfie Reanimator

Can you give an example of some kind of logic that cannot be done without multiple states? "=!" is not an operator. It is two operators; "=" (assignment) and "!" (logical not). "!=" is an operator. It means "not equal".

Items in object inventories are always sorted alphabetically and there's no way to change their order. You could collect all the names of the items in inventory into a list and then randomly sort that list (which would only affected the list of names, not the inventory items). What exactly are you trying to do, and why is it important to have the items "sorted?" Maybe there's another solution.

I totally agree, the griefer must be REALLY good at it if they can change the files or memory on your computer without infecting your computer first. And if they can do that, what's the point of protecting your whole computer? Your computer hasn't been infected, so having the world's best security system installed isn't going to save you. 😂

The code you've posted shouldn't work at all, because all of the llDetected* functions only work in the collision, touch, and sensor related events. What you need to do, is get the object's own group first. You can do that with llGetObjectDetails and OBJECT_GROUP. (Attached objects are always set to the avatar's active group.) Then, you just check whether or not it is the same as whatever group UUID you want. key allowed_group = "779e1d56-5500-4e22-940a-cd7b5adddbe0"; list details = llGetObjectDetails(llGetKey(), [OBJECT_GROUP]); key object_group = llList2Key(details, 0); if( object_group == allowed_group ) { // groups match } Note: I used my own avatar key as the "allowed group," so you must change that. I also wrote the code to be as simple to read as possible, most of this could be done in a single (rather long) line. You could also use a list of allowed groups, and check if the the object's group matches any of them. list allowed_groups = [(key)"779e1d56-5500-4e22-940a-cd7b5adddbe0", (key)"0375a183-05f6-450d-f0db-888574fdeea8"]; list details = llGetObjectDetails(llGetKey(), [OBJECT_GROUP]); key object_group = llList2Key(details, 0); if( llListFindList(allowed_groups, (list)object_group) != -1 ) { llOwnerSay("groups match"); } Again, I've tried to leave out as many complexities as possible, but there are a couple important things to know here. When you put UUID/keys into a list, their type is string by default. If the list has a string that matches your key, they are not considered the same because they are different types. That is why you put "(key)" in front of the string to change its type. There are other ways to do this, but this is an example. The same thing is done in the IF check -- llListFindList compares two "lists" and tells you where the match is found. The (second) list we are trying to find in the bigger (first) list only has one thing; the object's group key. We can just change it into a list so that llListFindList can use it. In this context we don't actually care where that match was found exactly, so we can only check that llListFindList doesn't return -1, which means "not found."

Make running scripts a group-only privilege, and prevent certain people from being in the group.

In that context, I think the most correct answer is "there is no answer." Since almost everything in SL is created by the users, there really isn't many standards people tend to follow. Even if you created a shape for your avatar that worked with that tripod pose, moving over to the next no-mod thing you have is going to have animations and object sizing created for that creator's arbitrary choices. You can try your best to find the "most practical size," but you'll never escape the need for adjustment in our nonstandard world.

It really depends on what kind of communities you hang around at. For example, my friends and the places I go to (primarily furries) tend to be fairly realistically sized on average, if not below the 185-170cm height. Giants are the rarest category and it's generally used as a deliberate style choice, rather than some kind of accidental "can't be too small or I won't look alpha" shape. But I also think height is a red herring. You can have an avatar with an "adult height" but still look very questionable, depending on a lot of other factors. One of my male avatars for example is 187cm but is so cutesy that a lot of people would mistake it for a child/teen (or a girl..) without (or even with!) a size reference. You can have avatars much shorter than that and no one would bat an eye if designed right. TLDR: Make the avatars you want and ignore the height police unless it is the owner/staff of the area you're in. If someone is bothered by your height alone, they're probably not the kind of person you'd want to be around anyway.

Hold on, I'm a bit confused. If you're using RLV to auto-accept all teleport offers, but don't have a way for someone to offer a teleport without sending them an IM, wouldn't the person about to offer a teleport already have the avatar's name and be able to just send them a teleport through their profile or IM tab without typing anything? I thought your problem was that the person wanting to teleport avatars to them didn't have any names, and you needed a way to let them know who was available. I think I understand what you mean by "handle" now, is it the clickable link that would bring up their profile (or right-clicked for more options)? If that's the case, this page should be very useful for you: http://wiki.secondlife.com/wiki/Viewer_URI_Name_Space You can create a clickable link ("handle") for any avatar as long as you have their UUID, which you can get with llName2Key or llRequestUserKey. secondlife:///app/agent/UUID/about secondlife:///app/agent/UUID/offerteleport When shown in chat, the first line would create a link with the avatar's name that opens their profile, just like you see in the chat log. The second line will open up the "offer teleport" prompt when clicked, instead of their profile. Then you can just click OK and the offer is sent.

You do not need to use llListen after region change. It will not stop working.

To add to what Innula said, certain third-party viewers (Like Firestorm) have chat commands that perform special actions. Specifically, typing "rezplat" into local chat will rez a platform 2 meters below your avatar's feet. (No message will be shown in chat.) By default the platform is 5x5x0, but you can specify any size between 0 and 64: "rezplat 1.5" = 1.5 x 1.5 x 0.01 platform You can find all of the special Firestorm chat commands in Preferences > Chat > CmdLine

I genuinely love to see Lindens join in on the technical conversations (and I hope to see it happen more often!) but.. I have created a prim and put this script inside it: (P.S. your script wouldn't compile because you used "what" and "change" in the changed event, I fixed that) integer MY_CHANNEL = 42; integer establishListens() { return llListen(MY_CHANNEL, "", NULL_KEY, ""); } default { state_entry() { establishListens(); } // changed(integer what) // { // if (what & CHANGED_REGION) // { // establishListens(); // } // } listen(integer channel, string name, key id, string message) { llOwnerSay(message); } } Notice how the changed event is commented out, so it will never be reset during this test. Then I attach the object to my self and type "/42 first message!" into chat. Works fine, as expected. (Sim: Mill Cove) Then I walk over a sim border to a neighboring sim and say "/42 second message!" Works fine. (Sim: Falling Rose) Then I teleport to an island sim with no neighbors and say "/42 third message!" Still working. (Sim: Fluffy) The reason why this works, I believe, is because llListen is a "property" of the script. llListen essentially "subscribes" the script itself to a specific channel, the handle is stored under-the-hood and llListen returns an index for the handler so that it can later llListenRemove or "unsubscribe." (Fun fact, you don't need to store the listen handle to remove the listen. The first handle is integer 1, the next handle will be integer 2, and so on.) When a script's state is prepared for transfer to another sim, its subscriptions are kept. llDialog does not use a handle, it simply tells the avatar's viewer to open a user interface, and the viewer is the one giving a response when the local user clicks a button on the local dialog. Part 2: Actually restarting the listen Let's uncomment that changed event and add a dialog menu on touch_start: integer MY_CHANNEL = 42; integer establishListens() { return llListen(MY_CHANNEL, "", NULL_KEY, ""); } default { state_entry() { establishListens(); } changed(integer what) { if (what & CHANGED_REGION) { establishListens(); } } listen(integer channel, string name, key id, string message) { llOwnerSay(message); } touch_start(integer n) { llDialog(llGetOwner(), "dialog", ["test"], MY_CHANNEL); } } When I click the attachment, I get a menu and click the "test" button. It works as expected. (Sim: Fluffy) Then I click the attachment again before teleporting to another sim while the dialog is open. Then I click the dialog button. Nothing happens. (Sim: Falling Rose) If I click the attachment again and click the dialog button while staying in the same sim, it works as expected. (Sim: Falling Rose) Then I click the attachment again before walking over a sim border. Then I click the dialog button. Nothing happens. (Sim: Mill Cove) This, again, proves that there is nothing wrong with llListen or the sim not receiving sent messages. The problem is that no message is being sent in the first place.

To quote myself: But limiting your HTTPRequest to the same sim doesn't change the external nature of the function, and doing that wouldn't serve the OP anyway because they are specifically asking for cross-sim communication. The system I linked is a good example because it demonstrates how to update each attachment with the URLs of the other attachments from other people, allowing anybody to get an up-to-date list of people available for teleport. P.S. I'm not going to compare our own projects in a public thread because that wouldn't help anyone. Maybe send me a PM instead.

This is going to sound rude but you've been posting in a lot of threads recently: Please educate yourself on what you are talking about and go learn to be more constructive with your writing if you are going to try and punch down any information given by others. Those functions you're referring to ARE part of external communication.

Communicating across separate sims requires some kind of external communication, like a web server OR inworld objects that have requested their own URL from the sim they're in. Here is an example of a grid-wide communication system: http://wiki.secondlife.com/wiki/Intercom#How_it_Works

I think there is a disconnected listener on the forum somewhere but I don't know if it's local or server-side.. Edit: Upon further inspection, it is evidently the latter.

To clarify a little bit: animations are what control what your avatar is doing, not necessarily scripts. AnyPose has a LOT of animations that control small portions of an avatar. The guaranteed way to stop blinking for example, is to create an animation that only affects the bones for eyelids and just.. not move them.

I understand very well. Can you prove (and objectively demonstrate) that the listener itself stops working? I thought it did, at first, but I have demonstrated that the dialog stops working because the viewer will not give any input in the first place.

Communication is handled server-side only, yes, but dialog menus are client-side in that it is the viewer that sends a message when a button is clicked, not the sim. Evidently it is the local viewer that discards the menu on sim change. We can't make a definitive conclusion on whether the sim would relay the message properly if the viewer did keep the menu, unless we can do the same test with a viewer that does not discard the menu.

Can you be more specific or post the full code? If you have a sit-target (on link 1), the avatar will always sit on that, regardless of which part of the linkset they right-click on. This is true even if you have a sit-target on link 2 as well. Sitting on link 2 (while it has a target) will put the avatar on sit-target 1, and a second avatar will be unable to sit because "there is no room."

I just did a test to see if it was the listener that was disconnected or if nothing was said in the first place. Using llDialog on channel 0 so my avatar would speak in local chat, clicking a dialog button wouldn't cause anything to be said in chat after walking over a sim border or teleporting to another sim. You would have to give the menu again entirely, because just restarting the listener wouldn't make the expired dialog menu work. It seems like it's the viewer that discards the old dialog when connecting to a new sim.

Okay, in that case (and this is purely a guess) I think the problem is caused by the way listeners work. When you use llDialog, the sim you're currently in registers a listener for a response. If you move to a different sim though, that new sim won't be told about any listeners registered by the previous sim, because the listener is not directly related to you or the object/script. (llDialog doesn't give a listen handler, for example.)

The llDialog buttons work by actually making your avatar speak on the dialog's channel. If you are beyond 20 meters from the object that gave you the menu, clicking the buttons DOES make your avatar say the button text, but the object that gave the menu is too far away to receive it. Try using llDialog on channel 0 to clearly see what I mean.

Indentation is important... if(llGetOwnerKey(id) == llGetOwner()) { if(message == "On") // <--- all code is inside of this check, { // the other message checks will always be FALSE. DRAWN = TRUE; llInstantMessage(llGetOwner(), " ON"); else if("off" == message) // <--- "else if" without leading "if" { DRAWN = FALSE; llInstantMessage(llGetOwner(), "OFF"); } else if("onifon" == message) { if (DRAWN = TRUE) // <--- DRAWN is set to TRUE, will always be true { llSay(-222,"off"); llSleep(6); llInstantMessage( llGetOwner(), "onifon"); llSay(-222,"On"); } } } // <--- this bracket needs to be moved up before the first "else if" // ... } ...because it reveals very obvious problems very quickly.

The hero we need but don't deserve. But also, @ellestones, I'm confused about why you would demand for BOM bodies be modifiable. BOM doesn't require modify permissions. I don't like no-modify stuff either, but any body that has an applier system will support BOM by default, so mentioning BOM and perms together makes little sense as there's no connection..

The HUD knows what rezzed it (look up OBJECT_REZZER_KEY). The HUD can use that info to check if the wearer is found as part of the rezzer.