Simulator User Group/Transcripts/2011.09.02

From Second Life Wiki
Jump to: navigation, search

Simulator_User_Group

Prev 2011.09.02 Next 2011.09.06

List of Speakers

Andrew Linden DogWomble Dollinger Fancy Greeter
Flip Idlemind Kadah Coba Kallista Destiny
Kaluura Boa Kelly Linden Leonel Iceghost
Liisa Runo Lomgren Smalls Motor Loon
Moundsa Mayo Pauline Darkfury Renae Daines
Rex Cronon Sahkolihaa Contepomi Simon Linden
Stickman Thord Karu

Transcript

[16:01] Flip Idlemind: My avatar is a little bit hyper today

[16:02] Sahkolihaa Contepomi: Hey Andrew.

[16:02] Motor Loon: You cansit on my lap Kelly...

[16:02] Stickman: Lomgren would need like 64 bytes. He's an icon.

[16:02] Stickman: Hi Andrew!

[16:02] Lomgren Smalls: Haha

[16:02] Andrew Linden: Hello everyone.

[16:02] Rex Cronon: hello everybody

[16:03] Renae Daines: Hello

[16:03] Rex Cronon: hi

[16:03] Flip Idlemind: What's it like in the future?

[16:03] Sahkolihaa Contepomi: Boring.

[16:03] Pauline Darkfury: hi folks :)

[16:03] Motor Loon: 1am here

[16:03] Motor Loon: pretty dark

[16:03] Kallista Destiny: Hi Andrew

[16:03] Andrew Linden: I didn't have a very productive week, so not much to report (at least for news of progress).

[16:03] Rex Cronon: wassup:)

[16:04] Kallista Destiny: Motor <CTRL+SHIFT+Y>

[16:04] Motor Loon: I tried it... dont work in RL Kallista

[16:04] Andrew Linden: I ran spent a bunch of time learning about autobuild, and wondering how to migrate our server dev environment over to that and VS2010.

[16:05] Kallista Destiny: Alwasy fun finding more warts in build.

[16:05] Rex Cronon: learning new things is called being productive:)

[16:05] Andrew Linden: I put aditi Morris up on my LSL optimization project yesterday, and I think Oskar and Maestro mentioned it in their User Group.

[16:06] Kallista Destiny: Sometimes it's cll ...flaceplant

[16:06] Andrew Linden: I still haven't received any feedback on any benchmarks.

[16:06] Rex Cronon: testing must be still going on

[16:07] Andrew Linden: As I mentioned before, I ran a few tests and they were all faster on the new code, but it ranged a lot.

[16:07] Flip Idlemind: Maybe now that it's on Morris, instead of the almost-empty sandboxes it was on, since as I understand it, the benefits come when there are lots of prims in the sim

[16:07] Tim Hortons coffee- double double eh? whispers: Yummm a Canadian favourite, eh?

[16:08] Tim Hortons coffee- double double eh? whispers: Yummm a Canadian favourite, eh?

[16:08] Andrew Linden: I guess I'll try to find the time to run some benchmarks for myself before it ships.

[16:08] Tim Hortons coffee- double double eh? whispers: Yummm a Canadian favourite, eh?

[16:08] Tim Hortons coffee- double double eh? whispers: Yummm a Canadian favourite, eh?

[16:08] Andrew Linden: ok that's all the news I've got. Got anything Simon and Kelly?

[16:09] Kelly Linden: I don't have anything.

[16:09] Simon Linden: I don't have much

[16:09] Simon Linden: I have some performance work in the pipeline, but it won't see the grid for a week or two

[16:09] Motor Loon: which kind of performance?

[16:11] Simon Linden: Better balancing between regions and other processes on the servers

[16:11] Lomgren Smalls: That sounds promising

[16:11] Renae Daines: Simon, would this be related to SVC-6972 or SVC-6689 in anyway?

[16:11] JIRA-helper: http://jira.secondlife.com/browse/SVC-6972

