Raven Huntsman

That exchange was super enlightening thanks guys. Though I'm not entirely sure if you guys were sometimes speaking generically (all/most viewers) or referring to your own specific viewers? I know Niran Developed BD at least. So to draw my own conclusion here; I've been using the typical high end settings in Firestorm up till now (x16 Anti Aliasing/Deferred/No NVIDIA forced enhancements). And if we're honest, if you want decent/modern graphical fidelity then you're not going to turn off Deferred(ALM). After reading this thread I did try jumping between x4 and x16 and noticed that there is effectively near no difference in the quality. That being said, this level of quality (in Firestorm) has never been as crisp as I'd like, and it's definitely not as crisp/smooth as what I experience in BlackDragon. I make this statement based on what I see when in both viewers during use and also from the quality of edges of avatars in images when taking high res (4k) shots in both FS and BD. So for anyone reading this in the future looking for similar reasons; Conclusion: There isn't much we can do if we rely on existing viewer settings to get better fidelity out of SL. A note: I jump between HD/QHD/4K monitors (I've got like 4 monitors due to covid), the higher resolution monitors definitely improve edge fidelity by a fair amount (so many more pixelllllsss). Worth mentioning I thought as better monitor hardware does improve quality if you were unsure. What worked for me in this case (I tried a couple of things in different combinations until I was happy with the result): I replaced the default Firestorm FXAA shader with Niran's BlackDragon FXAA shader as mentioned in his post. (Unclear if this helps in Firestorm as I can't tell if it's using FXAA with hardware AA on). I then forced AA via the NVIDIA Control Panel with settings near identical to the ones detailed by @Rachel1206 (Thank you) I also changed my Firestorm font to roboto. And I set my viewer Anti Aliasing setting to x16. This definitely made a difference compared to x4 with NVIDIA forced AA, might be the result of the breakage or overlap that was mentioned or combination of MSAA. I suspect the main tweaks here that are helping are the texture related settings in the NVIDIA Control Panel + the font change which allow me to benefit from forced AA without a blurry font. All of these changes result in an edge fidelity comparable to what I get in BlackDragon. Aka, no jaggies at all. And with a 30 series card, I'm not worried about GPU load either but this may not be a solution for everyone. Thank you

Does anyone know of a way to get better Anti Aliasing in Firestorm? Something comparable to Black Dragon? (I cant stand BD for general use as it does everything I do a lot like building just a little bit too awkwardly for my liking). I've tried forcing Anti Aliasing improvements through my NVIDIA Control Panel but this doesn't work great in Firestorm as it gets applied to all of the UI + Text causing blurriness. Wondering if anyone knows any ways to improve graphic fidelity with firestorm in tow.

I don't know what the requirements/plugins/viewer in use were, but I know someone who frequently uses a VR headset for SL. So it's definitely possible.

Hey guys, I'm a little stumped on the 'best' solution that is widely used by others for increasing an avatars movement speed (when on the ground) via a scripted attachment, in a stable manner. I've had a play with llSetForce/llApplyImpulse/llPushObject and in my testing, all of these suffer from an issue that I can only assume is the result of avatar to ground friction. I.e., llApplyImpulse(fwd * 100, FALSE) will only truly give me that level of force when I jump, shooting me off into the distance. I've tried adding small varied upwards forces to compensate against friction and this can work, in an unstable and difficult to control way. (You'd then have to start testing for when the avatar is airborn and disable impulse etc). My best attempt so far was using llSetVelocity, but this had some odd 'jumpy' results whereby the movement was not smooth, presumably due to friction and/or slightly unstable terrain. I've seen movement speed enhancers where the avatar plays some sprinting animation and the movement speed is increased without any of the above issues that I've observed, so i'm wondering if anyone knows how these are accomplished? What's the suggested method of removing avatar friction ? Changing the physics material doesn't seem to work for avis. Thank you

Hey Grace, still looking for someone to do this? If so, I'd need some information before taking on the job. Particularly, would you want this accessory as rigged mesh for a specific head? Or as a static accessory that can be repositioned?

