Frionil Fang

Yes, I know JPEG2000 is the internal format, but I didn't know about that asset fetch URL, interesting. Tested it with my test images from above, exact same results (I mean, the viewer would be fetching the same asset, just isn't offering to *save* it as a jpeg2000 from the inventory), no perceptible difference to my eye and only minor noise in difference-blending. Checked your images and yes, the new one's messed up. Something's gone wrong for your file, but it doesn't seem widespread?

Definitely not happening for me right now or any time recently. Found an ancient image with lots of text in my inventory, saved it, reuploaded its original .png version, saved that to disk. Then I set them in difference blend mode, boosted the result since I couldn't see a thing (input levels to 0-15). The original text at the top and grid-like pattern in the middle are just barely discernible. That isn't to say your image isn't *really* messed up though, for comparison, with the difference blend and levels boosted only to 0-63 it turns into clown vomit. Dunno where your .jp2 format files are coming from though, when I save to disk from the viewer I don't have an option to save it that way. PNG or TGA only.

Can't comment on the rest of the process, but when baking normal maps and using them as image textures, you must set the image color space to "non-color". For generated images like this, you must set it before baking since it's grayed out. Using the default sRGB will corrupt the normal map, since it's actually vector data that's just represented as colored pixels, and color correction will twist those vectors.

Can confirm this, and isn't just rigged mesh. Uploaded a static, non-textured, non-rigged mesh object on Aditi, but attempting to rez it resulted in just a ghost shape in selection tool (like the "fake prim" you see before the mesh actually loads) without anything visible inworld whatsoever. Multiple uploads and testing it on different sandbox regions didn't work any better.

Lights being on is a prim property, there's no way to choose who sees the property or not. Two things come to mind: is your light source an attachment? There is an option to turn off seeing lights in avatar attachments specifically, and the other people in question may be using that setting. Alternative: are those people running such low graphics settings that they can't see the light because of that? There's a checkbox in graphics preferences to disable lights in general, and additionally without advanced lighting enabled, there is a very low limit of lights that are rendered (6, if I recall correctly), so other lights in the scene might block yours from showing.

Actually, the inventory asset has the description, the texture itself doesn't. That might be the issue referred to here. Both inventory assets are copies of each other, the UUID is the same, but each has their own description.

Yeah I was surprised how snappy it is compared to notecard reading, despite a fairly simplistic "send chunk-wait ack" communication style. That forced delay is huge. Only "downside" is that a linkset data tape fits only ~63 k of binary data (hex encoding+headers), the equivalent of 2 notecard. The tapes can be easily shared without editing required, too, to pirate 8-bit games and pictures with your friends. Warez the phuture.

My SL computer emulator does something like this, notecards are used as read-only storage for files, but if you rez a "tape" near the storage device it will transparently switch to using linkset data files on the tape over a chat channel, with both read and write. Incidentally it's also much faster than reading from notecard ..

I've had a couple 1-star reviews along the lines of "this is a scam, I received nothing" because the delivery failed, which isn't exactly my fault and the redelivery button is right there. I've also had 1-star reviews for my product not doing thing Y, when the product image says it does X, the product description says it does X and the features say it does X. Not all 1-star "reports" are based on actual failures on the product's part, just sayin'.

Dunno if I'd call the traditonal way "synchronous" since the calls are still fulfilled at a later date, I'd go with "sequential". I have a hard time thinking of particularly great reasons for putting in multiple read requests at the same time though, barring a basic "read multiple notecards sequentially at the same time" situation -- get them all started at the same time, process as usual. Requesting multiple lines would need you to build a list of the handles instead of just keeping track of a single handle, and if you're not storing them, then you're probably not guaranteed to keep track of the notecard line order, which probably isn't ideal. Alternatively, maybe you want to externalize the dataserver event handling to another script to save memory, but then you'll need to communicate that request handle to the other script in some manner, and if I had to guess (without testing) that's going to be hard because of the built-in delay on llGetNotecardLine -- by the time you can know the key to send it, the dataserver event on the other script might have already fired, unlike the single-script case where you can be sure the event isn't going to interrupt the currently running one.

I absolutely second the recommendation for paint.net for SL texture work. I've been using it for ~15 years and do all my texture work with it. The program itself is fairly bare-bones even if efficient, but there are dozens of useful plugins available on the paint.net forums to make it fairly competitive with the Big Suites, including things like liquify, content-aware fill (sure makes life easier than clone stamping everything manually) and a plugin to let you use Photoshop plugins (for getting normal maps for materials).