[#SVC-6972] Server Lag every one or 2 hours for 5 minutes

[16:11] JIRA-helper: http://jira.secondlife.com/browse/SVC-6689

[#SVC-6689] Sims Perfomance Substandard due to "TIMEWARP"

[16:11] Simon Linden: It's somewhat experimental ... it will ship with it off, and I'll be able to try a few tests and see what happens on real servers

[16:12] Motor Loon: coolness

[16:12] Motor Loon: How are we on mesh pivots?

[16:13] Andrew Linden: Don Linden is working on the TIMEWARP issue. Sounds like the way to move forward on that is to update the linux kernel.

[16:13] Andrew Linden: Which means we really should just upgrade to a later version of debian

[16:13] Sahkolihaa Contepomi: Heh...

[16:14] Flip Idlemind: What is it now? Still "Etch"?

[16:14] Renae Daines: Ah, okay - is there a time frame for that to happen? Would you mind if I passed you a notecard with a bit of information Andrew? TJ mentioned it was an outstanding server side problem - interesting to know it's kernel issue

[16:14] Simon Linden: DOS 6.2

[16:14] Sahkolihaa Contepomi: Oh dear god no.

[16:14] Liisa Runo: Sorry to spam this. But i need to know if this is getting attention? SCR-90 Yesterday at Oskar's OH Maestro said that he is not looking at it, and suggested Kelly. And Earlier Kelly told to hand it over to Maestro. This is currently badly bugged in all server versions, and we dont have workaround.

[16:14] JIRA-helper: http://jira.secondlife.com/browse/SCR-90

[#SCR-90] llGetBoundingBox() returns wrong values on Magnum RC

[16:14] Leonel Iceghost: Simon, how does the system put region in servers? I think you said you try to put two bussy sims together.. what do you take to tell they are "bussy", script lag, physic lag, http ussage, fps?

[16:14] DogWomble Dollinger: DOS 6,2 using Windows for Playgroups 3.11 for multitasking? :P

[16:14] Kallista Destiny: OS 360 rel 21.7

[16:15] Andrew Linden: Yeah, Etch. But upgrading to Lenny is related to geting our server code building with autobuild.

[16:15] Pauline Darkfury: llGetBoundingBox was broken then fixed ages ago, wasn't it? Or has it broken again?

[16:15] Simon Linden: It's pretty brain-dead at this point, Leonel. That's one project we've talked about towork on

[16:15] Flip Idlemind: I remember when it changed to Etch...it was shortly after I joined .()

[16:15] Flip Idlemind: Back when I wasn't even really sure what a "rolling restart" was

[16:15] Simon Linden: There are two interesting factors ... region crossings are easier within the same host, server rack or colocation

[16:15] Liisa Runo: Broken again, and even worse than earlier, i reopened the JIRA. look at my comment there

[16:16] Simon Linden: The other is balancing busy vs empty regions

[16:16] Kallista Destiny: That would make sense, lets tiem to xfer the data

[16:16] Leonel Iceghost: and how do you tell they are busy, sim fps? what are the factors

[16:17] Kallista Destiny: AVAtr count I/O processor load...

[16:17] Fancy Greeter: Gez Linden has arrived!

[16:17] Stickman: How many colos does the grid use?

[16:17] Leonel Iceghost: if you can share a bit more detail..

[16:17] Pauline Darkfury: ahh, yeah, that does sound bad, Liisa

[16:18] Simon Linden: We'd probably look at the sim fps or number of AVs on a host to rank how busy they are ... I'm not sure, and we'd certainly want to do something that isn't too easy to game

[16:19] Pauline Darkfury: Maybe a*(sum of traffic on all parcels) + (script count), Simon

[16:20] Leonel Iceghost: the problem is, some sims are empty because they want to be fast.. if they got 30 avatars to play a game.. will sharing it with a "busy sim" affect the first light one?

[16:20] Simon Linden: yeah, we'd have to figure something out ... but don't want a situation where people would have camping bots or extra scripts to be considered 'busy' and thus get low-load sims on the same server

[16:20] Leonel Iceghost: say the sim is empty 23 of 24 hours a day, and only 1 hour with people playing

[16:21] Simon Linden: That's another factor

[16:21] Pauline Darkfury: well, the camp bots are already against ToS, so ban them (and the people abusing the system with them)

[16:21] Simon Linden: At this point, however, it's all ideas being tossed about casually, there isn't a solid project to work on it yet

[16:21] Pauline Darkfury: could base it on network traffic stats

[16:21] Kallista Destiny: I'd say Average rrocessor load over the day would be a good indicator

[16:22] Simon Linden: Right, there are a lot of numbers we could look iat

[16:22] Simon Linden: look at

[16:22] Pauline Darkfury: network traffic stats are very opaque to us, would be fairly hard to game them

[16:22] Pauline Darkfury: best is probably several factors weighted, then tune the weights once you see how it goes

[16:22] Leonel Iceghost: Simon what I would like, is you not to take average day to do the "busy", if the sim is used for a couple hours a day

[16:23] Pauline Darkfury: so a*traffic + b*scripts + c*cpu + d*disk + e*network

[16:23] Leonel Iceghost: Average is bad, for sims that are well tunned to be light, so they can hold a good game

[16:23] Simon Linden: + random fudge factor

[16:23] DogWomble Dollinger: perhaps by hour then?

[16:23] Pauline Darkfury: those sims already can't choose what is on the same host, Leonel

[16:23] DogWomble Dollinger: that could be a good balance between leonels situation and not overdoing it the other way

[16:24] Leonel Iceghost shouts: Pauline now it is random, in the future it will not...

[16:24] Leonel Iceghost: sorry

[16:24] Leonel Iceghost: didn't want to shout lol

[16:24] Rex Cronon: the less prims/scripts/texture a sim has the faster should run. right?

[16:24] Pauline Darkfury: lol, np

[16:24] Kallista Destiny: Does each region have it's own Linux instance?

[16:24] Pauline Darkfury: sims don't have textures, that's mostly a viewer lag factor, not sim

[16:25] Sahkolihaa Contepomi: Well.

[16:25] Rex Cronon: from what i understood sim stores textures

[16:25] Sahkolihaa Contepomi: 1.x viewers still access textures through the sim, don't they?

[16:25] Kallista Destiny: Well simes and textures that thy load to the client

[16:25] Renae Daines: Is there any way we can request our regions to be moved to a server not experiencing this "Timewarp" issue? Personally I've see those 5 minute dead-zones in performance up to 3-4 times an hour.

[16:25] Pauline Darkfury: yeah, but we're talking about server load balancing

[16:26] Kadah Coba: We'll just end up with bots that create real load to simulate user to game the system, which would be wrose

[16:26] Kadah Coba: Worse even

[16:26] Simon Linden: Right, textures now can be downloaded 2 ways, from the simulator itself or via http from a web server

[16:26] Rex Cronon: how about temp textures?

[16:26] Kadah Coba: Only 1.23 uses UDP textures, 1.5 uses http

[16:27] Pauline Darkfury: The sim texture thing while a nice thing to offload isn't really a major load factor, is it?

[16:27] Rex Cronon: the temp ones r used for clothes/skin

[16:27] Kadah Coba: Phoenix has it disabled by default cause it causes issues for most users

[16:27] Flip Idlemind: But it's optional, and some third party viewers default to using UDP

[16:27] Pauline Darkfury: And very soon, most viewers should be HTTP texture capable

[16:27] Kadah Coba: Most already are

[16:28] Kallista Destiny: Kadah, I never had any poblmes with it.

[16:28] Simon Linden: I've had mixed results with it ... at times it seems to cause some bad viewer lags, where it stops and goes black for 5-10 seconds

[16:28] Andrew Linden: Apparently the viewer's HTTP download pipeline has a lot of bugs. I just got a glimps of the extent.

[16:28] Simon Linden: I think there's a bug in there where some operation blocks

[16:28] Kadah Coba: A lot of times it depends on the ISP and the connection

[16:29] Andrew Linden: some of it is documented in http://jira.phoenixviewer.com/browse/PHOE-2707

[16:29] Andrew Linden: i have yet to read all of the comments there

[16:29] Kallista Destiny: but look at the discussion on SH-744

[16:29] Kadah Coba: Some ISPs dont like the massive number of connections that viewer2 uses, and a few dont like the use of http over non-standard ports

[16:29] Andrew Linden: but I might be pulled into that project soon to see if we can salvage that system

[16:29] Kallista Destiny: There have been people that cured it by changing routers.

[16:30] Andrew Linden: not all of the problems are the routers' fault

[16:30] Meeter: Timecheck : User Group is half over

[16:30] Kallista Destiny: nope, but it is one part of the picture...

[16:30] Kadah Coba: For starts 300+ active connections would be an issue :P

[16:30] DogWomble Dollinger: yeah, some consumer level routers only have small memory allocations for keeping track of open connections ... if that fills up, you tend to get problems

[16:30] Pauline Darkfury: Yeah, it's far from unheard of for cheap/basic routers to choke on too many NAT or firewall table entries

[16:30] Andrew Linden: Or so I've been told. I have yet to fully understand it all.

[16:31] Kallista Destiny: It's complex, to say the least

[16:31] Rex Cronon: maybe we don't need so many open connections?

[16:31] Simon Linden: yeah, Monty has been looking at some of that. I debugged the bad pauses I saw with it stuck in one of the aprs library functions, I think

[16:31] Pauline Darkfury: Some routers also have small memory leaks on that stuff, so a high sustained rate will cause them to choke even if the instantaneous rate fits into memory

[16:31] Simon Linden: Yes Rex, that's one of the complaints ... it's not playing nicely with the system and making too many simultaeous requests

[16:32] Pauline Darkfury: The number of parallel requests should be tunable, with a default that is generally ok for most current tech

[16:32] Rex Cronon: something like a connection manager that uses only a few connections

[16:32] Leonel Iceghost: that's a good idea Pauline

[16:32] Leonel Iceghost: like P2P clients

[16:33] Rex Cronon: all requests go through it

[16:33] Simon Linden: yeah, and there are too many different systems making requests

[16:33] Leonel Iceghost: going back to the load balance, say you have a perfect sim 22ms spare time to do snail races.. and it gets a server with a sim with 50 avatars 24/24hs a day dancing... at the moment you want to make a race with 20 participants it is going to be laggy isn't it?

[16:35] Leonel Iceghost: right now it is random, and if you are lucky you get your light sim.. but if I undestand it well.. in the future no mather what you do to keep it light, it will get problems from other sims

[16:35] Andrew Linden: I think the answer there is "yes sometimes, but yes eventually for any such collision"

[16:35] Renae Daines: Andrew (or anyone) - not trying to beat a dead horse. As fas Timewarp is concerned. Is there a work-around? Changing hosts, servers, etc. Anything we can do to get rid of this problem? 5 minute drops in performance (causing 0 ability to get into or out) is a little unsettling. Especially with the costs.

[16:35] DogWomble Dollinger: and i think some real world testing is warranted to work out how much of a problem it becomes

[16:35] Andrew Linden: that is, it depends on what the regions are doing at any second, but eventually the very busy sim is going to block something that the other sim process needs

[16:37] Andrew Linden: the hosts typically have plenty of memory but can block on file I/O sometimes

[16:37] Renae Daines: So what's the cause of it being 5 minutes each and every time?

[16:38] Andrew Linden: I believe that a kernel upgrade will reduce the problem, but we also have some file I/O stuff to clean up

[16:38] Simon Linden: Renae - I don't konw of any solutions right now for that 5-minute slowdown problem

[16:38] Andrew Linden: in particular during region crossings and maybe object rez

[16:39] Renae Daines: Last question I have regarding that is - is there an ETA to this fix? (This seemed to crop up more prominently in the last 3 months)

[16:39] Leonel Iceghost: and Simon, I don't think there is a way you can prevent gamming the system :P if I pay 350 dolars a month to play an hour with friends, they'll not care fill the sim with lag while they are not present the rest of the day

[16:39] Andrew Linden: the 5-minute slowdown problem... I don't know what is causing it, but if we were able to dig into the logs for particular events I'm confident we'd find some smoke for that fire.

[16:39] Renae Daines: Would you like a log of events I have Andrew? No idea if it is helpful, but it's pretty evident on what times it is happening (at least on my region)

[16:39] Pauline Darkfury: I don't really think there should be too many cases where it's vastly worse, tbh. Right now, you could end up being 1 light sim sharing with 3 heavy (C5), or 1 light sharing with 6 heavy (C7).

[16:40] Andrew Linden: no ETA for a progress on that. I think the first improvement would be complete the kernel upgrade.

[16:40] Pauline Darkfury: If this works out, hopefully the heavy sims will be more evenly spread across all servers, so you're going to be very unlikely to land on a host that has multiple very heavy sims on it

[16:40] Andrew Linden: So I think we should be working on that first. Which depends on the autobuild conversion.

[16:40] Renae Daines: I appreciate the response

[16:42] Simon Linden: I know a couple of people have looked at that 5 minute problem ... it's a strange one, because like you say, it's usually pretty easy to look at the logs or perfomance tools and find something that is bad

[16:42] Andrew Linden: There is at least one feature that we were thinking about working on that depends on some upgraded third party libs, and that also depens on getting things working under autobuild

[16:43] Andrew Linden: so the needs are starting to align on that issue

[16:44] Andrew Linden: I think we're going to have a little hackathon on automated tests for part of next week, but the week after that I'll probably be doing some autobuild wrangling

[16:45] Kallista Destiny: llCastRay() since this is supposed to be ,per Falcon, the solution to SVC-5927 when will it be up on the main grid?

[16:46] JIRA-helper: http://jira.secondlife.com/browse/SVC-5927

[#SVC-5927] Temp on Rezzed objects get queued

[16:46] Kelly Linden: It is part of "DRTSIM-92" which is on Aditi now and will *not* be in RC next week.

[16:47] Kallista Destiny: :(

[16:47] Kelly Linden: "DRTSIM-92" is the next server maintenance

[16:47] Andrew Linden: are we deploying anything new next week? or is there a "no change window" (NCW) ?

[16:48] Simon Linden: I believe we're still rolling new code on Tuesday and Wednesday

[16:48] Rex Cronon: btw. i am a little curious. how many people have used: llRezObject(string inventory, vector pos, vector vel, rotation rot, integer param)?

[16:48] Kelly Linden: I have.

[16:49] Motor Loon: Ditto

[16:49] Pauline Darkfury: That's pretty widely used, Rex

[16:49] Simon Linden: I _think_ the code in Bluesteel now is getting promoted to the main grid

[16:49] Liisa Runo: everybody?

[16:49] Rex Cronon: and how many have been frustrated with the inability of sending even a 128 letter initialization string:)

[16:49] Thord Karu: @Andrew. Is rayCasting really the fix for SVC 5927?

[16:49] Kallista Destiny: Most peoplethat script anyway

[16:49] Leonel Iceghost: me me me

[16:49] Kallista Destiny: that is what Param is a 32 bint nmber

[16:49] Pauline Darkfury: You send the param, then you use that to establish a chat channel for details

[16:50] Rex Cronon: 32 bit. lol. so short:)

[16:50] Kallista Destiny: That works too

[16:50] Kelly Linden: or these days you could do llRegionSayTo from the object_rez event.

[16:50] Leonel Iceghost: 32 bits int and chat is frustrating

[16:50] Moundsa Mayo: Or use hex coded nibbles and lookup tables.

[16:50] Motor Loon: use the params to tell it a listen channel, and tell it the rest thru that

[16:50] Rex Cronon: i know how to do it pauline but is hack:)

[16:50] Flip Idlemind: It

[16:50] Flip Idlemind: is possible that...

[16:50] Kelly Linden: 32 bits is whatcha get. :)

[16:50] Simon Linden: llCastRay() is an alternative to rezzing projectiles, it's not going to fix that queuing, from what I know

[16:51] Flip Idlemind: the object_rez event in the rezzing object could trigger before the rezzed object is ready to listen

[16:51] Leonel Iceghost: Kelly, that would be calling for bugs, you never know when the other scripts are reseted, initialized, or anything

[16:51] Andrew Linden: Thord, Falcon Linden believes that llCastRay() is the solution. I am not convinced.

[16:51] Flip Idlemind: So the rezzed object has to say "ready" first

[16:51] Pauline Darkfury: Alternately, you could use the param to set a PIN, then spam scripts at it ;)

