Profaitchikenz Haiku

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.

If your code in state_entry resets such variables to null then each time you change states the variable(s) will again be set to null, thus making them worthless as globals. The way to deal with this is to have a variable at the top of the script that starts off set to 0, and state_entry checks this variable, if it finds it set to 0 it then calls a function to initialise any globals and sets this variable to 1, then any future state changes will interrogate this variable in state_entry and not call the initialisations.

This is particularly evident when using keyframe motion, as Molly said, rounding errors accumulating and moving_end lapses both cause this drift. It is particularly noticeable in regions where the %script run figure is 40% or less. My own workaround is to keep a record of the centre height or rotation angle and use a counter : every 20 movements or swings, when it has returned to what is supposed to be the centre, I will issue a llSetPos or llSetRot to actually enforce that position. The counter is then reset and the slow creep away begins once more. I find myself being forced reluctantly into a slow spiral downwards: adding defensive programming to try and cope with the region performance issues is actually making the problem worse in that it is yet more code to further load the region, and yet, there is no alternative.

That's probably more the result of draw-distance. If you have sculpted trees or rocks or similar on your skybox, the shadow they cast is not the same as their visible shape. I suggest you record the position and rotation of all objects above the ground and then take them back into inventory until the shadows vanish. If you don't want to take them back you can obviously just lower then down to the ground, but then they might get in the way of the shadows and prevent you seeing when they vanish. If your parcel is big enough then another option is to move things to one side or the other and see which things affect the position of the shadows that way.

When you reset the script it will read the current rotation of the object to get the starting point, and if you stopped it while it was in mid-rock, it will take that angle as the normal angle and then start rocking it side to side. You have to first remove any X and Y rotations that have been added by the oscillatory part of the script (and it isn't as simple as just setting the X and Y rotations to Zero, your object might be a strange mesh build that has to be rotated on the X or Y axis to assume a normal visible appearance).

Have you tried "draw distance stepping" in one of the FS extras preferences tabs? Also, does reducing your draw distance to 96m make any change? 208 means it's going to be trying to fill up an awful lot of surfaces all at once.

Coming from another thread, there used to be a way of doing this by a prim parameter PRIM_CAST_SHADOWS, now obsolete. However, that would not be sufficient, as in addition to turning off the shadow-casting ability for the skybox, things on it such as a hacienda would then start casting a shadow that had been previously occluded by the skybox, and so on... I think I can see now why this property was removed. It is simpler for the region to treat every object on it in the same way. One suggestion I have though, if you set the skybox to be totally transparent, does it still cat a shadow? If not, then you could just change it's alpha state depending on whether somebody was on the skybox or near enough to need to see it, or not.

Yes, it's the simplest solution. There is one slight complication as I mentioned in a post above. When you touch it and the motion stops, you must reset any small rotations or position variations, and then make the rotation, before touching it and starting again. I suggest you post what you already have working and we can then suggest how to add such a touch event handler to it. In passing, Molly's suggestion of using keyframed motion for this is both the most elegant and the most likely to give best visual effects, but from what you have indicated is your level of scripting knowledge, not the best one the start off with, I suggest you become comfortable with basic rotation and position manipulation first and then progress to the smooth stuff when you're happy.

I would start off with "a chemical being" which puts us into the class of animals in terms of basic constitution, after which comes "a communicating chemical being" to partially differentiate us from other animals, but since animals obviously do communicate something, we are now into the territory that David Chalmers said was characterised by "The Hard Question", and from now on it's a problem with using words that have many different meanings and values. Meanings are somewhat personal, words can be accidentally or deliberately misconstrued, logic is as fallible as mathematics - (See Godel). Some problems may never be solved, some questions may never be answered, some posts may run for ever without a resolution acceptable to all. You might as well ask how many angels can dance on the head of a pn, we're in much the same territory.

What is being suggested is not to explicitly move the boat up and down or rock it from side to side, but to set it to be a physical object and allow such region forces as the wind to disturb it. Because such forces would only move it around on the level of the water, some additional random impulses would have to be applied to make it rock and bob. My past experiences with this were that it's very difficult t get subtle motions like this, the object either doesn't visibly move at all, or else it starts leaping everywhere like a gazelle with piles.