Frionil Fang

It looks to me that however you're saving it in Krita, it deletes color information from the transparent pixels and saves it as premultiplied alpha which is not suitable for an emissive mask texture, causing this to happen to the transparent areas and their edges: See if there is an option on saving to use less aggressive compression to preserve the transparency colors or use straight alpha or something like that. I know nothing about the program but googling turns up the following manual article: https://docs.krita.org/en/reference_manual/layers_and_masks/split_alpha.html Edited to add: if this is a PBR emissive map and not a classic BP emissive mask, you don't even need alpha on the emissive map itself. Alpha is used only on the base color channel, though same color loss from unsuitable transparency saved by your editor is still an issue.

That's a known bug: having mirrors enabled makes highly shiny surfaces (low PBR roughness, or high BP environment responsiveness) turn black up close when there's no mirror probe. The fix is to disable mirrors in graphics preferences.

That'd be my strong suspicion but maybe just rename it first to be safe, heh!

I saw mention of them implementing the Khronos neutral tonemapper and switching to it as the default, in the viewer issue log: https://github.com/secondlife/viewer/issues/2464

The defaults are stored in settings.xml *in the program directory*, specifically <viewerfolder>\app_settings\settings.xml. The one in your user data directory is the modified version.

I'm a bit confused what exactly you're going for here, but I'm pretty sure states are not the correct tool for the job. You might be looking for user-defined functions to make chunks of common code to be shared from multiple places.

Multiple problems: llParticleSystem takes a list, so parameters should be enclosed in [ ] like Marvin said target key isn't enclosed in quotes or cast to a key (that is, (key)"01234567-89ab-cdef-...") burst speeds and acceleration have no meaning when you are using PSYS_SRC_TARGET_LINEAR_MASK, it overrides all motion other than the linear motion from source to target. Use PSYS_SRC_TARGET_POS_MASK to not override other motion parameters. texture is missing (this is presumably on purpose though?) PSYS_PART_BOUNCE_MASK: this is a flag, not a parameter. It should be combined into the other flags if you enabled the bounce mask properly anyway, the particles would be unable to move to their target since the bounce Z level is defined by the source prim and would fly out *away* from the target Not really my business but: You are using thousands for particles for this effect by using 0 particle generation rate which means "as fast as you can", and 50 particles per burst. At 60 FPS that translates to 3000 particles per second, and they live 2 seconds for a total of 6000 on screen - the sheer amount can cause serious lag if viewed closely.

Alpha cutoff is only for the masked alpha mode, it's equivalent to the old alpha masking threshold, only the range is 0-1 instead of 0-255. Has no effect on blended. Alpha adjustment being wonky might be because the old system used sRGB alpha, but the PBR renderer changed to linear alpha (even for old materials, ugh) which means the curve of the alpha levels is no longer as we got used to. That also might be relevant for the alpha cutoff but not sure.

Yeah, it's definitely not supposed to become a permanent effect when selecting an object while the UI is off. It does happen on LL viewer 7.1.10 DeltaFPS so it very much isn't fixed, the gyazo video clip in my previous post is taken in that viewer.

Basic flow idea: bumping with the gate or otherwise interacting with it will send a llRegionSayTo message to the bumping avatar on a chosen channel: llRegionSayTo, when aimed at an avatar, will be heard only by that avatar and their attachments. keycard object has a listening script on that channel which will respond via llRegionSayTo to the sending ID (the gate) with an "I'm ok for this door" message if the message sent by the door matches gate has a listener script that causes it to open when receiving the confirmation message Not too many moving parts and things beyond basic listeners, and llRegionSayTo takes care of any unintended object hearing the messages.

It's a bug in PBR viewers, if you have your UI off (which I assume you want while doing camera work), selecting any object will make it constantly emit the particle swirls and deselecting will not help. Turning off the swirls or particle beams does not work, only setting particle count to 0 does. Chaos ensues: https://i.gyazo.com/27af2aa2e5f3168273753809010b82ec.mp4 Firestorm has a JIRA for it: https://jira.firestormviewer.org/browse/FIRE-34345 and I thought there was a report on feedback.secondlife.com but I couldn't find it - maybe one should be written since it's a LL inherited issue.

For what it's worth, uploading a gltf material doesn't hide the texture assets from you, they'll get put in your textures folder so they will be reusable either way.

I'm not sure what "PBR packer" you mean, but MakeGLTF and glTF Packer from this forum produce a .gltf file ready for upload with all the materials populated, on top of packing the textures. Just use that as a local material, do edits on the textures (this is why I use MakeGLTF, glTF Packer locks the files in a way that my image editor can't resave them unlike the former program), repack, and the material is updated inworld. Once satisfied, save the material and the textures are uploaded.

