Quistess Alpha

from your code above it looks like those play the same animation. I haven't tested myself, but from other things you've mentioned, it's my working hypothesis that stopping an animation and then playing exactly the same one leads to issues. You could fix that by cleaning up your code a bit: string gCurrentAnimation; // the animation that we expect the avatar to be playing because we started it and have not stopped it. //... state_entry() { llLinksetDataWrite("AnimState:Walking", "playThisAnimation"); llLinksetDataWrite("AnimState:Turning Left", "PlayThisOtherAnimation"); //... llSetTimerEvent(0.2); } //... timer() { string animState = llGetAnimation(); string wantToPlay = llLinksetDataRead("AnimState:"+animState); if(wantToPlay!=gCurrentAnimation) { if(gCurrentAnimation) llStopAnimation(gCurrentAnimation); if(wantToPlay) llStartAnimation(wantToPlay); llOwnerSay("AnimState is: "+animState+"\n"+ "Changing from '"+gCurrentAnimation+"' to '"+wantToPlay+"'."); gCurrentAnimation = wantToPlay; } } or so.

That would indicate to me that it ~is (very likely could be) a problem with animation priorities. If 2 animations which move the same bone are played at the same time, the one which is received as a signal by your viewer last actually moves the bone. Most AOs ~should use only priority 4 and lower animations*, so if your animation is priority 5, it's probably some other issue. If your animations are priority 4, perhaps add a slight delay before playing the animation. *Although, do verify the priorities of the animations yourself; the official viewer, and most up-to-date TPVs can tell you animation priorities now.

