Wulfie Reanimator

I think the point they were making is.. "I will." Regardless of why you no longer have a business on SL, if you can't handle even second-hand criticism, your business has little chance of growing past a certain point as word will spread about how bad of a person you are to customers. Do you think "We do it this way and you can go somersault out of our store" is an acceptable response when you voice a complaint at a store IRL?

Do you also provide the required objects/mesh, textures, and animations? Or do you expect the scripter to have/create them?

The bug is about the Firestorm Bridge script. You're correct that it doesn't have anything to do with viewers or 32/64bit (Like Ichi/Lucia mentioned), but the JIRA that was linked is about a script being set to "not running," the same issue as what some of us have encountered here. There is a strong enough correlation that it can be said that it might be the same issue.

Scripts are actually the last thing to run on the sim, after everything else has already been handled. Usually, unless physics are to blame, most of the frame-time will be spent on scripts and "spare time" will be near-zero unless 100% of the scripts are being run every frame. Realistically, you can't expect any sim to be running 100% scripts and occasional script lag is the norm. I wouldn't say 40-55% like in this case is normal though, but 70-90% is very common.

Except for all the places that do exactly that...

Flatly, no. But in a greater context, like someone persistently targeting another person with malicious intent? Yes. But how easy that is to prove and how much is "too much" is very much up to the individual moderators' discretion.

Edit: Actually, I apologise. I badly misread Steph's post and I've removed the part of my post that was in response to it. As for me, I have noticed something similar, where I would create a new script and then immediately open it in-viewer and click the "open in external editor" button. Two things happen; when the script is opened, it is still set to "not running," and opening it externally saves the script which keeps it in the "not running" state. If I were to wait and reopen the script instead, it would be set to running and function normally. I always brushed this off as mainland lag though. It's probably not even the same thing as this happens before "Hello, Avatar!"

That obviously wasn't enough because the OP kept referring to it as kbps later. They thought their mistake was the "M" part.

I dunno why anyone hasn't caught this so far, but when you inspect scripts and it says "32KB" or "64KB," that's not the same thing as "kbps." Firstly, "KB" means KiloByte.. a thousand bytes. "Kb" (little b) means KiloBit and there are 8 bits in a byte. KB or bytes are generally used to measure memory use. Whatever number you see for scripts is the amount of memory they take up on the sim (not your computer). "Kbps" means "KiloBits Per Second," and it's used to measure data transfer rates, like your connection speed. But scripts or their data are never sent to any viewer, they only exist on the sim/server and a viewer will only be notified of any in-world changes (like a new position or color or hovertext). The bottom line here is that you don't need much bandwidth at all for SL, but even if you have lots of it, the total amount of connections in a short time can cause you to disconnect either from SL or from the internet entirely. I'm not entirely educated on how to fix it, but I would suggest checking for "packet loss." Packets are small pieces of information sent over the internet. Some routers are worse at dealing with lots of packets.

And in the nearr(tm) future, Bakes On Mesh will automatically combine worn system-layers so that you can wear any number of tattoos without the need for separate mesh body layers.

This is exactly what I was talking about earlier. Unfortunately there is no fix for this that I'm aware of, LSL just can't get the exact facing of a free-standing (unseated and not in mouselook) avatar. (Ignore Steph, Qie and I have already explained the difference in behavior between different attachment points and you're doing the correct thing.)

If you want everything done for you, make a post in these categories instead (with more information about how the head was made): https://community.secondlife.com/forums/forum/313-wanted/ https://community.secondlife.com/forums/forum/312-inworld-employment/ If you have any scripting-related questions, you can ask them here!

With all due respect, I don't have the words to explain how uninformed you seem to be about almost everything you've posted about on this sub-forum since you started and I feel sorry for all the newcomers trying to learn things and being confused by your misleading statements and advice. Before you dismiss people, and if you're going to tell people they're wrong, you need to start posting your own code and learn how to explain things in-depth. I don't think you're able to do that, but as long as you at least try to do it, people could correct you and... oh wait, you're never wrong. You've never been wrong. "Everybody else is wrong, end of." I wish you were better, for the good of literally everybody, but you've proven impervious to criticism and feedback. I've nothing more to say.

Yes, thank you for pointing that out. The purpose for the script I posted is to make it not do that, as was asked by the OP.

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.