Void Singer

General thread reply follows: To say that phoenix did it wrong to begin with is silly, they did it the only way it could be legitimately done. LL's solution was a change to the inventory system, as well as the viewer, something no TPV could have accomplished in that manner... it was the same story with multiple attach points. LL did not do it wrong either, although a bit of cross testing on their own v1 download would have made the problem obvious and a patch might have been generated sooner. v2 itself was NOT the problem, but changes to it DID cause problems not only for TPV's but also their own unsupported (but not abandoned) v1 version. summary of phoenix changes: V2 physics wearables fully supported + additional bug/crash fixes.

writing a quickie script to do something or rather I don't even remember.... shuffle things around to make it easier, and boom, region hangs, and I get red mapped.... well that blows log back in write a few more line, save the script again, a few moments later it happens again... you see the problem now, I'm sure, but I didn't because it wasn't happening immediately... or at least I didn't notice it... so I relog, assume the region is dying on me and move to a different one... a few minutes go by, I go to move.... I'm stuck... minute later... redmap. oh damn.... did I just? yup... but how... this script is dinky and doesn't do anything special.... stare at the code for awhile.... call in a friend to test it, boom, we both get locked up and red mapped. I'm staring at the code some more... oh I shouldn't have copied that line there... it shouldn't even work there.... OHHHHHHH and that was the day I learned how to stop a region dead with only three lines of actual script code. (and I was a good girl and reported it.). the funny thing was, it didn't crash the region... just caused it to stop dead for as long as the script ran

if it involves a security issue or problem, then opening a jira in the SEC project will be private, otherwise, you can use direct email, or even file a ticket, both of which only you and Linden staff can see.... if it involves these forums you can even send a private message to Lexie or Amanda Linden

welcome to the internet =D

IMPORTANT NOTE: when following PeeWees suggested folder delete, make sure to go to you avatars name(s) folder(s) and save all the chat logs that you care about. then wehn you log in an go to the empty region, type something into the search bar in inventory, which will cause the viewer to jumpt start on loading your inventory... it can take a few minutes depending on size

