arabellajones

This is something I have been watching with my system for the past few days. I have a program that displays the readings for various temperature sensors. I'm running Linux, so the specifics won't be much help. What I do see is the video card temperature rising, so dropping back the video settings could help. It depends on the video hardware, but the Advanced Lighting Model setting can be more efficient. Firestorm can also limit the frame rate, which will help a little. (There are some jobs I would not try running in the current weather.)

It is still lousy documentation. It needs improving.

A Project Viewer for Estate Access Management came out in August 2018. There were a few mentions of it then, but I've not found any definite source for when it merged into the main SL viewer. I assume it must have, because now it's part of the latest Firestorm Viewer. The only thing I can find which might pass as documentation is a pair of article in Inara Pey's blog, which assume everyone knows what an Estate Manager is. I eventually found this old web page on the SL Wiki: https://wiki.secondlife.com/wiki/Estate_Manager I am not an estate manager. I can ban people from the parcel I control. I can see how being able to get at least some of the info, such as a banned resident's last-logged-in date can be useful to me. But I am not an estate manager. I reckon, with the Firestorm-led hype, that it's time to update that web-page to cover the EAM features, making it clear who can, and cannot, use them. In the past, extensions to section-A through feature-B have suffered from only having B->A links provided, so that a search which finds section-A doesn't have a chance of revealing feature-B. I think one web-page, covering Estate Managers and the current tools, is enough

What has started me off is the lousy optimization to the Mole-attributed items of the SL16B freebie outfits, up to five 1024-size textures for a pair of shoes, with two of those textures for the inside of the shoes, not visible while they are worn. It might be the poor mole was only responsible for loading the versions distributed, but somebody at the lab signed off on this crap, and they couldn't even be arsed to upload a smaller version of the usually invisible textures. This solution depends on finding somebody competent. I doubt I would be up to the job, but on the evidence I don't think a Linden would recognise competence if it sat on their face!

It might not be the ideal solution, maybe a last-resort one to do with support guidance, but the relevant setting is likely to be in one of the preferences files which can be edited while the viewer isn't running. Looks like it's in user_settings/settings.xml and search the file for "TextureMemory". Either I am in totally the wrong place, or setting the value to 512 would fix it. Is it really that simple to fix?

I know the place where this happened, but as long as there is nothing more than that automated acknowledgement of an AR, I am not sure that anyone can be sure whether the Lindens do anything. I can think of a couple of places where these creeps could have been standing, outside of Nor's area of control, where they would be able to harass new residents directed to info and teaching facilities. There needs to be some attention paid to 24/7 support cover, because Second Life is global. There are some long gaps, and the daily variations are, very roughly, 28k users to 45k. I'm not sure how you could pick out events such as this from the AR stream to direct to an overnight team, but just waiting for normal office hours starts to seem reckless. I hope the Lindens can do better than that on the computer security side, because they're holding my personal data (and just shoving the responsibility over to Tilia doesn't change the timing problem). I'm in Europe. Does Linden Lab (and it's subsidiaries) want to be in the same legal mess over European data as Google and Facebook?

There are many websites that have been reporting basic stats, such as concurrency, for all the time I have been using SL. But all of them seem to have stopped getting updates at various times over the last couple of months, most recently https://eregion.kicks-ass.net/munin/servers/akari.eregion.home/SL_Online_Now.html which stopped updating on Tuesday. It's less clear when https://e*****up.com/slstats/concurrency/ stopped getting data, but it seems to have been a couple of weeks ago. Point is, it's not all at the same time, so it's unlikely to be some change to the API. And Firestorm is still reporting a changing concurrency figure. These charts did give some sign of connection problems, you could see if there was a sudden drop in numbers, when it had happened, and whether it was continuing. And, unlike a web page from Linden Lab, it didn't vanish when somebody plugged in a vacuum cleaner. A wild guess, but I know some sites watch out for repeated requests from the same IP address, and block automated requests when they exceed a limit. The requests made by the Firestorm viewer don't all come from the same IP address, so that sort of filtering would fit what I see. Add a bit of security by obscurity to the thinking. It doesn't help that I am using Linux: there's not much chance of getting a straight answer from Linden Lab. Also, I'm in Europe, and I am usually tucked up in bed when those in-world meetings with the Lindens happen. So somebody else is going to have to ask.

