Quistess Alpha

That may work (I've not tried it) but I think you meant llRotBetween(<1,0,0>, CorrectedOwnerPos-llGetPos()); you want to rotate by an angle defined by a line sticking out from the object going in the forward (x?) direction (<1,0,0>), and a line sticking out from the object pointing at the owner (ownerPos-llGetPos()) rather than 2 lines pointing from the region origin to the owner & object. to look up/down at the owner, I think you could right multiply that by llRotBetween(CorrectedOwnerPos-llGetPos(),OldOwnerPos-llGetPos());

scalar multiplication (and also division?) of vectors/rotations also I think may allow the scalar on the left, For debugging, I think you can get the type of an expression by embedding it in a list and using llListStatistics. if you try to assign an expression to a variable to assume its type, you might accidently do an implicit typecast.

I think so, but it may typecast floats to integers implicitly; would have to test.

float = vector * vector. . . float = integer ? float, for basically all opperators in place of '?' string ?= key + string ; can you add a key and a string to get another string? list = * + list ; preppend anything to a list ==, !=, >, <, >=, <= all return integers regardless of the arguments. unary opperators ~ ! ++ -- might need special consideration?

Given that most avatars are wearing at least one non-HUD attachment (OBJECT_GROUP returns NULL_KEY when used on the avatar itself) , I'd say its false negative case is much less likely than OBJECT_GROUP_TAG 's 'spoofability'. The main reason I brought it up is because I've often forgotten it exists (there's no independent function for it) and it seemed like the OP's application (a bridge) needed security more for roleplay purposes than for actually keeping people out; maybe an opposing organization using forged road passes could lead to some interesting scenarios :P.

yeah, but is she discreet, and professional enough to politely turn down untoward advances?

Indeed, if you have multiple groups you need to keep track of, then llSameGroup and llDetectedGroup won't help. If you're not overly concerned about 'real' security, you could instead use group tags ( llGetObjectDetails(ID,[OBJECT_GROUP_TAG]) ), and just honor system that it's too much effort for someone to make the same group tag in a different group. That would avoid the (extremely rare) situation where the attachment check method fails because someone isn't wearing any attachments, and allow different roles in the same group to have access or not independently.

Sorry for the bump, but it's pretty easy to change the page in the url. starting from say https://marketplace.secondlife.com/products/search?search[keywords]=cute+dress&search[maturity_level]=G&utf8=â&page=2 you can jump to page 47 by changing the page number in the url: https://marketplace.secondlife.com/products/search?search[keywords]=cute+dress&search[maturity_level]=G&utf8=â��&page=47

No not really. Everything in SL is intended to look the same for all observers, to conform to a "shared experience" as a very intentional choice by the devs. While a few things break that, like local environment settings, and sometimes media-on-a-prim, there's no way to change object properties for individual observers. Either the light is on or it isn't, who's local settings should get to decide that, the nearest person?

because that script specifically avoids changing the backwards movement speed due to problems with AOs that use llOverrideAnimation() There's not much you can do to fight against "adverse use" when using the reverse force method. for a restraint, you'd want to take controls without pass-through, and manually apply forces given the user's input. RR specifically also overrides the jump key to be just a short impulse, which gets around the need for a "stairs force" working against gravity. minimal demo of that would be: float speed = 1.75; integer gNeededPerms; default { state_entry() { gNeededPerms = PERMISSION_TAKE_CONTROLS; llRequestPermissions(llGetOwner(),gNeededPerms); } attach(key ID) { if(ID) { llRequestPermissions(llGetOwner(),gNeededPerms); } } run_time_permissions(integer perm) { if(perm& PERMISSION_TAKE_CONTROLS) { llTakeControls(CONTROL_FWD|CONTROL_UP|CONTROL_BACK|CONTROL_LEFT|CONTROL_RIGHT,TRUE,FALSE); } } control(key ID, integer level,integer edge) { if(level&edge&CONTROL_UP) { llApplyImpulse(<0,0,0.75>,TRUE); // allows walking over small steps. } vector vel= speed*llVecNorm( <-1, 0,0.0>*!(level&CONTROL_FWD) + < 1, 0,0.0>*!(level&CONTROL_BACK)+ < 0,-1,0.0>*!(level&CONTROL_LEFT)+ < 0, 1,0.0>*!(level&CONTROL_RIGHT)); vector v = llGetVel(); vel.z = v.z; // allow falling while moving forward, causes problems if jump impulse is too high. llSetVelocity(vel, TRUE); } }

