RespectableCow

Good to know! I edited that whole part out of my post, because I realized like you just said that the 'length' of the ribbon isn't affected by the X scale, but rather it controls the 'thickness'. I didn't want to bother refactoring my logic to reflect that when the rest of it was probably wrong, anyway, so I just snipped it.

I just hid the flickering bit inside another prim. Like @Wulfie Reanimator said, the flickering is caused by the last ribbon in the chain dying. Even though you say it doesn't help, it seemed to me that using more particles reduces the flicker, because it shortens the length of each segment, so the segment dying is less visible. However, I still found that the speed of the particles (being derived from their lifespan over the distance in their path to the target, as opposed to particle "speed" or velocity) has the most noticeable effect. Keep in mind that if you are using a target mask, the particles will travel from the emitter to the target by the end of their life, so particles with a shorter lifespan travel faster to compensate. I was able to get a steady ribbon of particles with a ribbon distance of probably 10m with a lifespan of ~5s. But if my ribbon was 50m, for instance, I would theoretically need 500% more particles to get the same effect, otherwise, my segments would get longer, and their deaths would therefore be much easier to spot. Another potential solution, which I haven't yet tried, is using an interpolation scale mask (PSYS_PART_INTERP_SCALE_MASK) and setting the end scale X value to some non-zero number, perhaps close to the start scale values. In theory, that should make the end of the ribbon blocky instead of coming to a point and might disguise some of the flicker from the particle shrinking while dying. However, I'm not sure if that will have any effect on a ribbon particle.

I did some experiments with KFM that I referenced vaguely in main post, which resulted in very jagged lines. I get the feeling that maybe there's a method or style of movement that would get the job done, but what that would be is beyond me. Your suggestion to reduce the particle lifetime, though.... That has had an immediate effect. I have to readjust the downward acceleration I give it to form the sag, but it definitely resists the wind a lot more! It also increases the distance at which you can see the particles die (I've been hiding it by putting the target center inside another object), so I'm going to have to spend some time searching for a sweet spot. And waiting for the wind to pick up, because I don't have any way to control that. Thanks a bunch! Edit: On second glance, it actually doesn't seem like changing the particle age has that much of an effect. Getting the camera angle correct to see what's happening is tough, and sometimes the wind speed does change, but the bend looks pretty identical to me even when setting the max age to 2 or 3 seconds. It might be for the best though, because the wind never really seems to 'wobble' the wires or bend it in the opposite direction, like you would expect for power poles.

I have a particle system using a ribbon and a wind mask. The thing the ribbon is simulating is a wire under tension. The wind blows it, but in a way that is inappropriate for a wire with that much tension. In other words, I want the wind to blow the ribbon, but with less intensity. I want the 'wire' to 'resist' the wind a bit more. How might I be able to manage this? An ideal solution would allow the script to stop running after it sets up the particle system. However, I was considering ways to simulate wind effects before looking into the wind mask again, so something that requires the script to stay running isn't out of the question, as long as a region wouldn't have too much of a problem with many of them. Though truth be told, I'd appreciate any solution which can be offered, because I can always try and work around its caveats. My approaches so far have been to mess with the location of the emitter prim or the particle system controls, but my attempts result in a jagged ribbon that doesn't look good here at all. I feel like messing about with those controls might work for what I'm doing, but if it would, I also feel like I don't know enough to figure out what I should be trying to do. Instead of flailing in the dark, I'm hoping that people here know of a solution or can point me in the right direction toward developing one.

This is exactly it! And as @Fenix Eldritch writes, the particle size in those other scenarios is the reason my other 'tests' also showed the particles disappearing. I am so glad I'm not going crazy or switched realities into the 4m particle range universe! The reason that I thought this behavior was normal and unavoidable is because the LSL Wiki says this about PSYS_PART_RIBBON_MASK: Bold added. "Ignored" has a strong meaning, here. My assumption was that no input in the Y value of the supplied vector would be read, at all. In truth, it seems that the Y value is ignored specifically regarding the width in a very visual sense, but it is definitely not ignored by the client's rendering code. When I tested other masks without ribbon, I did supply a 1k particle for science, but either I had incorrect assumptions about the default size, or I forgot to comment out the PSYS_PART_START_SCALE. The Wiki has been an awful jumping in point for someone like me who has never used particles, but I'm still surprised behavior like this went unmentioned, unless it did, but I don't yet understand where it said that. Either way, thank you both for the good answers and thank goodness there were some and they were easy!

So, it seems like particles from llParticleSystem are only rendered when the client camera is within 4m of the emitter. My question is: What? That can't be right. Right? I'm trying to develop a way to simulate hanging wires. I was given the brilliant suggestion to use the particle system with a ribbon mask. It's a great setup, because a target position mask combined with a drop pattern (and a little negative acceleration) generates a very nice curve that is low LI while remaining highly scalable and configurable. The only issue is making sure to manage particle count. Oh, and that you need to be practically eating it with your camera to render it out! Again, that can't be right. While I feel like I remember plenty of times where I have witnessed particle effects from much farther than 4 paltry meters, that limited range doesn't make sense for much of anything. Water feature? Only if you're swimming in it. Fireworks? Better be strapped to them. Tire tracks? Not without getting run over first. And yet, 100%, absolutely, I see my particles disappear when I move my camera more than 4m away from them. Another scripter reported the same behavior on their end. I tested this on SL Viewer 6_6_16_6566955269 (non-PBR) and Alchemy's 7_0_1_2198 (PBR) and experienced no change in behavior. On LL's Viewer, I bumped up all the graphics settings (including particle count and draw distance) to maximum and experienced no change in behavior. I performed some script tests, too, to see if it perhaps related to a specific mask or pattern being used, but it doesn't seem like it to me. However, I'm not a real programmer, so those tests were in no way exhaustive or conclusive. Has this always been a thing? I can't imagine it has. I recall a few years ago that a scripter working on a HUD was using the particle system to display certain HUD elements over a wearer's head for others to see. Think of it like if you had a scripted poker game, and when you showed your hand it displayed your cards over your head as particles. It wasn't that, but it was basically that. There is no way that had a 4m range back then. That wouldn't have been useable, and we used that feature often. There has to be something me and the others are missing. Does anyone know what's going on?