Profaitchikenz Haiku

Probably the top of your avatar is contacting the ceiling or wall or similar part of the build as it reaches the start of the descent. On the way up the head will often pass through a slight obstruction because there is a little bit assistance given to an avatar ascending a slope that will push it past a block, but no such assistance on the descent. Try two things to assess the causes: 1) Reduce your height (quick and easy) 2) Examine the build around the top of the stairs. try raising any prim in close proximity to the top of the steps by 0.5 metres and see if that gets you through. Don't forget to use Ctrl-Alt-T when examining the build as a common trick is to make the detailed parts of a structure have no physics to keep the LI down, but then hide a transparent prim inside parts of the building to make the walls/floors etc solid.

Actually, I was able to see the physics shapes for myself by going into the advanced menu then render info, render types, and found the option in there to show the world as physics shapes. It gave me a real insight into my own 1-prim four chairs around a table - the physics shape was a strange distorted rhomboid that stretched from the centre of the table out and down to the seat of each chair but didn't go out as far as the chair backs, or bridge from seat to seat. It was quite different from the bounding boxes of the mesh, which were far more complex but as we realised, had no real impact on where the avatar could or couldn't sit. I suspect ray-tracing gives a far more accurate view of the avatar's physics shape, or anything else for that matter, but the viewer's own advanced info is quite adequate for making sense of what is going on in the world.

If I understand what Wolfie has been showing, it is the physics shape, and this is not the same as the bounding box.

In fact my experience is that the second avatar, if in close proximity to the first, is usually rotated 90 degrees on the Z axis, which allowed a cheat to get somebody apparently sitting on somebody else's lap when I first began playing around with multi-sits. Thanks for the exposition on the physics shape, it's an area I've not paid much attention to previously but it's now making more sense.

As already mentioned, this is due to other factors, you can have a prim with a perfectly valid sit target but if there is another prim in an unfortunate proximity to it you may get this message. One way to investigate this is to move the prim containing the sit target to different positions and see if the message goes away. It is harder to do in something like a vehicle but a possible way to investigate it would be to move the child prim with the sit target up a metre and see if that clears the problem.

maybe your fullbright on is the reason, Chic's doesn't have fullbright.

Change to graphics settings, such as ALM off or choosing a different graphics preset? Or some TPV's have options about what to do with glow and alpha when ALM is on or off.

