Profaitchikenz Haiku

That wouldn't explain the growing incidents of it in grids outside of SL. My current hypothesis is that its delayed network traffic. I haven't seen any SL incidents now since before Christmas, and only a ref recently in a couple of other grids. However Niran favours cache corrupption. Presumably th TP away and return results in a refresh of somethhing, eithr cached data or fresh data from the region server. When such an object is not showing, it is possible to right-click it, edit it, and then view the textures on the face(s) that you are able to get to with the limitations of wireframe view. Invariably these show the textures that should e showing, together with the expected scale, rotation and offset parameters. How this information is obtained by the viewer is outside my knowledge,but could be significant: You (and Niran) would be in a perfect position to implement some sort of "Check this object" action. The way I see it, you would right click on the missing object (possibly after first going into Wireframe to actually find it) and then choose an option called something like "check". This would be rather lie a ix of the old inspect function, it would determine the object vertices and the textures on each face from what it had in cache and compare then to requested information from the server similar to what a refresh command does. There are a few pitfalls obviously, texture UUIDs cannot be listed for items with insufficient perms, so preview thumbnails wold have to be used instead. If differences are detected then some sort of reload completely action is required.

I always wondered what the plot in Hitchcock's film was...

What are they going to be called, CollecTilliables?

A blueberry, rampant , upon a mont vert. With the motto "The only way back is down"

Intelligent would be better

Yes, it's a text-based browser. Log in, there will be a very basic world view, low ;level detail, but full chat and IMs, and under inventory is a drop-down field for backup. Choose a folder, and your SL inventory folder structure will be recreated to contain any textures, scripts and notecards whose permissions allow you to save a copy. It can take twenty minutes or so for somebody with a large collection of stuff.

Just thinking, if there are a significant number of notecards to be saved, the best way is to use Radegast, it has an option to backup the inventory to disk. It saves notecards, textures and scripts if the permissions allow. If there are several items in a folder with the same name, only the most recent one will end up on disk, so if you have a dozen "new note" notecards, you will have to rename them by appending sequence numbers, such as new note 01, new note 02, ...

I'll leave him to you, he should at least be bouncy and comfy for a cushion.

I had got that far after making the root prim significantly larger and tweaking the dimensions of the rod and weight. The random angle stop had been driving me nuts and I was looking at whether I had to add energy to the system at each end of the swing. Thanks for the insight.

I want my name to become a term to describe non-sequiteurs, as in "That was a real ProfAicth of a reply"

Midian City always gave me that feeling of Bladerunner territory.