The viewer colour scheme, and there is no supported alternative, is pretty horrible. Yes, there is Starlight, but the default colour settings make me struggle to read anything, and no viewer seems able to pick up the OS setting for the mouse cursor. This is not good UI design, and my eyes are old enough to notice this sort of thing. So the viewer is efficient, but is that enough to make it good?

This is one of the tricky settings. What I am seeing my viewer built-in Help telling me is that this only affects UDP traffic, which has been shrinking for years. Stuff such as textures have been shifted to http. Just that is a huge difference. There are recommendations for the setting, based on the type of connection, and they haven't changed since the days when everything was UDP. That does make me wonder if I can trust the advice. If the UDP traffic has been halved, it wouldn't surprise me if the minimum recommendation hadn't dropped that much, but no change at all just doesn't make sense. This is one of those things where any definite answer is likely to be wrong for you. All you can do is try. That 1500 setting is the absolute maximum setting recommended, labelled as "cable", and all I know is that I can't get "cable". That tech used to be high-speed co-axial, and my current DSL is faster than some "cable" tech that was being used a decade ago. And using the Wi-Fi label, the standards for that have changed too, it can be much faster, but the number of wi-fi systems I see as I walk along the street with my smartphone, all from router/modems using the same out-of-the-box default channel, I have a feeling that anyone using wi-fi, for anything, needs to do some serious thinking about how it is set up. I think I would stick with the Wi-Fi label because of the bandwidth sharing with your neighbours, a totally different class of problem, but "DSL" and "cable" are looking antiquated as labels I would say you have to try different Connection settings. You might even get better results down at 250 or 300, but I would try 1500, 1000, and 500. There's no point in going higher, there just isn't going to be that much UDP traffic now. And Second Life is rather unusual in how it shares UDP and HTTP. Keep an eye on packet-loss rates.

As you understand it, but why can't they make it clear? The inactive account thing looks to include just logging on as activity. I'm not 100% clear whether that includes logging in to Second Life, Sansar, or whatever else Tilia might provide these services for. I remember some of the past problems there were, with even just buying a few L$, for people outside the USA. The US financial industry seems so primitive, compared to the rest of the world.

The computer I am currently using is about ten years old, with a much more recent graphics card. The old nVidia 750 I used was pretty slow, but OK for standing around at an event. The replacement I got makes other things more comfortable. Computers which are that old can fail for all sorts of reasons. I don't think I am using anything super-powerful. And I am trying, when I make stuff, not to waste the computer power my audience might have. I have seen a fancy dress with an ARC of over 1 million. I did look, once. It did did nasty things to the frame rate that old 750 was giving me.

When I look at some of the behaviour of non-rigged mesh in SL, I do wonder how many creators know what they're doing.. You can make vehicle wheels which don't collapse into lumps of triangles as you move to the side of the road: I've done it. ARC is used by the Max Complexity limit in graphics settings. You know, the Jelly Dolls. It's a poorly implemented pieced of UI and to see anything over about 350k complexity you have to switch off the limit. That's risky, because of griefers with graphics bombs. As far as I can tell, the LOD switching is badly calculated for rigged mesh, making the Medium->Low and Low->Lowest switching mostly irrelevant, because of Draw Distance settings. but it still seems to happen, and the ARC calculation gives plausible answers. We have confusing documentation (and I have ranted about that) but I don't see any signs of things not working as documented. Could things be done better? Yes, but I am not confident that some of the big name, high sales, creators could optimise their way out of a soggy wet paper bag. Rather than learn just how to do their job, they start screaming "It's a bug!", and go on to do nothing. And you know what started me off on this: people using 1024-size textures with pointless alpha channels. Let me check, rez the original version of this pair of shoes, so it does't invoke the rigged-mesh bug excuse: 6264 display weight. Used reduced size textures, without the alpha channels, and I get a display weight of 2998. The LOD switching distances shown by the Firestorm editor look right for a mesh object of that size. Let's try the Inspect right-click... 1024-size textures with alpha channels: 12,288 KB VRAM Reduced-size textures with no alpha channels: 1,536 KB VRAM Yep, it's an insanely high triangle count as well, but textures are so easy to re-scale, and it looks like these people don't even bother to try. The Download/Streaming weight reported doesn't change, which is a bit odd.

