Frionil Fang

Using TARGET_POS_MASK or TARGET_LINEAR_MASK is pretty straightforward: the particles reach their destination object in exactly the number of seconds of their lifetime. Size and velocities do not matter (and ribbon particle size doesn't matter for segment length in the first place); if they're diverted from their path by velocity, they will just move faster towards the target. Since the last segment dies when it reaches the target, that causes the flicker, and the only particle setting that directly affects the amount of flickering is the lifetime. Beyond that, shortening the distance or making sure the particles have as little velocity as possible when reaching the target (not having the target move, less gravity or no wind, etc.) are the only options.

By changing the type and value of gCleanupMessageChannel to an integer.

Channels are integers, you declared yours as a float.

Plain old cylinder, tube or ring prims might be good enough for the teeth: using path cuts (or hollow, in the case of a cylinder) doesn't change the object's center point that it rotates around. Can't check inworld right now, but perhaps a cylinder with path cut 0 to 1/12th and 80 hollow would have a serviceable shape; make 5 copies of that and rotate them around the z-axis to spread them out evenly. With a separate but identical rotation effect around the z-axis on each, they'll probably stay in sync well enough, and can be linked into the main body of the object.

You could use normal llListSort for clean-up if you just swap the owner and count when building the list. Or not even need the clean-up at all: before adding an entry to the list, look up if the name already exists. If it does, add to its value instead, otherwise append.

I'd do something like... strided sort the list, and now that you know all the same names are following each other you can just peek ahead/back to combine the values until the name changes. Doing it by modifying a list in-place, it's easiest to loop backwards so you don't break indexes that you're going to use. list test = [19, "epsilon", 37, "alpha", 8, "gamma", 14, "beta", 99, "alpha", 1, "gamma"]; // sort list, stride 2, element #1 (so 2nd element) test = llListSortStrided(test, 2, 1, TRUE); // start from 2nd last element pair integer i = (llGetListLength(test)/2)-1; integer value; string name; while(i >= 0) { value = llList2Integer(test, i*2); name = llList2String(test, i*2+1); // peek at the following name; if equal, add values and delete following element if(llList2String(test, i*2+3) == name) { value += llList2Integer(test, i*2+2); test = llDeleteSubList(test, i*2+2, i*2+3); test = llListReplaceList(test, (list)value, i*2, i*2); } --i; } llOwnerSay(llList2CSV(test)); // "136, alpha, 14, beta, 19, epsilon, 9, gamma"

Even if you can't trust what the build tool says about link numbers that well, at least the order of linking seems to be deterministic: if you have 4 objects A B C and D, and select them one by one in order D C B A and link, they will be in A B C D order in the linkset. If you link an object to an existing linkset, it will be inserted in the #2 position: adding single-prim object E+ABCD and linking, you get AEBCD. Adding a second linkset to the previous FG+AEBCD gives you AFGEBCD - the whole second linkset is inserted at #2.

Not sure what you were doing exactly, but linkset order is displayed wrong in the build tool quite often. It'll be correct after rezzing, and scripts will always see the right order, but if you were to, say, make a collection of cubes and link them together, the viewer is probably going to report completely wrong link numbers until it's been taken into inventory and re-rezzed. Rezzed 3 cubes, linked them together, then made a script that gives each prim its number as floating text, note the discrepancy between that and what the build tool says: And the same, after re-rezzing:

Alpha blending is set per texture, not per pixel, so having opaque details on an alpha blended texture will be subject to the same old alpha sorting issues. At least some viewers have a "fake masking" trick: if there are sufficiently few pixels that aren't fully transparent or fully opaque, a blended texture is rendered in masked mode instead, but that's also limited to the entire texture, not just individual pixels. That's my guess as well, alpha blending 2 identical colors with different alpha will always look the same, no matter which is on top, and you can get away with minor differences without really noticing. On the left: 2 alpha blended textures, top layer plain green, bottom layer gradient green to black, correct apparent order. On the right, camera nudged a fraction of a degree: top isn't noticeably glitched, but bottom part starts to stand out due to the shading differences.

Depends, I tested the song from the video I posted on a sim with 0 ms spare time and 48 people, it's a little sloppy but not unbearably so, I'd say it stays in sync as well as the big fancy thing from the other clip. The test song doesn't push the tick rate to its maximum, but the sound rate throttle makes such tick rates impossible to get much use of unless you're just playing single-channel. On an unburdened sim it stays in near perfect sync nearly every time. The script efficiency changes made stuff like this a ton more tolerable. Mine has only 4 channels though, 1 script, 8 kB song memory, which is enough for a couple minutes.

Even if this is thread necromancy, 64 k and a single script are enough for multi-channel music playback, thanks to being able to set up and offload stuff via linkset data. You're more likely to run into the sound throttle (max 22 sounds per second per object) before memory limits IMO, and running multiple scripts and objects would cause more latency problems - and if your track is so complicated it requires more sounds than that, then you'd be using multiple scripts and would have more memory at your disposal anyway. Starts at 2:42 in the video if the timecode didn't copy over to the URL. yes it's a shameless plug

They do, I tested it before answering. The key the script is associated with isn't changing, nothing is being looked up by name. Edit: nevermind, I saw the other post only later because of the silly non-chronological answer order. But yes, the updates go through "when they do", the viewer seems to be more aware of the experience detail changes before scripts are, took almost 10 minutes for the scripts to catch up.

The only functions that *refers* to an experience I can think of is llGetExperienceDetails and that takes a key that defaults to the script's experience key, the name is not something that's ever used as a reference. Changing the name (or any other detail) about an existing experience doesn't affect the key. You'd have to go out on your way to acquire, store and compare the experience name to see if it's changed.

I didn't actually see mention of particle size culling at all on the wiki, so I added a caveat. Also changed the wording on the ribbon Y-size being ignored. To be honest it was news to me too until today but kind of makes sense (if the ribbon particles were to use their actual size for culling they wouldn't be consistent, lower framerates would make them visible for longer distances, they'd start flickering near the culling limit since not every segment ends up the exact same length, etc.)

Particles are culled based on their size, and even if ribbon particles discard their Y-size during rendering, it's still a part of the equation. If I render a ribbon particle between two things with its size set to the minimum <0.03125, 0.03125, 0>, they disappear just a couple meters away. If I set them to <0.03125, 1, 0> instead, they stay visible until roughly the distance they reach 1 pixel size.

Could try the following for the sky: Haze horizon, haze density, cloud coverage: 0 Scene gamma: 1 Ambient color: 50% gray or however bright/colored you want things to be, up to taste Blue horizon color: black Blue density color: any color but black, white is fine, again up to taste Sun color: any, again to taste Cloud color: no effect on these settings

They are valid operations though, just don't make sense in a rotation way but as bunches of 4 float add/sub. Not terribly useful, unless you were using rotations just as float storage (or complex numbers! A rotation in the form <b, 0, 0, a> behaves like the complex number a+bi for addition, subtraction and multiplication, though not division.)

Only thing I see as missing is that rotation*vector and rotation/vector are invalid as well (are they truly missing in that case?), you can only rotate vectors from the right.

If you're using the llRotBetween method, you might want to change the start axis it uses, i.e. the first vector: llRotBetween(<0, 1, 0>, end) or llRotBetween(<0, 0, 1>, end). Depends on the object and how it's built which way is the "visual front side", the x-axis i.e. <1, 0, 0> being towards the front is just a convention that isn't necessarily followed. <0, 1, 0> points to the left of the object's local perspective, <0, 0, 1> points up. You can also use -1s to point backward, right or down.

Oops, yeah, my bad, should've actually taken time to double check but I was on the way out of the door. Basically boils down to the correct form being "if(groupMode && llDetectedGroup(0))" or "if(groupMode && llSameGroup(llDetectedKey(0)))".

You're using llDetectedGroup(n) and llSameGroup(k) in an inverted way. llSameGroup returns TRUE if the object/avatar/group*with key k has the same group as the object the script is in. You're always just checking your scripted object against belonging to the group, and presumably get TRUE. llDetectedGroup returns the key of the group detected object/avatar number n has. In other words, you're doing llDetectedGroup(TRUE) in your code, which probably is not going to do what you expect. Fix: Flip the order, get the group key first, then check SameGroup on it: if(groupMode == TRUE & llSameGroup(llDetectedGroup(0))

If the AO uses the classic ZHAO-II style notecards, just extract the entire AO's contents, notecards and animations, to a folder and drag the config notecard into the Firestorm AO: it should do exactly what you're asking for. At least used to, but haven't tried in a while.

That basically means the script has run out of memory. It could be due to a programming error or unexpected conditions, and there's not a lot an end-user can do to fix it: If the object is modifiable, scripts inside it can be reset (even if the script itself isn't modifiable). Open the object with the build tool, go to the Content tab. Depending on your viewer you may need to open the script (it'll tell you you're not allowed to view it, but you should be able to press the Reset button) or just click "Reset Scripts" in the object contents window directly, or possibly viewer's Build menu->Scripts->Reset scripts. If the object is not modifiable, you need a fresh copy that has a non-crashed script. If the object is copiable, rezzing it and duplicating it inworld (not in inventory!) via shift-dragging or control-D should create a copy with a restarted script. If all else fails, get a redelivery. Naturally, if any settings were stored only in the script's memory and not saved in some kind of more permanent storage, they will be lost.

