Wulfie Reanimator

Doesn't seem like it, there's no mention of "voice" on the API page at all.

You're right. I found some time to look at different outputs more and one thing that really sticks out is the closing curly-quotation used at the end of 1:9. Comparing it to other verses, like 1:11, which also has the closing quote without issues, the difference is that 1:11 also has a matching opening quote. I can't see any other oddities on the string itself. I didn't find any way to fix it though, or have the time to find other verses that only have the closing quote so I could double-check if it's that.

It's actually llOwnerSay that's the issue. Its output is always truncated to 1024 bytes.

What exactly do you mean by "weight?"

Small corrections: The code for an if-check will execute as long as the evaluation is true. "if(true)" will execute the code after it, but there's no implicit "if(true == true)" While the LSL constant TRUE has a value of 1, any non-zero value is not-false and would pass the if-check. "if(3)" will execute the code after it. When you are comparing things with == for example, you are actually creating a new value. "integer test = (3 == 3);" is the same as "test = 1" Edit: Ah, sorry, skipped literally the next thing you said so these aren't really corrections.

Missing the forest for the trees, are we?

Blender Cloud and the rest of their store says hello. Selling things doesn't make you automatically "for profit" and most open-source projects make money somehow. Edit: Yes, thank you for agreeing with what I said. Edit 2: @Drayke Newall I worked for the Red Cross for over a year doing exactly the same, our store making ~$125k/mo, with 5 others nearby.

Sadly, no. Integer division is going to give you an integer result. (Rounded towards 0.) One question would be: Do those integers need to be integers?

I would reassure @Scylla Rhiadra and @Madelaine McMasters that in this hypothetical world, C++ would be an option just like LSO and Mono. And I believe it's not even the specific language that matters, but some of the specific features they have. @Chaser Zaks gave a good example with list accessors. list choices = ["A", "B", "C"]; // current LSL: list item = llList2List(choices, 0, 0); // ["A"] string selection = llList2String(item, 0); // "A" // C++ array accessor, with implicit typecasting: string selection = choices[0]; // "A" Sure, in C++ specifically a "list" (array) must be of a single type unlike LSL lists which can have mixed types. That's not the point, the point is reducing the amount of typing we need to do what we want to do. I don't think this change/addition would be disliked or difficult to understand by most people. Another useful thing from C/C++ is grouping of different data so it is easier to pass around. Here's a practical example that I would accept as an addition to regular LSL code. // Describe a user and pass that data into a function to make bad decisions. // LSL: // No easy way to store all of this into a single list. // "inventory" might have more or less items. string name = "Wulfie Reanimator"; list inventory = ["glasses", "hot chocolate", "pillow"]; float awake = 129600.0; Function(name, inventory, awake); // C-like structure (not exact syntax, but very close) // Define the structure and name it. define user { string name; list inventory; float awake; }; // Now there is a new type called "user", just like "list" or "string" // Let's use it to define... me. // either user nina = { "Wulfie Reanimator", ["glasses", "hot chocolate", "pillow"], 129600.0 }; // or var nina = new user { name = "Wulfie Reanimator"; inventory = ["glasses", "hot chocolate", "pillow"]; awake = 129600.0; }; Function(nina); // The function call is now simpler too. // And it's easy to store and access grouped data to/from a list: list storage = [nina, rolig, chaser]; user test = storage[0]; llOwnerSay( test.name ); // "Wulfie Reanimator" llOwnerSay( (string)(test.awake / 60 / 60) ); // "36.00000" I don't believe this would complicate LSL. A structure like that is almost like another list, but more flexible, and this could be one workaround for "LSL doesn't support lists-within-lists." (Did I mention C++ has lists-within-lists and multi-dimensional lists? Down with strides!)

While I agree with you in principle and on a grander(?) scale, I think you're blowing this a little out of proportion in context. Primarily the emphasis on "every single word," not really. Still just each message as a whole, no extra work for the sim besides skipping the string-matching. Pattern-searching a string is not a very expensive method, and since that's pretty much all the script is doing, you can't even leverage the script-lag argument. This seems like it's probably going to be used by very few people, and even if 100 people on sim was using it, the chat lag from the sim checking for those 100 scripts would almost definitely not be noticeable. Here's where my agreements come in. "Don't listen public chat" is a good mantra so we don't accidentally end up in a bad situation in the future (I wish we had a similar mantra for high poly mesh), but for some use-cases it just can't be avoided. In this case they want an animation to play when someone else's script is triggered (which talks in public chat), so there are few (if any) options unless the creator of that other object has already taken this situation into account and it's talking in two channels at the same time.

Two things: Scripts are effectively "sandboxed," they cannot do anything outside of their own "space." While supporting another language, like C++, you can very easily prevent certain things from being done. You can block memory access outside of the script. You can just... not support pointers. Bonus: You can still enforce delays as well. The server is still in full control, even if the syntax is some "scary" language like C++.