I'm not familiar with that specific part of the product, but if it involves looking into people's RLV folders, then looking at someone who's RLV folders have a lot of children directly under the root folder (not uncommon for people who really like to play with "traps" that add folders directly) can easily crash anything that isn't extremely careful with its memory management.

For a restrictive thing, you may want to consider llMoveToPos() the wearer's current position in adition to taking their controls and doing nothing with them. other than that, see what @elleevelyn linked. The best methods I've found are allowing the underlying SL movement and applying a reverse force, or directly setting the avatars velocity given their input. Both can have some nasty side-effects if edge-cases aren't carefully considered. llMoveToPos() as the movement mechanism would also work, but it interacts badly with jumping.

omega is a 'prim property' which means that it continues to rotate even after the script is removed/stopped. for debugging problems, you want to use llSetLinkPrimitiveParamsFast with the PRIM_OMEGA property to set every link in the linkset to not rotating before trying to figure out what's making the wrong things rotate. llSetLinkPrimitiveParamsFast(LINK_SET,[PRIM_OMEGA,<1,0,0>,0.0,0.0]); or so.

Are you sure your alt isn't already subscribed to the experience, or on an access list, or a member of a group that always has access?

Googling through documentation, it looks like replacing NORMAL with GIMP_LAYER_MODE_NORMAL or just the number 0 (hopefully corresponding to GIMP_LAYER_MODE_NORMAL_LEGACY) might fix that specific error.

llDetectedKey(0) isn't going to return a usable value in this context. perhaps changing that to id, similar to the line 3 above that would make it do what's expected. I don't know how many of the people here are familiar with the smartbots api (I'm not) you might be better off asking in their support group (assuming they have one).

Things I might test/ would like to see in the wiki: What happens if certain parameters (REZ_POS and REZ_ROT specifically) are not specified? I.E. What are the default values?

Yeah, but you need to own your own region for that.

Also note that HUDs are just just ordinary SL objects, like the ones you can rez in-world, but attached to a HUD attach point.

You could have a 'server' object set up in-word somewhere; the egg (or the chicken, but need not be both) messages the server instead of rezzing from inventory. The server then sends a (no-copy no-mod) generic chicken object to the egg's owner. The first time the generic chicken is rezzed, it asks the server for its specific characteristics.

Right, but presumably the rezzer will be in the same sim as the rezzed object at the moment of rez; assuming chicken-first: Chicken contains both a copy of itself and egg. Chicken rezzes egg, gives it copy of itself and a copy of egg to the rezzed egg. Egg may change regions, but still contains a copy of itself and chicken. Egg rezzes chicken, gives it a copy of itself and a copy of chicken. Chicken . . .

Oh, I seem to have missed that somehow. The wiki says the object_rez event happens in other scripts in the same object, so another script ~should be able to detect an object rez, unclear whether the new event will transfer to other scripts in the same link.

If your script rezzes more than one type of thing, I think it's pretty valuable. Either you store the UUID in a global to check which of the things you might have tried to rez actually got rezzed, (imagine simultaneously rezzing 2 things with the same name, and being able to tell which is which!) or sleep until some sanity check tells you the thing is finally rezzed.

try llOwnerSay((string)llGetLocalRot());

Since you need to (very briefly) rez anything that is temp-attached, I don't think attaching it to someone gives much benefit over just having it rezzed in-world while the seat is in-use: the land needs the extra LI 'float' in either case.