From my experience save and keep do the save thing except one closes the notecard and the other keeps it open for you to hack away at a bit more? (Don't trust me on this, I've got up because of insomnia, I had a waking dream that somebody had replied to a post I made so I got up to see if it was true, and in a sense it was; somebody had indeed replied but it wasn't the person mentioned in the waking dream)

I'll settle for Blueberry.

I was hoping to adjust both the length of the rod and the size (and therefore mass) of the weight. My aim is to try and see if there is a Foucalt's pendulum effect in SecondLiife. If there isn't, it would be a smart answer to some f the bozos who persist in the idea that the universe is a giant computer simulation.

I came up against something I've not seen before: Scripting a pendulum where the root prim is a sphere, attached to that is a 5-metre rod, attached to the end of that is a cylinder intended to be the weight. So a 3-prim linkset. When non-physical, rotating the object around the root Y axis using KFM works as expected. When physical, trying to rotate the object around the centre of the root prim using llRotLookAt , swings appear to be operating around what is either the geometric centre or the centre of mass, about midway along the rod. I can find no way to force the centre of rotation to be the centre of the root prim. I'm not sure if I've overlooked something fundamental in physical objects or if this is something vehicle builders have always known about and I've missed because of living in an ivory tower? ETA, OK, I forgot all about the object dimensions field that lets you fiddle around with what each object is made of, so it appears to be centre of mass that determines the rotation centre, not geometric centre.

You know you're spending too much time online when... You walk into a shop in RL, open your mouth and start to speak, and expect half a dozen suggestions to magically pop up out of nowhere.

I got inworld after Windows finally got tired of churning my machine around updating something . I too am a standard avatar, like the OP. I looked in all the appearance edit options but could see nothing where it might be possible to accidentally set a body t be non-BOM. I can suggest a simple test: Create a new shape under BodyParts. Wear it. Apply a different skin (if you only have the one look on the Marketplace for some freebees). See if a fresh shape with new skin still gives the same problem to you and other people viewing you. ETA I am assuming you have a recent PC with a good enough graphics card: the only time I have heard of this problem was with somebody who was trying to use an old 32-bit PC with an old NVidia 32-bit PCi Express card that would not show alpha masks to them, but everybody viewing them saw the masks working.

If the body is a mesh one, look for where it is in your inventory with "worn" shown, right click the inventory entry and choose "edit". In the edit floater, make sure "select aace/Select texture" is showing, then choose the texture tab. You will see a field for alpha ode. I you can't find an object in your inventory named for a body of sorts being worn then this is a system avatar and the above advice will not be applicable.

I'm confused by what you describe as a "standard mesh" avatar, not a "mesh avatar", do you mean you are a basic system avatar? If the latter, then I too am at a loss for what could be causing it. If however you are indeed using a mesh avatar set to Bakes on Mesh, check the texture settings on your body and see what alpha mode is set to. It should be "alpha blending" with the mask value set to 128. There are some reports of mesh bodies having the alpha mode reset to "none" and the results are exactly ass you describe.

That is certainly my conclusion, and as it's showing up just as frequently in other grids, that's pointing towards infrastructure.

Not if it's random and aperiodic, bit like the telephone noise that Mandelbrot investigated. Errors arre rare but cluster. So you would every now and then get a blip, something no textured. Somebody TP-ing in beside you would see what you couldn't, because they hadn't experienced the blip, their hops to SL and back wouldn't be the same as yours. I tested Black Dragon earlier, no problems, but I also tested four other viewers and again no problems, Whatever it is that causes these issues, it's in hiding today.

The idea of malformed data being written to cache is one I had't thought of: so after it has happened, TP-ing away and back again causes more recent information t be returned from the server and so makes good the cache error? ETA just realised you're talking about the object-cache not the texture cache here, so that might explain why the right-click and "refresh textures" trick fails. As much as it would be fun to blame it all on AWS, one of the Opensimulator grids I use is entirely on UK-based servers, so unless there's a loot of tromboning on the backbone I'll stick to it being a general innernet issue rather than a specific one. I must get your viewer up and running again, I should have installed it on my new (old but new to me) PC which does now have a bit more resources, but things got in the way.

The closest you can get would be to have a texture in each folder showing a view of the item, some viewers will pop up a small preview of such a texture when you hover over the opened folder (Catznip definitely does this) So in a folder, you park a snapshot of the outfit/object, and somehow try to get it to the very top of the list, or else name it "0Preview" or "!Preview", the idea being it's always going to be the first item in the folder whether you have sorted by name or by date, and as you open the folder and mouse down into the content, the preview picture pop up as the mouse passes over it.

I have a slightly different take on this: I use separate caches for different viewers so I think that rules out cache corruption due to viewer change. What I have observed is This happens in all the viewers I use, to varying extents, Singularity and Alchemy Beta are perhaps a year old and show it so that rules out recent viewer changes, other viewers are up to date and still show it. This happens in the Opensimulator grids too, so that rules out SecondLife server code changes, LL's content delivery system, EEP, etc It began to increase in frequency in the couple of months leading up to Christmas, so I an tending towards it being a general internet traffic loading issue, some packets are just not getting to their destination in time. As an example to justify this, consider the other day when I logged into SecondLife and TP-ed somewhere I spend lot of time at, so all of the required textures must be in my cache. There are two clumps of four trees straddling a railway line. The clumps are sculpted trees, each object having one prim for the foliage, one prim for the trunks and branches. Both clumps were well inside draw distance. Both clumps showed the foliage but only one clump showed the trunks. Wireframe showed me the invisible trunks were there. So the same bark texture, in cache, was showing on one object and not showing on another object alongside it? The likely scenario I envisage is that a packet of information from the server saying "object blah at position blah-blah has texture blah-blah-blah on it" got through for the first clump of trees, but not for the second. Against that hypothesis is this observation: editing the clump of trees and selecting the face for the trunks showed the preview of the texture and all the correct offset and scales, but didn't toggle it back into view. So it knew what should have been there, it just wouldn't show it.

Not in the Billy Bunter series, it wasn't. "The Fat Owl of the Remove scoffed the lot, you rotters! Ow whoop Yaroogh!"