[16:51] Kelly Linden: lots of ways.

[16:51] Rex Cronon: we really need a initialization string on rezzing. even if is 128 chars:)

[16:52] Andrew Linden: I suspect there is some broken logic that is making SVC5927 worse than it needs to be and we should fix it.

[16:52] Simon Linden: That's a good point, Flip ... if you ever need an object immediately, the best way is to pre-rez it and hide it somewhere until you need and move it

[16:52] Liisa Runo: sure would make stff less complex if we could give it a string

[16:52] Kadah Coba: llCastRay is instant, it doesnt simulate time like a physical object would

[16:52] Andrew Linden: Also, I don't think llCastRay() is going to work for all projectile applications. Some people are going to want to rez lots of bullets.

[16:52] Pauline Darkfury: If you need the object to only "appear" after the init string, have it phantom + 100% transparent in the copy in inventory, then appear after the string has been received

[16:52] Kallista Destiny: Most of use that have looked at the problem are quite unconvinced but we can't even demonstrate it under real world condition w/o llCastRay() and a reall properly loaded region.

[16:53] Thord Karu: ray casting a great feature, exactly SImon! But it will not work for all combat. First it doesnt handle region crossing and secondly for combat where you use arrows are some sort where they are somewhat slow, the ray cast trottling would regquire even more calls.

