Profaitchikenz Haiku

Agreed, but I spy the odd hint or two of abnormality in many of our Slitizens. Some people live for nothing else but closeup shots of eyelashes and accompanying makeup. There are some things I have made in SecondLife and exported to a 3D-printer that have to be made 10 times and scaled down externally because of the minimum dimension. I know itt's not a problem, but also for some things I make such as the handrails for steam engines, the minimum 0.01 dimension means the assemblies from which the mesh or sculpts are to be made must also be scaled up and the finished item then re-scaled before use. It's not a big issue except that in order to make the assembly to fit precisely in the build, the build also has to be scaled up...

It's a question of scale, would you really want to be seen with fingernails 1cm thick?

It's quite simple to investigate. Set it to a low level, say 100, and TP to somewhere you know is cached. watch how nothing seems to rezz. Increase the slider to a more reasonable level, sat 1000. Notice how everything begins to appear. Because the location is cached the delays to rezzing cannot be due to texture bottlenecking, they're already there in the cache. I am still not sure why having a very low bandwidth setting should result in such a delay rezzing. What I do now is that if it is set too low, not enough information regarding object positions, sizes, texture uuids on the faces, etc, gets to the client, or possibly such handshaking that the client performs with the regions goes so slowly that the region assumes the client isn't there. However, it does prove that the bandwidth slider could allow you some control over how quickly or how slowly information is sent to your client by the region, I'm jut nor sure if it has any practical purpose.

I can't believe it's not barter. (I''ll get me coat...)

Lessons learned the hard way with a swinging pub sign using KFM: Rotation is less accurate than position, left to itself a swinging pub sign slowly works around until it is well to one side of where the centre is. moving_end does not always trigger precisely enough to be certain the swinging object has actually stopped swinging ping-pong mode exacerbates rotational problems in regions with idling happening. Oddly, the errors seem to preponderate in one direction, leading to the ratcheting round effect. (Still not investigated is if the direction of the error is connected to the initial swing direction). Use @Animat 's defensive programming techniques and constantly check where the rotation is and make a second KFM call if it's lagging behind where it should be. However, doing an llSetRot() at the end of each KFM rotation can break the smoothness of the required swing due to the inherent 10mSec function call delay. The best way to get around this is to either check the discrepancy and only do a setRot when it exceeds a certain value, or only do the correction every few cycles.

Uploading to the Beta grid is the most accurate way to assess this. Plus it will allow you to asses the visuals and look for any ommisions.

There is a way to do it using the in-world sculpt or mesh creation tools. (you could actually do it with prims but you would have a 64 - prim rope) Create a short cylinder, say 0.2 m long and 0.02x0.02 for the diameter. (If using the Mesh Generator tool, set the top and bottom faces to be transparent) Copy this as many times as you want, changing the position and angle so it follows the required catenary curve. Link and create the sculpt or mesh. I've used this method to make railway lines and paper chains. The short straight lengths don't show up as much as you might expect, the eye and the brain seem to have an agreement to stop quibbling and just go with what one desires.

I can't comment on windows but I have been using the latest Firestorm on Linux an what I have noticed is that it seems slow to empty out the textures it no longer needs. I might be misinterpreting what I saw, but this what what made me come to that conclusion. 1) Visited a welcome centre with quite a lot of stuff around, particularly mesh. 2) Checked HTop and saw how much RAM had been grabbed. 3) TPed to a sandbox, effectively nothing but land. 4) checked Htop and saw no change in RAM usage. 5) Shot up to 4000 metres to clearre video ram (old trick that might not work any longer) 6) Checked Htop, no change in RAM usage. 7) Logged out, relogged into the sandbox 8) Checked RAM usage, minimal as I would have expected.

"Budgies? Budgies? We don' need no breedin' budgies!" (With apologies to The Treasure of the Sierra Vindaloo)

I never knew the void was socialist

Thanks Fenix, that one had slid by me.

Like Tiny Empires?

I agree with Candide, I am using the Linux versions of Singularity, CoolVlViewer, Firestorm, and all are quite satisfactory for mesh uploads.

