Profaitchikenz Haiku

There is a little gotcha to this acquired date we discovered last week: select some items in one folder, use "cut", then paste them into another folder. The moved items now all have the date of the paste operation in them as the date acquired. It screwed the person's primitive version-control-during-build method totally, as the items are now longer shown descending from most recent to earliest.

The other thing you can do is exploit the fact that in rotations as quaternions as opposed to vectors, 0 and 180 degrees come out as 0.o and 1.0, therefore the test for X, Y Z being either 0 or 180 degrees , when applied to a rotation, would be rotation testMe;if( testMe.s == 0.000000 || testMe.s == 1.000000){ // we are at 0 degrees, or 180 degrees on any of the three axes // because ZERO_ROTATION is <0.0, 0.0, 0.0, 1.0> // X 180 degrees is <1.0, 0.0, 0.0, 0.0> // Y 180 degrees is <0.0, 1.0, 0.0, 0.0> // Z 180 degrees is <0.0, 0.0, 1.0, 0.0> // therefore interogate testMe.x, y, z for 0.0 or 1.0 to look for 0 or 180 alignment doStuff();} Again, the problem here is that your code is easier to understand for somebody (like me) who doesn't naturally understand quaternions or SL rotations. I don't know if my two suggestions would actually run faster, or consume less memory. ETA experimeting inworld shows that as has already been pointed out in another thread, you do need to specify at least 5 digits of precision to make sure that 0.0001 gets excluded from the success test.

Personally, I think your script is easier to understand the way it is. In othe languages this is a good case for using the terniary operator, which LSL doesn't have. Here's my suggestion, picking just one of your processes. // consider you have a global vector offset if (RoundRot==<0,0,0> || RoundRot==<180,0,0> || RoundRot==<0,180,0> || RoundRot==<0,0,180>) { offset = < 0.5 * (float) (llRound(Scale.x) % 2 == 0), 0.5 * (float) (llRound(Scale.y) % 2 == 0), 0,5 * (float) (llRound(Scale.z) % 2 == 0) >; }// the trick here is multiplying 0.5 by a truth value TRUE or FALSE, which are implemented as 1 and 0. // so what you get for each vector component is 0.5 or 0.0 depending on the effective multiplier The (float) casts are probably redundant, but I find I need to do things like this so that in a year's time I don't look at the code and have my eyes glaze over, Standard disclaimer about my propensity to typos applies.

No, I'm probable

" If you want to point your arm in the direction, all you really need is an anim that raises your arm and points straight ahead. " And then shout "Seig Hiel" I'm sorry, but I just couldn't resist it ...

Scott McNealy's "you have zero privacy, get over it" quote keeps coming back to haunt us, doesn't it? (He was CEO of Sun Microsystems at the time, the company which managed to insinuate Java into anything chippable). I know this isn't in the same ball-park as Dennett's assertion that free-will is an illusion, but online privacy is a sort of illusion, one that we get promised regularly, but what we get is not what we all expect it to be, it's what the provider can manage to deliver. So somebody knows your IP at a certain time? As mentioned above, DHCP leases mean that without the ISP records of who had what dotted quad at what time, it's not a reliable pointer to who is who. Trolls have been around for a long time, and are almost never outed without the cooperation of the ISP. As has already been mentioned above, somebody doing packet inspection can see your IP, a forum or web-page will get it and probably log it, you're giving it away all the time as a necessary part of being online.

This is often caused by network interuptions. Wireless networks in particular can give problems. There are a few things you can try. From the View menu, choose "Show statistics" and look at the ping sim time. If it's too large it means that the sim is not getting a response from your client in sufficient time and is deciding you are no longer in that sim. Sometimes you connect to an SL server with low times, other times it seems high, and I don't know any other way to get a good time, it's luck of the draw. If you are using a wifi connection, try moving your machine closer to the router, or repositioning it. Find your ADSL download speed, and make sure the bandwidth setting in your network tab is set to less than this. A suggestion is to divide the download speed by the number of people using your router and not set your bandwidth higher than this value. Check other running applications on your machine that might be using the router for traffic and stop them whist connected to SL. Check for any attachments you are wearing thatg are heavily scripted, although my experience is that these don't cause you to be logged out of a sim, they cause you to have TP-fails and a consequent logout. The only other thing that seems to work for me when this sort of thing happens is to not stand for too long in one spot, but to keep moving around a little bit. Each time you move you send information back to the sim which then recalculates your position, and in doing so seems to keep track of you better than if you are just sitting or standing in the same spot.

Good call about the attachment, I missed that whilst popping in and out from trying to see the meteor showers. Now I'd better show them how to script a follower that shouldn't be used for griefing, only pestering.

Shouldn't I be banned for actually providing them with the means? (Memories of the catapuly scene in Jabberwocky here...)

Well, to start you off, here's a script to show how you get the basic hovertext and possibly some contributions // Warning, script composed out of world and not syntax-checkedinteger iWant = 100;integer iHave = 0;string begging; vector colour = <1.0, 1.0, 1.0>; float noShame = 1.0;message(){ begging = "Saving up for Christmas, I need " + (string) iWant + " $L and I have " + (string) iHave + " $L, please help"; llSetText(begging, colour, noShame);}default{ state_entry() { message(); } money( key benefactor, integer amount) { iHave += amount; message(); llInstantMessage( benefactor, "thank you so much for your kindness"); }} Drop the script in a prim, set the prim to invisible, and attach it to your head, and then think very carefully, do you really want the ire and approbium that using it will doubtless draw down upon your (prim-enclosed) head?

So this is it, we're just waiting for the "All Yore Ass3tz are Pwned" message now. Only, due to the lag, it might not arrive until after the problem has been resolved.

I also have just noticed whilst looking through the marketplace many of the pictures are not loading for the products.

I've been seeing troubles the past two or three days on our island, and several visitors have commented on it. Textures are slow to load and blurry, needing a reload. Editing an object and going to the contents page can give a wait of many seconds (30+) until the contents appear, editing a script can result in a long wait (60+ seconds) until the text appears in the window, renaming a script inside a prim sometimes fails at the first attempt... Chat-lag comes and goes with the worst delays of up to 20 seconds. AOs sometimes are not working for up to a minute. One of the most unsettling things is when standing up from an object one has sat on gives a blue screen for several seconds until the view restores to the correct position. I have always understood this to be a sim-loading issue, the sim has to calculate a physics position for a standing avatar but not for a sitting one, but the View Statistics bar and region debug panel show healthy figures. In addition I am seeiong many of the moving objects in the island are not smoothly transitioning from point to point but instead will lurch from one point to another one, doors which should have closed remain visibly open, although if you try to walk through them they are evidently closed. This is experienced with several different clients, and by visitors from a wide range of geographical locations, so I don't think it is anybody's local network here. Maybe there are still asset-server problems, they did some unscheduled maintenance on them last week.

Drongle, thankyou for the research, I don't think I would have seen the connection with perimeter. I've been playing with a prim textured with an alignment mesh and managed to see for myself what you've explained. It's also made me realise there must be a derivable formula for calculating the repeats and offsets for each different hollow figure to get a perfect alignment around the hollow texture, whereas in the past I've simply clicked the spinners or tweaked the figures until I got the look I needed.

Oddly-enough, yes, the only time I have ever used a triangular hollow section in a cube is to make a chamfered piece, a bevelled-edge, and I found when butting pieces up that the previously-square cut faces were now slanted, and I had to tweak the path cuts. I don't know why it's doing it, though, because the angle of the internal triangular face is 315 degrees, therefore the obtuse angle to the cut face ought to be 135 degrees, instead of the 130 that actually results. If it were a smaller amount than 5 degrees I would have suspected some sort of rounding error in the maths. What *I* could never understand about the triangular hollow section was why they had chosen the particular alignment of the triangle, I wonder if that has a bearing on this? Is this worth the pain of a JIRA?

The comparison operator when used on lists simply tests the length of each list, not the contents, so two lists [1,2,3] and ["A","B","C"] will show as being equal. [1,2] and ["a","b","c"] will show as different. If you want to check if two lists are different, the first thing to do is compare them as you have just done, and if the result comes back as FALSE, it shows the lists have different lengths, and are therefore not the same. But when it returns TRUE, you then need to step through the lists element by element, comparing them and seeing of they differ. Or.... http://wiki.secondlife.com/wiki/ListCompare in the wiki under extended operations is a very good example of what is at first non-obvious, and will save you lot of time which going through the list element by element, finding the element type, seeing of the other list has the same element type, then comparing values if they are the same type would otherwise involve.

The items might not have gone, but are just not showing visually. There are two things you can do. Log out and log back in, this may cause the items to once again show up as normal. Or, right-click on anything close to where they should be, work through the pie-menus until you find an option "reload" or "refresh", and try that.

There are some upper limits on how far apart the centres of the prims to be linked can be, but it is actually quite large, in the order of tens of metres, unless some of the prims are very small. Try this approach first. Get as much linked as you can. Then pick each remaining unlinked prim in turn, edit it, hold the shift key, and click on the bunch of prims already linked. You should then see a link button appear which when clicked, links the prim you first selected to the group you selected next. Doing that will allow you to spot any odd-sized or out-of-area prims that are causing the error message in your earlier attempts to grab them all in one go. If you really do have the parts spaced too far apart to link them all, try linking all the first floor in one set, then the second floor in a second set, and make a note of the two root prim positions so you can reposition the two linksets again when re-rezzing. As a safeguard, after linking together all the prims you think are in a link set, edit that linkset as a whole, and in the object pane add 10 metres to the Z position figure. The linkset will go up 10 metres, leaving behind it any prims you have overlooked. Go round each of these in turn, clicking on it, then the main linkset, link it in, and then check the edit linked checkbox, and shift the prim up 10 metres by adding 10 to the Z position box so it goes into the correct position with the rest of the link set.

I know y'all want to chew the fat about experience, but.... I had a think about the OP's script issues and read up a bit, and have found a couple of things. First, regarding the llMapDestination call, a wiki caveat is if called from touch, it may only work for the first or last touch in the event queue (example: num_touched > 1) In the script, it is being called inside a touch_start event where the number of touches (junk) is being ignored. This suggests it should instead be called from within a touch_end event, and the test should be made for the number of touches being either 1, or if greater, only the last toucher should be processed. Further to this, and again, coming back to the timings, I see two more potential problems, llMapDestination causes the script to sleep for 1 second. Before the touch_end event has completed, readyDest will be called, which will raise a dataserver event, and ( from the wiki) However, be aware that further dataserver events cannot be received until the event that sent the request has been completed. So, if a second touch is made before the dataserver call resulting from the first touch has been completed, the second touch might not trigger a dataserver event because the first touch event won't complete until the dataserver event completes. With the inherent 1-second delay I see a prime case for repeated clicks being lost, and hence the perception that the OP has to double-click to get the thing to work. It looks to me as if this is a sim-loading issue catching out a script that would previously run happily when things weren't quite so busy. So my suggestion is, switch to using touch_end, use the event variable recording how many touches there were and only process the first or last, set a 1.2 second timer before calling the llMapFunction, and move the call to ReadtDest to get the next random landmark into the timer event. As a safgeguard, instead of the return statemnent at the top of the touch event, I think I would have a global set to false if a previous touch event is still being processed which the dataserve event then clears, and if this variable is false when touched, whisper to the user that a request is still in progress, please try again later. ETA The dataserver event never even returns a key for a non-existent LM, it just hung there, so I moved the call to readyDest back, and set the timer going just before calling requestInventorydata. Testing shoswed that even after 30 seconds there was no key issued, if an LM doesn't exist you might as well give up after 0.5 seconds and try for another one. I could find no documentation backing up the original script claim that the call had to be in a touch_start, it worked fine inside a touch_end. I've sent a notecard with my script revisions to the OP for them to trial it.

Do you know how many landmarks are already inside it? I am wondering if it is churning away processing a mass of items each time a changed event occurs. To save you having to laboriously count them all, you could add a line to the readyDest() function to set the prim's hovertext to do it for you; readyDest() { destok = FALSE; integer count = llGetInventoryNumber(INVENTORY_LANDMARK);// suggest adding the following line for monitoring content level llSetText("Containing " + (string) count + " landmarks", <1.0, 1.0, 1.0>, 1.0); if (count == 0) return; integer which = (integer)llFrand(count); llSay(0,"Which is " + (string)which); last_ds_req = llRequestInventoryData(llGetInventoryName(INVENTORY_LANDMARK,which));} I suspect Qie is right and that it is getting thrown by non-existent LMs. Since there is already a diagnostic line in there chatting the random number out on channel 0, it might be worth adding some lines inside the dataserver event to see what happens each time it gets triggered. I have noticed in the cinema slideshows I created that when there are several dozen textures inside a prim the contents take a long time to show in the build floater, and likewise editing the scripts in them can sometimes take a long time to get the text up. In some extreme cases I wasn't able to actually edit the script until I had right-clicked the content line for it and set it non-running.

I was a bit rushed this morning and now too much time has elapsed for me to edit the post above and expand upon the timer. When you call llSetTimerEvent with a value x, you are setting a repeating timer event to occur every x seconds, and until a time of 0.0 is specified, the timer will continue to raise the timer event every x seconds, or a different value of another call is made to llSetTimerEvent with a new non-zero figure. In your case, you want the door to close 30 seconds after it has been opened, unless closed earlier by a definite touch event. Therefore you need to call llSetTimerEvent(delay) as soon as you have opened the door. The first thing you should do inside the timer event is call llSetTimerEvent(0.0), to prevent it then being called again 30 seconds later. You then make the call to close the door. Inside the call to close the door when a touch event specifies it, you should call llSetTimerEvent(0.0) to cancel any waiting timer set by the previous open command. Now, it does seem as though you could therefore dispense with the call to llSetTimerEvent)0.0) immediately inside the timer, and I agree, you could, but you are then relying on program flow to keep track of where you have set up or cancelled timers. Also, in very short time loops, you might run the risk of another timer event being triggered whilst you are still processing the first one, resulting ( I think), in them stacking up *, so as soon as you complete the first bit of processing, a second timer event is raised, and you could end up getting lockewd inside a non-stop stream of timer-events. A satisfactory alternative which does at least remove a redundant call to zeroing the timer inside the timer loop is to write such a call, comment it out, and add a further comment explaining that the door-close function zeros the timer. * As far as I can determine, events are stacked in the order in which they occur, so a very fast timer or repeating sensor will stack events to be handled, and not allow touches, listens, link_messages etc to get priority. I originally assumed that there was a round-robin poll of all the different types of events so that a stacked touch would then be procesed, followed by a stacked listen, then back to the stacked timer, but it does not appear to me that anything like that happens, it's purely a first-come first served occurrence. Also, I have some evidence that not all events stack as reliably or are detected as reliably as others; timers, sensors and touches are always reliable, but moving_end can sometimes be missed, and collision_starts and _ends also seem unpredictable.

