Search the Community

Hi everyone thanks for looking .I have a strange mesh and prim seating problem with a 38m high mesh . This behaves oddly placing my seat at link one at around 19m up in the air ,not at link two as requested . by llSetClickAction(CLICK_ACTION_SIT); llSetLinkPrimitiveParamsFast(1,[ PRIM_SIT_TARGET, FALSE, ZERO_VECTOR,ZERO_ROTATION ]); llSetLinkPrimitiveParamsFast(2,[ PRIM_SIT_TARGET, TRUE,<.05,0.11,0.01>,<0.0, 0.0, 0.0, 1.0> ]); I had some grateful help from Crystal to work out what is linked where but LSL does not return any linked data! Can anyone help? I click this script in my seat when seated on a seat with four links it produces from the code below this result: [23:45] test: line:0, 34|1|41 [23:45] test: line:1, 34|2|41 [23:45] test: line:2, 34|3|41 [23:45] test: line:3, 34|4|41 [23:45] test: No Object Data found As you can see 'llGetLinkPrimitiveParams(' does not return the data from data set what am I missing please? list GetSitTargetLinks() { integer iLinkCount = llGetNumberOfPrims(); integer iIndex; list lRequest = []; for (iIndex = 1; iIndex <= iLinkCount-1 ; iIndex++) { lRequest += [ PRIM_LINK_TARGET, iIndex, PRIM_SIT_TARGET ]; llOwnerSay("line:" +(string)(iIndex-1)+", "+(string) PRIM_LINK_TARGET+"|"+ (string)(iIndex)+"|"+ (string)PRIM_SIT_TARGET ); } list lData = llGetLinkPrimitiveParams(1, lRequest); if(llGetListLength(lData) == 0) llOwnerSay("No Object Data found"); list lSitTargetLinks = []; for (iIndex = 1; iIndex <= iLinkCount-1 ; iIndex++) { integer bSitTarget = llList2Integer(lData, (iIndex - 1) * 3); if (bSitTarget) { llOwnerSay("Got Seat @"+(string)iIndex); lSitTargetLinks += iIndex; } } return lSitTargetLinks; } default { touch_start(integer total_number) { llOwnerSay("Hello, !"+ llDumpList2String(GetSitTargetLinks(),"|")); } }

Due to Firestorm being extremely buggy and laggy on macOS as of late (I'm guessing it's due to all the latest server-side changes, or something like that, and Firestorm is not on par with Linden Lab's latest performance improvements - But I'm eagerly awaiting an update, as I love Firestorm's features), I've been using the Default Viewer a lot lately - It has epic performance in comparison to TPV's (Nearly double the FPS, and zero lock-ups or crashes. on Firestorm, by comparison, I have to completely disable ALM for barely tolerable performance.) but unfortunately, despite the great over-all performance of the default viewer, it falls short when it comes to texture rendering (probably due to its hard-coded 512mb texture memory limit). I'm attempting to take pictures for various projects including snapshots for my new Second Life related Blog but It's a real struggle on the default viewer with textures going blurry at random. I would be focussed in on the perfect shot and then suddenly, one of the objects in the scene would go blurry right as I'm about to take a snapshot. On rare occasions, I manage to catch everything in full resolution for a second. It's mostly a waiting game, sitting around for 10-15 minutes for every snapshot, waiting and hoping for all objects in the scene to render at full resolution at the same time, and hopefully hitting the screenshot button at the right moment, before something goes blurry again. Sometimes it happens, other times it feels like it's never going to happen. Is this a macOS-only issue? Or is this a general Default Second Life Viewer issue? Or is this a me/my system issue? I've tried to increase the texture memory of the viewer through the debug settings to the same value that I use when running Firestorm (1024), and I do not experience this problem on Firestorm, but due to FS's recent performance issues, I'm sticking to the Default Viewer until there's (hopefully) a Firestorm update that fixes the performance and stability issues. Regardless of what value I enter in the default viewer's texture memory debug setting, it always defaults back to a maximum of 512. Now I'm wondering, is there a way to force it to a higher value? Or is there another debug setting that I'm unaware of, that I could change, to stop textures from constantly going in-and-out of focus? There must be a way around this. Please help! Here are my system (potato?) specs for reference: (iMac 4K, Late-2017 - I'm still saving up for a new M1X MacBook Pro)

Several hours ago a bunch of Script Warning / Error / Debug messages appeared: Unable to create item '' that has caused problems on this region. I was in my home / the region I rent, and when these messages appeared I was suddenly unable to rez anything - anything at all. I logged out, rebooted, and logged in, only to get the same error messages and most of my clothing and body did not load. I've made no changes to property settings. I tried using an alt, but the problem repeated. I tried using alternate viewers, but same result. My av's body and clothes appear only when I teleport to a different region and "wear" the outfit again. This is weird - it feels like my IP address has been blocked by the owner of the region where I rent. I quickly inquired with the property owner, but have heard nothing back. No way to know until they respond. I'm quiet, keep to myself, and cause no trouble, so don't think there's any reason for an IP block, but you never know. Has anyone else had this problem? What can I do to fix it?

