Profaitchikenz Haiku

On and off. Sometimes I'll log in and in local chat I'll see the tail end of conversations from a few years back. No idea what triggers it and it's too infrequent to pin down.

Sorry if I stubbed your toes, but I'm under doctor's orders to ruffle somebody's feathers once a day to keep my blood-pressure down

Yes, I agree, but from my own experiences I found that running scripts on their own to just count messages sent from other inworld objects showed no signs of any issues. It is when events requiring server and client communication are involved that the problems do start to become apparent. Things like Hud comunications don't seem to be affected, scripted attachments all seem to function normally, it is objects moving inworld that seem most affected by whatever is at the heart of this issue.

Those of us who noticed something strange a few months back already had scripts that used keyframed motion or prim puppeteering to move transport objects to and fro, and observed these movements were becoming jerky and erratic, and the times for the journeys were longer than had originally been programmed for, These changes coincided with a dropping in the contentious figure. The only problem, as I have discussed with Coffee previously, is that helivators, railways, busses, wandering pets are too complicated to form the basis for a jira. I on't think we need new scripts, just simpler test cases derived from them.

I ought to bring to everybody's attention that Monty said "some are just wrong". Some != all.

As n old-school programmer* I have to say give absolute priority to getting the code to work properly, documentation can be given to less able people during quiet spells. * Those who can do, do, Those who can't do but know, teach. Those who can't do and don't know, go into QA

I think what Monty was trying to say is that although you might have a lowish scripts run % figure, you might not actually be suffering any performance as a result of it. As I said above, using a scripted object that should perform to a known schedule is probably the only way to really evaluate the performance of scripts in your region. If the object behaves acceptably, doesn't jitter when moving, and keeps reasonable time, then the value you're seeing for your % scripts run indicates an adequate level. If the object takes much longer to complete the movement and is noticeably jitter then your scripts are not performing adequately. I am coming to the conclusion that many of the metrics we have in the Ctrl-Shift-1 floater are quite old diagnostics dating from when SL was in it's infancy and haven't been updated for some time, but are left there because trying to remove them from the code could a) break something because parts of the code involved may have other purposes b) cause all the TPVs a real headache in having to revise all their code in line with the Lab's sweeping changes So they're there, and because they don't actually have relevance today no attempt has been made to document them.

Add an on_Rez event and inside it either call close() or llResetScript() default { on_rez(integer n) { close(); } state_etry.... } Oh, and you don't need the two return statements in the touch event, the event isn't called as a function so they do nothing.

It's a bit like building a sandcastle, it's great fun and totally absorbing while you'e doing it. And then somebody comes along and kicks it everywhere...

I have tried comparing the viewer stats for several parcels and am as puzzled as you. The %scripts run seems to be the simplest comparison method of all but by itself doesn't really tell me much. The only real comparison I can think of is to have a scripted object that performs a regular travel between several points, at a set speed, such that the journey time should be a specific figure. I can confirm that in one parcel where %scripts run improved from 30% to 75% the journey time is now close to optimum, but I am not able to put that same item on different parcels. Elsewhere Month Linden has said that % scripts run is of questionable use for comparisons but I don't know if he meant comparing parcel to parcel or on parcel before and after a change in the figure. My own study suggests it is a weather vane. The lack of any spare time at your friend's club is slightly ominous.

The main force of nature I can think off is the upper prim limit for a region, which isn't a power of two and so seems to me to be somewhat arbitrary. Upping the prim allowance could be done for populated regions by reducing the allowances in sparsely populated bits of mainland. The trouble is, the limits would be reached almost before the end of the first week in which it was implemented....

This might seem a radical proposal, but I'm coming round to thinking that attracting new users could end up being analogous to the insurance situation where companies fight tooth and nail to attract customers away from other companies to their ones, leading to what had been described as "churn". An alternative is to look at why customers don't rush off to the brightest new thing, and that could lead to the conclusion that what you've got is adequate for your requirements. So, maintaining what the company has that convinces it's customers that what they've got is adequate leads to customer retention. We have chosen to live in what is effectively an islanded world, we have to accept therefore that there will be less new people drifting by simply because of the separation. Maybe it's the exclusivity that we all find to our satisfaction? /me checks the post heading, is he perhaps reverting to his old habits and drifting off-topic again? Oh yes, gosh crikey, time to salvage the situation. SL used to be a place for creatives, when everything (with the exception of textures and animations) was created inworld. Nowadays, SL has become a place to display creations made off-world.

