Wulfie Reanimator

Neve is another store that has a lot of very casual (covered shoulders, zero-clevage, knee+ length skirts) summer/fall wear. They have a lot of products though (1300 items at 0L) from over 10 years, so you have to dig a bit.

Even if it was impossible to cram your camera under that shirt, it'd still call it sexual/sexy. It's not just a tank/crop top that leaves the belly visible, the creator went out of their way to add detail to hike up one half of it while adding a bit of emphasis to her breasts with those creases.

Some people use capitals for Emphasis, similar to "some" people using quotes for the same thing...

Yeah, that's what I meant with the line you quoted. 🙂 The power of cheaper, mobile/laptop CPUs is pretty good on their own in current year. GPU optional as far as I can tell.

Yeah, it's the Iris Xe. I haven't done any benchmarks and don't plan on gaming on the laptop, SL was just one-off for funsies. Is there anything specific you want me to do?

Even the laptop processor I got recently (i5-1335U) can run Firestorm on ultra (without shadows) in a populated place with everybody (10-15) fully rendered. No real GPU, still 30 FPS. I think SL users tend to really underestimate modern hardware, myself included. And while the performance difference to my ridiculous desktop build isn't as big as it should be, anyone who says better hardware doesn't matter is just very wrong.

Meaning something like this, with llListReplaceList. Can't get inworld (let alone OS) to test it, but basically.. check for existing stride, get the land impact from it, add the new LI to it, then replace the old stride (start to start+1) with the new stride / updated sum. If the stride doesn't exist, just do the old logic. CalcPrims(vector Loc) { list TempList = llGetParcelPrimOwners(Loc); gListLength = llGetListLength(TempList); if (!gListLength) { llSetText("[ERROR]\n Couldn't get Parcel Prim Owners", <1,0,0>, 1); } else { // Produce a copy of the list suitable for sorting by count, i.e. count then key integer x; for ( ; x < gListLength; x += 2) { key owner = llList2Key(TempList, x); integer newLandImpact = llList2Integer(TempList, x+1); integer stride = llListFindList(gListCountsAndOwners, [owner]); if (stride != -1) // Found this owner before. { integer oldLandImpact = llList2Integer(gListCountsAndOwners, stride); list data = [ oldLandImpact + newLandImpact, osKey2Name(llList2Key(TempList, x)) ]; gListCountsAndOwners = llListInsertList(gListCountsAndOwners, data, stride); } else { gListCountsAndOwners += llList2Integer(TempList, x+1); gListCountsAndOwners += osKey2Name(llList2Key(TempList, x)); } } } }

How do you get this data right now? Frionil's suggestion works for cleaning up the data, but maybe we can get it in the right format before it needs to be sorted.

Just post bad code! Garbage in, garbage out.

I never knew communism was about this, thank you for educating me.

I can totally believe that, I've been (am) a really shoddy coder too! The script just has an AI-smell about it, especially after I saw that line. It's one thing to make a silly/redundant/impossible check. It's one thing to use an imaginary function-call. It's one thing to add extra comments on every line of logic. It's a whole other thing to do all of those things at once, with otherwise very good coding style (implying a reasonable level of understanding), and confidently present it just as "try this one." 😋

A human (even one that wasn't good at scripting) would not write this: // Check if the detected avatar is in the same group as the groupKey if (llSameGroup(detectedKey) && llGetAgentGroup(detectedKey) == groupKey)

ChatGPT?

If you upload a 2048 texture to SL, it will be automatically scaled down to 1024 because that's the maximum resolution we're allowed to have. The benefit of resizing the image yourself is that you can choose different downscaling options - bilinear, sharper, nearest neighbor, or whatever your specific texture details call for. You lose that flexibility with LL's forced downscaling. I don't like the way LL's resizer handles color data in general, based on my own tests by uploading 2048/1024 with different options, downloading the uploaded texture, and using Difference filter between them and the original. From 2048 to 1024, aliasing on black/white lines becomes "blotchy." And PPI is only used for physical printing, it doesn't affect digital image quality. 1024x1024 with 72 PPI vs 150 PPI still have the same number of pixels, 150 PPI is just a smaller ("more dense") physical print. This is absolutely true though. 🙂

You could always PM Keira on Discord about it.

That definitely seems to be the case! Using the performance test script from the wiki, Quistess' version (from your post) is about 50% faster than my first example. Sometimes a little more, sometimes a little less, but the difference is significant. I also agree that the raycasting functions are at least intermediate stuff, but I would still feel bad if I added some obscure code to the page (referring to my second example... which is slower than the original). Edit: The examples for llCastRay have been updated with a simple example and the GetSimEdge function.

I'd be all for it, I've been racking my brain while looking at the usual (Sutherland, Cyrus, Barsky, Nicholl) clipping algorithms. All I can come up with are either really long functions or short but very "dense" functions. I want to imagine there's something to be gained from the assumption that one point will always be within the region. It's very hard to find anything to corroborate that though. Or maybe I'm just overthinking the whole thing. 🙂 That's why I'm asking here.

I recently updated a caveat on the llCastRay wiki page about region bounds, referring to this thread: In short, if a ray crosses a region border by about 8 meters, it will start failing to detect hits even in the simplest conditions. (Like trying to hit a large default prim.) To prevent that, we can "clamp" the ray so it always ends near a sim border, ideally in a valid location for a prim to exist. (A valid X-coordinate for an object includes 0 to 255.99999... but not 256.) That thread already came up with a function to limit the ray within region bounds to prevent the error, but could we refine it into an example that could be included on the wiki? Here's one example (with extra spacing for clarity), which would use the ray's starting position and direction to find a point on the nearest sim edge. The edge will be the ray's ending position. // Use-case: vector start = llGetPos(); vector edge = GetSimEdge(start, <1,0,0> * llGetRot()); list data = llCastRay(start, edge, []); // The math, assuming "dir" is a unit vector: vector GetSimEdge(vector start, vector dir) { // if dir.x == 0, no value is assigned. vector range = <9999, 9999, 9999>; if (dir.x > 0) range.x = (255.99 - start.x) / dir.x; else if (dir.x < 0) range.x = ( start.x) / -dir.x; if (dir.y > 0) range.y = (255.99 - start.y) / dir.y; else if (dir.y < 0) range.y = ( start.y) / -dir.y; if (dir.z > 0) range.z = (4095.99 - start.z) / dir.z; else if (dir.z < 0) range.z = ( start.z) / -dir.z; // Multiply "dir" by the shortest distance/ratio: X, Y, or Z if (range.x <= range.y && range.x <= range.z) return start + dir * range.x; else if (range.y <= range.x && range.y <= range.z) return start + dir * range.y; else return start + dir * range.z; } The above calculations could be simplified a little bit to this: vector GetSimEdge(vector start, vector dir) { // Very small number to prevent divide-by-zero. dir += <1E-45, 1E-45, 1E-45>; vector range; range.x = ((dir.x > 0) * 255.99 - start.x) / dir.x; range.y = ((dir.y > 0) * 255.99 - start.y) / dir.y; range.z = ((dir.z > 0) * 4095.99 - start.z) / dir.z; if (range.x <= range.y && range.x <= range.z) return start + dir * range.x; else if (range.y <= range.x && range.y <= range.z) return start + dir * range.y; else return start + dir * range.z; } I'd like to ask for different or simpler solutions. Something appropriate for a wiki, without weird tricks in like the second function.

I suppose, but I don't think the rate of control events is as consistent as time-tracking. It's probably much harder to remember what the number of events represents in time. How long is 123 events? Scripts also tend to "run faster" based on inputs. (It's a bane for combat devs, since it affects rez-speed.) I dunno how the rate of control events would be affected if you were making intermittent/rapid inputs.

To differentiate between "press" (quick) and "hold" (long), you need to track time manually using llGetTime or similar. For example, llResetTime if (level & edge & CONTROL_whatever), then llGetTime if (level & CONTROL_whatever) until the "hold" action should trigger. If the key is released early (level & ~edge & CONTROL_whatever), do the "press" action.

Here's an article about what the deal is: https://gist.github.com/FelixWolf/ddea8e96b8195181098d8d4e7c4273c4 In short, it's a scam, and the "viewer" will install a bunch of malware on your computer that allows the scammer to have remote access to your computer.

I'm talking about the discussion in this thread, not the TOS. The people who have issues with SL<->Discord connection are mainly concerned with privacy. It is BB using it. The SL group has a link to the Discord server. The founder of BB is the server owner. Multiple BB moderators are in the server. Teachers/mentors use the server for BB classes. It works by using 1-2 bots. One in the Discord server, one in the SL group. They both read messages in Discord/SL, relay them to the other bot, and the other bot repeats each message in its own chat. When anyone posts a message in those "synced" channels, a bot in SL will repeat the message starting with "Bot: Wulfie Reanimator [via Discord]: Good morning!" (We have to use our SL names in the BB server as a rule, otherwise "Wulfie Reanimator" would be whatever my normal Discord name was.)

Yeah. Posting direct SLURLs to stores is definitely naming and shaming, with avatar names visible in screenshots, done by multiple people.

If you read the OP and skim through the pages of discussion, I feel the tone if that entire thread is very obviously hostile and demanding while calling out specific Lindens by name. That thread reads like a witch hunt, not criticism or "suggesting improvements."

It would also be good form if for example Builder's Brewery made it more clear in the group's description that the group chat is integrated with their Discord server, instead of just linking it. I don't think it should be required to explicitly state that, more like good manners. The people who I've seen raise a stink about it in the group chat did not share something sensitive and then find out it went to Discord. They usually start their argument without prior communication. I don't think those people are acting in good faith.