Love Zhaoying

That's why llMessageLinked() / link_message() stands out. Because it is tempting to compare it to llSay() / listen().

Was the entire original post copied from an old thread? COOL!

I think sandpaper sounds more fair. The alternative being "eye bleach", why should I be the one to suffer?

OMG! If I ran into her jogging, I would be terrified. Even if I had 2 giant huskies with me. "Why aren't you in your own neighborhood? You aren't allowed to walk dogs if you don't live here. Got a cigarette? You're ugly and your dogs are stupid." <= REAL LIFE things that neighborhood Karens have said.

Actual picture of architects wearing famous NYC buildings they designed:

And, we did not need a post that was merely the "default new script" without any comments. 🙂

Maybe one day I will look more at "shorter" hairstyles. Maybe. Maybe not. If I do, then there will be more choices of hair.

The most counter-intuitive thing for me (which bites me on occasion) is that some Events trigger in any-and-every script that is "listening" for that Event. And, an event will even respond if triggered by itself. Sure, that's obvious for "listen()". But for "linked messages", it's bitten me a couple times, the fix being just add a filter at the start of the event. (No, using "states" wasn't a good fix approach for me.)

My general fix for this, is to use functions that get/save data in a global JSON heap. 🙂 Extending it: Use functions that get/save data in LinkSet Data using JSON. Pass the LinkSet Data Key around. Works pretty well.

Sheesh .. If it doesn't, maybe don't jerk off to it ? Healthy sex life, self respect, all that good mental health stuff ? TMI: There are some people (not ME), who no matter the subject of their "attention", go into a deep funk post-. For those people, nothing passes that "post-" clarity test.

Uggghhh. I am being forced to learn Python right now for my job, to help support a VERY poorly-written Python app. Written as a Website. Without using a Framework. Using "print()" statements for the actual HTML. Using almost no "copy/deepcopy", so everything is deceptively pass-by-reference. Couldn't get much worse. Python, not a fan.

Now that I have a "lot more" hair than I used to, I could change it frequently. But there's not much point. (Unless I start taking more pictures, or going out in "public".)

Does anything? Ever?

Friends playing "Russian Roulette" is usually the first thing I think of.

I'm going to quote you on that! ETA: Oops, just did.

because LSL is 'imperative' the possibility of functions having "side effects" is normal and expected, unlike those weird functional languages where you have to jump through hoops to make a function do something other than manipulate its arguments into a return value. All true. It is however important for some people to understand that all LSL functions are treated as if they are "pass by value". You've got to use the return result of any "string manipulation" LSL built-in function, for example. Otherwise the call does nothing for you.

It depends on what they do or don't know already. EVERYTHING in LSL starts with at least the "state_entry()" event, or a "touch_start()" event, or something. Since that is the case, there is no way to code LSL without events; it is always "event-driven". Explaining the difference would be hard if the other person didn't have the experience to know why it matters. If LSL was my "first language", I would think that it is pointless except knowing that LSL is indeed event-driven.

Yeah, I was surprised last time this came up (I was asking at the time). Because if you wrote a function to return a "string", you'd think that ignoring the return result would merit at least a warning!

This only works if the bots are "Registered Agents". Otherwise, LL would have no clue which bots are real "live" users.

This is the default script every time someone clicks the "new script" button. If the original poster doesn't know this by now...they will find out! They will also find out that the only thing "required" in a script is default state (I could be wrong, and often am).

Return types are "weird" in LSL. You don't have to use any returned value, no matter what the return type (if I recall correctly, not just for integer types unlike how some languages may be). You don't even get a compile-time warning. I'd agree with you if there was an explicit keyword "void" like there is in C! 🙂

Your Runes (or tattoos) really add a few years!

What is trivial for one person might not be quite so much for another. And as some relatively recent threads have shown, having a basic understanding of variable scope and "user-defined function" declarations (which are explained in the wiki in a rather terse way) can really give one a leg up in understanding ~why scripts work the way they do rather than copy-pasting examples. Yeah, working on my LSL parser recently, I had some epiphanies that are "obvious" but not usually stated: - Variables can only be declared "outside of states" (then they are global), or "inside" of User-Defined Functions or Events (then they are local scope to the UDF or event). - User-Defined Functions can only be declared "outside of states". - The only thing you can define "inside of states" is Events. An Event signature does not have to match the official definition for each parameter's "variable name", but the "types" of each variable have to match. - Events never have a "Return type". You cannot call Events directly.

Nice 'do!

Even a single function can do amazing things that take a long time to fully understand. I was talking to a friend who scripts for Minecraft the other day. He said something about how vehicle support is limited (and I assume complicated). Whereas, in LSL there is a SINGLE function that controls all vehicle parameters (not counting "taking controls"). So in some ways, the LSL library grew over time in such a way that you'll mostly find yourself focusing on the individual functions.