Perfectly possible. This was touched on in the recent post about rotating items around a rezzer. "Have a look at http://wiki.secondlife.com/wiki/Rotation this page , in particular the section headed Position of Object Rotated Around A Relative Point"

You are setting the timer to operate every 30 seconds in your state_entry, when it should be set to 0.0 there, and also set to 0.0 at the start of the close function. At the end of the open function, set the timer to the duration required. That way, touching the door to close it ahead of the timeout will zero the timer and prevent it kicking in again. I noticed in passing that you are adding/subtracting values from a couple of variables in the init(0 function which will not have values assigned to them (the slide and pos).

The build floater numbers are not reliable. The thing to do is identify the individual objects with unique names, and check for them in an initialisation call. Should you edit the build and objects get added or deleted, re-run or reset the script. Snippets follow key owner = NULL_KEY;integer leftDoor = -1;integer rightDoor = -1;init(){ integer iiMax = llGetNumberofPrims(); integer ii; for( ii = 1; ii <= iiMax; ++ii) { string name = llGetLinkName(ii); if( namne == "door left") leftDoor = ii; else if( name == "door right") rightDoor = ii; } owner = llGetOwner();} state default { state_entry() { if( owner == NULL_KEY) init(); // then check none of the important integers such as leftDoor is still -1 The idea of using the owner key in the way I do is to allow from switching stgates and not triggering all the setup stuff again when returning from another state. Both Qie Niango and ChaliceYeo have explained some of the reasons whythe floater numbers are not the numbers a script call obtains in the past, but I don't have saved bookmarks to their posts, some of which are probably on another site completely. There are probably still typos in my post even after three edits, so expect the code to make the syntax checker vomit if you try a C&P inworld.

I think part of the problem here is that you may be recording the rotation of an object relative to the rezzer, but as a region rotation, that is to say, the actual rot obtained by llGetRot. The rotation of the object around it's axis is one thing, but the rotation of it in respect to another item is more a question of positions. The position of the object as LLGetPos is similarly not the same as the position of the object relative to the rezzer. When you rotate the rezzer and re-rezz, the vectors are going to change. Your prim which was previously 10 metres greater X and 5 metres greater Y then has to be 10 metres Lesser Y and 5 metres greater X after the rezzer has rotated 90 degrees in a clockwise direction. So, what is required here is not the rotation of the object itself, but the rotation around a point. Have a look at http://wiki.secondlife.com/wiki/Rotation this page , in particular the section headed Position of Object Rotated Around A Relative Point After that, there may still be a rotation to apply to the object if it is to be inverted, or twisted, and that is in effect the object's rotation you will see on the built floater extressed in degrees, but it will be relative to the object's centre, not a regional rotation. And yes, I hate rotation too.