Talia Davidov

Ok your analogies fail completely as it is not the same thing at all. You want analogies here are your analogies more apt to the situation. You are driving along in a zone that has a speed limit of 70 MPH and after you pass the posted sign a county worker comes out and changes the sign to 55 MPH and a cop pulls you over and gives you a speeding ticket. Do you blame them for your speeding . .yep. In your checking account analogy. You write all your normal monthly checks, but the bank suddenly adds a $100 processing fee to every check without notifying you. Therefore, you go overbalance. Do you blame the bank heck yeah. (both analogies are strained but hey I had crud analogies to start with). Here is the one other thing Cincia that DOES make LL responsible. They have a setting in the client software that sets the maximum bandwidth the client is supposed to use. This BUG ignores that setting. It is not unreasonable for an end user to expect the software and servers to adhere to its own settings on maximum bandwidth used. Bottom line, I am not arguing the LAB should be paying peoples Internet bills. I am arguing that they have a moral obligation to fix this as quickly as possible. They have a moral obligation to TALK TO US. The silence is maddening. At the very least they should have posted a warning somewhere when they finally realized this was a legitimate issue. I am sure there are people that won't have a clue until they get a large bill about it. Your assertion that it is the peoples using the service fault for not checking bandwidth every moment is what made this personal, not Ayesha. It implies a stupidity factor for all those affected.

It was just as wrong when you said it in the other thread as it is here. This is solely a SL problem. Why would we the users suddenly expect SL to spike traffic to an unprecedented amount. I am sure users who have a cap have calculated how much bandwidth SL usese. Are you saying they should do that each and every time they log on?? Thats just silly and you know it or should at least.

I agree with Rolig just try again, however I would also say that when I get this message I make sure I have a copy of the script in a non SL format (either in notepad or LSLEditor) just in case something really wonky happens like suddenly I get disconnected.

Innula Zenovka wrote: ETA -- about the traffic issue. It's just been pointed out on the jira that this sounds very much indeed like a repeat of SVC-7459 from last November. I would have to agree it mimics last years bug number almost exactly on my sim.

Right now you are using a repeating sensor to find the names to add to your list (well four of them). So the process goes as follows: SensorRepeat repeats every 5 seconds so each 5 seconds, if someone is in location a sensor event is raised In the sensor event you do all the detail work, adding them the appropriate list In using llGetAgentList it does not fire an event but simply returns the list to you Therefore, instead of using a repeating sensor, you would use a timed event to run every five seconds. This would give you: Timer event runs every 5 seconds This returns you a list of keys all the avatars in the designated area (region,parcel, etc) You then step through the list just like you stepped throug the sensors list to do all the processing note: you can not use the detected functions but you can use llGetObectDetails to get things such as position Note2: since this has no distance limit, you need only one object

Things like this happened long before pathfinding was out. It has happened at least twice to my home sim. Simply contact support and they can reset it for you. Last time it happened ot me contacting live chat had the sim up in running in under 10 minutes.

But saving processing time by not doing the function call, nice just didn't know about it.

integer i = (gone !=[]);while ( i ) What an interesting little tidbit. I am trying to wrap my head around the (gone !=[]). Can you explain it as I have not seen this? Thanks

The GetAgenSize trick is just a quick and dirty method of finding out if an agent is still in a region because it always returns a value if the agent is in the region and always returns a zero vector if the agent is not Copied snipped from that original thread I pointed to if(llGetAgentSize(id)==ZERO_VECTOR){ // the avatar whose uuid is "id" is no longer in the region}

If you store the time they arrived, then note the time they are no longer there, then the duration is simply subtracting one from the other. IHere is the psuedo logic I use: 1. Do Area scan, store entries in DetectedInZone (note I store in the list entry Key|starttime), also keep integer varialbe of time scan ran 2. Compare DetectedInZone with InZone list to generating two additional Lists, NewInzone and LeftZone 3. Add NewInZone entries to InZone list 4. loop through LeftZone list subtracting the stored start time value form the scan time integer to calculate durationtime

If its in a region, you can use the snipped that Innula gives at the end of this topic. Just run it on a timer to check if they are still in the region. If it is just an area within a region, then you will need to simply compare your sensor runs each time tracking who is currently there and if someone is no longer there, marking that down as exit time. How accurate it will be will depend on how often you run the timer. I do something similar and use ListXnotY to compare whether they are still around or not. As a suggestion instead of four sensor objects you could rewrite the code using the new llGetAgentList.

That seemed like a pretty postive response to me . . though am I the only one that finds it a bit scary the things Andrew didn't know like do picks still work . .:matte-motes-agape:

Number 3: it would add liability to LL. Right now they get safe harbour protection, but if they are in the approval process I believe that puts that in Jeopardy. Number 4: HECK NO!!! I don't want some one who can't even bother to post any information updates for months on end to suddenly be responsible for "approving" my stuff. Let market forces approve my stuff, if its good people will buy it. If its crap they won't

Maybe try to get the land owner to do a restart fo the sim. See if that clears it up.

The only way to do long senteneces is do the sentences up in the description. For example if your choices are: A - This is the first button to priess. B - This is the second option C - and the third option. Then on your buttons you would put A B and C. There is a maximum length for the description text (512 characters I believe).

Innula's observation and warning were much appreciated by me. We should never plan our scripts on the best case scenario. There is very little chance of a sim with 100 Avatars. It is still theoretically POSSIBLE, and therefore we need to take it into consideration in our memory usage planning. As for the rest of the discussion about other functions returning a great deal of data . . .um . .so? You need to plan for them too if you use those functions.

That had not occurred to me either, and I just released updates to my entire product line with scripts that use it. I tested with 25 people on the sim, but the implication of what happens in an even busier place did not occur to me. Thanks for the heads up. ETA: I got lucky, the script I have calling it has quite a bit of free memory.

Just a heads up, in a reply to Jenni in the server forum Oskar not only confirmed that its sister function was owner only, but that llTeleportAgentGlobalCoords is owner only as well. He has corrected the wiki now to reflect that.

Rolig Loon wrote: /me waves to Darkie and marvels at his fast typing :smileyhappy: /me always marvels at all your fast typings. I think "hey that question just appeared and already has four answers . . ."

:matte-motes-grin: Thanks anyway!

figured it out. There was an old setpos command in there I had missed. So the error message was telling me it couldn't use setpos while keyframedmotion animation was playing

Actually there is no animation running at the moment, just a set sit position.

Was looking at replacing looped SetPos commands in one of my cages with KeyframedMotion. When I put in the llSetKeyFramedMotion command I get the following error Cannot use a script to move a linkset while it is playing an animation. Stop the animation first. erm . . .I moved it with SetPos, but can't move it with llSetKeyFramedMotion??? command I used llSetKeyframedMotion([<0, 0, -3>, ZERO_ROTATION, 2],[]); any thoughts on what to do? Thanks Talia

Didn't those end up not be "non-delivery" issues. The items were being delivered but where not showing up until the users relogged. The root issue being they where having some grid problems and unscheduled maintenance that has since gone away? I know the Marketplace has issues and LL treatment of us as costumers here has "sucked" to put it mildly. But the DD process itself (if you can get in, since some peoples merchant outbox won't work at all) does seem to work. I have not had any delivery issues since switching to DD. Of course, I didn't have that many when I was using magic boxes either, but I did have some.

Oskar/Maestro . . just a pointer to make sure you are still looking at the conversation from last weeks deploy thread. The discussion about the prim accounting changes was still ongoing when the new thread appeared. Thanks