Huh, the firestorm source I have downloaded (I'm not exactly sure what version, must be relatively old) has the following numbers: if (reversible) { parameters.tcp_numlayers = 1; parameters.tcp_rates[0] = 0.0f; } else { parameters.tcp_numlayers = 5; parameters.tcp_rates[0] = 1920.0f; parameters.tcp_rates[1] = 480.0f; parameters.tcp_rates[2] = 120.0f; parameters.tcp_rates[3] = 30.0f; parameters.tcp_rates[4] = 10.0f; parameters.irreversible = 1; if (raw_image.getComponents() >= 3) { parameters.tcp_mct = 1; } } Went through the trouble to grab the certified most recent FS source and it sure has those numbers you do. Would explain why I get same-looking results when I leave out the 10 compression rate I see in the old version, and it changed at some point. Edit: digging through commits, it was broken in October 2022, "Merge branch 'DRTVWR-570-maint-Q" which clobbered the higher quality max value with LL ones.

Out of curiosity I dug around a bit and if I compress your old, better quality image with openjpeg 2.5 (I know the version used in self-build Firestorm is 1.4) with the same parameters as defined in the FS code, ("-r 1920,480,120,30,10 -mct 1 -I") I get a 77k file with mostly identical look to the original. If I leave out the lowest compression rate (10), I get a 26k file with a crusty look mostly identical to the new upload. Could be the version used in FS self-build is somehow leaving out the intended best-quality compression level, beats me why and how though.