Darien Caldwell

Jenna Felton wrote: Principally it seems to be possible to test how good is a connection of the avatar and how good is the avatar's machine by using a RLV-enable viewer. RLV has a number of commands awaiting a response from the viewer. For example a "@version=channel" command. The protocol is this: A scrip in avatars object (e.g.) relay opens a chat listen on a channel, e,g, 222, than issues a command llOwnerSay("@version=222"); This is a message sent by script directly to the viewer using by the avatar.The string " @version=222" is thus passed over the server - viewer connection and is delayed in respect of the connection speed. The viewer receives the message and understands as command to reply the viewer's version on the channel 222 (if the viewer supports RLV, if not it just displays the message.) The response again is sent over the viewer - server connection and is the faster the better the connection is. The script in the scripted device receives the message and calculates the "ping" value. However, in most cases you have a device that is owned by you and not by the avatar. In that case there will be also a step 0, when your device sends a RLV Relay message towards the relay worn by the avatar, This message is a command to request viewer's version and this will make an additional delay by script - script connection. From the step 1 on, there will be three delays until you receive the viewr's response, those in steps 2 and 4 are caused by the viewr - server connection and are as bad as the ping of the avatar's machine. The delay in step 3 is caused by the machine itself and determine how fast the machine is but can also hapen because of the virus scan program and similar loads at the moment. So with this technique you can quess the avatar's ping but not measure an exact value, but principlly it is possible. PS. Two links about that RLV version checking command RLV Relay specification LOL. Thanks for the laugh Jenna. That's the most Rube Goldberg thing I"ve ever seen for checking ping. Of course it wouldn't work, since the server can, under load, delay script execution and therefore delay any scripted replies. Somefimes for up to 15 seconds. And of course if it did work, you could easily do it without RLV. The simplest solution is usually the best. You ran a stream, checking the Ping on a stream is trivial, and bad pings on streams = choppy music that cuts out constantly. So likely that was not only how he checked, but why he checked.

I was wondering the same thing. THe only guess I can have is, They would want you to file a JIRA BUG about any issues. You can do that here: http://jira.secondlife.com

Failed mesh loading looks more like a pyramid.

They announced it at last Friday's Meeting.

A Linden who I won't name posted this link once. He made the point of saying LL doesn't endorse any particular router, etc, etc, so I will repeat that here: http://www.smallnetbuilder.com/lanwan/router-charts/bar/77-max-simul-conn Basically this charts the # of simultaneous connections various brands of routers can handle. The most problematic ones for SL simply can't handle many connections (and really don't deserve to be called routers). So you can make some determination about how good a router is for SL by looking at this chart. For my personal Recommendation, I recently bought a Netgear N300 Wireless Gigabit Router. (WNR3500L) It's great. 4 ports + a built in wireless node. According to the above chart, it can handle 2048 simultaneous connections, which isn't the biggest, but for the home user, is plenty. I can run 2 clients, browse the web, have my secondary PC transfer files to my NAS, all simultaneously, with no complaints whatsoever.

You can reset scripts that are no mod. BUT, you can't reset scripts that are *inside* no mod objects. As for Things corrupting, I haven't see that. But I do know the "Recompile" feature on viewers doesn't work as it used to, since compiling was moved server side. I think it only works when a script is full perms.

My guess is Lydia stepped through some kind of Time warp.

MB Robonaught wrote: The renter was using a forced pos ball set up that did work fine on the mainland but did not function on either of the two magnum sims we tested on. It could be due to this List Issue being discussed.

I'm trying your script, but I'm not seeing the issue you mention. LeTigre: [10:09] Object: GOOD:72435d55-873c-4617-b6ea-9a707d1f6800 BAD:72435d55-873c-4617-b6ea-9a707d1f6800 NOTBAD:6a5aef83-93a6-42e1-9d76-bd03b4f5e8aa UGLY:1234567890 Magnum: [10:10] Object: GOOD:72435d55-873c-4617-b6ea-9a707d1f6800 BAD:72435d55-873c-4617-b6ea-9a707d1f6800 NOTBAD:6a5aef83-93a6-42e1-9d76-bd03b4f5e8aa UGLY:1234567890 EDIT: Ah I missed the part about it has to be LSO, not MONO. When compiled to LSO, I see it: Magnum: [10:13] Object: GOOD:72435d55-873c-4617-b6ea-9a707d1f6800 BAD: NOTBAD:6a5aef83-93a6-42e1-9d76-bd03b4f5e8aa UGLY:1234567890