And yet, we're all here, and not there....

It depends on what you want to accomplish. If your goal is to get a channel for a listen hat is reasonably safe against duplication, there are better methods such as taking a portion of the user's UUID and converting that to a negative integer.. One safeguard you could try is to take the length of msg before trying to cast it to an integer and making sure it does not exceed the length of a string holding a maximum integer representation, and don't cast if the string is too long.

Ebay is a suitable workaround. Just steer clear of Small form factor machines

To quote from the Godfather "They sleep with the fishes"

To quote Yoda "End well this thread may not"

I've puzzled over that for quite a while TY

I was mulling over my earlier reply and it seemed to me that although it is useful to know if there is a common element to a couple of lists, in general terms it is more useful to know what is the actual commonality? I realised my snippet adapts to return the intersection of a pair of sets quite easily list A = [1,2,3]; list B = ["a", 1, "c"]; list intersectionOf(list A, list B) { list result = []; integer start = 0; integer stop = llGetListLength(A); integer found = -1; list lookFor; while( start < stop) { lookFor = llList2List{A, start, start); if( llListFindList(result, lookFor) < 0) // don't repeat successes { found = llListFindList(B, lookFor); if( found > -1) result += lookFor; } start += 1; } return result; }

I suspect for animations the data being sent back to the server saying "avatar A has just commenced frame 2 of animation xyz" gets sent not at the precise moment that xyz starts again, but at a defined slot when a batch of information is sent, and so there will be an inherent locking into one of several distinct timeslots when the information is re-broadcast. I wonder if it's unique to animations or if it occurs in all client side activities. If you set a wheel of fortune spinning using targetomega and several people observe it, do they ultimately see it turning in the same orientation?

There's still lots of scope for just using prim and textures, system avatars or BoM on mesh. I think we got the flashy new methods far too soon, we hadn't really exhausted all the existing methods.

This problem about the speed of searching large amounts of data for a matching entry brings back memories of a system I worked on way back in the eighties. The problem was to determine very rapidly if a data item was already known, and like the OP, the client didn't want to go through the entire volume of stored data looking for a match. The solution I came up with worked like this. A piece of data was to be stored, let's say "My hovercraft is full of eels". This was hashed to a number which was the address of a storage location. If this location was empty, the data "my hovercraft is full of eels" was stored there. If there was already a different data item there, the hash process went through a second iteration to generate a new hash number, and the lookup performed, until a blank location was found and the data stored. To interrogate the database to see if a particular item was in it, the item was hashed, and the resulting location examined. If empty, then the item was unknown. If not empty but not the required data, then the second (and maybe a third hash) was performed. The system was extremely fast, rarely needing more then three hash operations, but required a large amount of memory, much of which was predictably unused. A refinement followed whereby the hash number was an entry into a lookup table where hash numbers were matched with records in a more compact database, at the expense of a little more processing time. I could see a possibility of doing this in LSL using two lists, one lit contains hash entries and indexes into a second list, but we are probably more constrained regarding memory than we are regarding processing time.

I must be not getting the full complexity of the problems, but to simply show if one list has any entry that occurs in a second list seems quite trivial and can be done using llListFindList, admittedly with a simple loop: list A = [1,2,3]; list B = ["a", 1, "c"]; integer isInList(list A, list B) { integer start = 0; integer stop = llGetListLength(A); integer found = -1; while( start < stop) { found = llListFindList(B, llList2List(A, start, start)); if( found > -1) return 1; start += 1; } return 0; } It returns as soon as it finds a match. There is some scope for being very clever and returning the entry number in the first list that was then matched in the second list by simply returning start instead f 1, and -1 if no match Regarding the matter of loops and script time, f there were to be such a function it would still be doing a loop internally, in order to go through the target list looking for matches. Loops aren't too much of a problem if you write them so that they stop as soon as possible.

If you substitute "challenge" for "problem" then I think you've got the best situation for a learner. Problems are as Sandy described - an unknown delay after rezzing an object before you cn get reliable communications with it. A challenge is "Make this prim circle around your head emitting particles so that you have a halo" The problem one is tiresome and you don't learn so much as plod doggedly on trying one thing after another. The challenge one is fun, and the only tough part of it is rotations ETA, as usualy, Rolig pipped me to the post what she said...

"He had a large chart, which was perfectly blank, and" "The crew were much pleased, for they found it to be" "A map they could all understand"