Stickman Ingmann

I would like to add in my voice to those who are confused as to how this can be anything but a bad idea. Only thing I can think of is that LL didn't feel the Jira was reflecting well on their public image (too many open bugs, or old problems that were never fixed) and decided it was better to hide the system then fix the system. This turtling is also visible by how we used to get blog posts explaining what happened when an outage happened and what they're doing to fix it, while now they're just saying they had some "unschedule maintenance" with absolutely no details. No news is only good news when the news doesn't actually exist, not when it's censored.

If you want to make a formal complaint, and submit Region Idling as the cause, submit a Jira. include the region name, the server version information, and as much information as you can offer regarding the cause, time of problem, and symptoms. If Region Idling is the cause, I think they'd want to know about it. I haven't checked release notes, but based on all of the rollouts that have been going on, I suspect not only is Region Idling NOT enabled, but the server version that even has that code has been rolled back. So you may want to double check your facts before you start pointing fingers.

More accurately than "physics slows down" would be to say that "time slows down." Physics calculations won't change, they'll just happem about 5 times slower. In many respects, this will appear the same to a region lagging. Say you have a racecar that automatically runs around a track. If it runs an entire lap in one minute, normally, then if the region is idle it will run that lap in about five minutes instead. But odds are it won't end up flying off the track or something when the region idles. It's possible, but it takes a certain type of creativity to write something that would end up doing that. And it would be immediately visible as soon as the region started lagging at all. Some vehicles can automatically compensate for lag. That is, they will detect if the sim FPS changes, and move "faster" so even though time has slowed relative to the physics simulation, the car moves at the same speed according to the external viewer. Depending on how your vehicles are written, they could encounter the problems you suggest. Have you ever had a vehicle get auto-returned because the region it was passing through was lagging? If so, the same problem can happen in an idle region as well. If you've already encountered this problem and compensated for it, you've already made your vehicles region idle compatible.

If the non-consecutive frame behavior for th timer event doesn't change, that puts the limit on timer events up to 0.25 seconds while a region is idle. (244ms actual) Less of a problem if timer events don't queue, but more of a problem if people expect the timer event to fire more often. Still, 250ms isn't bad at all. But having accurate numbers helps when designing things. Thank you for the information, Moon. Much appreciated.

Yes.

A timer tries to execute on the nearest frame closest to the real-time (not lagged time) equivilent. Someone was complaining in the scripting usergroup that a timer of 0.075s wasn't triggering every 75ms at all, but was wavering back and forth between 88ms and 67ms. Since simulators normally run at 45 frames per second, each frame is around 22ms seconds long. (1 second / 45 frames = 0.0222 (repeating) seconds.) A timer can only execute when a frame comes up, which includes 88ms and 67ms, but not 75ms. Thus, when region idling kicks in and you start getting 8.2 frames per second (frame time increases from 22ms to 122ms, with the extra 100ms being forced "unused" time, so 1000ms/122ms = 8.1967...fps) your timer only has around 8 chances to trigger every frame. It'll get a little less accurate, and if you're calling it more than 8 times a second (every 122ms, or just 1 second / 8 frames = 0.125 seconds, or 125ms) you're going to end up not having the timer execute as often as you call it. That is on a normal, unidled region, if you were able to call the timer more often than 0.05 seconds, such as 0.01 seconds, and frame time is 0.022 seconds, the timer would be trying to trigger more than twice every frame. In this case, the timer would start queuing and executing every single frame, but lag behind because it wasn't executing as often as you called it for. After one second, your script would have executed 45 timer events when you asked it to execute 100 events. In the case of region idling, calling the timer more often than 125ms/0.125s does the same thing. The events queue up, and once it hits 64 queued events it will start dropping events. But will still execute every frame. Thus, well written scripts won't be affected by region idling. Anyone who needs more than 0.125 seconds per timer event can just detect region idling and adjust their timer accordingly. Physics will be affected by region idling. So will things like keyframe animation. Physics will run at roughly 1/5th the speed (8/45=0.1777..., 18%). It's possible to detected (llGetEnv()) when the region begins idling and compensate for this artificial lag if it's necessary to "keep the trains running on time." Just keep in mind that no one will be around to see it, and things will pop back up to speed within milliseconds (notably less than 100ms or one tenth of a second -- likely before anything even loads on the screen) of someone even getting close.

I am an estate owner and I have no problem with this feature. Could you voice your specific concerns? Perhaps I could help you resolve them.

Short answer to breedables: They won't even notice if the region goes idle. Long answer, Simon Linden explains here http://community.secondlife.com/t5/Second-Life-Server/Region-Idling-coming-to-Second-Life/m-p/1536577/highlight/true#M5464 that frame time is reduced to 8-10 frames per second. While he didn't answer all my questions, this information means that as long as your script doesn't try to call a timer() event more often than 0.125 seconds, most scripts probably won't even notice if the region is idling. This includes breedables. If there is any breedable on the market that has a constant timer running at 0.125 seconds or less, I would recommend you do not do business with them until they improve their scripts. A breedable with a script that aggressive would be take up more resources than it should, and be a hinderance to a lag-free experience for everyone. Most of the breedables I've seen appear well made, and would not fall into that category.