[16:53] Simon Linden: I agree ... I think it's going to be very useful and faster in some cases, but not everything

[16:53] Andrew Linden: btw, Kelly has a fix for SVC-34 somewhere in the works.

[16:53] JIRA-helper: http://jira.secondlife.com/browse/SVC-34

[#SVC-34] Right-clicking another Resident's moving object freezes it

[16:53] Pauline Darkfury: Yeah, I agree with that, Andrew. llCastRay is a nice new feature, but there's still going to be cases where flying prims are desirable for one reason or another

[16:53] Simon Linden: and in some cases you definitely want ballistic motion

[16:53] Kelly Linden: That is in "DRTSIM-92" andrew.

[16:54] Rex Cronon: ray casting is nice, but as andrew said not everybody wants only that

[16:54] Andrew Linden: excellent

[16:54] Simon Linden: My old bear cannon would be useless using llCastRay

[16:54] Thord Karu: I dont think it is making it worse. But SVC 5927 has been open for over a year, and from what I gather this throttle was put in to combat against griefing?

[16:54] Kadah Coba: Fix how?

[16:54] Liisa Runo: llCastRay dont relly matter in this rez param string conversation, bullets are not the only thing we rez in SL

[16:55] Meeter: Timecheck : User Group is almost over

[16:55] Rex Cronon: i support what liisa said:)