To set all faces at once you need to use the constant ALL_SIDES. However, to do what you wish to do you will need to provide a loop that increments the variable from 0 to llGetNumberOfSides(); and take action accordingly // thi is a snippet, not a complete script setFaces() { integer face; integer maxFace = llGetNumberOfSides(); // set any initial texture states here such as texture, stopping anims, etc llSetTextureAnim(0, ALL_SIDES, ... for(face = 0; face < maxFace; face++) { if( face == 1) // set a texture anim for this particular face { llSetTextureAnim(ANIM_ON | SMOOTH | LOOP, face, ... remaining parameters } else if(face == 4) // do something different { llSetTextureAnim(ANIM_ON | SMOOTH | LOOP, face, ... different parameters } // otherwise do nothing } } The snippet shows you how to go through the faces one by one and do things for specific faces. If you want to start and stop these animations alternately you are better using a timer which calls this function every few seconds, and have a global variable onOff which controls whether the functtion starts or stop the animations, changing the value of onOff at the end of the function so the next time the call curs it does the alternate action.

There is a way around this problem that is a little klutzy but it's quite workable. Let's assume you are going to use CoolVlViewer and you're going to use it for SecondLife, some OSGrid work, and your SimonaStick, and you don't want to start mixing textures and objects from totally different grids. Let's assume you've just finished some SL-hopping and bopping around. CoolVlViewer in the preferences will have a cache director location. Let's assume it's F:/Caches/CoolVlViewer. In F:/Caches, create two additional folders CoolVlViewerOSGrid and CoolVlViewerLocal. Create a third folder called CoolVlViewer_now_SL (This is telling you that currently the cache folder called CoolVlViewer is being used for SL visits.) So now you decide to go off to the OSGrid. Shut down CoolVlViewer. In the cache folder, rename CoolVlViewer to CoolVlViewerSL (This is keeping your SL content safe) Rename CoolVlViewer_Now_SL to CoolVlViewer_now_OSGRid (This is telling you that the cache folder is now going to hold OSGrid stuff Rename CoolVlViewerOSGrid to CoolVlViewer Now, when you start CoolVlViewer, it will have an empty cache and as you wander around the OSGrid, it will start to collect the things it must At the end of your wanderings, if you want to go back to SL for a while, you reverse the procedure Rename CoolVlViewer to CoolVliewerOSGrid (whatever the CoolVlViewer_now_ indicator folder says it is) Rename CoolVlViewerSL to CoolVlViewer Rename CoolVlViewer_now_OSGrid to CoolVlViewer_SL Like I said, it's a bit of a klutz, but it's actually quicker to do than it is to read the description of it.

Having two different viewers installed, the LL official viewer and an additional TPV, with them using separate cache folders, is the first go-to when you find odd behaviour with buildings, textures, scripts...

I would be interested to know precisely what the OP has been seeing / not seeing that caused them to start this topic. It could be slow loading / grey textures, which most people replying have assumed to be the case. There are some things that we can do to alleviate some of these problems. But it could also be the deteriorating performance of scripts, which nobody seems to have considered. There is nothing we as users can do to alleviate such problems, apart from stop using scripts.

It's a good idea to do so as it stops the real-time protection AVs from constantly scanning each change to the folders. Then as Rowan has said, it's probably something your OS or other background programs are doing hat's stealing CPU or RAM. Have a look at task manager to see what's busy next time it happens.

A large window resolution coupled with a 128m draw distance means there's going to be a lot of texture fetching and object-occlusion processing going on. If you have draw distance does this improve things? Also, have you stuck the cache file location into your antivirus exclusion list? If not, do so. I've also stuck the chat and IM files folder in there, but I've stopped short of also excluding the SL processes.

This is something that should be applied to a lot of issues that pop up here.

First thoughts are you're wearing something that listens to the owner and echoes it back. I'd suggest trying the LL viewer first because if you have anything with RLV-scripting,( which Firestorm supports), it won't work with the LL viewer. After that, try removing anything scripted you're wearing.

This cries out to be turned into a novel @) But seriously... I share your sense of loss, I have similar feelings not just about SL but also several other periods of my past. But be careful not to focus on the inevitable rose-tinting that the mind puts on fond memories: I've done this myself over and over again but when I look back through old diary scribbles or tape-recordings, I realise there was a lot of hardship or suffering going on at the same time that tends to get overlooked when reminiscing. SecondLife does lend itself to very short intense relationships that begin in a flash and then just fade out. I consider that time-experience in SL is just as accelerated as the day-night cycle, and I think an effect of this is that memories get even more rose-tinted (or black-dogged for the negative experiences) than in RL.

What secondlife/Opensim/new-venture has to try and break away from are the twin railway-lines of shopping and radio-with-animated-pictures. They might be well-travelled, but they're going round in a circle. You can't see twits on the radio. If I want to listen to music it's going to be of my choosing, and my current tastes wouldn't suit the dances - you can't boogie to Buxtehude.

A new venture doesn't have to mimic SL, it simply has to offer something appealing.

Indeed, but the point is how to use the existing information LL already store to sort out permissions for the proposed new function.