There's still a deep misunderstanding on how notecard reading is done: you're making requests but not really doing anything with them, and instead treating the requests like they were the data. The attempted processing of the values you actually didn't get also doesn't work: things like "if (paramName == "YellowLevel") { YellowLevel; }" do absolutely nothing, you're not assigning anything to the variable. Notecard reading crash course: 1) llGetNotecardLine returns a key that identifies a dataserver event; you are NOT given the line you're asking for directly 2) in a dataserver event, check that the dataserver event key matches the key you were given for your request 3) if so, you know this is the line you asked for 4) if the line is EOF, the notecard is over and you can let your script proceed knowing you've finished reading the notecard 5) otherwise, process the line in some manner (read its data directly into variables, or build a global list of notecard lines to be handled in bulk later, but that's potentially memory intensive) 6) you are not given the next line automatically: you must request it with another llGetNotecardLine, store the request key and repeat Minimal example: string nc_name = "my notecard"; integer nc_line = 0; key nc_handle; default { state_entry() { nc_handle = llGetNotecardLine(nc_name, nc_line); // start reading from line 0 } dataserver(key id, string data) { if(id != nc_handle) // not my request return; if(data == EOF) { // end of notecard llOwnerSay("All done!"); return; } llOwnerSay("Read line " +(string)nc_line + ": " + data); // process the data, in this case just say it nc_handle = llGetNotecardLine(nc_name, ++nc_line); // read next line, note the pre-increment ++ } }

Space is by default mapped to "stop moving", so by holding it you're suppressing your normal avatar movement. The script isn't and can't be aware of this since it's watching your control inputs directly (stop moving is not a control you can hook), so only the scripted impulses apply.

The backup folder is shown at the top of the Backup&Restore page in preferences. Copy that to your USB stick, then off the stick to your new computer. Open Firestorm on the new computer, go to Backup&Restore, click "Set" and point it to the folder where you offloaded your settings from the USB stick. Click restore settings and restart viewer. The backup won't include your logs and other stuff like that, those you'd have to move manually from C:\Users\<PC username>\AppData\Roaming\Firestorm_x64\<SL username> to the matching location on the new computer.

From what I see, in your initial example and your changed script the increment happens on the same level, getting the same result of skipping sound #0. To paraphrase to its minimum, your script kind of does this right now: timer() { if(out_of_bounds) { sound(); // resets everything } else { llPlaySound(a_sound); } i_playcounter++; // counter is incremented every time, even after reset, so sound #0 never plays again } } What you want it do to is: timer() { if(out_of_bounds) { sound(); // resets everything } else { llPlaySound(a_sound); i_playcounter++; // counter incremented only when a sound is actually played } } } Make better sense?

You may have missed the last part of Fenix's post: "As for skipping playing the first sound on each successive iteration, that I think is happening because of where you increment i_playecounter. You have that statement at the very end of your timer, outside any checks, so it will happen each and every time the timer goes off - which I don't think is what you want. Instead, move it up one scope level into the end of the else part of the timer's first if/else statement. That way, you only increment the counter if you just played a sound." Basically where the increment is now, it skips the first (number 0) sound after the first loop since the counter is incremented on every loop -- when it reaches the end of the loop, it resets the counter to 0, but then increments it to 1 before actually playing anything. Move the increment to the same block as llPlaySound, right after it and it'll be able to hit #0. The script actually doesn't care about the names of the sounds at all, it goes strictly by their inventory position, so renaming them can only change their relative order.

From that "null oddity" exploration a couple weeks back, the string coercion for "if(string_variable)" appears to work like "if(string_variable != "")", since null is TRUE and it's not even checking the length. Likewise, list coercion "if(list_variable)" appears to be equivalent to "if(llGetListLength(list_variable))", since coercing a null list caused an exception. I was always taught that pre-increment is better for general use, since it's fewer (virtual) machine code instructions. A smart compiler would of course detect that and optimize it for you, but I think we've established the LSL compiler does the bare minimum.

For 1), they can have values but the value is simply ignored (I know, doesn't matter here). Assignment produces a value; "a = 2" has the value 2, so you can do a = b = 2. Can't do "(a = b) = 2" since that would be trying to assign a value to a value. For 2), the expression has no type restrictions, it works like the if statement and coerces it to a truth value. "if("")" is false, "if("abcd")" is true.

Wow, that's surprising, I always assumed comma-separated statements were not available anywhere in LSL since you can't do multiple definitions (with or without assignments) like "integer a = 3, b = 4, c = 5". The for loop has unique privileges. Two other observations since I had to see for myself which other C-like features would be available: You can leave out the initializer and the per-loop statements, but you can't leave out the termination condition statement. "for(;TRUE;)" does the same as "while(TRUE)", but in C you could just do "for(;;)". Likewise, the termination condition can't be comma separated, it wants a single value, no more, no less. In C comma separation is legal anywhere and the rightmost value is what the entire comma-separated statement evaluates to. "for(a = 100, b = 0; a < 0, b < 100; ++a, ++b)" is valid but dumb C since even if "a < 0" obviously always evaluates to false, the entire statement gets its value from "b < 100".

Had to check: the media URL is limited to 1024 bytes (including the data:<mimetype>, header), not great for images, but still might be useful for some esoteric ideas...

It works with more than just text MIME types; you could use the url "data:image/png;base64" to specify a base64-encoded png. Of course, images of any usable size will balloon up fast to be terribly useful in LSL scripts/any prim property field, but something like .svg might be more feasible. Cheeky example: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAQAAAD9CzEMAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAACAZJREFUWMPtl2tQVdcVx/+XV0UUNCiR4Dvq+MB0tCGKSiK0FMZJp2biaIxt02oVUxOjRq3PxqhomokaHauJwWiIL8Qn9wo+wVwFjVp8RUVQR0QRkOoFRJDXrx84nFxedjL52rU+nL332fv/P3vttdZeR/q//EwJ1EtNaPefD5skhxxy9KkJprG2qZRDDh2RVVZFa7bC5PFT4Me6Vy7DQSWV1ACVXMGGDTt27BwkmRSSiWMvSexgHn/GA48qXdAmjZPr/4Yf7Vd5iTrJYT+7uEUJhSRjx04K96kAnnLG1DKKSWI5/VGGXpPlWfC93fOPGeAl7MXKPfZg4zhXeAxAOVc4ZOymVm3YOcJFNlLFV/ijWLVsDt5VKYsN+NukkIONFBKdDLSOQzhLNlc4jp2jlBgj+YxGh+XZNEFId0qBGuLIJpUEdrGfMifAImKdeqe5RCHFQBkJ7DRGK3kVTWiaYOc8AGp4SCopbCSXhnLcqV3MVqdeLnXG/RjNbtI5vSk0p9/lAvepJJbZhBFMMFHE85QcJ8h041zq5AfjuRbFNYb/pSVjZYOvPUVPZOibLOVlBnDJ6f1lSkklmilMYQpZ5vgdPJ5qWAPrqyiEGGI4QAFgw0Ymfowh0CCYyFGqWMFzpJhA5YxGiJ6E0A0v/k0Cd7hOJntoU6nFTvCeRR+wlzzOksR3ZHKDHdxgLMNZRDwr2MYMXiCETXRlBQBn6EoQwoUBDGEqU1lFCXlcJI8MNnOVgCqNqIX3V95nHKSa92hFCCG04112md9pw490oIx/0ZeFhlfVcJLeTGrCDWA7e9jKanS0liB2IjZgPsPJBTZxi7/Sg17MZB5D6MRBmpZRJBmtW5RTwWK88cKDOdgo5jOULkmeLUrvYaeQtpwHimjNSaCCRFazmlhKaU7GMt/wo+m8SCheXKaMG8ziBA5iDAKv5wE7aQwFSvgHHWnHWE41gjtLMhN4n3KnTPUKvbkBlHOMGBLYzTQA8rjISnMHT3Kxk0Y/NtAWP6IoYgl+jOAY1cANI00k4c0q9lNdj3YknmYMwxaGUUge68jnPXSi9gzSj2GjCl9O4eAs7SgEHCzFnUAWct1YXIYPeQzBhy58bqaODgQxA5sRH39EfEM55/iSvuitWoLx3WpSOMEmDgMP8OY1UqgBnmc742lPR95lB6VMZhpxlHGe25SzjZsM4m/UUAOk8h9WYqE/0zjAbbZhyZJXXRxYPyCN/VwDIAELnoSSQg/DWb9nMS/jwhjWc9U41hIG4stcYydV2HgFL94mgCCggkA09sdA66BLwZwwLfkWY1hCAKIlB3gAwE1as5ZRdKY9/YgiihVsYQtb+JCRdOdF1uHHVkQQkIny61+jHXR5gUlwH39slNCZloiWvM1x4gk3fedLBrCRKN7Ehyjms4UINgBBnMOPIMCK9jZMdn6W7ASTIglfchjFHlbQAyE8+TXHKAAgmdcBeEQLY/5GRpCKGx2NHVjR9sb5dGKYk/stpxPtyQCq2c2HuGFBuBNCOL+iHeGEE44r4YTTBQ/czLzbPIGv+6Nz9Sh6YTd7PpxnNv64mEBNqxsRzRJICwbz0IniG9rzERXAPjoZAXaNefjRG/dG0Ba60ZJQlj+DwFXxETxyoshgMEGkMZwYc+wMoUAON5nJq2xmPZ6sYg6DmM7veY6MZxBIPvpqMI/YQQEXsFLNU1bhhwubKK5HUJtNvwWs9OMxXUlkEZ15B55JILlonT8nsBJPKYnsABxsJBRPhhPN1ywwCXqTykMGMYmPcKM3Lfm7EYZWlNh88ZWgo26FUWSwgz3ksZUEioFHbCaaPxFJX7ycdBiRjCcaG1Bl1kvKlUvT8CN0V23VWV/4Vi2hgFS2kcVhtpFGhbH8MXn19IlZC24EsqmknBdougb3Ua6mGe1gHQlgJhc5RRxH+Z5d2DjLXQq5Xk8dQBmpbOIpYKcMeKmW4C8NCQJUpRJ9alSX7hqs9a4PIkmlhCvYOUIMMcQ7VaV1d8UhHgAVWNlHTR1BPxU0JBgqNEw23dTvzDFvzXN9EEkaANU4OOtU+iaRZmoS3xpOXo4/6q7t+rQ+vJeWCx1QioqE0pSsZH2txXJVa821FESQRk2Di7SyntZJNDopi/IU4GyceD3UXaFZClKQhukHnVGIuuic4uQiyVtzlR/MEBZxoV5J3FD20eqJAuWqgh+vnMkq1Bp10jihSaqrl/bpknrIV9n6rekEbyhKa3WnA6F8znc4GuznNO9gyVaEpF7KlrskuWmDrqi/JGmccpVh/gh5KEoFGqdZsjXwahd11h/0hS61YSDjDB1DAMrUQrWVJPVSeq2zrFWKWhsLxylJqfWK7+HK1FLdVnAzYemr32ikqYH6hdPKShVJfVSk9uagvwo1QmUKdILorCw91NYGwBYFKFShClV/86+sp7zN92F6rEz5S68rvt7CFdqvsbqvN5yM0klZuuf0W9RC45WpfFlllVX5OqhIWdRXD1WqnfKUFKZ8bdVqSYrWJ/UI2uq6ZihSOUpSHydD3NI1DZEUoI+Vq+OKMC91H81RlmK0W9Fqo6P6RGHKV5iW1UZBtKY22Hwf5StcrbRMhdqvCRqoXuqlgk7IoUTlKFahjU7CX3uFpslHQ/VA9/S+pDiNappAGq4idZUUoOmKVbrSdVVojVYrW4lq1+RhhytbJ1WkIl3QKEmtVKh+tQQLm5i+SKfVwqk/2Tgpb61Rgf6pjo1WzNYqWbRIN4zonaBkWaT/AhVN9H0fVf20AAAAAElFTkSuQmCC

Oh right, my script is ancient from times before I realized I could simply just do that! I'll amend the example script. Thanks, no need to run a timer, even if it's lightweight.

You can use a local texture but, it won't automatically update when used for a particle system. When a local texture is saved again it gets a new UUID, i.e. becomes an entirely new texture. If it's used on an object as a normal texture, the viewer will change that texture for you automatically, and that means you can use a proxy object set to that texture to simply read its UUID and reinsert that into the particle system. The tool I use myself is just a cube prim that I put my local texture on, with the following script: string last; default { changed(integer change) { if(change & CHANGED_TEXTURE) { string s = (string)llGetTexture(ALL_SIDES); if(s != last) llOwnerSay("texture change:\n"+s+"\n---"); last = s; } } } I.e. detects a texture change, gets the UUID on the object and compares to what it was on the last call and if it has changed, says it. This relies on re-pasting the UUID manually into the particle system, but you could just use it as a say over some channel which the particle script listens to, or even incorporate the on-object texture and UUID check into the particle system script directly.

You can just move the unpacking code from the touch_start event to the on_rez event, like this: /* everything before state default was snipped */ default { on_rez(integer p) { OWNER = llGetOwner(); list items = []; integer noCopy = FALSE; string script = llGetScriptName(); integer i; for(i = 0; i < llGetInventoryNumber(INVENTORY_ALL); ++i) { string name = llGetInventoryName(INVENTORY_ALL, i); if(name != script) { if(~llGetInventoryPermMask(name, MASK_OWNER) & PERM_COPY) noCopy = TRUE; items = [name] + items; } } if(noCopy) { if(!llGetAttached()) { invite(); for(i = 0; i < llGetListLength(items); ++i) llGiveInventory(OWNER, llList2String(items, i)); } else llRegionSayTo(OWNER, 0, "Please rez before unpacking"); } else { invite(); llGiveInventoryList(OWNER, llGetObjectName(), items); } } } The lines before the default state aren't shown, so don't remove those. Remember that any changes you made to the unpacking code to filter items out won't be displayed here.

Restart viewer, try again.