Thanks haha, that's too quirky/sci fi for what I'm after, it's might be decent without that odd whistle that goes through it.

I'm working on a project where I'm in need of 'thruster sounds' in a few different varieties/contexts. Think iron man flying as a base sound (just the jets/thrusters) and then a few variations on top for faster speed/take off/landing etc (will discuss the specifics further, this is just a generalised brief). If this sounds like something you can do to a decent/high quality. Please IM me in world with your rates thank you. ~ Raven Huntsman

Thank you very much!

Saw it in an advert and wondering if it even exists in SL? That's definitely an SL mesh head in the image but it could be edited. I've asked the advert creator but no response sadly.

Contact me in world (Raven Huntsman) if you're still looking.

Never had any issues with Maitreya Lara and Catwa heads. As long as you use a matching skin for head and body and ensure both the head and body are using matched materials or none.

The Sensations store on the mp definitely has some fp mouth animations that I've used for gags before. But from what I've seen when developing my own items of that nature there are no fp packs or sets of animations specifically for BDSM/restraint items. I have come across a few standalone ones here and there but it's always finnicky and never exactly what is needed anyway so I lean towards making my own. As you said, they aren't that difficult to put together so you're best bet would be hiring someone to make them for you or sell you some they've already made that they may have lying around.

Thank you! The examples on the wiki don't work anymore so I'm trying to get my head around all of this, slow and steady!

Thanks for the info!

I was not aware of that, is there any documentation on html media on prims? I knew you could do video media but not html.

I asked about if an 'on hover'/'on mouseover' event could be simulated or faked in some way using LSL a while back and the answer was a resounding no. Which was also the conclusion I came to after extensive research through documentation. However I was sure I'd seen this achieved somewhere. I've just realised where and it's the Legacy Mesh Body HUD. The body is free/L$1 and comes with a HUD. If you navigate to the second tab/skin panel, all of the buttons in that tab respond to the mouse hovering over them with no other input. Does anyone know how they are achieving this?

Have 4 available 1024sqm (32x32) parcels available for purchase or rent. Nice and flat! http://maps.secondlife.com/secondlife/Kitster/61/147/5

Title says it all. I need 16,384sqm, Flat, Grass. And ofcourse a reasonable price Contact me in-world, raven.huntsman No longer searching.

Found someone for this, thank you!

I'm looking to hire an animator to create some specific walk animations to simulate restrained movement. We can discuss your rates and work towards a single request initially that supplies a single walking animation exported with priority 4, 5 and 6. (.anim format). Following this, if you're open to more work I'll have a handful of other walking animations that I'll need and will pay for these at the same rate unless they vary excessively. I'm interested in pretty high/decent quality animation here though I am NOT interested in any kind of captured/mo cap animation due to the translation of mocap data to SL animations having results I dislike. (Jitter/sliding). Drop me a notecard or IM in world if interested: raven.huntsman

Second life needs an engine rewrite to make it multi threaded. It's the primary bottle neck for FPS. You can get the best CPU and GPU combo on the market today, last year, next year. You'll get the same crappy performance because SL viewer source code (and i think server logic?) is heavily CPU bound and to a single core. It's pretty depressing tbh and every other day I google for news that they may be working on future proofing SL but I don't find much

Hey guys, I'm in the process of scripting my own surfboard and have a few questions that I can't answer by myself or through online research/Wiki docs. There are a lot of different 'waves' across sims which I'm guessing all function in some similar manner. I was wondering if anyone is aware of some universal API that these use which existing surfboard's hook into, or if it's just a case of surfboards running unfiltered collision checks and looking for the word 'wave' in the name of the colliding object? (That's my current assumption on how to get a surfboard to react to a wave'. Floating - What's the correct way to get a water based vehicle to float? I ask because I'm currently using : llSetVehicleFloatParam(VEHICLE_HOVER_HEIGHT, 0.1); llSetVehicleFloatParam(VEHICLE_HOVER_EFFICIENCY, 0.6); llSetVehicleFloatParam(VEHICLE_HOVER_TIMESCALE, 1); llSetVehicleFloatParam( VEHICLE_BUOYANCY, 1); And notice that my board occasionally hovers above the water by a significant amount, and decreasing that '0.1' hover value close to zero doesn't seem to affect it at all. Ideally I wish it would accept zero as a value indicating that I want it to float '0' distance above water level, but of course zero is considered disabled. Any value above water level for a thin object like a board doesn't seem to work out so well. Is there a better way? I noticed that existing surfboards are unable to be driven from water onto land, they just kind of collide with the boundary between water and land, however in my tests, my board/vehicle will drive onto land and then become very unwieldy with it's controls. Is there a recommended way to keep this from happening? Note, my vehicle script is setting the vehicle type to 'boat' and subsequently adjusting all necessary vehicle params to achieve the type of movement im happy with. Any info would be greatly appreciated, thank you.