I have a simple but complex jet helicopter showing error message after engine start, at my home parcel with helipad. the helicopter won't "lift off" at my home parcel, but will lift off at another airport. I can't figure why the home parcel is not functional with the jet helicopter. The physics of the plane won't "enable", to keep the plane sitting on the helipad. Is there a debug setting needed to adjust?

When you edit the object of an HUD and scroll to see everything out of the viewport (hud-area) there is a white rectangle, to make aware, what you can see and what not. I would like to remove it, because I would like to reduce the scale of my HUDs. Have now a 4k monitor but can't make use of the benefitis of it, when the HUDs just don't scale with resolution. In Firestorm I wasn't able to recduce the HUD size (1.00 is the minimum scale), but with a Debug-Setting called HUDScaleFactor it seems to work. But you see the white frame/rectangle then... is there a way to remove it?

One of my helicopters is now showing a script warning, error, debug message, at every sim crossing flying the plane. I have to click off each one of the message pop-up, at sim crossing flying. Is there a debug section to stop this from happening? To know something is "amiss", there's planes hanging in the "air" to be concerned about the stability of the viewer.

We've seen a number of questions already arising about a "debug setting that miraculously improves texture quality". I'd like to explain the background and the underlying facts. Firstly though, let's establish a couple of facts. There is no magic button or debug setting to improve the resolution or quality of all textures. There is no way to display textures of a resolution greater than 1024x1024 in Second Life So what is all this muttering about and is there any substance to it? The "muttering" stems from some investigation by @Frenchbloke Vanmoer that was published by @Hamlet Au on his New World Notes blog with the title "How To Display Extremely High-Res Textures In SL's Firestorm Viewer" and in spite of the headline's conflict with the facts listed at the head of this post, yes there is substance to this news as it happens. I'll keep this post relatively short. If you want to see more rambling on how and why @Frenchbloke Vanmoer hit upon something interesting you can read about my subsequent investigation in my blog post, compression depression - tales of the unexpected. The bottom line is that whether by luck or by judgement the Second Life viewer uses a bilinear resampling algorithm when it resizes images. Until yesterday I, like many other, and I would suspect most of you reading this, had somewhat slavishly followed the generally accepted advice that bicubic resampling gave better results, more specifically that bicubic-sharper was the ultimate "best for reduction" choice. The evidence that Frenchbloke stumbled upon goes contrary to that advice and, in all my tests so far, for the purpose of texturing in SecondLife where you typically want to retain high contrast details bilinear gives better results. I should re-assert here, you do not need ANY debug setting. The original article used an obscure debug setting but it was only a means to an end, you are in general far better off and have far more flexibility if you use your photo tools as you always have. So what are bilinear and bicubic and why do we care? When you downsize an image, information (detail) gets discarded, deciding which information to keep and which to lose is behind these choices. All resampling methods try to decide which data to keep, or how to blend the data into some kind of average value that will please most people. Put simply a bilinear sample takes the 4 nearest points to the current pixel and produces a weighted average of those as the new value for the resulting output pixel. Bicubic takes this further, using 16 adjacent points to form its result. By virtue of the larger sample you get and smoother average which ultimately is why it fails us when we want to preserve details. On the flip-side of this is that for smooth gradients you may find more "banding" using bi-linear sampling. Why should we not use the debug setting? Firstly, as a general rule, debug settings are not a good thing to go playing with. They can frequently have side-effects that you do not realise and we often find that people tweak some random settings because "XYZ person recommended it" and perhaps it achieves their goal at that time, or as is often the case, it seems to fix things but doesn't really. In any case, they forget the changes and move on. A week or so later they are furious because things don't work anymore, they've forgotten all about the debug changes of course. More importantly in this case, if you use the max_dimension setting to force the viewer to rescale for you, then you will only see the benefit in 1024x1024 images. 1024x1024 is appropriate to large texture surfaces but not so much for smaller objects. If you can use a 512x512 you are using a quarter of the memory of a 1024x1024. That can make quite a difference to the performance of a scene. Many people remark that using a 1024 is the only way to get the detail that they feel that they need. I urge you all to take the lesson here as an opportunity to increase the clarity and sharpness of lower resolution textures by resizing from the large form originals directly to the target size in your photo tool of choice. Don't forget, and this may sound obvious, You need to have high-resolution images to start with. You cannot create something from nothing and whatever you do don't save the resized image to disk as JPEG before uploading, use TGA or PNG both of which or lossless. Give it a try today, and raise a glass to Frenchbloke while you marvel at the increased detail. A quick example My blog post above shows a worked example, but I thought I would show you another on a natural scene. Here, an original high-resolution image has been resampled down to an SL friendly 1024x1024 using both methods (entirely within photoshop to avoid all doubt around various other compression factors). First is the bilinear https://gyazo.com/545a21efb514ed16051f791ea9d527c4 Second I give you the bicubic https://gyazo.com/a969ec986746ced323e6f2f0ddbda0e8 On their own, they don't look that different, but the bilinear shows a lot more detail which is most noticeable in areas of high contrast such as the steps on the hillside