Profaitchikenz Haiku

Yes, we are, but some of us are abnormal.

There's always opencollar, that manages it

I agree that readability is greatly improved, but I'm not convinced there would be any improvement at runtime.I am slightly biased here because years ago I was working on two system in parallel, a threaded-interpreted Language (Forth) and a stack-based intermediate language. In each case I was able to take the "compiled" code to a dissassembler and look to see what extra stuff was being added by the compilation process, and the stack-based intermediate language (read bytecode today) had nearly twice as much extra machine operations as the TIL. Yes, it was much nicer looking at C-code when writing the programs, but the Forth implementation ran almost 30% faster and took up a lot less space, to the point where there was no longer a need to have overlays being paged in and out. Style and form are both great, but I will go for functionality every time.

'Twas on such a blustery day as this" the owl began. ETA Ah, my bad, I've just found you're probably quoting the musical, not the book.

Isn't this a list?

The main problem with the beta is that all the new Bento bones are at the top-level hierarchy together with the main limbs and torso parts. Half the time you aren't going to do anything with the face so it would be nice to have that collapsed into a single heading that can be opened out should you wish to start tweaking the subtler parts. That said, it runs Ok on my Windows7 machines, but I can't speak for Windows 10 or Macs.

One way for safe updates is to have a link_message event in the script that will receive messages to change the existing contents of a list of texture UUIDS or add new ones. This is done by dropping an extra script into the object. The new script sends link messages giving details of the revisions to the textures in the other script. After it has sent all the link messages it deletes itself, leaving just the original script with the revised list. Because the update method is a script it can be given out to owners of objects with no-modify set so that people cannot see the contents, thus the UUIDS of the textures will remain concealed.

It could be a form of throttling over mobile networks if they're allocating maximum chunks of data at a time, so when you visit a new region and have to cache in the new textures you are being forced to wait for the rush. If you have some regions you know you've visited on the other connection so the cached data for them is up to date, see if visiting those regions does not show up the issues. I had similar experiences myself when I was using mifi in a caravan for a week, and ended up just sticking to the places I knew had everything in cache.

That is only applicable to inventory textures, I believe objects in your own inventory don't get a UUID until they are either rezzed inworld or added to the inventory of an object rezzed inworld? However, it has made me realise there is a hole in my boxing method, I have notecards of the contents of each box giving the name and type, but now I think I need to have the UUID as well.

For notecards textures and scripts that are full-perm, Radegast does a good inventorybackup. For objects you have built yourself, Singularity and other TPVs have ways of saving them to xml files. For everything else, your suggestion of boxing up is about all there is, but ... what happens when the boxes themselves vanish from your inventory?

Two ways. Both hard, but the first might be easier to understand. The first is probably the worst since it fills up the object inventory and as that gets bigger, editing it gets slower, but in essence; have the textures in the object with their actual name in the description field, and the name of the texture is the name the script expects. So if you decided to replace some of the textures, you would first of all rename the ones back to whatever their original name was from the description field, then add the new textures, with their actual names in the description fields and their object inventory name whatever is appropriate for how the script is going to use them. So if you are going to have a different texture for "Texture_2" you would rename Texture_2 to what it's description reads, copy in the new texture, put it's name in the description field, and then rename it to "Texture_2". The second is a lot more complicated and either needs you to add a notecard reader to your script or else edit the script itself if you need to alter the textures. It builds on Qie's advice to refer to textures by UUID instead of by name, which then means they do not need to be in the object at all. Effectively you already have in the script some variables, such as string texture1="nameOfTexture"... You either edit your script and amend what is on the righthand side of the assignment, or you have a section that reads a notecard with lines of the form texture1=UUIDofTexture Both suggestions are going to involve a fair bit of work, but I suspect my first suggestion will be easiest to implement initially. Long-term, the use of UUIDs and a notecard reader will be much better.

Database? Just guessing

Don't believe everything people tell you. Especially if it's me saying it. I'm going to have to make it plain to everybody that if I have my hat on, I'm tongue in cheek. If I'm bare-headed, I'm either being serious or I've just arrived by TP.

Re Global Grid, I have no idea, I tend to just pop from LM to LM, not travel by vehicle. Read some of the posts in this forum about sim-crossings and vehicles to get an idea of what is involved, also large-scale mapping of Mainland has been discussed in several forums. Not every destination will allow entry by prim, by the way, and I don't think it is possible to determine this from the outside.

My suggestion is that you have one or two friends or alts and do the Noah's Ark trick. In each region, send a friend or an alt to try and zip into the adjacent region that is in your direction of travel. If they then zip back to you you know that region both allows object scripts and object_entry and you can jump into it. If they don't come back try detouring one way or the other. And so on. If you run out of friends or alts before reaching your destination then it might be worth looking at some of the more normal ways of getting around in SecondLife.

Go to a region which has an adjacent region up-X, both regions must allow scripts to run and object entry Rez a cube Drop this in // test popping in and out of a region key owner; integer moves; list destinations = []; integer maxDests; default { state_entry() { owner = llGetOwner(); vector whereNext = llGetPos(); destinations = [whereNext]; whereNext.x = 260.0; // over the border destinations += [whereNext]; whereNext.x = -6.0; // over the border tother way destinations += [whereNext]; moves = 0; maxDests = llGetListLength(destinations); } // use touch_end here because touch_start usually misses the first touch when the rergion has changes, i.e. you have to touch it twice to make it work touch_end(integer taps) { moves += 1; if( moves >= maxDests) moves = 0; vector whereTo = llList2Vector(destinations, moves); llOwnerSay("Going to " + (string) whereTo); llSetRegionPos(whereTo); } } Sit on it. Touch it. repeat until bored or your missing attachments have finally got tired of going off on their own and follow you across the edges

"Glad to be of service."

TL;DR - Yes slightly longer - see llSetRegionPos caveats in wiki even longer - see aforementioned thread

That is so so so tempting - I'm sure I had the circus human cannonball gun once but I just looked and if it's in my inventory it's under another name. This thread is a jumper from another, where the question has already been answered. See the tail end of "Global teleport coordinates"

The numbers look right. But see my edited post above regarding the farthest point outside the region 0/256 boundary you can get to.

It should work to get you across the 256/0 line. This is quite an old method you've got hold of, mostly superceded now by llRegionSetPos. llSetPrimitiveParams has the typical function delay which is why llSetLinkPrimitiveParamsFast was introduced, there is no such delay. A more elegant way of doing what that routine does is to use llSetRegionPos since it does it all in one go and doesn't try to build a list of up to (capped) 100 intermediate positions. I suggest you go to a sandbox that has neighbours on several sides and see what happens when you use coordinates that end up just over the boundary of the region you are in. Before doing that, you might like to read up on the caveats in the wiki for llSetRegionPos, in particular, look at the limits of -10,266 to the X and Y components in the destination vector. I'd hate to hear that the routine is broken because it won't move an avatar to -11 or 267 (Linden Lab missed a trick here, they could have had a "go to eleven" setting).

But very annoyingly, there's no primitive_params for it to apply different textures under script control, or have I missed something?

"over-tired..."

It's a kludge but all I can suggest for this is each time to add to or remove something from your current outfit, save it as a new outfit, but name it as the date in format yyyymmdd. You'll end up with lots of folders but they'll be in date order and if you know roughly when you were wearing/not wearing things you can narrow it down to the right era.

If you and those you want to view this submarine can stick to V1-viewers like Singularity and CoolVlViewers, invisiprims still work, which is one (the only?) way of stopping the inside of your boat/submarine/boots showing full of water.