Penny, I agree about memory use having more relevance than than texture size, but they still have to be downloaded, and having better use of memory by the viewer isn't going to help download, streaming, or whatever other label the Lindens are using this week. I can already set my viewer to not display larger than 512-size, but there's no way to not download the 1024-size original. Besides, pixel count, in the data or for the size on screen, it what the graphics system works with. There are shoes in these SL16B sets which have the laces modelled and textured, distinct faces around 10cm across. Why is a 1024-size texture even being used for something that small? That works out at 10 pixels per millimetre. I reckon the level of detail in the model is a bit wasted, but as a texture? (The same shoes have a texture for the lining, the inside of the shoe that nobody sees while it is worn, and that's another 1024-size!)

Please note that the texture system doesn't have any connection to the LOD system, calculating mipmap usage independently of LOD switching distances, and maximum texture size, which might never be seen by a user in-world, but which has to be downloaded and processed by the viewer, does affect the ARC number. Since the Lindens have known about this for a long time, and said sweet fanny adams about changing how it works, persisting in calling this LOD behaviour a bug, and ignoring it, seems like foolish wilful blindness. If that's how the system works, why aren't you using it? Why do you persist in using high triangle counts for the Low and Lowest LOD models, which still have to be downloaded and stored locally? But, before you get all snooty about this, look at what you make in wireframe mode. If the edges of the triangles are so close together that the item looks solid, can your opinion on optimised content be worth anything?

I'm not sure they would do that, some would start screaming about content theft, but 1024-size images are all too common, and the way the graphics sub-systems work on the viewer you have to get very close before you see the full resolution version on clothing. For a good example of essentially unoptimised clothes, The Lindens have given us the four SL16B outfits, with 1024-size textures and very high mesh density. The way the LOD-switching distances are calculated for a rigged mesh, graphics are weighed down with sub-pixel triangles, and the download weight rises a lot, hurting sim crossings and teleports. My usual avatar, mesh body, mesh clothes, and all, comes in at around half the ARC of one of these outfits. Just the texture sizes would make a big difference, with minimal effort. These things are choices, I can see reasons for 1024-size on a large object, but I doubt the competence of some creators who use them.

The existence of this document wasn't mentioned at all.

This topic came up in a rather euphemism-laden part of Ebbe Linden's "Meet the Lindens" session on Wednesday, and there seem to be two very obvious things that got missed. I'm writing from experience of being an Executor under English law, which means being the person named to handle the assets of somebody who has died. It wasn't complicated, but these two points are pretty fundamental. My starting point is somebody who has IP assets generating income in Second Life. Every so often, the income accumulates enough to be worth cashing out. But what happens if you die? 1: How does your executor know about it? That's the obvious question. For me, I have made stuff, it sells, but the total income is tiny. It's just not worth bothering about. For other people, if you're paying taxes on your income from SL, and your payments to Linden Lab could be a business expense too, your executor should be able to find out from your business records. The job is all about paying any debts and collecting any monies due. Make it easy for them. 2: And what procedures do Linden Lab have to deal with their side of things? Banks have procedures for this, and some of what Linden Lab do comes under rules applied to banking. Essentially, as an executor, there are documents that prove the person is dead, that he controlled a particular account, and you are the executor, and the bank needs to see them. I suppose Linden Lab would come under California State Law and US Federal Law on this. It is a problem that people have dealt with, and the costs of proving all this, probably hiring an attorney, could make the whole thing not worth the bother. But some people do make enough money to be worth the effort. If I wrote a book, sold it to a publisher, went through all the editing process, saw it go on sale, and then died, my estate would get all the payments due. The publisher would continue to have the right to publish it, that's part of the contract we would have, but there would be a time limit in the contract too. Copyright can last a long time after death, but how long will people want to read it for? I know a little about how books work, and there's a lot of legal history covering this sort of problem. The money gets to the creator, and their heirs. Linden Lab have to be careful, that's part of the law, and there are tens of millions of dollar getting paid out to users, every year, payments other residents make for the right to use IP of all sorts. That's why it surprised me that Ebbe seemed so vague on the topic. (Yes, you could leave details of your username and password for your executor. They could log in, take the L$, and delete the Marketplace store. That wouldn't be lawful.)

One things about scripts in the old days, which changed, but could still be lingering in old items: There used to be LSL functions which could run in one prim, and do something to all the prims in a linkset. But that action triggered a 1 second delay, and people would program a control script that sent a signal that was detected by a myriad of scripts, one in each prim. I've worn prim hair which had over 70 prims, and to get an instant colour change they needed over 70 scripts listening for the signal. Most of those delays have gone. Prim hair still has a few useful feature, such as flexiprims, but the reason for a large script count seems to have vanished. You'll need somebody with more clue than I have on LSL to report just which bits of LSL had this problem, but it's a problem with old stuff on the marketplace. And if you don't have enough permissions on the scripts and the object there's not much you can do about it.

If you're working with mesh, the collision prim can be mesh, so the bridge deck and side rails could all be one component. But if you do that you can't use that convex hull option for the collision prim/physics model. The L-shaped kitchen here can't use a convex hull. The stool would be inside the physics shape. It does use a mesh physics model, which isn't strictly a collision prim but it does the same job. It's simpler, lower physics cost, than using the detailed visual model.

This is something I try to get right with the stuff I make, but two things to bear in mind: 1: If you're wearing a rigged mesh, such as mesh clothes. the switching distances are the same for all items, and are based on your body size. A small item might otherwise switch detail level rather too soon.The switching distance may be too high, some people call it a bug in the calculation, but that's the way it is. 2: Some objects have several distinct mesh parts, and some parts will switch long before others. It's fairly common with wheels on vehicles. It can be made a lot less obtrusive by doing something like setting Medium LOD the same as High LOD Getting things right doesn't depend on making specific LOD models, though the automatic generation of lower LOD can make some horrible choices. For ordinary rigged mesh clothing, the Low and Lowest LOD models can be very simple, nobody will ever see them as anything more than a blob at the distances they're visible. There's a similar system for textures, all automatic. Using several materials from the same texture make the choices less clear, but it does mean that big textures can be easily wasted. It all works from the size a texture will appear in your viewer. A lot of 1024 textures are wasted.

One thing I have noticed is that the viewer seems totally unable to to pick up basic settings, colour schemes and cursor-size stuff, from the operating system. Some elements can be set in the viewer, some can't. That's not just in Linux, it happens in Windows too. And so I have doubts about what you said there.

Wine works pretty well for a lot of programs, but my experience with the SL viewer has been mixed. Is there any recent info on setting this up? Likewise for Wine and Firestorm. SL16B is getting close, and if it is anything like last year, a lot of events are going to be a waste of time without voice access. I have heard a suggestion that a windows version of SLVoice.exe can be run under Wine to provide voice support for a Linux viewer. Where is that documented? And how do you get the Windows version? Where Is The Documentation!!!

I did wait a little while before logging in, and things went well the rest of the day, peak numbers close to normal, a couple of sims seemed to have a loading problem, and the original 13th-to-16th warning was closed. Had they got it finished? I maybe read too much into this message. Completed - The maintenance has been completed and services have been restored. No. Further work late on Tuesday. No actual shutdown, and I was asleep anyway. They've finished, but the messaging is better. Update - The scheduled maintenance for tonight has concluded. (Tuesday) There will be no more work done until tomorrow evening. (Wednesday) I maybe should have expected the Tuesday-night session, but "completed" feels wrong. It's too final.

Way down among Brazilians, Coffee beans grow by the billions,So they've got to find those extra cups to fill.They've got an awful lot of coffee in Brazil. Should have ordered a decaf...

We need a furry dust bunny avatar.