[16:55] Leonel Iceghost: that's right, when I wanted to buy a house I found the problem there too, had to come back at night

[16:55] Pauline Darkfury: People with laser guns will like llCastRay, but want visual FX for it ;)

[16:56] Flip Idlemind: I agree with all that too, however it would require a replacement for llRezObject and a replacement for on_rez()

[16:56] Flip Idlemind: I imagine

[16:56] Andrew Linden: Thord, it was implemented to prevent the physics engine from being the source of terrible simulator FPS.

[16:56] Rex Cronon: no replacement. just add a new parameter.

[16:56] Kallista Destiny: Oh Andrew, Thord is one the preimer weapons makers in Sl Gor.

[16:56] Andrew Linden: Which solves one problem, but introduces another... laggy/bursty object movement.

[16:57] Pauline Darkfury: Can't add params to existing stuff

[16:57] Pauline Darkfury: Have to add alternate new functions

[16:58] Kallista Destiny: Well some functions work on lists, those you just expand... (llSetPrimitivePqarams() comes to mind)

[16:58] Rex Cronon: if u add a parameter it becomes a new function:)

[16:58] Pauline Darkfury: Yeah, lists like the llSet/GetPrimParams can have new features

[16:58] Leonel Iceghost: then add an event, rezzed( key id_object_rezzed ) to send llRegionSayTo :P