For anyone running into this problem in a simple context like this, this was my immediate solution. Most likely could use some optimisation. // 5 strided list, link:link num, (vector)color, (float)intensity, (float)radius, (float)falloff list data; default { touch_start(integer total_number) { // Grab touched light link num integer link = llDetectedLinkNumber(0); // Get it's point light params. list params = llGetLinkPrimitiveParams(link, [PRIM_POINT_LIGHT]); // Enabled integer on = llList2Integer(params, 0); // Flip enabled on = !on; // Check if we have light settings data stored for this link integer index = llListFindList( data, ["link:" + (string)link] ); vector color;; float intensity; float radius; float falloff; // If we have stored data, pull it out of the list. if( index != -1 ) { color = llList2Vector(data, index + 1); intensity = llList2Float(data, index + 2); radius = llList2Float(data, index + 3); falloff = llList2Float(data, index + 4); } // If not, take it from the light params and add it to data (this should occur once) else { color = llList2Vector(params, 1); intensity = llList2Float(params, 2); radius = llList2Float(params, 3); falloff = llList2Float(params, 4); // I'm storing the link number as a string with the format 'link:'+'number' because the link number could conflict with light settings data. This would give the possibility of not being unique which would not be desirable. data += ["link:" + (string)link, color, intensity, radius, falloff]; } // New param list with flipped enable bool list newParams = [PRIM_POINT_LIGHT, on, color, intensity, radius, falloff]; llSetLinkPrimitiveParamsFast(link, newParams); } }

Thanks for this guys. So basically, for some odd reason the point light values are getting zero'd out when the point light is disabled. Which isn't expected behaviour, because if you manually turn a point light on and off via the build window, it will retain it's light settings. But by script this isn't the case. So when I switch it off, and then pull data to switch it on again, I'm getting a bunch of zeros. Seems like the only way to fix this is what I didn't want to do and cache the light values globally (I'm working with multiple lights) so that's a good 5-6 strided list potentially eugh. Is it worth me reporting this bug again? Seems like it was closed or lost with a jira upgrade?

Hey guys I'm having some problems trying to switch a linked light on and off. Sounds like a simple task, but I'm having to use llGetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast. I only want to switch the light on and off. Without touching the other light parameters. What I've noticed (maybe im screwing something up) is that when I retrieve all the parameters on touch and dump them to chat, they all have the correct values, I then send those values plus the flipped on/off bool back to the object. The subequent touch to turn it back on has all the point light values set to zero along with the color as black. (FYI, these point lights are probably flagged internally as projectors as I also have a projector texture set). What's going here? (Note, I got verbose with the point light data and pulled it out into individual values as I was initially just using the original param list but couldn't figure out what was going wrong). default { touch_start(integer total_number) { // Grab touched light link num integer link = llDetectedLinkNumber(0); // Get it's point light params. list params = llGetLinkPrimitiveParams(link, [PRIM_POINT_LIGHT]); // Enabled integer on = llList2Integer(params, 0); vector color = llList2Vector(params, 1); float intensity = llList2Float(params, 2); float radius = llList2Float(params, 3); float falloff = llList2Float(params, 4); // New param list with flipped enable bool list newParams = [PRIM_POINT_LIGHT, !on, color, intensity, radius, falloff]; llSetLinkPrimitiveParamsFast(link, newParams); } }