I've never noticed it happening myself, it may be down to a video card setting... you do want to make sure the setting for "high rez snapshots" is turned off... that setting doesn't do anything any more, except bork things (it's legacy code from before we could set the image size our selves).... you might also try different save formats, as it could just be a bad conversion in one library, or use print screen button and then change the format in your image editor

three ways,(some already mentioned send a message from the clicked prim script to the door prim script... the door triggers from that instead of a touch as already mentionedlink messages (must be linked), chat (must be in range), even http(rather complicated) and other formats will work put the whole script in the button, and target the door with llSetLink* type commands (assumes it is linked) put the whole script in the root, detect which prim is clicked, and target the door as above (assumes it is linkeddraw back: the entire link set will have a touch icon when hovered over

and unfortunately, while you can call llDetected* from a function, that limits the function to only running from events that support it... LSL will throw a compile error if you try the same with a variable name (like ID) so the only solution there is to have the function take a variable and explicitly pass it either llDetected* or your variable in the call to the function.

it's not been stated directly, but right click acts like an override allowing the user to pick ANY valid action in the current state. to completely disable an action it can't be in the state you are. and as Innula mentioned, if you change states form an even with a chain (anything that has a *_start / *_end) always do it from the *_end event, or your likely to end up with bugs that will drive you mad (in fact I recommend always using the *_end handler if you can help it so that changes to scripts later don't see similar bugs)

also, llLoadURL shows to the user, and only if they click on it... if you want data returned to the script you'll want to use llHTTPRequest

I seem to be confused.... what's wrong with llGetRegionCorner?

yeah object owners may get a few more options... jumpPos to nowhere (I don't advise this for objects you care about, because they require being rezzed by script to clear or access to the zero point on a region), scripted delete, setting temporary, moving onto land with short return limits, or into the void. making them physical and volume detect so they drop through the ground.... etc etc.

yeah, my thought is that it's a sorting issue, since they sort of snuck sorting code into multiple layers.... but if it's happening before a relog it may be easier to test for, but a slightly different cause than I was thinking... it should be able to reproduce with something like 2 or three items... apply A then B, remove A, then reapply... or extend the same idea out to thre layers, causing a previously baked and sorted layer to change positions, or a new layer to be applied after an earlier layer is removed from the stack (just not the last one applied)..... throw in actual clothing layers for added testing, but it should give you an idea for where to start for getting a reproduction that others can test.

yeah, I noticed they''re hiding out in answers now... they've been reported of course

adding a note: in V2, the ctrl+alt+t command sends the information to chat history, but not to chat console (console is the default that scriolls up from the bottom of the screen and fades out over time, history is the window you get when you click on the icon on the right hand side of the chat bar where you type.)

you're saying that it's when they relog that the avatar baking stage fails? I'd actually suspect this might be caused by layer being applied out of order from what is received from inventory (basically trying to apply the layer before it's sent). that may be down to the order they are fetched from inventory which might be hard to test for.

heh, and I totally misread your meaning just goes to show that sometimes a lot more thought goes into some things that appear simple, and sometimes even simpler things get completely overlooked

Ya know, that a very good question and it's actually based on a bit of experience.... the cube (should read box, will edit that) because it's a flat surface on all sides, even after it's cut, so that it retains it's basic shape. the path cuts suggested allow the inside/outside (top/bottom for lids) to face along the x axis which makes modifications like automatic opening and direction of swing for reversible doors a little easy to code for...and because some users are unfamiliar with the build tools so may not know what to modify to get a "half-cut" that the code requires, and because cuts start from the corner not the side as some might expect (so it helps counteract the non obvious nature) ETA: the inworld build tools actually conflict on cube vs box, the create tab tooltip calls it a cube, and the edit tab prim type refers to it as a box. however all the scripting commands also refer to it as a box, so that's what I'm going to go with.

::tries not to laugh:: ::fails miserably!::

Addendum: I didn't catch it before, but the font was also changed from fixed width, and that is also something that needs repaired. Most preformatted text (not just code) relies of having a fixed width font for various reasons, and with the changes to span behavior we cannot repair this without a great amount of effort and up to 4 times the byte count used normally.

you might take a look at the simple hinge action script I posted RE-posted in the Library, as it might work for your needs

Doors, Gates, Lids, anything with a simple hinge /*//( v7-D Simple Hinge Action )--//*/ /*//-- Works At ANY Angle --//*/ /*//-- NOTES: works in ANY single prim door, linked or un-linked works in multi-prim doors NOT linked to a larger structure Never needs reset (even after moving/rotating) //*/ /*//-- REQUIREMENTS: Root should either be a cylinder (to represent a hinge) or half cut prim; I suggest Box, pathcut start=.125, end=.625 //*/ /*//-- CAVEAT: Single prim doors are limited to 5m width Treats current position as closed when reset //*/ /*//-- USERS MODIFY HERE v --//*/ integer gIntSwing = 90; /*//-- use -# to reverse the direction of swing, eg. -90; --//*/ rotation gRotSwing; default{ state_entry(){ gRotSwing = llEuler2Rot( <0.0, 0.0, (float)gIntSwing * DEG_TO_RAD> ); } touch_end( integer vIntNul ){ llSetLocalRot( (gRotSwing = (ZERO_ROTATION / gRotSwing)) * llGetLocalRot() ); } } /*//-- IF Redistributing as-is: Please leave script full permissions & include all comments so that others may learn and use //*/ to use in lids, create lid as above, move/rotate (via object edit) into place, done. to create realistic hinge action: path-cut start = .375, end = .625 (preferred) OR path-cut start = .125, end = .375 (remove gIntSwing and state_entry if you pre-calculate and assign the value of gRotSwing) 

You aren't the only one who thinks it's a little silly, although I do get that the intent was to cut down on the ease of stalking/harrassment/annoyance.... that said, you can still get this functionality from a scripted object, if need be.

fixed typos above (this is what I get for posting code on the fly, sorry) any actions you want the lock item to take would go where the comment "//-- do whatever you need to do to open/unlock the item here" is in the lock script. unfortunately whatever action is going to specific to the object that it's in, so I don't have a good way to guess. I can say that llGiveInventory is the simple to use, and you should have no trouble figureing out how to insert just there =)

I'm not having the problem mentioned, winXPPro, FF 4x and Phoenix 908 (yeah I know I need to update) although I will note that the cursor position ending up in the middle of a fucntion name like that on a syntax error is more than a little odd.... I've never seen that happen before =/ (to make sure I counted the lines and reference positions noted above, and that's where it would place it)