[16:58] Motor Loon: any timeline on ability to script the physic-shape settings on a mesh?

[16:59] Kelly Linden: leonel that is the object_rez(key id) event we already have?

[16:59] Andrew Linden: No timeline on that. The potential lag consequences of such a feature push it way out into the future.

[16:59] Kaluura Boa: That will come with prim_slice... in 2050...

[16:59] Kelly Linden: Motor: Also in DRTSIM-92

[16:59] Motor Loon: wonderbar Kelly

[16:59] Kelly Linden: prim slice is not in DRTSIM-92

[16:59] Kelly Linden: and oh my look at the time. ;)

[16:59] Kaluura Boa: I was talking about physics settings on meshes

[16:59] Thord Karu: yea I dont know if you recall Andrew we tested the new server with you when it was first released. And I completly agree and see LIndens point about protecting the physics engine. If that is the case has lindens thought about givin sim owners the options for these throttles?

[16:59] Motor Loon: prim slice?

[17:00] Motor Loon: oh nvm... i know what you are talking about

[17:00] Meeter: Thank you for coming to the Server User Group

[17:00] DogWomble Dollinger: motor it's where you make a slicable watermelon prim, and give a slice to torley

[17:00] Liisa Runo: So, it seems my llGetBoundingBox question got ignored. Should i just edit the LSL wiki and mention that nowdays some shapes dont give very accurate values so it is ok to expect the values returned to have only +- 32.5 Kilometer accuracy.