Does the "Large Groups" feature require a special viewer? or will it work with any viewer?

there is nothing to revert. if you rez an object in an area that has a return time of 5 minutes, that clock starts from the time its rezzed. if you' re riding on it for 15 minutes, you have already exceeded the time by 10 minutes. it won't return because you're still sitting on it but the instant you get off, it will return because you are already over the return time. it was like this in 2005 it was like this in 2006 it was like this in 2007 it was like this in 2008 it was like this in 2009 it was like this in 2010 it was like this in 2011 it was like this in 2012 it will always be like this

This isn't new behavior. No Object Entry means just that. There is an exception made for vehicles, but once you get off, that exception ends. The only people who would be complaining abou tthis are griefers.

This is normal for SL. Some time ago Gaia explained this in-world, and I will point you to her explaination here: http://darisl.wordpress.com/a-dialogue-about-vertice-counts-and-sl/

Masami Kuramoto wrote: Oz Linden wrote: We now have a wiki page on how Material Data is interpreted and used. Note that nothing there is final until it's all working... I could write all day about why lightmaps are a must-have feature, but maybe a few pictures will help bring the point across. This is where we are now: tinted diffuse mapping: This is where we are going: tinted diffuse + specular + normal mapping: And this is where we should be: tinted diffuse + specular + normal + lightmapping: The diffuse map: The specular map: The normal map: The lightmap: Total texture size: 512x512. Effective texture size visible inworld for this example: 8192x8192. No blur, no pixelation, no alpha sorting issues, and the floor tiles can be reused elsewhere because the shadows are not baked in but kept separate. Furthermore, static lightmapping is much less taxing to low-end hardware than dynamic shadows. It's ideal for indoor scenes with multiple lights and soft shadows. Static lightmapping was a feature of the Quake game engine released in 1996. Please, for the love of Philip, give us access to this ancient technology, so that SL can finally look decent. I don't see how this is any better than baked lighting. From the looks of it, it's still static; if you moved the light to the other side of the rail, then what? You're going to have to explain why this is better than a baked shadow, when both don't move with changes to the light source.

Drongle McMahon wrote: Oh yes. That would certainly lose backward compatability. It could be a bit of ambiguity - Solid color only if ther's no texture, tint if there is? A more general question is whether the new system will apply to existing things, using just the diffuse map and defaults with no effect for the rest; or whether there will be a toggle new/old system. A toggle would guarantee not breaking anything and allow people to go on using the legacy system if they wanted to. I guess the biggest potential problem would be old shiny vs new specular. I hope it's just a mistake or as you say an ambiguity. People like to have coloring options, and a very common way to do that is to use greyscale textures combined with color tinting of the texture. It's a very important tool. One could argue removing this functionality just means you have to make a texture for every color, but the lack of scripting interface would prevent that too. So it would certainly put creators in a bind.

Drongle McMahon wrote: A couple of comments/queries... 2. "Used only when Alpha Mode is Alpha Test (see description of that mode above)". Alpha Test mode appears not to be described above (or below) this statement. From reading the descriptions I think "Alpha Test" refers to "Alpha Mask (cutoff)" mode. That value would be the Alpha cutoff value used for 'cutoff' mode. I am curious about the statement: Color "a solid color for the surface; not used if a Texture is also specified" Is this color in addition to the usual "prim color" already available? And if so, this is a change in behavior. One was always able to tint textures using the color.

I was tipped off to a rather laggy sim that hovered around 0.9 dialtion. I tried your script for about 4 hours and drift never strayed from 0. So I think at this point it's safe to say dilation doesn't affect the function after all. I'm going to go ahead and modify the wiki.

Looks good. From talking to others and some limited testing of my own, I'm starting ot lean to the "Not affected by dilation" side. But lets see what your long-term results are.

