Profaitchikenz Haiku

I visited Ruritania a few months ago to look a the railways there, and I did find the spaciouusness of it very appealing. It is one of the best places in the Metaverse I have ever visited.

If your list of shameful practices gets any bigger, either your head is going to explode or you're going to have a stack=heap collision

But that's happening in both SL and the Opensim. I've been pondering Chin Rey's points about Ruritania, and as far as I can tell, the min difference between SL and the Opensims is that SL has all the asset servers in one place, but the Opensim has wide diversity of hosting. So is the bottlenecking simply down to that? Too much in one small place?

I'd have to say here, does it always matter? Take for example shoe or hair resizer scripts. You use them rarely, so if they take perhaps twice as long, it's insignificant really. Poor example, I know, so let's take another one, a vehicle with some scripts in the child prims to set target omega for wheels, maybe animate a few textures. (let's for the moment ignore that a single script with setLinkPrimitiveParams will do the job in one script). Each of the small functions like targetomega or textureanimation are called infrequently, not looping constantly, so it doesn't matter if they run slightly slower, it's unlikely to be detectable. None of those functions requires any significant memory either. The keynote here I'm trying to make is that it's the application of the script that really determines how to compile it, not just a desire to always attain the fastest possible runtime performance.

This worked fine on systems like the PDP=11s, but once you got to the 32-bit processors there was almost no gain, sometimes even a los. On one project I was asked to see about implementing overlays on a VMS system, and the prototypes I set up found no measurable improvement, if anything, a slight loss with the time taken to swap the memory to and from disk. Going back to an earlier point of yours, I worked my way through a lot of my scripts looking to see which ones did actually need the 64K maximum offered by mono, and I found very few did. Of those that didn't, almost all of them would fit in the 16K limit of LSL and so I have now stopped using mono for scripts where there is no possible requirement for it.

I need to get out more, looks like.

All of this is suggesting that a ne'er-do-well seeking to have a squad of zombie avatars under their control is going to have to use a fresh Hud/device to get the victim's permission, then detach/take back o inventory, where they will need to somehow rename/identify it to keep track of who it will animate... You're talking about a James-Bond style evil maniac, not the typical SL scallywag?

In the LSL wki, have a look at PRIM_GLOW under the entries for llSetLinPrimitiveParams, it's quite straightforward to use, You'll also be able to adjust the alpha of selected sides using PRIM_COLOR but you will need to get the colour of the side first since it must be present in the list of properties to be set. llSetLinkPrimtiveParams(linkNum, [PRIM_GLOW, side, intensity]);

I remember now this was discussed a couple of years ago or more, that a script in an object would retain animation perms for the last person it had got them for, and there was no obvious way to get them revoked. But surely blocking a person is also going to block their scripts? Or, once the script owner finds another victim, the earlier one is going to be freed?

If those four browsers haven't solved the problem I don't know what else a mac-user could do. You could try in Firefox clearing cookie for the maarketplace site, other than that I think you need advice from a mac-user.

// outside the states we declare global variablees and functions string nameTag; // inside state_entry we read the object nname annd xtrat five characters as the nae tag default { state_entry() { nameTag = llGetSubString(llGetObjectName(), 0, 5); // we will only action messages from other objects with this prefix in their name } // then in the listen event listen(integer ch, string name, key id, string msg) { if( llGetSubString(namme, 0, 5) == nameTag) { // we hear and obey } // otherwise we do a van-gogh (turn a deaf ear) "I hear no sheeps" } }

Yes, you can read the object name of the listener prim and extract the first 5 characters into a global variable "nameTag" and use that as the comparison.

Inside the listen event If llGetSubString(name, 0, 5) == "CG REP") // is the name of the sending object in m class of names? and then only process the heard text if the name of the sending object fits your naming pattern.

You could have said "You can't steal my soul - you've still got the lens cap on"

Download another viewer, one you don't already use, and try that. It's possible that you've got some corruption in the files of the viewer you currently use. If the fresh viewer still has the problem then it's looking like t's an inventory issue and support i your only help.

There's always macs... (and I don't mean the network card addresses)

I would point you to a Mr Jeff Geerling who has been trying for over a year to get a Graphics card, ANY graphics card, to work on a Raspberry Pi. Although the beastie does perform marvels with HDMI video, it has no OpenGL support, which is s sort of a hobbling function.

And that ends this week's episode of Romper-room. Tune n again next week when we'll be discussing how to modify the Raspberry Pi Minecraft App to connect to Secondlife...

Oh get a room, you two.

Since there are three known Linux TPVs which run happily and tend to track the LL viewer code at varying intervals, is it even necessary to get LL to provide a Linux viewer? I

You could always turn your back on them and flap up your coat-tails Amadeus-style.

It wouldn't hurt to get a group of people here who use Linux viewers to compile a list or two of what happens on different systems. I agree that Linux isn't a hold-your-hand type of environment and many Windows migrants are going to find themselves rather lost. That said, both Firestorm and CoolVlViewer run nicely straight from the box. Henri has put a lot of effort into helping people set up his viewer, to the extent of having an additional stage post-install that checks for missing dependencies, gives advice on how to make up the deficiencies, and then goes to to advise on setting up wine to get the bare minimum Vivox voice running. Singularity also has linux builds but I do admit to having one or two issues there, the latest built fails with an illegal instruction call on earlier Lubuntu, although it did run happily on 20.04. There will be several technical migrants crossing over in the next few years, I would like to think we have a welcome party ready for them instead of gunboats in the channel

I too have had issues with Nvidia cards and an OS, in this case it was Windows 10 that forced me onto Linux, but I've also very recently had issues with a different Nvidia card and Lubuntu 20.04 that has now forced me back to Windows. The trouble is, for every couple of people like you and I who experience problems, there are thousands others who don't. At the end of the day, we each have experienced real problems but to each other, we can only offer anecdotal information.

I think it's a mistake targeting particular people just because they have strongly-held views on some topics. Software engineering does tend to produce people with robustly voiced opinions but don't forget, they also write the programs we know and love.

Firestorm offers a native linux build and runs well, but the other three would have to be run using Wine. I have managed that with Catznip and the LL viewer successfully (*), but bear in mind wine is best with 32-bit programs. I can't help with RLV, it's not smeething I need or use. CoolVlViewer and Singularity offer Linux native builds which also run well. * Animats posted something a while back on how to get the LL viewer to run under wine, you need to add a disk serial number in the wine config otherwise the connection attempt fails.