There was a time when LSL had Classes like object-oriented languages, and when Mono was implemented, there was consideration about supporting at least C# as well. (But that was a long time ago.) The Boost library used for LSL is written in C++. While C++ is not an "event-driven language," there's absolutely no reason why C++ couldn't be used in an event-based context. People do, it's nothing special.

I'm gonna have to disagree with you there. Try rezzing a cube, make it physical, and drag it against your avatar (this is an easy way to make your avatar "run"). Or look at this KFM platform. Granted, if the KFM platform is thick enough (along the direction of movement), or it's moving slow enough, the avatar stops walking in place. That platform is 2x2x0.2 and anything at or above 0.4 meters per second on it will cause an avatar to walk. Same applies if the platform was narrow (0.2x2x2) and moving sideways. The tram in New Babbage is much slower but it still manages to reset my stand animation every couple seconds because my avatar gets bumped by physics and changes state from standing to moving. This is pretty basic character-controller stuff to me.

As the script is now, the animation will only play if someone says "ass" and nothing else. "Someone slapped your ass." will not be detected. The script would need to be modified slightly. Whether the animation loops or not is determined by the animation itself. Animations either loop or they don't, a script cannot loop a non-looping animation or the other way.

What you've described so far is too vague. A script can't change the color of your whole avatar, unless you aren't using the default LL body and everything on you is modifiable. There is also the concern that the other things on your avatar are probably scripted as well. Changing color on them might break them (if the other scripts rely on color), and if there are lots of faces to color, it might require a lot of script memory to record all of the original colors (assuming that you would ever want to return the original colors). If you have the script used in that example, you would pretty much just put that into all of your attachments and be done.

If you're just using the physics system (applying forces), no. Avatar animations are based on the avatar's state and velocity, not user-input. An avatar would also play a running animation while standing still on a platform that is moving up, because the avatar is moving and on the ground. To prevent this effect, you would have to override animations by manually calling llStartAnimation and writing an AO using on that function, not llSetAnimationOverride.

You... paid for this? Regardless, the script looks okay on first glance. Is there an animation called "twerk" (not "Twerk" or anything else) in the object's inventory with the script?

You don't have to send them everything. Any government-issued identification you may have is enough. Just one. You can verify with your Citizen Card, or your passport, or some kind of bank statement, or your driver's license, etc.

I don't think I was repeating what you said, but I definitely misunderstood the context. I changed the scripts a little bit (added timing restrictions) and went to a near-empty sim with 100% scripts running. Sender manages about 590-690 messages in one second, receiver gets 16-23 messages (15 or less very rarely), depending on if I wait a few seconds between resetting the script/loop. (script 1, script 2) So yes, receiving chat messages is a lot slower than sending them. Now, whether or not you need to update at or faster than ~15 times a second (timer of 0.066) is another question.

I can't comment on object update speed, but based on this statement I doubt that you are correct on it either. Scripts don't have a limit on how many messages they can detect per second, inherently. There is a practical limit based on the event queue, which can hold up to 64 unprocessed events before new ones are discarded, but the event queue is irrelevant for listen events. Each script will poll for new messages from the sim regularly, and generate events for messages it hasn't processed yet. This means that even if the event queue is full and an event is discarded for a new message, that same message will be requested again later. You can easily test this by using llSay on a loop with another object listening and printing to chat. In a laggy sim (70% of scripts running per frame), my object didn't miss a single message out of 1000 from a loop with no delays. (script 1, script 2)

Ah, that rings a familiar bell. I also found these in the wiki: Edit: I don't think that's what Animats is trying to get at. The lowest LOD for any medium-sized or larger model should be solid at least, like buildings as his example. A building that turns into a floating triangle is bad and useless in every case. A building with the lowest LOD as a solid 6-sided cube is still useful when viewed from across the sim.

Hey buddy, based on your post history it sounds like you of all people need to go enjoy The Great Outdoors. Whatever happened to you in the past year has had a clear effect on you. (Besides, Sansar is a bigger fail than SL, let's not kid ourselves.) Just go all the way and turn your Sims into an adult game!

It seems like this was a case of having more than 21844 triangles per material, as described by the wiki, though I don't know if that bug is still in effect. @Polyester Partridge Were the holes on the "bottom" mesh, and is it now under 21844 tris?

Sculpties are a menace with no benefits over mesh. Burn all sculpts. They cost more to download. (Bandwidth) They're a pain to texture. They can't do sharp corners without texture stretching. They're always spherical, physically speaking. (No custom physics model) If you wanna talk about the most anti-beginner content, there's your prime candidate.

Ah yes, I didn't think of region crossings. I also misread llSetPrimitiveParams AND misspelled llSetLinkPrimitiveParamsFast, I've blocked out the delayed ones' existence out of my head. 😂 You're correct there too.