Sharie Criss

This release TOTALLY broke my sim Lochme. It recalculates the LI of objects that have Alpha masking so that a 2 prim tree is now 200 - this put my sim about 8000 prims over and stuff returned ALL OVER THE PLACE. I need my sim rolled back (yes, I filed a ticket) and the CODE reverted too - at least until I can remove Alpha Masking from each and every single object in the sim - or some other kind of remedial solution. HELP!!!!!

Since nobody has replied, I would suggest that you open a new bug report. It's a well-known fact that LL never looks at old bugs.

Torrents are a poor indicator of network issues due to the nature of that type of traffic, but I too was seeing network related issues as I was moving around / interacting in SL. They are all better today but it was causing a lot of TP trouble for me and very slow texture / mesh loads yesterday.

Yes, that's the region.

My region is being restarted AGAIN?!! The first time this morning it was down for over an hour. How many times are regions going to be restarted today?

Qie Niangao wrote: Sharie Criss wrote: If you read the documentation you linked to.... "the decision to allow or block the request is persistent" That fits 100% with my statement Once you have permission, you have it for everything requested, you don't have to keep requesting it over and over. It doesn't actually work that way. I too got a little confused about this at first, and even after I figured it out, I couldn't come up with improved wording for the wiki articles. In short, an Experience-enabled script still has active permissions for only one agent at a time. If it wants to switch to another avatar in the Experience, it must switch that permission target, too. The script can still use llGetPermissionsKey() to find which agent for which it currently has permissions, so it knows when it needs to switch, but when it does, it needs to call one of the llRequest*Permissions functions. Actually, it DOES work that way. Ever wondered why a dance ball has so many scripts? Or that many furniture items to? It's exactly so the script can maintain permissions. In an Experience, if you are doing it correctly, you are going to have a Master Controller that has these permission scripts, and other little things here and there and everywhere that trigger Experience actions are going to send a quick message to the master telling it to do something to the avi. That Master script will be the one that maintains all the state for the Avi as your little triggers won't have the brains to do it. Another alternative that many people do is to give the user a HUD that will maintain the permissions and initiates the actions. There are many ways around LL's super limited script engine, and you have to employ them to provide a decent experience to the users. LL's insistance that a script can only maintain one avi's permisions at a time is one of those limitations that people script around all the time. And it kind of sucks, because it DOES require more "needless" scripts, but as they are not active unless actually doing something it really isn't a big deal. These anim / permission scripts are also small and don't use much memory (and as we know, the memory reporting of scripts is fatally flawed as it always reports a full 64K for Mono scripts when they may only be using 2K.) Cheers!

If you read the documentation you linked to.... "the decision to allow or block the request is persistent" That fits 100% with my statement Once you have permission, you have it for everything requested, you don't have to keep requesting it over and over. Perhaps you are misreading or what I wrote. Furthermore... "estate managers will always see the permission dialog even if the experience has been previously approved. " This basically means that if scripts did what you suggest, constantly call and ask for permission, estate managers would be deluged by the permision request dialogs. I plan on using ExperienceKeys on my regions, and I sure as heck don't want to be hammered with permission requests all day long! That would be extremely bad programming. You are better off letting the errors happen and dealing with it than than pounding the crap out of the script engine causing needless lag. Frankly, the permission system has been broken "forever" and despite countless pleas over the years, LL has failed to address any of the concerns brought up. It would be SO much better to have a graceful way of handling script errors. (Hint: debug channel is one way.)

A couple observations. Once you have permissions to start an animation, you always have permission to stop it EXCEPT if a viewer breaks things, such as the Firestorm "revoke on stand" which does NOT exist in the official viewer. Once you have permissions, it's crazy to keep checking for it over and over everytime you do an animation change - all that does is make your script laggy. As everyone knows, script lag is a serious problem and poorly designed scripts that do needless things cause a lot of it. Experience Keys goes even farther with the "always allow" if you read up on it. I would simply ignore these obnoxious errors, and would STRONGLY recommend NOT hammering the permission system over and over and over to eliminate them. Instead, a better solution would be for LL to recognize that there is a very popular misbehaving viewer out there that can cause them, and implement a way for us to always silently ignore those errors if we choose to do so (like so many other things we can choose to ignore.) Perhaps file a bug report (feature request) asking for that in the LL JIRA. Revoke on Stand could have been implemented in a way that wouldn't cause these issues, such as adding a delay to the revoke of a couple seconds after a stand. Perhaps file a JIRA on the Firestorm site asking for this since they are the ones causing the problem in the first place.