Qie Niangao wrote: Oh, jeez. The wiki is inconsistent on whether script time is or isn't affected by sim time dilation. According to llGetTIme() and llGetAndResetTime() it is unaffected -- apparently stemming from a 23 November 2009 edit to llGetTime() by one "Chance Zeta" (complete with a link to a picture of a wristwatch in the change log!), which (mis-?)information was apparently copied over to llGetAndResetTime() by Gaius Goodliffe as part of a larger edit on 14 April 2010. But your cited text showing it to be affected by dilation is still present in llResetTime(). FWIW, my own homegrown rental script uses unix time, and I don't think I've ever used these other functions for anything significant or long term. I don't know for certain that they're actually affected by dilation. We should test that and update the wiki accordingly. But my sense is that the timer freeze we seek is more all-or-nothing than the kind of drift we'd get from cumulative dilation. Yes I noticed that inconsistency after posting. I started a thread at SLU to see what people's experiences are. I'd try testing it myself, but so far have been unable to find a consistently dilated sim. (if anyone knows of one, let me know.) I know as long as I can remember, time measured that way was considered innacurate due to dilation. But much has changed since then.

The problem with the script as I see it, is that it's using llResetTime() and llGetAndResetTime(). Using script time to keep track of elapsed time is dicy at best. As the wiki states: Script time resets when...Script reset (user or llResetScript or llResetOtherScript) Simulator reset (admin or crash) Call to either llResetTime or llGetAndResetTime Script time doesn't measure real world time, it is affected by time dilation. So that has the potential to introduce a lot of error into the timekeeping function. A better method would be to use llGetUnixTime() or some other real-world time to ensure accurate timekeeping. It could be what is interpreted as freezing is in fact that enough error has been introduced that it's days or even weeks off in it's timekeeping.

Lot of questions: "First, why do some designers make the alpha layer for dresses too long?" They don't. I"m sure it lined up perfectly on the shape they used when they made the dress. However, Not everyone in SL is the same shape or height. Whe the Avatar's body shape/size changes, that is accomplished by elongating bones and morphing faces of the mesh body. Naturally that means the 'skin' stretched over the 'skeleton' has to stretch. This stretching results in the Alpha layer edges also being stretched out of position. That is why if you're taller/bigger than the shape the mes creator used, gaps will form. "Second, some designers include textures in the pack with what appear to be alpha layers or pieces of them. What am I supposed to do with these? I am not a designer myself and I cannot modify the alpha layer. Why are they there?" Whily you may feel you don't have the skill to modify the alpha layers, many people feel they do, and in fact the process isn't all that hard. So many people demand these layers so they can correct the gaps themselves. As well users of the old, oudated, Phoenix viewer have no choice, since that viewer only supports wearing 1 Alpha layer. They *must* combine these textures into 1 texture.

I'm not sure I see why having runtime permissions non-revokable is a problem. The fact is 'unrevokable' isn't even accurate. Permissions can already be revoked through reset of the script, copying the prim or script (copies do *not* retain permissions), or even from script memory rollback (admittedly a bug, but still valid). There are also many viewers that allow for revoking of permissions as well. I think just reading this proposal shows a case of the 'cure' being worse than the 'illness'.

Perrie Juran wrote: ETA: I also witnessed several of AnneMaries cars having problems at this crossing. Well, at least there was an upside.

A number of people from the SL Beta group have decided to form a side group for JIRA issue discussion. The more who participate, the better. The group is called "Bug Bashers", you can find it in-world or IM one of the members (Me, Iain Maltz, Scorch Braveheart, Larry Leborski, etc, etc) for an invite. secondlife:///app/group/7581bf2d-29a5-4fea-7a98-7a520565d427/about Our plan is simple, but it requires everyone's help. When you file an issue, also make a post about it on the subforum at SLU called "SL JIRA Issue Discussion". That way everyone knows about it. That's really all it's about, centralizing reports someplace where everyone can access.

Qie Niangao wrote: I've mentioned it in another forum, but just to add here: It's critical that there be a scripting interface to the server side of this as soon as it's available in the viewer. At the very least, we need to be able to set the maps. Assuming they aren't locked to textures (and they sure better not be), they'll also need to be animated, aligned, and scaled by script, too. (Futile though it may be to mention: it's not necessary to further clutter-up the viewer's build tool with any UI for this. I don't actually expect that viewer devs (LL and TPV) will be able to stop themselves from hanging yet more floating complexity off what are already UI abominations, but it's an option to instead simply let scripts define how users manipulate these.) Agreed. For various items with texture changing needs, being forced to use the same Specular/Bump for every possible texture would be madness. At a bare minimum, Scripts need to be able to update these new attributes as well.