Coffee Pancake

and one guy just necro's a dozen threads from 2011 with the same reply to every single one "interesting"

Can anyone recommend anywhere to get typing animations, I have a fair collection already but would really like some more? The more fun the better

No, im meaning the script might be listening for commands from specific keys

The collars listen might be set to only listen to a specific avatar

I think you need to verify her collar is running the required scripts and set up as you are expecting it to be.

You are only executing one RLV command in that script (the initial forced TP). You need to use another command to restrict TP and then flip that command in the timer.

Current texture policy does not downgrade a texture once it has been loaded it at 1024 if VRAM is not under pressure, it does not load 1024's for distant objects. If you zoom in to a distant object it will load at full rez. The viewer will then keep that one around a little so when you zoom in again to check.. its still 1024. Camming around and inspecting everything is a great way to force the viewer to max out your texture ram. Just like having the texture console open to watch it work has a significant impact on the decode pipeline. As is cranking your LOD to the max ...

Wow.. you derailed the thread on the first page. Well done.

I don't think I even dare dream up a number for the bandwidth fees ....

I'm going to necro the ever loving llalaalalalaa out of this

Region auto return is a very blunt instrument and would result in major parts of builds being sent back, it also isn't in the least bit even handed .. I can tell you for a fact that if this had happened when I was running mine, I would have been spitting fireballs at LL support over the phone along with every other region owner. Roll backs would be coming hard and fast and the new Li calculations would be on the trash fire by lunchtime. It would be an unmitigated disaster for LL and certainly result in heads rolling. Not to mention a lot of long time customers reevaluating their commitments. They aren't ever going to do it.

So I made a feature request ... https://jira.secondlife.com/browse/BUG-225024 Please keep the discussion here rather than on the JIRA <3

FFS .. PLEASE LL LOCK OLD THREADS

I like bob, not you ... please be more bob. Damn .. find a new friend! (unless you're into being made into bob, in which case, I'm not judging)

It might well be because you;re from Egypt .. poke your bank and make sure they arent blocking you from paying for an international service, failing that, poke LL billing and ask. This forum is resident to resident, so we can only point you in the right direction, you will have to poke LL yourself.

Yes, it is out of decoding resources.. because SL isn't ever going to use all your cores and most of the time .. you have at least one core running full tilt - that's openjpeg that is.

To be blunt .. learning that SL is 100% user created and has a real economy based on selling the things we make to each other is huge part of SL. So is learning that it's not a game. You would expect a book shop to let you camp out for free while you figured out if you like reading, especially if the book shop was actually the authors home. The learning curve for SL is very deep depending on what you end up wanting to do here (and mostly dependent on the application of real world skills outside of SL - eg 3d modelling). Many people find it an extremely creative outlet and make some money off the back of that, but in order to learn .. you're going to need to explore what options there are. Spending a little on you avie can help get you onto a level playing field socially, you will find looks and first impression matter. My best advice would be to get a single quarterly sub - you will get most of what you pay for membership back in L$ a little each each week and will be able to get a free linden home so you have someplace to rez things and mess about. if at the end of the quarter you're having fun and want to carry on, gen an annual membership, it will end up only costing you $12 a year counting the value of the L$ you will get paid during its time. SL "jobs" are primarily for the fun of it with a token amount of L$ - remember $1 US is L$250 ... that L$20 you just got tipped in a club or from a "make money minigame" suddenly doesn't seem worth your time.