[17:00] Leonel Iceghost: Kelly, oh sorry then, I didn't use that at the time because I had to llSleep for two secs to be realliable, and forgot about that event, and its arguments

[17:00] Andrew Linden: Oh right, I forgot one aspect Thord... the throttle on that also protects the whole host.

[17:00] Renae Daines: Thank you Andrew, Kelly, and Simon

[17:01] Thord Karu: so yea that wouldnt work giving sim owners control than

[17:01] Thord Karu: then

[17:01] Simon Linden: Liisa - I forget the details, but I know we discussed that one recently at our bug triage. It's more complicated than it seems

[17:01] Andrew Linden: There is a lag mode where one simulator can lag the entire host ... the "busy host neighbors" problem.

[17:01] Kallista Destiny: Andrew, I donlt see how havin one region on a server in hiccuough mode protetects the other regions.

[17:01] Motor Loon: Torley never just eats a slice Dog... he eats the whole melon

[17:01] Andrew Linden: And that throttle protects the host from such very bad lag events.

[17:01] DogWomble Dollinger whispers: true motor :)

[17:02] Kelly Linden: Have a good weekend all

[17:02] Kelly Linden: o/

[17:02] Motor Loon: u2

[17:02] Moundsa Mayo: Andrew, Simon, Kelly, thanks for your time!

[17:02] Sahkolihaa Contepomi: You too Kelly, Simon & Andrew.

[17:02] DogWomble Dollinger: catch ya round kelly

[17:02] Andrew Linden: That said... I suspect there may be a way to smooth out the throttle while still protecting the host.

[17:02] Thord Karu: well I am not saying combat is the life line of sl we all know that isnt true, but there is a stong contigent in sl that comes here just for combat, how about splitting them up

[17:02] Rex Cronon: tc kelly

[17:02] Liisa Runo: ok, good to know you discussed about it. Hopefully it get fixed some day. 32.%Kilometers is quite big bug

[17:02] Pauline Darkfury: Thanks, Lindens

[17:02] Pauline Darkfury: Have a good weekend :)

[17:02] Kallista Destiny: Oh? havein the affected region fluctuting between .01 FPS and 45 FPS is good for the rest of the regions?

[17:02] Andrew Linden: I need to take the time to dig into it.

[17:02] Simon Linden: Thanks everyone for coming and the good discussion

[17:03] Andrew Linden: But at least I would be willing to look (if I could fit it in).

[17:03] Andrew Linden: Cheers everyone. Have a good weekend.

[17:03] Thord Karu: bah

[17:03] Rex Cronon: tc andrew, simon

[17:03] Leonel Iceghost: a friend filed this for me, if you want to vote https://jira.secondlife.com/browse/SCR-184

[17:03] JIRA-helper: [#SCR-184] llMessageLinkedTo( "script name"...

[17:03] Kallista Destiny: Thanks andrew Kelly et all

[17:03] Thord Karu: thanks have a good labor day

[17:03] Rex Cronon: tc everybody. and ahve a nice day

[17:04] Simon Linden: right, I guess we'll meet again after 3 or 4 hours of work



Simulator_User_Group

Prev 2011.09.02 Next 2011.09.06