Quistess Alpha

It would depend on your exact usage of the system, but I would recommend storing point values in a centralized database or KVP (a scripting feature which requires being a premium member or owning a private island) rather than directly in a user's HUD. Attachments can sometimes be "refreshed" to an earlier point in time after a teleport failure or other unfortunate accident, which means that your hud might "forget" any transactions that happened up to a few hours before the accident/crash.

I agree that's overkill, just the length of the key would make me a bit wary of using it for script communication given the 1024 byte message limit. XTEA could be more suitable, but IMO it's still overkill for most use-cases.

That's not how you read values from a notecard.

Sticking (forced no-movement) someone can be as simple as llTakeControls(0x337,TRUE,FALSE); while doing nothing in the control event, but to be antagonistic to attempts to unstick oneself via another script, you might want to try llMoveToTarget(llGetPos(),0.05); to stick, llStopMoveToTarget() to un-stick.

An interesting feature/bug I found when testing it (without my usual scripted movement control on) is that if you begin to hold down space while already walking forward (and continue holding both space and forward), you never come to a complete stop, but continue walking at slow speed. However, if you try to start walking (from a stop) while space is held, then you're stuck in place.

It's been a bit since the gacha ban scare, but the TL;DR from what I remember is that as long as the vendor shows you exactly what you're going to buy for the exact transaction you're making, and you don't call it gacha, it's allowed. so "Conveyor belts" that show you the item you're buying and the next 3~10 items it's going to sell are allowed. There were also some stipulations about transfer-ability which I didn't quite catch the nuances of, but I think it boiled down to a specific allowance of "fishing" for non-transfer items of "zero value". I'm not intimately familiar with the current state of it, but from what I gather, the only "miepon" are from specific creators, or event-holders. creators want their vendors to be at the event places with the most traffic, so consolidation is to be expected, I wouldn't be surprised if the Arcade and Concept had 90% of what's out there, assuming they duplicate most big individual vendors like Nutbusterz and Positive Wavelength (I haven't checked, did they both convert to conveyors?)

Backwards turning behavior is different depending on whether your AO overrides your walking animation with llSetAnimationOverride; An animation overridden avatar will face backwards when walking backwards, but can be bugged out by scripted forces. I think overriding the movement directly (second method of previous post) is the only way to not have that specific issue. Why would you move while holding your space-bar though?

The two main methods of doing this are to apply a reverse force in the direction of intended movement, or to override movement entirely and move with one of several physics functions (llMoveToTarget, llSetForce, llSetVel) in such a way as to aquire the desired speed. With a reverse force, you have to account for various cases that can cause an undesired effect (jumping, crouch-walking & falling off the top of my head) if not handled carefully. With overriding movement directly, the special cases are less of a concern, but you lose some special magic that allows the avatar to walk over small bumps. You can fix that problem with applying a small anti-gravity force while walking, but that causes the avatar to walk into the air in some severely physics-lagged regions. Fixes for airwalking work some of the time but are hit or miss. I have some example scripts in the LSL library section:

midi could be fun to play with, postscript would be awesome if it worked (doubtful)

I didn't know you could directly embed a (severely space constrained) page directly into the URL like that. Neat!

The in-viewer web browser can resolve SLURL links (anchors) in HTML, but I'm not sure if it can do the pretty formatting. for example: <a href="secondlife:///app/agent/8645873d-1306-4f22-a60c-4f2bc3bb9ca2/about"> Tessa's profile </a> creates a clickable link to my profile if viewed as (X)HTML in the in-viewer web browser. It would be really useful if app/chat links weren't blocked for some generic 'security reason'. but that's off-topic. . .

I'd have to have the viewer remap window in front to confirm or deny, but perhaps that function prematurely stops the "walk_to" action? (By default I think walk_to is unbound, I usually bind it to 'q', rarely useful, unless you're used to runescape style controls; could be useful in a setup where a script forces an overhead camera view.)

Ahh ok, it's not clear on the wiki page, but according to that they're supposed to resolve to the key that is bound to that function for the user's viewer. That's a pretty nice and sensible design idea!

So I just looked at the 'Viewer URI Name space' page and noticed a lot of things that definitely weren't there last time I looked. Specifically the /keybinding domain; it's not 100% clear how those are supposed to work, how do you describe the key that is to be bound to the action? (if that's what they do?) which print the key that the user's viewer expects to perform the given function.

if it's for saying / ownerSaying you can convert the key to a SLURL like secondlife:///app/agent/<key>/inspect which is often more useful than just their name.

If I'm reading it right, the script already seems to have a non-zero PSYS_SRC_MAX_AGE, which will cause its particle effect to activate whenever someone sees it enter their draw distance or receive any unrelated-to-particles object update. People other than the wearer may already see the particles happen when the wearer teleports into a region.

They probably copy-pasted from a word processor and didn't turn off rich-text support (a blink or you'll miss it option that pops up in this forum's interface after such a copy).

If you want other people to be able to see it, and you have land rights, and access to a private server, the parcel media texture accurately displays the parcel media image on particles. (but not projectors unfortunately)

A bit of a tangent, but if you have mega bucks, 'literally everyone is doing it' and you can prove the copyright holder isn't actively doing much to protect their claim. . . but I think that's more common for trademarks.

Your account status shouldn't change how you upload files to SL. It's probably an issue with your viewer. Use an older version if you still have a copy, or try switching to a different viewer. Ask around in your viewer's support group if it has one. (Cool VL Viewer is a good choice for debugging viewer differences, as it's the most 'different' from other viewers.)

that makes sense, even if unintuitive; LSL's scope detection doesn't take jumps into account; the fact that there exists a variable definition previously in the same scope means the erroneous say references the local version of the variable (which isn't declared because of the jump!). Consider also: default { touch_start(integer total_number) { if(FALSE) jump hook_1; // no error if TRUE. else jump hook_2; @hook_1; string s = "1"; jump hook_out; @hook_2; //string s = "2"; // compile time error! @hook_out; llSay(0,s); } } also noteworthy is that the fact that the variable is a string is important; integers seem to be initialized correctly to zero even if their declaration is jumped over.

It seems the OP wants to make a HUD that instead of changing the texture on your own clothing, changes the texture on someone else's clothing. In principal, that's not too different from a regular texture change HUD, but it would require specific changes to the script, and possibly the addition of a UI for targeting the specific person who's clothing is to be texture changed. (or just a switch between targeting oneself and llGetObjectDetails(...OBJECT_LAST_OWNER_ID...) )

Actually, yes, but if the script is in the detached object, it may or may not have enough time to do whatever useful thing you want it to do. from inside the attachment: default { attach(key ID) { if(ID) { llSay(0,"This object was just attached."); }else { llSay(0,"This object was just detached."); // anything more placed here may or may not happen the next time this object is attached, before any other events. } } } for anything more complicated than saying a message, you should expect that some of the code may run during the next attach. see https://wiki.secondlife.com/wiki/Attach From another object, you'd need to iterate through llGetAttachedList() on a timer.

I glanced at the site, but didn't see anything about an open API. If ZCS doesn't provide a clear and open way to interface with their scripts, then it is not possible to read their health-bar to do other stuff with. RLV stripping requires specific setup on the part of the person being stripped. Depending on the script implementation, they'd need to be very careful about attach points, or place their stripables into specific RLV folders (as the 'literal' object, not links).

https://jira.secondlife.com/secure/Dashboard.jspa for the official SL viewer, look in the help menu (top bar) of your viewer of choice, firestorm for example: https://jira.firestormviewer.org/secure/Dashboard.jspa