You seem to have grabbed thee wrong end of the stick again ... The CDN is more than capable of meeting the data supply demands, I believe it's run on Amazon servers. You land on a region and the viewer (with nothing to do) requests every asset and texture it can. The texture request rate drops off because the decode list is full and the viewer is spending all it's time on that and file I/O. As decodes finish, more are requested. The bottlenecks are KDU/OpenJpeg, writing data to the cache and writing data to the GPU. This is why performance takes a while to recover after a TP - it's the texture decode sucking up every cycle it can. *decoding also does not give up on a task until it has been completed, even if the asset that spawned that task is no longer visible because you cammed passed it. There is an assumption that when you arrive at a location, you will hang about and wait for it to rez, not immediately scoot your cam to the other side of the region and get upset that a vendor you were looking at on a previous visit is refusing to load. The intent with the cache changes is more complicated than simply the "better performance" sales pitch. They hope to end up with a faster more responsive local cache that offers real benefits over having no cache at all (the cache helps, but if you're sitting on a fat pipe, it's not as good as it could be). If we get it, decode once rather every single time a texture is needed will add a marked performance boost. And finally (and perhaps core motivation) reduce the amount of data the viewer fetches overall as currently, not everything even makes it into the cache; This will reduce the insane costs associated with having a CDN. The cache we have now looks a little like the bins out back of Dr Frankenstein's lab, it's been terrible for a decade and new stuff has been tacked on year after year by random unconnected contractors; and as a whole Igor makes terrible decisions about when to even use the bins vs the incinerator. So in short, the patience of Frankenstein's assistant, Dr Oz (the ever living), has been tried once too often and Igor is getting roller skates, a new brain and a fresh set of colour coded bins. Should he fail to perform, Sensei's favorite new pupil, Sar-san will be set loose to wipe the land clean.

I think the lack of such limitations accounts for a lot of SL's success and longevity, the platform is so open ended that even if a parcel texture limit was imposed we would work out a way around it in a matter of hours (and our solution would be a million times worse than the issue such a limitation was intended to correct).

I'm sure she feels differently.

Recalculating Li based on texturing will cause people to instantly go over budget with objects already rezzed in world and auto return will send half the grid back. It wont ever happen.

.. keep in mind the viewer doesn't load everything at full resolution and will attempt to drop to lower resolution versions of a texture when VRAM is under pressure. The performance downside for high VRAM use comes during the decoding phase and that happens before the textures are placed in VRAM. Inspecting an object will override SL's intended texture loading and force the full resolution textures to be loaded. Not everything is loaded fully under normal operation. (madly inspecting everything and running around like chicken little makes it worse) I would fully support LL boosting max texture sizes right up to 4096. VRAM usage is less important than atlassing - every face with the same texture can be rendered in the same pass, a single HUGE texture is way faster to render than many small ones. Unless you are seeing textures swapping in and out, then you don't have an issue with VRAM use. Using more doesn't make SL slow on its own, the associated pre-processing does that, reduce draw distance and universally lighten the load. Textures swapping in and out highlights a flaw in the viewer code. Loaded texture resolution is based on the amount of screen area an object occupies (as it should be), BUT when VRAM is under pressure the viewer will junk textures trying to free up memory and invariably picks something really obvious to unload. The screen space based allocator kicks in again saying "wait that's huge, put it back" .. and your floor starts bouncing in and out. This is further undercut by some creators screwing around with an objects bounding box to make it appear much larger to the render engine than the actual pixels rendered on screen. The viewer is kneecapped in the amount of VRAM is can access. But as LL have been finding out the hard way, many graphics cards lie about the amount of VRAM they actually have and Windows & other applications will be using a sizable chunk of it - games get away with high VRAM use as they presume they are the only focused application, yank everything and force windows to swap out the stuff you cant see because the game covers it up). If you have low VRAM and texture thrashing ... crank VRAM to the max your TPV of choice will allow, disable shadows and CLOSE CHROME (plenty of other apps use VRAM too, but browsers are the worst). In my own testing, it's rare to find a location that pushes VRAM use over 1.5GB .. adding more just means the viewer doesn't have to bother unloading textures for things you can't actually see this frame (like stuff behind you cam).

This is what happens when i'm only on my second cuppa.

So many creators are uploading products copied directly from real world items and brands and changing one or two letters. STOP IT http://wiki.secondlife.com/wiki/Linden_Lab_Official:Intellectual_Property

NEE NAW NEE NAW