Depending no how they did the details of region idling, and how the breedables were created, there could potentially be problems, but I doubt there will be. It all depends on the way the timer is set for the breedable, and how low the framerate gets. Once more information about region idling is released, you can contract the scripter of your breedable and ask them if it would be a problem. My guess is that it won't be. I posted some technical details on why, here: http://community.secondlife.com/t5/Second-Life-Server/Region-Idling-coming-to-Second-Life/m-p/1536199/highlight/true#M5460

I have a couple technical questions. 1) From what I remember, regions are CPU-locked. They're not allowed to use a CPU that they're not assigned to. In order for region idling to have any effect other than decreasing server energy consumption/heat generation, the simulator code would need to be able to use a second CPU that's been freed up. This would mean that the simulator code would need to support multi-processor/core threading. Since it was never a consideration before, if regions were CPU-locked, do the simulators support threading like this? Or is the current phase of this project simply limited to decreasing resource consumption on idle regions? 2) What is the reduced framerate for idle servers? Default is 45 frames per second, how low does an idle server go? Lowering the framerate will affect scripts (as I mention below) but without knowing the new framerate, we can't determine what will need modification. On the same vein, when frame rate is reduced, is frame time preserved at 0.022-ish seconds, or is it increased proportionally? 3) To be more specific about people's breedables question, as it effects other scripts. How does llSetTimerEvent() handle lower framerate? Does a timer of 0.5 seconds try to execute every half-second, or does it try to execute every 22-ish frames? This answer seems obvious, I just want to be sure. 4) I duplicate the previous question of "how will object keyframing be affected?" There may also be other functions that are framerate dependant. Did LL test these, and knows how they'll behave? Does it at least have a list so content creators can check their scripts? (Some answer is preferably to no answer, even if the answer is "no, you'll have to do that yourself.") To answer people's questions about breedables (to the best of my knowledge), the short answer is: there shouldn't be any problems. They won't even notice that your region is idle. The long answer is: unless they are poorly scripted and call the timer() event more often than the framerate supports, you should see no reduction in performance. That is, if framerate is lowered from 45 to 20 (or 10, or even 5), and the timer event is set for 0.5 seconds, you shouldn't see any notable change in behavior to your breedables while the region is idle. However, if the timer is set for 0.1 seconds, and framerate goes below 10, you would start seeing events getting queued (eg, the script would lag and fall behind). That is an extreme situation, and I don't expect it will occur during region idle. Unless the breedable is poorly scripted, like I said, in which case you'll want to contract the creator and ask them to improve performance.

When creating a base skeleton to work with, if you change the avatar out of the standard t-pose, then standard animations will not work as expected with it. This is fine and normal, especially for a quadruped skeleton that won't be using standard animations anyway. But if you have a bipedal avatar, and you make the arms down at the side, instead of out in a t-pose, all of the traditional animations you try to play on it you'll find that the arms are "lowered" out of the t-pose, and end up sticking through the body itself, as the arms were already lowered in the basic stance. I suspect that the problem you had with Jacek's exporter was that when you repositioned the skeleton to follow your quarduped stance you did so in pose mode, rather than edit mode. In edit mode, you would be repositioning the source of the bones, rather than simply animating them. If that isn't the case, it's possible Jacek's exporter expects a few values that you changed in edit mode, and ignored the changes you made, using some internal values in the scripts. Edit: I am informed that edit mode was used. It's possible that IKs were in place and were not "baked out," though I suspect Jacek's exporter doesn't require this. So it might just be that Jacek's exporter doesn't support altering the skeleton. Might be best to contact her about it.

Even if there's no transparency present, if you save the file out as a 32-bit TGA, or a PNG with transparency, or another format that's explicitly supporting transparency, Second Life considers that as a transparent texture. Try saving the texture out as a format that doesn't support transparency, such as a 24-bit TGA or a JPG.

You say that 1.23-based search will be inpaired when this becomes the official search method. Please defined "impaired." Will 1.23-based search simply receive no updates and if it breaks will not be fixed? Will it be taken down so search in 1.23 will simply not work? Feedback: Searching Everything for "Stickman" returns a fairly new alt account of mine, Stickman Resident, followed by some relevant results. To avoid confusion, the account name is "Stickman" and I have set the display name to "Stickman Resident." I stop seeing immediately visible relevance at "Aurican's Pyramid Store," the the seventh result. But it might be that the parcel is owned by a person or group with Stickman in the name. The user account "Stickman Ingmann," which is what caused results 3, 4, and 5 to show up, is not listed on the first page. The owner of the sixth result, Stickman Stilman, also doesn't show up. I'm guessing that only one user account is shown in the Everything search and then a couple groups, and then the rest is a dump of places. I would argue that this isn't the best method and that how many results of each type are shown should be weighted based on the relevance of the results. To find more relevant user accounts, you will likely want to have more statistics you can pull from. Someone who logs in a lot, owns land with more picks to it, changes their profile often, etc, will more likely be a relevant search result than a close name match.