Profaitchikenz Haiku

This was on CoolVlViewer. Now this is interesting, I had no idea such activity occurs, do you know what the criteria for selecting ones to purge might be? I have noticed after crashing that on return the world is often grey despite having been there for long enough to have cached all the textures, it's as if the action of a crash flags up the content within draw distance as being unreliable and needed to be reloaded?

One point I recently learned, when your cache gets full, textures just don't load. I hadn't appreciated just how much I'd stored flitting around places, and when textures plain refused to load and I saw the cache directory size was greater than the upper limit I had set in the preferences, clearing it was the only option. Bearing in mind the churn of sims coming and going , there isn't any obvious way to get rid of cached textures that are no longer relevant. Suppose you have regularly visited a full region which then packs in. Those cached textures you've got are now possibly worthless, if none of the other places to go to used the same textures during their builds. Since the region isn't coming back it would be nice to be able to purge them but this isn't an option. Once a certain number of places you visit are no more it's probably a good idea to clear cache and then go around the places you still frequent and re-cache it all.

I have often found a difference between the link number of a child as shown in the build floater and the link number as reported by a touch on the child. I would suggested you drop a script in the root that chats out the llDetectedLinkNumber of a touched prim to determine what number to then pass to LinkPrimitiveparams instead of reading from the floater.

You can get round some of the line length problem by formatting the float to string result so that 0.00000 gets sent as 0.0 which can often shorten the transmitted line considerably.

Loops are always going to be too fast, this is where a short duration timer will give you a better visual effect. To rotate through 60 degrees I would suggest you first try it in increments of 10 degrees at 0.5 second timer setting. Shorten the timer interval and see how this makes the rotation appear, and if that still isn't smooth, try 5 degree increments. On things like railway engine spoked wheels I'm using quite a short timer interval but I'm rotating 22.5 degrees at a time, on the basis that the forward motion of the locomotive is going to mask some of the otherwise jerky effect. If (as I suspect) you're making a fish swim then you can probably get away with the same trick.

I doubt it was that intentional, they had to have an image selector for picking the map. they re-used the existing code from the texture tab.

I can see that it would give a lot of read activity, but I can't see how AV scanning would cause write activity?

Animations are client-side and don't result in position updates, while objects in motion (not omega rotation) will be causing updates from the region to the client at frequent intervals. This can cause some jerkiness if there is network delay or server loading, but the avatar animations will not be subject to such delays.

I'm guessing here that Kyrah was hinting at it being a bitwise operator?

I'm sure they are, but a point here is that LSL might not need to go to the number of decimal places that approaches the area of vacillation: for example, since you can only scale an object to a minimum size of 0.01 metres testing for equality is unlikely to be affected, similarly just how fine a precision does on need for a position vector? If you can also only position to +- 1cm then again you're not at the point where a difference in the fifth significant digit is going to be noticeable. This problem pre-dates c# by several decades, by the way, In the past there were two standard ways of dealing with it, (three if you count turning a blind eye to the problem). Method one is to declare your smallest amount that is to be taken as a difference such as 0.00001 and then taking the absolute value of the difference between two floats and testing for greater than or less than. Method two was to work in fixed precision, say three decimal places, and do integer arithmetic, sticking the decimal point in at moments of display "the output, as the Ita name it".

I think you should have a go at it yourself. Look at llTakeControls in the wiki and examples, it's almost always nused njust for steering a vehicle but there's no reason why you couldn't use the cursor keys: left and right to go next or previous pose and the up or down to vary some other factor.

Good point, that escaped me entirely when I first read the post. Thinking about this, omegas also stop when you grab an object to inspect it, don't they? There might be a wider range of things that freeze updates on the client.

I don't know why the other script is being reset, but resetting this script is a very inefficient way of doing things. I would suggest creating a global variable isBright, toggling it between 1 and 0, and in the timer, either set things bright or dull according to the toggle // snippets only, not a full script integer isBright; state_entry() { // just after you have set primitive params for fullBright isBright = 1; } timer() { if( isBright == 1) { // set primitive params to dull isBright = 0; } else { // set primitive params to bright isBright = 1; // and delete that sleep(2.0), it's superfluous, the timer will activate every 2 seconds // and delete the resetscript as well. } } Note that there is a faster way of writing it where you invert the value of isBright and also a shorter way of writing the test line but it is probably clearer as I have suggested. Note also, biggest gotcha of this class of language, the use of == inside the test value, losing one of them will result in isBright always being set to 1 Making these changes to the script will at least solve your problem with the other script resetting with the added bonus of being more efficient.

The train simulators such as MSTS and Trainz take the bogie positions as those which should adhere to the track vectors. The hierarchy of objects is a little complex, especially as each simulator uses a different format, but essentially the bogies belong to the parent, in this case the railcar, but in determining the placement of the railcar on the track, it is the bogies that are used. A complication with any system you try and implement in SL is that you have to cater for reverse-curves, ie the two bogies at their separation are going to have to adopt different rotations to each other. When traversing a crossover, for example the lead bogie will be at an almost opposite angle from the centre-line of the railcar to the trailing bogie. This gives a problem when taking the body as the master object which senses the track and communicates position and rotation information to the child bogies. If you decided to make the two bogies and the railcar body as three distinct objects you could then have each bogie sensing the track to determine their alignment and communicating their results to the body, effectively telling it where it should go, but that creates more problems : a vector has to be established between the two bogie centres and the body must be aligned along that vector. Trying to do it with the railcar as a single object would involve some complex puppeteering of the child prims making up the bogies.

Spinal Tap - "11"

I tried that, but I'm not too keen in seeing what's inside me.

"Throw in an arbitrary refrain"

Ignore, I'd not spotted the requirement for remote communication. Distance is a consideration here, if the two objects are going to be further apart then chat is not going to be heard, so I'd suggest you look at llRegionSay. Each object would listen on a certain channel that needs to be set up in each script. Object 1 gets some text in a text box which it then echoes on the communication channel using llRegionSay, and the other object hears this and shows it on the screen. I bet Molly just beat me to it by less than 60 seconds

It might be more fruitful looking through stackexchange for getting and using 32-bit libraries, they are still around but things like synaptic and apt-get are going to not see them so you will end up doing stuff yourself. My personal experience now is that 32-bit systems just can't manage the new stuff on SL, they cope with the OSgrid/Outworldz places Ok, but not our mesh-heavy Advanced-lighting triple-image downloading system we need because "we're all so beautiful - dah-de-dah-de-dah..."

Ah that's it, green-dot bait. Works every time.

That explains why I still get this feeling someone's watching me even after that setting

I think you're getting confused about "object" here. Think of "Object" as a linked set of children. Then a link message from a script in any of the child prims is available for any other child prim that has a script to receive, or in fact another script in the same child prim that sends it. The link flag controls then can be LINK_ALL_OTHERS to broadcast the link message to any scripts in the rest of the linkset. Other flags allow targetting specific children, or even the sending child so that other scripts in it get the lessage but no other children.

Not sure on this, but if you are in your own parcel, setting the options so that other avatars can't hear or see residents in the parcel might also block camming in?

I had this issue with Singularity when trying to upload any animations with the extra Bento bones. Firestorm and CoolVlViewer both worked correctly. I didn't try the LL viewer but I suspect it too will handle them, it's just Singularity lagging behind a little.

Reminds me of a Stanislaw Lem story where robots called humans "Mucilages"