Profaitchikenz Haiku

This is very true, and at the risk of repetition (bzzzz....) I had this in mind earlier in the thread when I asked could there be a guide for the non-coderatti to say what some/all of the many available tweak buttons actually do, when they should be used, and what happens if you eat too many of them at once?

At last, somebody cares...

This was mentioned at one of the last server user group meetings I attended, they said they were going to limit the profile pictures to just the moderators or owners?

I see the macs as very much the Vincent Black Shadows of the desktop world, you could get around on a Honda 90 just as well, but.... there's a certain style to the recherche and the anachronistic

as much as I admire the way you've managed to besmirch all the major OSes in a single sentence, I have to say you're being unfair on the mac-users, their equipment is more expensive and more esoteric than most other things you find on desktops

"Do not meddle in the affairs of wizards, it makes them soggy and hard to light"

Travel far and wide?

Hello, Mac-user

If you''re on Windows Get Windiff installed on one or both machines. Change the default location of the chatlog folders to a folder you can then open for sharing on each of the machines. (the default location isn't a good one for this) Run Windiff. This will show which are new files and which are changed files between the two shared directories on the machines. It will then allow you to copy the differences to get both sets of chatlogs to the same state. If you're on Linux, you can get an app called Unison to do the same as Windiff, once you've jumped through the hoops to get file-sharing, guest access and the appropriate permissions set up. I you're on a Mac, I can't help Cache size is an awkward one at the moment, since it has been suggested that when the cache grows beyond a certain size it then becomes slower to use than just downloading the stuff straight off, but there is no real idea bout the size at which this happens. Henri Beauchamp elsewhere suggests 2GB is more than adequate. My own examination of my cache folders suggests this is right unless you go gadding about wildly everywhere. I run 4G for my caches and don't see any issues but I do see very strong evidence that accessing the textures cache is slower than grabbing them straight off the connection.

What it says . If you are only dealing with a single avatar at a time it's quite straightforward, once the CHANGED_LINK condition had been detected and a non-null UUID found on the sit target, the very first thing you're likely to need to do is to stop the "sit" animation to replace it with one of your ones. So you request animation permissions for that avatar, and once assured, stop "sit" and start the desired one. If you are cycling though several animations for an avatar you can play more than one on them at a time, for example a hands animation juggling a chicken, fox and a bat, and legs animation for the unicycle they are riding. If you then want them to stop jugging and switch to patting their head and rubbing their stomach at the same time, you want to stop the upper body animation and replace it with a new one, but not stop the legs animation. With more than one avatar it gets slightly more complicated in that you have to keep track of the uuid AND the animations, and which one you last grabbed perms for, because when you come to stop an animation, it will be for the last avatar you started an animation for, and if that is a different avatar you have to get to the right avatar by requesting perms again for them, then call llStopAnimattion. It therefore pays to keep track of which animation(s) you have started on which UUID. Just another bit of list work.

Would you have any idea what the size is at which this trade-off occurs?

Is there any chance of extending the Firestorm 32-bit option to limit textures to 512 so that the 64-bit viewrs can take advantage of it? Or is reducing the texture size not a cache-storage operation but a GPU-loading one and so would further increase the processing?

I just noticed this, you have to test for specific changes in the way I illustrated above if( change & CHANGED_LINK) ) will test for a specific bit set in the integer to show that somebody has joined or left the linkset.

OK, I think that you only need to call stop animation before starting a new animation if it's the same person, so when somebody stands or TPs away there is no need to stop anything. when a new person arrives you obviously have to stop the sit animation, and any changed ones for them. ETA, are you dealing with multiple sitters?

In another thread on these forums it was mentioned that it is no longer necessary to stop animations when somebody stands or crashes or TPs away. I'm not sure how exactly you are trying to stop an animation and getting it held there for such a long time. Typically, this is what I do in the changed event... changed (integer change) { if( change & CHANgeD_LINK) { key sitter = llAvatarOnSitTarget(); if( sitter != NULL_KEY) { // we start doing stuff to/with them llRequestPermissions(sitter, PERMISSION_TRIGGER_ANIMATION); } else { // the sitter has left the building // clear out any globals that were used for them // set up for the next sitter, which is usually preparing to stop the "sit" aniimation // and starting one of a sequence of animations } I used to try stopping the last applied animation right inside the else construct in the hope it would prevent animations continuing to play on the deer-departed, but with mixed results, getting permission errors with TPV's that revoked permissions on stand, etc. I suggest you try only stopping an animation inside the run_time_permissions event when you are then going to start a fresh animation and see if this makes the error cease.

This isn't necessarily true, using a single 1024x1024 texture for a building and mapping parts of it to the various faces i far more efficient then using half a dozen textures on the different faces. In the train simulators many buildings and structures are textured in this way, and when moving through a 768x768 region of the world in Trainz there is none of the blurred greyness that plagues SL, despite the trees and buildings using large textures. The problems that plague SL are more specific to the manner of storing, retrieving and applying these textures, so the fewer that can be used in a scene the better. Sadly, we lack some of the more advanced texturing tricks such as picking a small part of a large texture and then tiling a face with it using repeats.

To save a lot of deletion and potentially losing un-backed up copies, I use the /* and */ surround combination to block out as comments whole swathes or code such as an etnire state.

I have a couple pf 12-year old PCs limited to 4G RAM, the run several viewers as well as Catznip quite well. I have to avoid the really crowded clubs but I see that as serendipiy, not a major limitation. I do accept though that if you want to visit a region that is chock-full of mesh buildings you do need ALM off to get at least half a chance, so that's one area where newer hardware is a must.

Possibly a slow learner then.

You have to try and see this from the perspective of a relative newcomer, they're done a search and had a thread come up that meets their expectations, they will inevitably add a post. I know it annoys the hell out of many of you, but I don't find it enough to make me thump the desk, And as Arielle said, possibly paraphrasing Georges Santayana, the past has an importance that is easy to overlook in the heat of the moment.

Halloween approaches, The dead begin to rise, Please put some pennies on The dead man's eyes

My guess is because they aren't doing anything of the type. Let's face it, anything they decide to do, half of us here are going to complain about, so why take the pain for an uncertain gain? Things here work, sort of. If they're happy to leave scripts struggling to get 40% completed within the time frame, then the slight pause in rendering isn't going to be a sweat-breaker either.

The news? Elections? TV Fishing? Knitting channels? I'd better stop...

I was being slightly tongue-in-cheek A typical user won't start categorising the type or reason for the unhappy experience, they'll gripe and go. Regarding the host-on-a-potato issue, the hardware is probably going to be less of a problem than the ISP connection said vegetable employs, based on my own experiments. I've not tried a potato yet, but I have carried out several experiments with Linux on dead badgers.

There was an interoperability project in the previous decade, hosted I believe by IBM? where a SecondLife to Opensim region connection was demonstrated. I can't remember why it went no further after the initial successes.