Due to this highly unreliable situation edititing attached scripts, I wrote a quick little backup tool that takes a copy of the scripts in your attachment and saves it in a rezzed backup prim. It's saved my butt a few times. Contact me in-world and I'll send you a full perm copy if you want it.

LL has never responded well to griefer attacks. A day of zero action is perfectly normal, in fact nearly a week is normal. The griefers know this, and they know that they have a near zero chance of LL doing anything to their accounts. The bottom line is that LL itself isn't impacted by griefer attacks. They still get their money, that's all that matters. When you rent digital land, there is no service level agreement. What does that mean? Simply this, LL is under no obligation to fix this stuff, certainly not within a specified amount of time. Yeah, it's a pretty crappy situation, but it is what it is.

Sigh. Yes, it appears to have been some bizarre viewer cache thing. I cleared cache and that resolved the mesh loading (yellow triangle) issue. It's odd that things were perfect prior to the restart, and broken after. And not just for me! The same cache clear has fixed the exact same issue for others who were seeing the same yellow triangles. We all use firestorm, not sure if that is related or not. To be honest, this just doesn't make sense to me. Now that the restarts seem to be over (I think?) attachment rezzing seems to be better as well. It's unfortunate that rolling restarts seem to strain the infrastructure to the point of causing all sorts of unusual problems.

Pre-restart, everything was fine. Post-restart, mesh loading is hosed. Tons of yellow triangles over mesh objects. Can this be resolved please? I hate to go an entire week with large portions of my builds not rezzing. And No, it's not just me. Everyone seems to be having this issue. Group chat lag is up to 5 minutes at times which is MUCH worse that normal. Mesh loading on avatar attachments also seem to be an issue from what I'm hearing. Is this all asset server related? Are they no longer able to handle the load? It seems we are having issues almost constantly lately.

I have NEVER seen mesh items load this slow. Could something in this release have affected load times? It does seem to depend on how busy the sim is, sims that are more busy are 100 times worse than empty sims but empty sims are still slower than they used to be. In a busy sim it can take 5 minutes for someone's mesh hair to fully rez. Bleh.

Roxie Torok wrote: Now that everyone has had a chance to rant, I was wondering why, when LL claimed Server Side Rendering was going to solve all the problems about others seeing your avatar as you yourself saw it, how come with the proliferation of Mesh and the Alphas that come with them, whenever I land in a SIM, almost everyone is partially invisible? When you TP to a sim, things do take time to load. It will never be instant. The problem is however made much worse by content creators that don't know what they are doing. It pains me to see alpha layers created with 1024x1024 textures for example - they should NEVER EVER be higher rez than 256x256!!! I also see dresses with insane numbers of verticies - looking at a wireframe view, the dress looks solid, probably 20,000 verticies. I've also seen insane things like a 1024x1024 texture on a button on a pair of jeans. LL can't fix the stupidity of content creators sadly. But that's not all.... A lot of people run around with their viewers set to insane draw distances. Why is this bad? Think about it... Your viewer has to load all the object and texture data for everything in view - this strains the asset servers and the sim server itself when your DD is excessive. It causes server side lag that affects everyone. We have silly script counters that do nothing but cause even more lag, and a lack of understanding that scripts don't cause server lag other than maybe some scripts will run a little bit slower - scripts only run in spare time. The sim will do what the sim will do no matter if there is 1 script running or 20,000. The calls to count script / memory usage are very heavy on sim resources and do more damage than good - and worse, they hammer on the sim constantly over and over and over. The damage caused by a script monitor is 100 times worse than the dormant resize scripts they are looking at. Lastly, your consumer router probably sucks and can't handle the massive number of connections that SL uses. Most handle it poorly causing texture loading to fail and retry, which appears to you as slow texture / scene loading / bake fail. So really, it's not LL causing the lag, it's horrible content creators and people running crap tools that they don't understand, with viewer settings that are crazy.

Absolutely fantastic advice, I plan on trying this out right away - thank you so much for your very detailed response!!! Edit: My new hill has an LI of 2 with the prim physics type - MUCH more in line with what I would expect Thanks! And the easy way of nuking the unneeded verticies, the Decimate modifier. Does most of the grunt work that can be hand tweaked.

