Wulfie Reanimator

To clarify what Qie is trying to point out, you cannot rotate an attachment towards an avatar if it is attached to anything besides Avatar Center. This is because animations are client-side only, which means that attachments (and LSL as a whole) don't know where they should be pointing if an animation (which aren't the same on every viewer) is changing them visually. Essentially, this is all you need to logically do exactly what you want (with the same code expanded): You can put this code anywhere you want the object to rotate, I tested this directly in a repeating timer event. key id = "779e1d56-5500-4e22-940a-cd7b5adddbe0"; vector target = llList2Vector(llGetObjectDetails(id, [OBJECT_POS]), 0); llLookAt( llGetPos() + (target - llGetPos()) / llGetRot(), 3, 0.2 ); key id = "779e1d56-5500-4e22-940a-cd7b5adddbe0"; vector target = llList2Vector(llGetObjectDetails(id, [OBJECT_POS]), 0); vector origin = llGetPos(); vector direction = target - origin; vector direction_in_region = direction / llGetRot(); llLookAt( origin + direction_in_region, 3, 0.2 ); But note that getting the avatar's rotation will always be kind of inaccurate. llGetRot's wiki page states as much, and llGetRootRotation gives the avatar's rotation instead of the attachment's root. This same applies to llGetObjectDetails(llGetOwner(), [OBJECT_ROT]).

Don't concern yourself with memory usage until it becomes an actual problem in your script (e.g. it crashes because it ran out of memory). The amount of channels you use doesn't matter either, because you are ultimately limited to messages from the owner only. Multiple channels like Steph is suggesting is not necessary unless: You are listening for messages from everyone, and.. Your script is doing something that requires a lot of script time, like lots of calculations, big loops, etc, and/or.. You are listening on channels 1-9, because these are the most commonly used channels and are likely to cause many listen events for your script, most of which you have no interest in. Listening and communicating on these common channels might spend unnecessary script time and could be easily avoided by just using a different channel. This might also be insignificant if you have some simple check in the listen event that prevents anything "heavy" from being done until you know you care about the message.

I should've said continuous. The type of algorithm used isn't relevant.