I'm not struggling and have had zero problems since it's a reasonably strong computer (no particular inexplicable lag, no texture load failures), but I felt like running some numbers out of curiosity. My test is just my own avatar on screen in my own not super dense apartment, with an invisible alternate viewer avatar camming to a defined position in the scene and recording the numbers with the statistics floater (control-shift-1, since not every viewer has a statbar FPS counter and having the floater up deducts some FPS) and settings tuned to as close to each other as possible. Firestorm release: 216-220 SL Viewer Atlasaurus: 222-225 SL Viewer DeltaFPS: 228-230 Alchemy 7.1.9.2492: 239-241 Cool VL Viewer 1.32.2.11: 252-255 It's notable though that after staying logged in for a while, going around places and returning home, Firestorm starts hitting 230-240 FPS in that exact same scene/avatar/position, so something is going on there. Didn't test doing that with the other viewers; the numbers are all "just logged in directly to the scene" numbers. Conclusion: it's consistently a little better, but still ways to go to reach Alchemy/Cool VL numbers.

There are 3 heavy-handed options to stop the popups, none are ideal but at least it's possible: 1) Add the "DontShowUI" = 1 option to Windows registry as in missyrideout's post above 2) Set the "Disabled" = 1 option in the registry, that stops the error reporting completely instead of just hiding the UI (probably even less ideal) 3) The most gentle option: change the PluginInstancesTotal debug setting on your viewer to 0. This prevents any plugins from running with the obvious consequences of being unable to use anything that requires them (viewer start page, media on prim, 360° snapshot, web search, destination guide, etc.) but since no plugin is running, it also can't crash. To restore plugin operation, just change the setting back to the default 8, no restart required. On Firestorm you could even make that a quick prefs setting to toggle it while building.

There are also policy settings for the error reporting, as well as other registry settings affecting WER, I poked at the policies a bit but didn't see any popups and didn't feel like investigating more. Maybe some Windows editions have a stricter policy by default and ignore the request for exclusion, dunno.

If you want to take a look at your registry: HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting\ExcludedApplications, is anything in there? The viewer tries to add itself/SLplugin.exe/dullahan_host.exe as exclusions via the WER exclusion function, but if that fails, that would explain why the popups get through. The WER\exclusions key also exists under HKEY_LOCAL_MACHINE but they don't seem to be added there.

Guess my provider doesn't just like the forum then, shame. It's not even making it to the spam folder. Yeah, it certainly is not great if used as an actual sun texture as it stands. However I've often used it as something else such as a galaxy in deep space, with no clouds or other sky behind to generate a halo.

did you just compare me to Sheldon P.S. your forum isn't accepting my attempt to register, I had a bug report for Cool VL Viewer! The sun texture isn't drawn at all while PBR rendering is enabled, works in old rendering modes.

I kept snooping around with the viewers I've got installed: Cool VL Viewer will produce the cache complaints in the CEF log, but doesn't cause actual crash events. With Cool VL Viewer's oldschool interface, the build tool works differently and doesn't try to unload media upon close... not that I know what I'm doing, really, but wonder if that's related. I mean, a lot of people drive their cars with the "check engine" light on, but maybe it shouldn't be ignored.

Well, there's the reason why Alchemy doesn't have the crashes: Alchemy doesn't have a SLPlugin (or ALPlugin as they call it) running all the time and even enabling media in general doesn't launch them: you must have actual media being visible for them to spawn. And guess what happens when you have actual media visible on an object and select it with the build tool? ALPlugin crashes just like LL/Firestorm viewers and Alchemy's CEF log says: [0902/153514.830:WARNING:value_store_frontend.cc(47)] Reading mhjfbmdgcfjbbpaeojofohoefgiehjai.alarms from failed: IO error: .../LOCK: File currently in use. (ChromeMethodBFE: 15::LockFile::2) [0902/153517.811:ERROR:cache_util_win.cc(20)] Unable to move the cache: Access is denied. (0x5) [0902/153517.811:ERROR:disk_cache.cc(205)] Unable to create cache

Just in case this is of interest to you: Alchemy's CEF log gets nothing added to it during build tool select/deselect, but Firestorm's CEF log spams this: [0902/143009.179:ERROR:cache_util_win.cc(20)] Unable to move the cache: Access is denied. (0x5) [0902/143009.185:ERROR:disk_cache.cc(205)] Unable to create cache [0902/143009.185:ERROR:gpu_disk_cache.cc(676)] Gpu Cache Creation failed: -2 [0902/143011.193:WARNING:value_store_frontend.cc(47)] Reading mhjfbmdgcfjbbpaeojofohoefgiehjai.alarms from failed: IO error: .../LOCK: File currently in use. (ChromeMethodBFE: 15::LockFile::2) [0902/143014.200:ERROR:cache_util_win.cc(20)] Unable to move the cache: Access is denied. (0x5) [0902/143014.200:ERROR:disk_cache.cc(205)] Unable to create cache

I just edited my comment there after doing more testing; results are identical between LL viewer and Firestorm, Alchemy and Cool VL Viewer show no incidents in the log.

Scripts can't access group notices or chat, or send group invites. You'll need an avatar to handle those, i.e. a bot.

Maybe this is the actual bug, looking at the code for the slplugin it's designed to swallow up exceptions and not have them pop up, but they'll still go into Windows event log as crashes. I was looking up the error and it seems to have happened in other programs too after they switched to a particular version of libcef and it was suggested it has something to do with an unclean shutdown instead of a "true" crash. Maybe there's a way to work around the flaw, or maybe a different version of CEF would work better... all I know is that transplanting a newer version of libcef .dlls to a viewer resulted in slplugin being unable to start, heh.