It faces towards the x-axis of the object the script is in (assuming it's not an attachment) so if you turn your object the 'sensor cone' turns with it. LSL has some rather primitive implementation at times, but it's not ~that primitive.

The function keys can be bound to gestures, and firestorm (specifically, It doesn't seem to be supported in some other tpv's) can bind gestures to other arbitrary keys. Gestures can then activate chat commands which poke some script. It's clunky but it technically works. You can also bind combinations of keys, for example: while control_down is held, the movement keys do different punches but don't move you. @Brandon Ghost commissioned me to make a system kindof like this a while back, but I backed out partway through because it's not something I'm really personally interested in. Maybe you could ask him for some of his ideas. ETA: SL's tank controls are also awful for this sort of thing. You might try locking the camera and only allowing forward/back/strafe. You'd really have to fight the animation system to get a strafe to look correct though; in that setup the avatars might have to be sat on the system and moved as child prims of the linkset.

Something you might be missing is that the SL simulator doesn't "know" where attachments are exactly on your body* because it doesn't "see" what animation/pose your avatar is doing. Doing things from the avatar's perspective saves a lot of headaches in misunderstanding where the thing "is" vs where it looks like it is. *Unless the attachments are attached to the root/center attach point, which ignores animations.

A box prim with taper at x:0.85, y:0.0 and varying the top sheer between x:+/-0.45 would work. The math shouldn't be too too bad, but setting shape primitive params is a bit of a pain because you have to set all of them at once.

There's llCastRay, which is quasi-similar to llSensor, but only detects things in a straight line and returns results directly in a list rather than a separate event, but setting up good raycast lines also involves some math and good judgement. personally I think doing a sensor with a full circle and then doing the math to narrow it down to what you actually want isn't so bad, but I'm pretty good at math.

you probably want rot*r instead, to rotate with respect to the intrinsic axes of the legs, rather than the intrinsic axes of the body? it's hard to say much specific without testing in-world or knowing the intrinsic axes of all the parts. It might be more clear to use: rotation rot = llAxisAngle2Rot(<1,0,0>, angle*DEG_TO_RAD); instead.

One thing I don' think was mentioned in those other threads: If you use a prim-position method, you probably want to add some extra touchable space around the visible part of the prim (make the texture have a large transparent border, or taper the prim), or allow touching the prim behind the slider to activate the slider. If you drag something too small too fast your pointer can end up beyond the area of the widget and stop dragging it.

Could help you get started.

Ehh my rule of thumb is the opposite. Switching from llSPPF to llSPP is of course one of the many tools in the debugging toolbox after making sure the logic is in fact correct and you know you're telling it to do the right thing but it's doing it wrong*. But on the whole I think it works well enough most of the time, and if there's something that fails because it needs a delay, I'd rather add that delay in manually (with a good comment about the issue it fixed) rather than just make things 'more delayed' by default. * other common fixes are to reset anything relevant on changing owners; don't read textures from a no-mod object (or other prim params if you can reasonably keep track of them in the script); llSetSoundQueueing often causes more problems than it solves, Especially don't mix it with looped sounds; Don't add euler-vectors together and expect a sane result.

Have you considered projecting the texture onto your setup from an invisible prim above? That seems like it could get a similar result to your image.

That's a fairly basic particle effect that anyone who knows particle effects could emulate. It would need at least 2 attachments (one for each hand) though.

I'd take it a step back and caveat that there are some "basic functionality" things that "can" be done by residents but should be done LL. The marketplace (and caspervend, but when will that get integrated/improved?), basic meshbodies (NUX), basic land management (belli), search (Is websearch still broken...) etc. LL's implementations can be very debatable, but for the most fundamental things, "Buy a widget from XYZ for 1000 linden" shouldn't be the first answer.

Is it perhaps related to your notification settings somehow? was there also a 'notification' in the area around where group notificaitons are? sometimes when I pay/get paid by someone I get the notification multiple times if I forget to confirm the notification. This sounds like it could be a similar thing?

For those of us who are bad at navigating 3d space and can't read white text over almost white flooring and walls: When you teleport in you will be near or in a recessed alcove of the wall which has the vendor for the main body on the far side. Near the lower left of the wall there are 2 mannequins representing the vendor for the "zero" body, next to an illegible white-on-transparent sign. . . These kind of shenanigans are why I shop on the MP when I know what I'm looking for. . .

Obviously don't take my word for it, but it's my understanding that as long as the things you can "buy" with your "currency" are no-transfer you're definitely safe. The ifs/ands/buts for other scenarios are a bit complicated and probably not worth the hassle of figuring out, since L$ works perfectly well for almost all use-cases.

Json doesn't support vectors or rotations AFAIK, and I think the conversion casts integers to floats.

funny timing, I just bought some new mice for similar issues. it wasn't so bad that I couldn't single click in inventory, but I would often make a selection in dialog boxes then touch or teleport to whatever was behind it. . . https://www.amazon.com/dp/B09JDL6T1M?psc=1&ref=ppx_yo2ov_dt_b_product_details is pretty cheep and it works and I've been having fun adjusting to https://www.amazon.com/dp/B001KBZ1J8?psc=1&ref=ppx_yo2ov_dt_b_product_details which works surprisingly well with my non-standard standing desk position once I figured out the ergonomics of it.

AFAIK the main way SL "links accounts together" is if they use exactly the same email address, and even then having accounts linked/tied together really doesn't do much practical (It may or may not affect stats on your rez-day email, but who cares about those?)

is more of a proof-of-concept than a fully functional device. In order to make media things "pretty" you need a very developed conceptual understanding of html, CSS and a bit of Javascript, and how to make the most of them within the very limited and non-standard situations LSL forces on them. And for "televisions" you either need to do a lot of research about streaming site (ex. youtube) APIs, or rip media to your personal external server at great expense and questionable legality. (or only support specific hardcoded media URLs) ETA: even if you do understand the API for some streaming services, the way advertisements are handled may lead to synchronization issues between observers.

@Feorie Frimon might know?

Internet is down, but I can still somehow see a horribly mangled version of the forums? Also, is there really a 75 emoji per post limit!?! ETA: restarting my router fixed it as I thought it would.

llSay(DEBUG_CHANNEL, "some text"); or similarly for llWhisper llShout or llRegionSay llRegionSayTo (it doesn't seem work with llRegionSayTo(); (no viewer support?) but does work with llRegionSay(); and all the others). it makes the text show up in a special kind of window in the same way as a stack-heap overflow, or llSetLinkPrimitiveParamsFast usage error. People who aren't the owner of the object can also see the message, so llWhisper might be the "most polite" version. random note: Cool VL viewer shows debug channel messages in red in the local chat window (with timestamps) and also does not echo llRegionSayTo DEBUG_CHANNEL to the user.

If it's for personal use, try using the debug channel; I thing that doesn't add timestamps.