Just to expand a little on my previous post, the sit-target of a prim has two important purposes. The first is obvious, where to place the avatar when it sits on the prim. The second is where to position the avatar when it stands. (Remember those TP pads where the sit target is way off from the prim and you simply unsit the sitter as soon as they're comfortable?) Take a single prim, smaller than the size which actually allows two avatars to sit on it. Give it a sit-target, possibly in the middle of the prim but 0.4 m above the prim centre. When an avatar clicks on the prim and selects sit, changed_link occurs. Inside changed link, check the number of prims. If greater than last time, somebody has sat down (or a prim has been linked). If less, somebody has stood up (or a prim has been removed). If prim-count greater, alter the prim local pos and rot of the most recently added child. Assuming it's an avatar, it will then be moved to the desired seating spot. If it wasn't, you've just mucked up your build but never mind, you've got a backup? When a second avatar clicks and sits, repeat that procedure, choosing a different local pos and rot. Note that when two or more avatars are sitting on the prim, llAvatarOnSitTarget won't update for the new arrivals. There is no need to amend the sit target, since it is only being used once when an avatar first clicks to sit, and again when they decide to stand. The complexity of the script is in managing the details of how many prims are in the linkset now and prior to the changed link, which of the children are avatars, where the next free seat position is to be (1 2 and 3 are seated, 4 is the next spot but what if 2 gets up?) I still don't understand all of what is occurring with bounding boxes, physics shapes, etc, but I anticipate see Wulfie will be has been along soon with the answers @)

There is only a single sit-target, you check the build at changed_link and move the new arrival to where they are supposed to be sitting. To be more specific, you take a single prim, give it a sit target as one does, but then do not follow the normal procedure of checking for llAvatarOnSitTarget. When changed_link you take the most recent addition and (a wise person checks it is indeed an avatar and not a second prim being joined ), and with that recent addition, set the local pos and local rot to the desired position.

That's the bounding box issue, I believe, you have to move each avatar so that their bounding box is not inside another prim's BB Somebody replied on this very message in the building forums recently, possibly Chin Rey? Have a look in there

I just took a look at the table and four chairs that I did which is a single prim but in fact has an LI of 2, so this supports what Qie posted, the workaround is necessary to maintain a sufficient LI to seat more than one avatar?

From my experiments some time ago with sitting multiple avatars on a single prim (admittedly mesh to look like several), you only see a difference changing sit-target if no avatar is seated on it. The approach I adopted in the end was to define positions for the four seated avatars as local pos and rots, then when avatar sits on the sit-target, move them to the first free defined position, and so on. Leave the sit-target alone, just manipulate the link numbers which are actual avatars. The devil in the detail is maintaining a list of defined sit pos and rots plus key of avatar on them.

Bots... Poking.... Hoses??? /me exits stage-left singing "High Colonic" to the tune of Oklahoma

Buy cheap, sell dear....

You've all overlooked the final one - flicker screen madly causing owner/user to experience seizure fits and violently throw PC to floor and kick it to bits.

Open Paint.net, create a new image 1024 x 1024 in Irfanview or similar, crop the texture you would like to be seamless. (can be done in Paint.net but I find their square selection less easy to use) Paste the cropped selection into a new image, resize it to 512 by 512 Select and copy this image, paste into the top left corner of your big image. In the small image, choose "flip horizontal" Select and copy, paste into the top right corner of the big image In the small image, choose "flip vertical" Select and copy, paste into the bottom right corner of the big image In the small image, choose "flip horizontal" Select and copy, paste into the bottom left corner of the big image. Resize the big image to 512 x 512, save as png - no transparency (unless you have alphas) Upload to SecondLife.

We're Domed, I tell you, Domed Domed, domed ! Domed for all eternity

I'm certain that Wanderton at least is available to non-premium members, possible some of the others are.

Flash will never die... Come on girls, show us your wits

The other major benefit to the wiki is it shows small and concise examples. The biggest problem I see new scripters encountering is a large script that they are struggling to understand or debug, and few of them know how to take a small area from a script and build it into a test harness to investigate it easily. The wiki snippets are a perfect example of how to investigate a function in a manageable chunk.

When I went looking for it all I could find was a statement on page 2 (October 2019) referring to the inability to offer the previous build for Opensim. All I can assume is I interpreted "We will continue to host Firestorm 6.0.2.56680 on our downloads page in the Opensim section until we are able to remedy the major issues. The SL version of this update will install separately, so you can use the 6.3.2 update for SL and continue to run 6.0.2 for Opensim. " as meaning the two versions would install and use sub-components separately. My apologies for casting any slurs upon the good people at PhoenixFirestorm.

Ah, now that's interesting, I've also got the second FS for a standalone, but I noticed that despite what they claimed on their web page (@WhirlyFizzle), the folder you choose for the cache is not different between the two versions. If I make a cache folder Firestorm_SL, and set that in Secondlife, then make another one Firestorm_OS and set that as the current one when I log into the OS version, when I then come back and choose the SL version, the cache folder is still set to Firestorm_OS (suggesting the two different installs are sharing a common set of files in the appdata local/roaming areas). I have to do a lot of renaming folders so that I have a single FireStorm folder which is either the SL or OS one, and a third folder Firestorm_now_SL or OS to remind me which is which. But I don't think the crashing is to do with that, I think it's to do with throwing too many large textures at the graphics card at once. I've tried reducing bandwidth to see if that allows me to throttle things but it doesn't seem to affect it. Turning off ALM to reduce the amount of textures to be thrown at the card by 60% does help considerably, until I turn it back on for safe places and then forget and go hopping around again.

The closest I can get to what you have been experiencing is on a machine of mine that I have recently discovered has a Chinese fake GTX1050, not a real one. If I visit places with large mesh structures I can get anything from a black screen for a few seconds to a full Crash to Desktop followed by an NVidia driver restart popup. My only workaround for this is to use the 32-bit viewers that Singularity, Firestorm, and Catznip offer. But for how much longer?

Time offline is losing time inworld. I can sort of understand why they prefer people to bang the prims together. Got to say that the builds that amazed me were all prims, the places I first stumbled into back in 2009 were entrancing. The mesh buildings I see now are more precise, more clinical, more detailed, but somehow they just don't grab my attention and awaken the urge to explore like the older builds. Portmerion, for example.

An orchestra? On a more serious note, what attracted me to SL is the same thing that has made me back away from Blender, SL has a nice simple building method and wandering around the object as I build it feels natural and intuitive, whereas looking into the viewport of Blender/3D Crafter/GMax has always felt like being in a nightmare where you know what you want to do but nothing seems to quite happen as you expect it to. Is there way to build a bridge from the inworld prim-to-mesh creation tools to get to the position you say we should try and work from, because I for one would make the effort if I could start from where I know what I'm doing and feel comfortable with it.