Void Singer

Alazarin Mondrian wrote: Strangely I've also had a mute / non-communicative Linden show up at my last two shows. no need to be paranoid, they could just be monitoring sim performance under load, or even just listening in the background.

cooking is another one... nautical culture is slow to change.. they have a heave emphasis on tradition. cooking is slow to change because common measure don't convert easily, and no one wants to put in that mush work converting old recipes to metric

Evan Reanimator wrote: [...] am I able to do the same but with textures and without the light. [...] yes

https://wiki.secondlife.com/wiki/Get_source_and_compile

as Qwal says, you have to add each person to the role for them to be able to set that roles title.... even if the only difference in the role is the title.... for free to join everyone permissions roles, you can manually add the first few people and also set the ability to add other members to group members role, so that anyone in that role can add other to it and you aren't stuck doing them all manually yourself. as for notecards, there is no way to make clickable links, you can however do it in chat secondlife://app/group/<uuid>/about will open the group pane

not against TOS... but sometimes I wonder if it should be.... setting scripted agent status is only required for bots that run on land in search, and there is no way for people in SL to know if that status is set. you can always AR for abuse of resources

pluto's planethood probably isn't a good example... it wasn't "proven" not to be, the scientific definition of what a planet is was changed, and the change excluded it.... and it's not just people in the US that find the change odd (people get attached to common definitions and forget that scientific definitions aren't the same thing) as for the US... yes there should be more of a push to actually use metric, it's included nearly everywhere, but seldom expressed in those terms. there is a slight argument for imperial measure, in that it's roughly based on common fractions, but because those fractions don't often follow a linear sequence it would be more trouble to rework it to do so than to convert to metric.

and just a simple check... are you close enough to hear the message? you must be within 20m of the prim that uses llSay to hear it.

it might help you to know how controls report... keydown = held:true, change:true keyheld = held:true, change:false keyup = held:false, change:true each key is a single bit in the control event, the bits positions match across the held and change variables. using bitwise AND (&) compares if particular bits (keys) are set to true or false. using logical AND (&&) checks if ANY bits are set.

no learning without exposure, but I'll count that as a questions so... gIdxColor = (gIdxColor + 1) % list_length; ~Y = (Y +1) * -1 -1 * ~Y = (Y + 1) * -1 *-1 -~Y = (Y + 1) * (1) -~Y = Y + 1 -Y = (Y * -1) ~(-Y) = ((Y * -1) + 1) * -1 ~-Y = (-Y + 1) * -1 ~-Y = (-Y * -1) + (1 * -1) ~-Y = Y - 1 X = 1 -~X = 2 ~-X = 0

ok, I've read that twice now, and I'm still officially confused. C^|B <-- A|vD A = actual root region position {regionPosA} B = swivel point (orbit center, locally offset from A).{precalculated, (regionPosB - regionPosA) / regionRotA} C = orbiting child prim current local position. {(regionPosC - regionPosA) / regionRotA} D = orbiting child prim local position after rotation (required for llSetLinkPrimitiveParams) rotArc = llEuler2Rot( <0.0, 0.0, 180> * DEG_TO_RAD ); //-- 180deg orbit D = (C - B) * rotArc + B if the same side of C should be facing B when moved to position D, also use: localRotD = rotArc * localRotC; if you use a smaller rotation, like 90 for rotArc, the position of D would be on the opposite side of B from A (it'd' be a straight line reading D,B,A) and you could apply the same formula twice to get from the above displayed C to D.

LL themed build mainland... which may or may not be a sufficient explanation...

maybe...

rotation in that formula would be the arc-segment to move..... for instance, if you wanted it to be 10deg more around the pivot point, you'd use a rotation that described 10deg off of zero rotation in your desired direction/axis.... or in other words, the arc of the circle between the old position and the new, centered on your old root prim... basically how wide a slice of pie to cut.

probably better to avoid the double assignment that the increment operation causes.... you could just write is as +1, but the double bit flip is faster and I expected someone would ask and I'd explain it

once upon a time I'd have taken a shot at that.... back before what I know now namely, that not only have greater minds tried and failed using methods far beyond me; but they've also spent large portions of their life on it. ps. that corrolary I was talking about? given a linear series of prime numbers starting at the first (n[1] which is 2), and ending at n[x], the sieve method can reliably find all primes up to n[x+1]^2 which will be the first one it misidentifies as prime.... it's a consequence of the square law, but very useful in computing your maximum numerical value you can handle when building a list sieve on the fly. mathematically it's probably too inconsequential to note, but procedurally it's significant.

if you mean fixed facing, then you may be after llRotLookAt, or llSetStatus (with the axis values set to false)

((local_pos_child - local_pos_old_root) * rotation) + local_pos_old_root

if you are looking to define the colors as static, then you want a list wrapper... the simplest list wrapper is a global integer that each time you make your call, you add 1, then modulus by the list length, and save the result back to the global gIdxColor = (-~gIdxColor) % color_list_length; //-- wraps the list index back to zero when it reaches the end of the list

llGetRegionName llGetParcelDetails

considering that and avatar in SL is easier to change than a shirt in real life, and there are expectations of attire in RL locations, I sincerely feel that you are making something out of nothing. just because a place is being suggested as an example of one thing, does not mean it is an example of all things... and the overall theme and limitations existed before this thread, and is integral to it's business model. It just happens to also provide an example of the things in this thread. There are other options to choose from, and it's not as if it were purpose created to serve this thread.

I find the argument of over non-human to be a non-starter... the point is to showcase scale, not inclusiveness... any person can throw on a human av for a few minutes to wander around and see the impact scale is making, and apply that to other builds, regardless of type.

yes, but programming geekery doesn't override my math geekery. true story: while in school I independently recreated the Sieve of Eratosthenes, by accident no less, to help with my homework, never having heard of it before... and went on to find two rules for primes before I learned about them (actually 1 rule, and a corollary I've never seen mentioned anywhere else). I was a math geek before I was a programming geek, which is why it's so embarrassing to admit that rotations still give me headaches and I just memorize the formulas and not the math. ETA: yes, I'm aware of the irony, that in different fields of math, some symbols have different meanings, but tau is a basic geometry variable, and it wouldn't do to have two conflicting uses in the same field... it's an interesting idea, although I'm not sure that I agree with the premise, I just think it needs a different symbol (a similar argument could be made the the circumference should be the base, giving constants for D and R of 0.3138 and 0.1592 respectively... but it's easier to measure a diameter or radius than a circumference)

I can't wait until PRIM_POS_LOCAL gets done (it's being worked on YAY) the formula for local position of a child is vPosChild = (region_child_pos - region_root_pos) / root_rot to rotate that around the root, simply multply the result but the rotation you want to add to it. multiply the rotation by the child local rot if you want to keep the same side facing the root. if you want to rotate around an arbitrary position, subtract the root relative offset to that point from the childs local position before multiplying, and then add if back in after.

fast, smooth, accurate choose any two. llTargetOmega, or set rotation