Because the slider is a linear scale between 20k and 350k, the increments you are seeing are entirely based on wherever your mouse pointer happens to stop. Technically the smallest increment on the slider is based on the resolution of your UI and monitor (and therefore, the distance between individual pixels on the slider). You can have numeric input though, literally every adjustable thing in your viewer (even those you can't find normally) are listed under Debug Settings (Ctrl Alt Shift S). Search for RenderAvatarMaxComplexity and set the value to anything you want.

The plot thickens... Note: That's from November.

Much lower land impact, generally.

This is caused by this section of your script: // ... if (ItemName != llGetScriptName()) InventoryList += ItemName; } llGiveInventoryList(message, llGetObjectName(), InventoryList); After your loop has finished, you send InventoryList without checking if anything was added to it. You must check that the length of InventoryList is greater than 0. // ... if (ItemName != llGetScriptName()) InventoryList += ItemName; } if(llGetListLength(InventoryList) > 0) llGiveInventoryList(message, llGetObjectName(), InventoryList); I would also generally advice you to be wary of leaving out the brackets after an If-check, it could easily lead into mistakes. Personally, if I leave out the brackets, I keep the following statement on the same line as the If-check itself.

It is, I believe. But the fact that you have 9 property wrapped materials won't prevent one of them from dying on upload. And if you manually UV unwrap with default settings, you're almost guaranteed to not keep the UVs as you'd expect. There's no easy fix because you HAVE to merge materials together. If you want them to look identical, it's gonna take some work.

The textures will get messed up because a single object can only have up to 8 separate materials. A default prim cube has 6 faces/materials, joining two cubes in Blender would total 12 materials, so some of them will be merged in some way. Manual unwrapping is required.

This is very easy to believe, Apple has always been a pretty proprietary brand. That doesn't have to be the only reason though, and I stand by what I've said, especially in general.

Mumbler scripts don't speak AS your avatar, though. Sure, a script can change its name to match an avatar's name, but the messages are coming from a separate object and the difference is very noticeable by default. Same goes with other avatars "making you speak," it's an object talking, not your avatar. Syncing one's camera to where your camera is is kinda the same thing, they don't really "see what you see," they just know what your camera is pointed at (so they don't see your HUD or chat windows, the same animations/sounds might not be playing, they won't know if you have something derendered..), and they must be in the same region and not blocked by parcel privacy. Controlling an avatar's movement is another very simple non-RLV feature, scripts can push the owner's avatar even in no-push areas, that's how it's done. Note that I don't disagree with anything you've said, I'm just clarifying some of the details and reiterating that none of these things are related to RLV.

Rolig means the last function listed on this wiki page. llSetLinkPrimitiveParamsFast( integer link, list rules ); // For example, show "hovertext" above link number 2 llSetLinkPrimitiveParamsFast( 2, [PRIM_TEXT, "hovertext", <0,1,0>, 1] );

Oh... You might be tight, I'm posting from mobile and didn't see the type table. In that case I'd fall back to the old and boring notecard reader with name/price matching. Also can somebody write a JIRA for a suggestion to expand the inventory request function? It should at LEAST be able to get the description and creator of the item.

Interestingly, yes, it is possible. (I didn't expect it but I figured it should be possible.) http://wiki.secondlife.com/wiki/LlRequestInventoryData

RLV doesn't actually allow anyone to spy on the person wearing the RLV attachment. RLV either prevents you from doing something, or forces you to do something. (RLV can't force your avatar to speak or send IMs, though. The full RLV documentation is here and I have read all of it many times.) Spying on your conversations can be done with regular, non-RLV scripts (Doing that is almost guaranteed to break LL's terms of service, though.) and the spy does not need to be online as the logs could be sent to their email address.

Personally, I'm mostly okay with this. Not because I don't use Mac, but.. OpenGL has been around since at least 1992. 26 years. Sure, it's been iterated on over time, but for how long is it reasonable to demand support for old tech when newer, probably better alternatives have come around. Obviously I can't compare between different API choices, but I think Apple's choice to stop maintaining support for something as old as OpenGL is reasonable. For example, if you go and read Tonya's blog post about this, she says this in relation to "segregating OpenGL" in the code: While she's talking from the viewpoint of a Firestorm developer and their viewer code, you can apply this same logic to Apple developers and keeping their hardware/OS compatible. OpenGL is still around and being used, but it's built iteratively on top of very old code. It takes a lot of time to implement new things in a way that doesn't break old things. New things that may be more benefitial in the next 20 years than OpenGL when it turns 45+. I also come from the background of following a game for 6+ years, and watching it drop support for DirectX 9 (2002) and 32-bit systems mid-development after the game was already released for sale. Their reasons for these choices were the same. "These things are too old and limit what we're able to do." P.S. In case anybody missed it, also from Tonya's blog post:

You might want to read up on the wiki page on what kind of constants you can use in your key checks. http://wiki.secondlife.com/wiki/Control

Sadly no, but the change is noticeable between Mono and LSO, where LSO becomes responsive much faster, even in very stressed regions.

How memory is handled internally is not a mystery, we've had Lindens talks about it (and Mono in general, specially in that one 1 hour(?) long panel) in great technical detail and more intricacies have been collectively documented on the official wiki. For what it's worth, I have experience with other programming languages as well so I have a more general understanding supporting my (admitted) speculation.

But to reiterate on what I said in my last paragraph of my correcting post, I believe using a memory limit decreases the time the sim spends calculating how much memory a Mono script is using while it's being prepared for transfer. (Sim crossing, rezzing, etc.) If you have no memory limit but have 90% free memory, the sim will theoretically waste 10x the time looking up where the allocated memory ends. A memory limit is a form of optimization and it should be used only when your script is past initial development and you know how much memory it realistically needs.

The point I was making is that unlike what a lot of people think (that a function will take up 512 when used) isn't really true. Using multiple custom functions will inevitably cross the threshold for another 512 bytes, but so will a few regular variables, or a list. In general, especially if you're only using under or around 10KB of memory in total, optimizing memory use really shouldn't be your concern, it's called premature optimization. Everybody should read about it, it's kind of interesting.

While maybe generally true, even user-defined functions don't always take up more memory in Mono, only when "needed." I'm not entirely sure what the criteria is for when and how much memory is allocated, though. For example, all of this is in state_entry with no other states: llOwnerSay((string)llGetUsedMemory()); // 3364 bytes llOwnerSay((string)llGetUsedMemory()); // 3364 llOwnerSay((string)llGetUsedMemory()); // 3364 llOwnerSay((string)llGetUsedMemory()); // 3876 integer a = 1; integer b = 2; integer c = 3; integer d = 4; llOwnerSay((string)llGetUsedMemory()); // 3876 So.. memory usage went up by 512 bytes before and after. This might be explained by memory allocated for bytecode in chunks of 512. The same behavior is seen when moving the integers to a user-function and calling that function. (Even though it does nothing but declare local variables and not use them. Unused functions get optimized out and consume no memory.) But... userfunc() { llOwnerSay("hi"); } default { state_entry() { llOwnerSay((string)llGetUsedMemory()); // 3876 (7*512 + 292), same as with the integers earlier userfunc(); llOwnerSay((string)llGetUsedMemory()); // 3920 (+44) } } Calling the user function only took up 44 bytes by the time the function had returned and memory was checked again. If the second llGetUsedMemory is put inside of userfunc, the memory use increases by an additional 4 bytes, still not quite 512.

@steph Arnott @Wandering Soulstar @Rolig Loon Regarding script memory usage and limiting it.. Script that run in Mono, which is the default mode, use a dynamic amount of memory at all times. A script with a memory limit of 64KB is actually using only the amount of memory it actually needs. (That is one of the big features of Mono, besides being faster and sharing their bytecode with other identical scripts.) Things like OBJECT_SCRIPT_MEMORY cannot find out how much memory a script is actually using, which is why all of the "script meters" (and Firestorm's Script Info) will give inflated results. In LSO, the old script runtime, all scripts use 16KB of memory no matter how little code is in the scripts, like @steph Arnott stated. The unused memory is "padded" with empty bytes and consumed from the sim. I believe there is a benefit to setting memory limits, though. Whenever a script is rezzed or moved between regions, the script's active memory must be stored and transferred between the servers. For Mono scripts, this means calculating the exact amount of memory that needs to be sent and freed, because the memory space is dynamically sized. LSO scripts are much better in this regard, because they are a set size, continuous block of memory. LSO may be slow, and it has its advantages over Mono, but memory is not one of them.

I do not understand. Can you show it in a simple script?

Means the same thing. I don't like how you jump on people and tell them they don't know what they're talking about, when you make that same mistake in the same thread. Those two things do completely different things. The fact that you try to deny that there's a difference between assignment and comparison just makes it obvious to anybody else reading that you're not knowledgeable. Put this into a script and study it: integer a = 1; integer b = 2; integer result; result = (a != b); llOwnerSay( (string)result ); result = (a = !b); llOwnerSay( (string)result ); result = (a=!b); llOwnerSay( (string)result ); Also, please answer my earlier question to you. And just to echo what others have already said, I don't find states very useful beyond disabling touch and clearing listens. Fragmenting the logic of a script into multiple pieces is something I would want to avoid as much as possible, to keep the script easy to maintain for myself and whoever else might look at it.