Profaitchikenz Haiku

I don't think it's Windows-specific. I'm seeing slowdowns on my Linux machines , my Windows 10 laptop, the pi400; things like googlemail take much longer to finishing waiting for the hangers-on to finish loading before giving you full access to your mailbox, several forums I frequent are noticeably slower to load (most of them are using CloudFlare? as a DDOS protection which might be a actor), and the grey textures problem in SecondLife seems more prevalent on weekends, when I suppose the demand for traffic soars. Broadband speed-checkers show no drop in speed so the problem isn't a local one.

I remember a few places sometime ago that had something against people flying and would nag arrivals. Trouble was, whatever they were using was differentiating between avatars actually flying and avatars on phone connections who seem to bob gently half a metre above the ground. Some people just get stuck on power trips, there's nothing can be done about it.

I have a similar system where the linkset word position and rotation are stored in the description field by a script. When rezzed, a similar script reads the description field and if the position an rotation are valid, repositions the linkset. The rotations are stored as degrees, so you can examine an object in your inventory and see where it is going to go in world. I have a feeling I posted the two scripts in the script library sub-forum, but I can't quite remember what name I used. ETA https://community.secondlife.com/forums/topic/437023-store-and-restore-rezzed-linkset-positions/

It might be worth trying the old practice of shooting up to 4000 metres to empty the video card's memory and dropping back to the ground to ee if this improves things?

Why would they when they have "Blender Game Engine" ? (OK, I heard they were thinking of dropping it but all my versions of Blender come with BGE)

Uuhh, you realise you're just incentivising the tiny avatars?

I've never used it but I have a similar reaction to the Timeless door scripts.

I really wish this was a mandatory click-to-accept popup every time somebody deploys these nagging script-counter devices. (Even though they'll probably just click-through and carry on regardless.) Interesting, the less-time-sitting is easily explained because the region doesn't perform physics calculations for seated avatars, but I'm puzzled by the difference between standing on large objects and the ground. How do you measure this, and what defines "large" ?

If the user has the texture in their inventory it is simple for them to get the uuid. That can then be copied into the clipboard and chatted on a channel or popped into a text box after the user has chosen such an option. That's probably the simplest and least likely to cause problems. The UUID access works regardless of permissions (something that surprised me a few months ago), but the drag to inventory option might fail if the permissions for the texture prohibit transfeer.

One thing to be wary of when allowing people to drop textures into an object is that if they get it wrong and the permissions allow it, the texture will end up actually being applied to the face or object rather than going into the inventory.

There isn't a viable alternative to the Beta Grid because the Havok phsyics engine/mesh uploader is unique to SecondLife. The uploaders in the opensim standalones don't offer the same level of optimisation and might not fully replicate the actions that you get when uploading to SecondLife.

You could try making or getting an animation that does essentially nothing, for example, a stand pose with all the bones at zero settings, and uploaded at priority 2, so that your normal AO will override it. Take careful note of the name of the animation in the attachment you want to stop. (remember case is important in names). Rename the animation inside the attachment to something harmless and put the new animation in, and give it the old animation's name.

Scripts aren't going to be the reason for slow texture loading, they are at the back of the queue and get executed after most of the positioning and physics jobs are handled. If touch dialogs are slow and scripted objects are jerky or not reacting as fast as you would expect then there is a case for looking to see if the region is script-bound, but the main issues with slow rezzing are due to other things.

I've noticed for a few days now that things take longer for the textures to go from grey to colour. Since I am seeing this on regions I visit frequently and therefore the textures are largely cached I suspect the botttleneck is in the information being sent from the region to the client, not delays in sending textures. But I am also seeing some slower responses outside SL in other forums and places I browse, so it is more likely to be general internet loading rather than anything LL-specific.

And for years I've written llKey2Name(llDetectedKey(touches - 1)) Even llPursue seems to be over five years old. I'm going to stop writing scripts and just memorise the wiki from now on.

How long has that been around? I spotted a couple like pursuit this morning I'd not seen before. Perhaps I'd better stop getting out quite so much and concentrate on LSL

Have a look at the LSLPortal for collision events, and inside those events, functions such as llDetectedKey(number-1), which is the key of the object that collided, the key can then be used with llGetObjectDetails to get the name.

Have a look in the LSLPortal for Pathfinding and KeyFramedmotion, also have a look at some of the SL Railroads where the vehicles follow marker prims that guide them along the track poitions.

I had to drag in a couple of libraries for Singularity and Firefox for Lubuntu 18.04 but once done I've had no problems running this two viewers in Linux, also CoolVlViewer runs well. I;ve not yet gone to 20.04 full-time( I had an initial attempt last year but ran into problems with MySql and Opensim under Mono, which I mistakenly thought was due to Lubuntu but in fact it's MySql changing the game yet again, my recollections of the viewers was that they all ran nicly under 20.04 nd I don't recall having to fish around for any extra libraries).

I think*, and I'm basing this more on my experiences with the train simulators, there was previously a condition that lower LoD models had to use all the textures that the highest LoD model used, you couldn't have a simplified model for lowest LoD with a simplified (differentt) texture. I've never been quite sure how SL managed this condition, but it seems from Beq's post that you no longer have to have all the textures that are on the highest LoD model on all the lower LoD ones as well, you can just have parts of them. * But I'm sure I'll be corrected on this assumption soon enough

I agree with Quistessa, the OP is so close I'd like to think they could make the final stretch

If you're thinking along those lines, the easiest solution is to have it listen on a channel , such as -123, for the owner and obey a set of commands, such as "start", "stop", "reset". Those three would allow the owner to start the boat rocking, stop it (at which point it is to go back to the initial rotation and position values), and reset to a new rotation and/or position after having been moved to a new location. This approach will be easier to code than a buttons/dialog system. Don't forget to have a changed event in your script to reset the listen if the owner changes. But get it working for yourself first and use it in lots of different locations to be cerrtain you've got 99.8% of tthe bugs out before you start marketting it.

Sure?

MariaDB is also free and opensource, if it makes a difference.

Don't use Loop, just make it go from the start (middle) to full and wait there. The timer will kick it off again at whatever interval you feel like trying.