Bingo. That did it. Thanks! It is unfortunate that the cost went from 3 to 10. That's quite an insane LI calculation on LL's part. I could probably make a similar hill from a bunch of prims that have 100 times the vertexes for half the LI. Bleh. The LI for mesh is still way too high. A simple mesh model like this should not have that kind of LI.

I've created a VERY simple mesh from a deformed plane... http://gyazo.com/cb0676cc9f9014570f9082aff7a3c233 This is used in the corner of a skybox to give a little terrain hill. The model is sized correctly in blender and I only have to make very minor adjustments when I rez it. No matter what I do, the physics seems off - I hover over the mesh by about .7m. In a few small places, it seems fine: http://gyazo.com/940546b906166c7394a6ec66bb284cb6 but the vast majority is way off: http://gyazo.com/0597679766a02c7721941e0c29c0cd0c I've taken most of the defaults when uploading the model, selecting the High LOD for the physics model as this is a pretty low-poly mesh. I've tried selecting the model DAE file for the physics model too, no change. I'm using the latest Blender, and have tried both the 4..5.1 firestorm and latest LL SL Viewer for uploading. Suggestions?

Using latest Blender and Avastar, I've created a simple dress going through Gaia's awesome video series. When the dress is created, it's shrinkwrapped to the SL Avatar skirt mesh, and when rigged the weight copy gets taked my guess mainly from that SL skirt. Now as we all know, and the video shows, the SL skirt has TERRIBLE weights, resulting in the nasty sheering between the legs, and the hard crease that badly distorts at the top of the hip. In the video, the weight painting tools make things a little better, but it never goes into deep detail about selecting different weight groups and the weighting tools. My result is that things get worse, not better! I "get it" that certain bones should have more influence over how a vertex moves than others, and I understand the color system blender uses during weight painting. What I don't get is how many dresses I buy the rigging is just totally awesome for moving those upper leg bones, the mesh remains smooth and stretches naturally. Question is, How do they do that?!! Are they not using blender? Not starting with the dress rigged to the SL skirt weights? Are there more controlled ways of editing the mesh weights than weight painting? http://gyazo.com/1dd063a6ec0cbb3754dfd14dc6422a6e

Not sure what went down today with the rolls, it looked very small BUT, as of this afternoon, I can no longer TP more than once without the TP failing and logging me out. Whatever got broken, please revert. For the peanut gallery, no, it's not my connections or computers (I've tried multiple tested connections and multiple computers,) but thanks for playing.

Most "residential" ISP's massively oversubscribe their services. Yes, you can "peak" at a high number, but that bandwidth they are selling is probably highly unreliable. When you test to your local ISP, sure, you will get fantastic results because you are on the local network. The thing is, that's not enough. Your ISP has connections out to the rest of the world and I'll bet that their connections are overloaded and that they need to increase their capacity. That's why your results are unreliable. Pinging the US WILL have higher ping times - the speed of light is the limiting factor. Sorry, but it's just the laws of physics, not that the test is bad

One other thing to check - do a VOIP test: http://www.voiptest.org/ Choose the server in the middle of the US and let us know ping time, packet loss and jitter.

The issues you described are usually networking related. Since you tried pretty much everything else, try powercycling your router. Many "home" model routers frankly have trouble with the high number and rate of conections that SL needs. If it's old (more than 3 years) consider replacing it, and get a higher end soho router. The other cause of issues can be your security software. Most AV software inserts itself into the network stack on your computer, doing network intrusion detection, etc. Done badly, it can cause problems with network intensive games like SL. You could try disabling it, or at LEAST put in exclusions for your viewer, the cache directory, the settings directories, etc. (there are a lot of places SL touches.) How to do that exactly depends on what version of OS you are running, AV software, etc. so I can't give exact steps. McAfee, Symantec, and Kasperky are just friggin horrible with how they screw with your networking.

I deal with email server issues all the time as part of RL work. Yahoo's email servers are among the least reliable in the industry in terms of delays and ability to deliver. GMail is one of the best. I know it's a pain, but if reliability is a concern, you may want to consider switching. Yahoo also doesn't allow you to use a regular email program unless you spend extra for "premium" email.

Seems the inventory servers are broken again. Massive issues here as well, including lost no copy items. Yay LL.

I'm very disappointed that nobody at LL seems interested in the content destroying bug in this release that I mentioned. I have now heard from DOZENS of people that have run into this same content destroying bug.