Simulator User Group/Transcripts/2011.09.13
| Prev 2011.09.09 | Next 2011.09.16 |
List of Speakers
| Andrew Linden | Ann Otoole | Arawn Spitteler |
| Helena Lycia | Imaze Rhiano | Kadah Coba |
| Kallista Destiny | Kelly Linden | Leonel Iceghost |
| Liisa Runo | Motor Loon | Moy Loon |
| NeoBokrug Elytis | Pauline Darkfury | Renae Daines |
| Rex Cronon | Sahkolihaa Contepomi | Simon Linden |
| Stickman Ingmann | TankMaster Finesmith | Thex Lecker |
| Vincent Nacon |
Transcript
[12:00] Sahkolihaa Contepomi: And hey Andrew, too.
[12:00] Motor Loon: and Andrew
[12:00] Helena Lycia: Hello Lindens *smiles*
[12:00] Simon Linden: Hello peoples, critters and sentient objects
[12:00] Meeter: Welcome to the Server User Group
[12:00] Motor Loon: damn Andrew... those clothes gotta go in the washer too?
[12:00] Sahkolihaa Contepomi: And kelly, heh.
[12:01] Renae Daines: Hello there Andrew, Kelly, and Simon
[12:01] Pauline Darkfury: Hi folks :)
[12:01] Motor Loon: Yes, and welcome to my meeting - today we're going to talk about what presents I should get for my birthsday
[12:02] Moy Loon: Hour ban, so you can spend an hour with your family ;)
[12:02] Motor Loon: thats like a punishment if you knew my family
[12:02] Andrew Linden: Lol
[12:02] Liisa Runo: Kelly always give new LSL functions when someone has BD
[12:03] Motor Loon: oooh... it's my birthsday EVERYDAY
[12:03] Sahkolihaa Contepomi: That must cost a lot for your friends and family.
[12:03] Motor Loon: coz' I'm da' king - and I said so
[12:03] Rex Cronon: hello everybody
[12:03] Motor Loon: ey Rex
[12:03] Andrew Linden: Ok news...
[12:03] Rex Cronon: hi motor
[12:03] Helena Lycia: Hiya Rex
[12:03] Motor Loon: good news?
[12:04] Rex Cronon: hi helena
[12:04] Andrew Linden: At the end of last week I was working on some uninteresting unit tests.
[12:04] Motor Loon: err
[12:04] Helena Lycia: Are there interesting unit tests?
[12:04] Andrew Linden: Those are all done, and I copied some viewer-side unit tests for llsdutil to the server... yay!
[12:04] Rex Cronon: thanks vga
[12:05] Motor Loon: llsdutil?
[12:05] Andrew Linden: Since then I've just been doing some code cleanup... sometimes it just has to be done.
[12:05] Andrew Linden: llsduitil is a section of our C++ code, used by server and viewer
[12:05] Motor Loon: code cleanup is always good
[12:05] Andrew Linden: a few people here may have fought with it
[12:06] Andrew Linden: Yeah, code cleanup is good, but not very interesting.
[12:06] Kadah Coba: Clean code = good, no complaints here
[12:07] Andrew Linden: I've got a little project on my plate to log occurrences of "cache miss"
[12:07] Rex Cronon: every hourt u should take a break and drink a coffee:)
[12:07] Andrew Linden: which referes to uncached UDP updates for static objects (geometry and position)
[12:07] Motor Loon: cache miss?
[12:07] Motor Loon: aha... how does that show?
[12:08] Andrew Linden: someone on our side was interested in seeing when that is happening, so I get to write the logs for it
[12:08] Motor Loon: stuff going invisible until you click it?
[12:08] Motor Loon: coz I've seen that alot
[12:08] Rex Cronon: is that the related to the drift of objects?
[12:08] Andrew Linden: and if I have to do that... I might as well clean up some code while I'm at it.
[12:08] Andrew Linden: Unfortunately, cache misses are expected... espectially for someone showing up in a region where they've never been, or haven't been in a while.
[12:09] Andrew Linden: So... how to filter the expected cache misses from the unexpected?
[12:09] Andrew Linden: I dunno the answer to that question yet... still looking.
[12:09] Renae Daines: log the last occurance in that region by the avatar?
[12:09] Motor Loon: why would there be "ok" misses?
[12:09] Andrew Linden: No Rex, it isn't related to object drift.
[12:10] Andrew Linden: Well, this is how the "interest list" (IL) system works, which is the code on the server which figures out what needs to be sent to the viewer
[12:11] Andrew Linden: (this info is useful to anyone hacking 3rd party viewers and who want to make sure their "object cache" system is working right)
[12:11] Kelly Linden: not everything is in the cache all the time. A 'miss' just means you need to go to the source to get fresh data. (talking in a general sense about caches). A cache miss isn't bad by itself, but if you get too many of them it is slower and you probably want to rethink how, what and when you are caching.
[12:11] Andrew Linden: The official viewer should be caching things correctly, so if your 3rd party viewer hasn't messed up that bit of code then it should be working too.
[12:11] TankMaster Finesmith: if a texture has never been requewsted, it wouldnt be cached, andtherefor a lookup in the cache would miss
[12:11] Andrew Linden: However, the official viewer-side cache has broken in the past and we did not know it for a while.
[12:12] Andrew Linden: So we're intrested in being able to tell when it is broken faster.
[12:12] Kallista Destiny: Fore which value of Official viewer?
[12:12] Andrew Linden: Anyway... this is how it works...
[12:12] Renae Daines: Which would also help alleviate a bit of load off the region i imagine?
[12:12] Andrew Linden: When the avatar arrives in the region...
[12:12] Motor Loon: so if the viewer is doing it correctly... what are you trying to fix?!
[12:13] Kallista Destiny: that is it was broken for 2.1 to 2.6 or what are the limits?
[12:13] Andrew Linden: each object has some position + geometry data that is required for the viewer to render it
[12:13] Thex Lecker: if object is not cached and object's last mod time < avatar's last interest time at object position then a cache miss.
[12:13] Kallista Destiny: plus the graphical informtion
[12:13] Andrew Linden: for each object the data is prepackaged into a buffer, and given a version number
[12:13] TankMaster Finesmith: LL updated the viewer side cache a month ago or so, uped the max to 10GB
[12:14] TankMaster Finesmith: and improved the code
[12:14] Andrew Linden: geometry data encompasses the "graphical info" in my description here
[12:14] Andrew Linden: so the simulator figures out what is in the avatar's view and sends a list of [local_id : version_number] pairs in a series of packets
[12:15] Andrew Linden: the "version number" in the code is actually called a "CRC" but is really a version number
[12:15] Vincent Nacon: starting from the nearest and out first?
[12:15] TankMaster Finesmith: so not for Cycle Redundency Ceck :P
[12:16] Moy Loon: That is what he just said..
[12:16] Andrew Linden: yeah, it isn't really a measure of what is inside the data, like a real Cycle Redundency Check, but is just incremmented when the data changes
[12:16] Andrew Linden: anyway, the veiwer gets a list of [local_id : version_number] pairs and looks them up in its region_id.objects cache file
[12:17] Andrew Linden: if the version_number is different, or if the local_id is not known, then it sends back a CacheMiss UDP packet back to the simulator, listing all the local_id's for which it doesn't know anything about
[12:18] Andrew Linden: hence cache misses are expected when all the data is new
[12:18] Rex Cronon: what happens if CacheMiss packet goes missing?
[12:18] NeoBokrug Elytis: How would that affect non-physical objects that make a lot of positional updates?
[12:18] Ann Otoole: go shopping for land on all mainland for an example :P
[12:18] Andrew Linden: When the simulator get's the list of misses it packages up that data and sends it
[12:19] Andrew Linden: So, they way it is supposed to work is that if you are in a region and log out... a region_id.objects file with all the position + goemetry + local_id + version_number data is supposed to be saved in your local cache
[12:19] Andrew Linden: if you then login to that region immediately then most of that data should still be valid
[12:20] Andrew Linden: and very few CacheMiss messages should be sent
[12:20] Motor Loon: Sounds clever enough
[12:20] Andrew Linden: (I don't think CacheMiss is the right name for that message... let me look up the exact name)
[12:20] Rex Cronon: maybe RequestObjData?
[12:20] Renae Daines: Will this increase overhead on current connections to report the misses? And if so, by how much? (though I suppose that may be more of a viewer question)
[12:21] Thex Lecker: i would look at positional rounding errors as a source of misses.
[12:21] Andrew Linden: Yes, thank you Rex. That is the one.
[12:21] Rex Cronon: it was a lucky guess:)
[12:21] Motor Loon: Go Rex go!
[12:21] Rex Cronon: i should play craps:)
[12:22] Andrew Linden: It has a "multiple block" that can store lists of [CacheMissType : ID] pairs
[12:22] Andrew Linden: where ID = object local_id
[12:23] Andrew Linden: Anyway, that is the motivation for what I'm working on today... try to "notice" when we're getting cache misses when we shouldn't.
[12:23] Andrew Linden: That's all the news. The table is open.;
[12:23] Helena Lycia: I have a question that might be sill but I'd like to know an answer anyway...
[12:23] Motor Loon: we have an agenda
[12:23] Helena Lycia: Do we?
[12:23] Andrew Linden: Go ahead.
[12:23] Helena Lycia: OK
[12:24] Rex Cronon: u put a monitor in place that keeps a list of who requested what and logs unusual requests
[12:24] Helena Lycia: I didn't realise it was possible to create a mesh physical vehicle with a PE of over 700... should it be?
[12:24] Arawn Spitteler: Silly questions are worthy of consideration
[12:24] Ann Otoole: is this for static objects or are avatars included? (i had a chance or two to crash and login to last location recently and the environment rezzed in real fast but avatars tended to need a group change to kick in)
[12:24] Kallista Destiny: That isn't a silly question at all
[12:24] Helena Lycia: Kind of scary flying over parcels in a 733 PE monster
[12:24] Motor Loon: Yes Helena... if the physical weight stays below 32 before it goes physical
[12:24] Helena Lycia: 26 PE before it goes physical and temp
[12:25] Andrew Linden: Helena, the Prims Equivalent (PE) cost calculations now add weight to objects that are dynamic
[12:25] Ann Otoole: oh and btw the behavior of mesh vehicles encountering full parcels is a real buzz kill.
[12:25] Helena Lycia: Does this mean the vehicle must stay over large, relatively empty parcels?
[12:25] Andrew Linden: so the PE cost goes up when you set it dynamic
[12:25] Helena Lycia: Well I knew the cost went up
[12:25] Motor Loon: try to optimize your mesh so it's not 700PE
[12:26] Andrew Linden: but what about those objects that have physics costs below PE=32 when static... but go over when dynamic?
[12:26] Helena Lycia: But the concept of flying 733 prims (equivalent) into a parcel is scary
[12:26] Renae Daines: I'd like to ask a couple questions once Helena is done =)
[12:26] Ann Otoole: just freezes and you have to delete to escape. making it impossible to even bother given the griefing 16m parcels all along the roads.
[12:26] Andrew Linden: Turns out we allow the objects to go dynamic if their PE "physics" cost is lower than 32 prior to being set dynamic
[12:26] Kallista Destiny: I think what it means is that PE computations are nontrivially difficult and probably subject to change in the future.
[12:27] Helena Lycia: But is still ahve to stick to parcels with 700+ pree prims?
[12:27] Helena Lycia: is/I
[12:27] Andrew Linden: Also... note that the total PE cost of the object is the max value of three different types of costs: physics, simulation, and streaming
[12:27] Helena Lycia: ahva/have
[12:27] Andrew Linden: we only allow them to go dynamic if the *physics* cost is lower than 32
[12:27] Motor Loon: Its being "fixed" so you can enter even full parcels, while sitting on your object...
[12:27] Andrew Linden: it may be that other costs are higher, but the dynamics bit only affects the physics cost
[12:28] Andrew Linden: unfortunately... it may not yet be possible to see the different costs of an object
[12:28] Kallista Destiny: Motor as in Sat upon objects don't count agains parcle limits?
[12:28] Ann Otoole: seting to temp has zero effect
[12:28] Andrew Linden: in particular... the physics cost may not yet be data that is sent to the viewer
[12:28] Motor Loon: yes Kallista... I belive so
[12:28] Andrew Linden: however, that should change soon in an up and coming simualtor update
[12:28] Motor Loon: if they are physical
[12:28] Andrew Linden: and the viewer will have to be updated to know to retreive that info
[12:28] Kallista Destiny: sighs....
[12:29] Kadah Coba: Its still highly complex
[12:29] Pauline Darkfury: That's a good point for me to raise SVC-7277
[12:29] JIRA-helper: http://jira.secondlife.com/browse/SVC-7277
[#SVC-7277] Prim count (labelled "Objects") in sim stats window can have huge errors with large mesh objects
[12:29] Motor Loon: My Kirstens viewer shows physics weights before and after object going physical
[12:29] Helena Lycia: So vehicles that are sat upon don't cound against a specific parcel? Or is that future behaviour?
[12:29] Helena Lycia: cound/count
[12:30] Pauline Darkfury: A useful stat in the sim stats has become broken with PE. The objects number always gave the 1/15,000 count, it now gives a more or less entirely useless number (at least for admin purposes, it now has no use that I can see)
[12:30] Ann Otoole: must be future because they sure count now. you freeze in the boundary and have to delete to escape.
[12:30] Arawn Spitteler: Vehicles count as Temp Prims, as I recall, but 700 is a good chunk of 1,000
[12:30] Andrew Linden: I believe that vehicles that have a sitting avatar count against the parcel's prim counts, but is categorized as "Selected or Sat-Upon"
[12:30] NeoBokrug Elytis: With llCastRay around the corner the documentation on the wiki refers to certain time allocations for execution, however it neglects to mention if those time allocations are per frame -- or per second. Any insight into if it's per frame or per second?
[12:30] Meeter: Timecheck : User Group is half over
[12:30] Andrew Linden: if the parcel is over its limit and their are "selected" objects, then they might not be returned until they go "unselected"
[12:30] Kallista Destiny: Doing that (sat upon) would solve all kinds of viehcle probems
[12:31] Andrew Linden: but they do as soon as they are unselected
[12:31] Pauline Darkfury: But they won't cause anything else to be returned instead, right?
[12:31] Andrew Linden: Pauline, I belive that is correct.
[12:31] Pauline Darkfury: Any existing stuff, that is
[12:31] Renae Daines: As far as SVC-6689 is concerned - has there been any internal updates? Regions I've noted the issue in are still experiencing it while other regions have mysteriously "fixed" themselves. (This was before todays rollout)
[12:31] JIRA-helper: http://jira.secondlife.com/browse/SVC-6689
[#SVC-6689] Sims Perfomance Substandard due to "TIMEWARP"
[12:31] Pauline Darkfury: Thanks
[12:31] Andrew Linden: Renae, they have a plan for that. I don't know the status of that project.
[12:31] Andrew Linden: I'll have to ask around.
[12:32] Renae Daines: Thanks
[12:32] Andrew Linden: The basic plan is to update the linux kernel, I believe.
[12:32] Simon Linden: I believe we've seen some improvements witha kernal upgrade
[12:32] Renae Daines: nods, just trying to keep tabs on the issue as it is affecting a number of regions currently
[12:33] Sahkolihaa Contepomi: Which kernel were you guys running, and what are you upgrading to?
[12:33] Kallista Destiny: Andrew, if a over ptim limit situation exists because someone is manipulatiing an object (selected) what gets returned, if anythi8ng?
[12:33] Andrew Linden: Dunno the exact kernel versions, but we're currently on debian/etch and want to move to debian/lenny (I think)
[12:34] Andrew Linden: Kallista, that scenario is a little complicated... but the good news is that I know all about it.
[12:34] Pauline Darkfury: It's supposed to be fixed around a month ago, so that only the bloating object gets returned, in the case of sudden bloat going over limit?
[12:34] Kallista Destiny: But selected objects can't be returned... Catch-22
[12:35] Andrew Linden: However... there is a simulator update with some bug fixes around that behavior in the works, may go out this week.
[12:35] Andrew Linden: So I might not be able to remember the differences of how it works in the world today, and how it will work once the fixes are deployed.
[12:35] Thex Lecker: I'd like to bring up SVC-4933 and see if Andrew or Simon can comment on it. Action on that would save estate owners a lot of time every day.
[12:35] JIRA-helper: http://jira.secondlife.com/browse/SVC-4933
[#SVC-4933] Ability to Allow / Disallow Changes to Public Access Across Entire Estate
[12:35] Motor Loon: hear hear !
[12:35] Andrew Linden: So let me explain how it is *going* to work eventually...
[12:36] Renae Daines: hhehe, that SVC would be a beautiful change =)
[12:36] Andrew Linden: As you know, with mesh objects the PE cost of the object is dependent on its scale
[12:36] Andrew Linden: as the object gets bigger its cost goes up
[12:36] Simon Linden: hmm, that has a lot of votes (4933)
[12:36] Kallista Destiny: nods
[12:36] Motor Loon: it does
[12:37] Andrew Linden: so in theory it would be possible to scale an object up so that it exceeds the resources of the parcel on which it sits
[12:37] Motor Loon: because it causes us a lot of timewaste
[12:37] Andrew Linden: in the updated code we now check the future cost of the scale, and allow it to succeed or fail depending on if it exceeds the parcel counts
[12:37] Pauline Darkfury: Not just scaling, add a script, set it physical, change the physics shape setting on a member of the linkset, give it a funny look, etc
[12:37] Andrew Linden: sorta... there are still some bugs there as I will explain:
[12:38] Andrew Linden: (1) the future estimate cost of the operation is not perfectly accurate --
[12:38] Andrew Linden: it might be off from the real cost
[12:39] Kallista Destiny: Basically , eventually, you won't be able to PE a space out of prims?
[12:39] Andrew Linden: but computing the real cost is too expensive (requires a real reconstruction of the physical shape because we rely on some info in the phys engine to compute it)
[12:39] Motor Loon: a hint that the accounting system is too damn complex?
[12:40] Andrew Linden: (2) There may be some race conditions where if you scale two objects nearly simultaneously each check will succeed, but eventually when everything is computed they both add up to go over the parcel resources
[12:40] Kallista Destiny: @motor, understatement?
[12:40] Andrew Linden: and (3) any other bug where an operation would increase the objects's cost but we don't check (dunno if these exist, but they might)
[12:40] Andrew Linden: ok...
[12:41] Andrew Linden: so we're trying to check the operations and make them fail if they would exceed the parcel resource costs...
[12:41] Rex Cronon: imo this PE makes matters overly complicated both for users and for servers:(
[12:41] Andrew Linden: but if they DO succeed...
[12:41] Andrew Linden: we have code that will now return the objects that pushed the parcel over, not random stuff that was in the parcel before
[12:41] Andrew Linden: and that code is pretty tight
[12:42] Andrew Linden: and... it will return the object even if it is selected
[12:42] Andrew Linden: however, here is another scenario on how to go over parcel resource limits:
[12:42] Kallista Destiny: AHHHHHHH
[12:42] Motor Loon: good... still sucks if you accidently scale up an object you've been working on for days and it becomes 15.001 PE
[12:42] Motor Loon: kinda hard to rerezz
[12:42] Andrew Linden: Own two parcels, build everything on one of them until you're full
[12:43] Andrew Linden: then abandon the empty parcel --> you'll be over your limit
[12:43] Andrew Linden: if you do it that way then selected objects will not be returned until you deselect them
[12:43] Pauline Darkfury: That one is less of a concern, as it's easy to predict, and well known expected behaviour
[12:43] Andrew Linden: and the return order goes in reverse order in the following order:
[12:43] Kallista Destiny: Yeah shooting yourself in the foort.
[12:43] Kallista Destiny: foot*
[12:43] Motor Loon: agree... but dont say it will never happen
[12:44] Andrew Linden: (1) objects owned by others (not parcel owner, nor parcel group) newest to oldest
[12:44] Andrew Linden: (2) objects owned by parcel's affiliated group, newest to oldest
[12:44] Andrew Linden: (3) objects owned by parcel owner newest to oldest
[12:44] Andrew Linden: fin
[12:44] Renae Daines: Next question - Estate Tools Top Scripts reports differently then the statistics window. This makes it difficult to properly administer a region with heavy scripts. I have seen upwards of 3x the Script Time on the statistical window versus estate tools. Was this an intentional change or is this a problem with reporting from the sim?
[12:44] Kallista Destiny: is that newest rez time or nwest mod time?
[12:44] Leonel Iceghost: a warning before abandoning and things like that would be nice
[12:45] Rex Cronon: so, if a sim owner rezes something huge, all that rent will have their things returned?
[12:45] Kallista Destiny: of do you even track mod time?
[12:45] Andrew Linden: Hrm...
[12:45] Motor Loon: probably not a good idea to compare those numbers
[12:45] Moy Loon: https://jira.secondlife.com/browse/SCR-169 would somewhat be related
[12:45] JIRA-helper: [#SCR-169] OBJECT_SCRIPT_CURRENT_TIME
[12:45] NeoBokrug Elytis: Ranae, there's a jira I made for that a long while back
[12:45] Andrew Linden: I don't know that top scripts feature well. Kelly, do you know the answer to that question?
[12:46] Ann Otoole: what happens when people start firing automatic weapons?
[12:46] NeoBokrug Elytis: https://jira.secondlife.com/browse/SVC-3819
[12:46] JIRA-helper: [#SVC-3819] "Top Scripts" in estate tools is inaccurate
[12:46] Pauline Darkfury: Yeah, more warning for noob landowners for abandon, sell, etc, would be a very valid way to "fix" that issue, rather than worrying about it deep in the code
[12:46] Motor Loon: rex: omg, hope you are not right there
[12:46] Renae Daines: I checked on the Jira, last I found was back in May 2010 I think
[12:46] Andrew Linden: It sounds like a bug. The info between those two UI elements should agree, ideally.
[12:46] Stickman Ingmann: Estate tools top scripts is a rolling average, if I recall. It was recently redone.
[12:46] Kallista Destiny: Ann theny SVC-5972 kicks in
[12:46] JIRA-helper: http://jira.secondlife.com/browse/SVC-5972
[#SVC-5972] Touch even ignored after State change and llHTTPRequest
[12:46] Kelly Linden: Oh.
[12:47] Kelly Linden: I have fixes for that going to RC this week.
[12:47] Kallista Destiny: errr SVC-5927
[12:47] JIRA-helper: http://jira.secondlife.com/browse/SVC-5927
[#SVC-5927] Temp on Rezzed objects get queued
[12:47] Moy Loon: I think current time, is much better than the "average"
[12:47] Rex Cronon: if i am returned, how can i be there:)
[12:47] Renae Daines: For script time Kelly?
[12:47] Kelly Linden: for script time, yes.
[12:47] Pauline Darkfury: One thought on the bloat-return. What happens on a region with bonus >1.0 if an object bloats and doesn't over-fill a parcel but over-fills the region itself?
[12:47] Kallista Destiny: I thought it was form Script memory?
[12:47] Renae Daines: Okay great - I noticed the behavior change in the past... well 4 months or so.
[12:47] Kelly Linden: Some scripts got too fast so they wouldn't get counted in the top scripts tool
[12:47] Kelly Linden: there will still be some discrepency but hopefully less
[12:48] Stickman Ingmann: https://jira.secondlife.com/browse/SCR-106 By the way, any insight on this, Kelly? I've got an object at the region Aggro spamming text right now. Persists across region restart. Useful to you at all? Or should I reset it to make it shut up?
[12:48] JIRA-helper: [#SCR-106] touch() events get "stuck" and continuously execute
[12:48] Renae Daines: great - when a region is running at 23ms script time with statistics and only 4.5 on top scripts, it makes one wonder =)
[12:48] Moy Loon: Another llCastRay question, is there any thought of having an EM set parameter to allow for unlimited usage of llCastRay?
Some sims might have heavy usage of raycasting, and the 50us avatar time, and 2ms sim usage times might not be enough for what the whole sim would do!
I think such limits are kind of pointless, as if someone wanted to lag, or crash my own sim, they could easily just do it with rezzing hundreds of objects, or sending some malformed packets.
So could such a toggle be implemented for private estates to avoid such silly limits?
[12:48] Kelly Linden: I have no idea stickman. Unfortunately the object you have in world isn't much help. I dunno how it got to that state, and don't actually have a lot to look at to see what state it really is in
[12:49] Kelly Linden: looks like the event is somehow not getting cleared after handled but I don't know how.
[12:49] Andrew Linden: Moy, the time spent running llCastRay() is indeed configurable, but not by EM yet.
[12:49] Kelly Linden: There is still some global overhead that isn't counted in individual script time.
[12:49] Andrew Linden: Yes we'll consider opening that up once we know more.
[12:49] Moy Loon: Oh awesome, is there any chance that things could be ajusted by EM?
[12:50] Moy Loon: That sounds great then!
[12:50] Andrew Linden: Yes, we need to see llCastRay() in operation for a bit to see how well it really performs.
[12:50] Moy Loon: I've been doing all sorts of things with it since it was on the betagrid
[12:51] Andrew Linden: If we open it up to EM's then I think it does not pose much of a risk to the host on which the simulator is located, but only to the simulator itself -- that is if the EM set the limits way too high.
[12:51] Kallista Destiny: And when is llCastRay() actually being released on the main grid?
[12:51] Andrew Linden: Soon.
[12:51] NeoBokrug Elytis: 50us per second or frame? :D
[12:51] Andrew Linden: Look for it in an RC's releae notes.
[12:51] Kallista Destiny: frame
[12:51] Andrew Linden: release notes, even
[12:51] Kallista Destiny: 50Us/sec is useless
[12:51] Moy Loon: The 50us is per frame, as it says on the wiki, but it doesn't say what the 2ms is
[12:52] Moy Loon: Then you get 25% of the time back per frame
[12:53] Pauline Darkfury: A request for a new function/flag related to PE. SCR-193
[12:53] JIRA-helper: http://jira.secondlife.com/browse/SCR-193
[#SCR-193] llGetObjectPrimCount() is broken for mesh objects, need llGetObjectPrimEquiv()
[12:53] Imaze Rhiano: ping
[12:54] Vincent Nacon: pinging you back
[12:54] Motor Loon: would have loved to hear comments on "In the modernisation of SL, why has all effeort for new features seemed to be targeted at Mesh? I feel that the biggest immersion killer, and the area where Second Life is lagging behind other MMOs the most, right now is not having seamless sim crossings, and not being able to traverse the seas. [Davido Chrome]" from the agenda too
[12:54] Andrew Linden: Yeah, that LSL function call is needed Pauline.
[12:54] Simon Linden: Motor - we've spent a boatload of time on region crossing performance
[12:55] Motor Loon: while I like mesh ... the ability to e.g. sail a boat between regions where there is no sims - or fly a plane... would be crazy awesome
[12:55] Pauline Darkfury: Alternatively, and possibly more desirable, OBJECT_PRIM_EQUIV (and OBJECT_PRIM_COUNT for llGetObjectDetails), possibly in addition to llGetObjectPrimEquiv
[12:55] Motor Loon: simcrossing are pretty good now I think actually
[12:55] Simon Linden: I think the real problem is that SL is designed with the idea that crossings _can_ be made transparent. I've reached the conclusion that they never will be
[12:55] Meeter: Timecheck : User Group is almost over
[12:55] Motor Loon: "and not being able to traverse the seas. " was the interesting part for me
[12:56] Pauline Darkfury: Thanks, Andrew :)
[12:56] NeoBokrug Elytis: Corssing a region without any scripts at all on your av is transparent. :)
[12:56] Motor Loon: The boat & avatar could still be "on" the sim it left... until actually hitting a new simborder...
[12:56] Pauline Darkfury: And, before time is up, encroachment-return on mainland, please :)
[12:56] Motor Loon: all that would change it your cordinates
[12:56] Kelly Linden: I thought I created that somewhere already.
[12:56] Andrew Linden: Well... actually there are problems with an unlimited size of the simulated world...
[12:57] Kelly Linden: (the OBJECT_PRIM_EQUIV version)
[12:57] Simon Linden: Right, one of the inherent problems is that everyone can easliy load up their AV with 50-100 scripts, but if you do that, they will be slow
[12:57] Pauline Darkfury: Oh, the LSL PE query, Kelly. I had a bit of a hunt through the wiki, couldn't spot it
[12:57] Motor Loon: we already have the world coordinates right?
[12:57] Kelly Linden: I don't think it is out yet. I think it is in the upcoming 'mesh maintenance' project
[12:57] Andrew Linden: the physics engine needs to know how big its world is ahead of time... so it can take advantage of some algorithm optimizations
[12:57] Rex Cronon: actually more than 100. much more
[12:57] Moy Loon: From a sim where I have 13 ping to, to another sim where I have 13 ping, wearing my usual avatar (100 prims, 10 scripts or so), it's nearly instant, I can barely notice a thing!
[12:57] Pauline Darkfury: cool, thanks, Kelly :)
[12:57] Motor Loon: but... really not much to do for physics in either open water or the sky in an airplane?
[12:58] Motor Loon: (that couldnt be handled by the sim you left)
[12:58] Arawn Spitteler: Is it possible, to have a state with no events?
[12:58] Thex Lecker: So I realize SVC-4933 does not involve sexy mesh or interesting prim accounting or cool physics... but will one of you guys comment on the Jira this week?
[12:58] Simon Linden: The crossings are really the worst with vehicles
[12:58] Arawn Spitteler: I guess that still wouldn't solve the resize problem
[12:59] Andrew Linden: Motor, as long as you don't want be able to bump into other boats I guess
[12:59] Simon Linden: Thex - I will pass that to our land product people; they are the ones that need to prioritize requests like that
[12:59] Motor Loon: Get scripting memory usage low enough, you hardly feel the crossing
[12:59] Kallista Destiny: Or evn see them
[12:59] Thex Lecker: Ty Simon
[12:59] Motor Loon: Indeed Andrew... no need for collisions while in "open space"
[12:59] Kallista Destiny: Region crossings now are quite painless.
[12:59] NeoBokrug Elytis: I like SVC-4933, voted!
[13:00] Sahkolihaa Contepomi: Painless? Not from what I've seen.
[13:00] Motor Loon: and should you stand up from your vehicle, just return the avi to the last location in the left sim
[13:00] Ann Otoole: my testing in the mesh sandboxes with a low pe vehicle was sim crossings were just a bump. Perhaps part of the delay is related to having to rez stuff farther out as the mesh sandboxes were empty.
[13:00] Andrew Linden: I think region crossings still need work.
[13:00] Kallista Destiny: Watching is signnificant voting is ignored (so I've been told)
[13:00] Andrew Linden: I also believe that progress can be made there.
[13:00] Pauline Darkfury: I find crossings are generally reliable and pain free at slow speed with up to 150 scripts, tbh, as long as both sims are generally healthy and not heavily loaded
[13:00] Rex Cronon: if you make all your players micros-sized u might not need to cross the border:)
[13:00] Helena Lycia: They seem to ahve gotten better, even crossing wiht a 733pe vehicle *giggles*
[13:00] Meeter: Thank you for coming to the Server User Group
[13:00] Motor Loon: I agree crossings are very good... but all depends on your worn scripts and what you are sitting on while crossing
[13:01] Motor Loon: try naked crossings... its wonderful
[13:01] Motor Loon: as in.... damn instant
[13:01] Helena Lycia: Oh and something else I noticed... I was carrying a standing passenger across a sim boundry and didn't lose him... which I didn't think was possible
[13:01] Vincent Nacon: thanks for the image, Motor
[13:01] Motor Loon: yw Vincent... Ill send you video if you like
[13:01] Vincent Nacon: no thanks
[13:01] Ann Otoole: well that was a ton of info packed into 60 minutes
[13:01] Moy Loon: That could be packetloss, high ping, or a really poor performing sim Koli
[13:01] Motor Loon: or we can go streaking together after the meeting
[13:02] Renae Daines: Thank you Andrew, Kelly, and Simon
[13:02] Sahkolihaa Contepomi: No doubt pinging 150-200 will cause problems.
[13:02] Pauline Darkfury: Thanks, Lindens :)
[13:02] Motor Loon: Might be right Pauline ;.-)
[13:02] Simon Linden: Thanks everyone for coming and the good discussion
[13:02] Andrew Linden: Thanks for coming everyone.
[13:02] Imaze Rhiano: thanks
[13:02] Sahkolihaa Contepomi: See you Simon, Andrew & Kelly.
[13:02] Kallista Destiny: thanks for a very interesting and useful meeting
[13:02] Motor Loon: Oooo kay... back to work
[13:02] Helena Lycia: Byeee
[13:02] TankMaster Finesmith: tc andrew, simon, kelly
[13:02] Motor Loon: have fun all!
[13:02] Pauline Darkfury: And my final plea for today - mainland encroachment return, pretty please
[13:02] Rex Cronon: tc simon, andrew, kelly, and everybody else
[13:02] Pauline Darkfury: with a cherry on top!
[13:02] Stickman Ingmann: Thanks for the office hours.
| Prev 2011.09.09 | Next 2011.09.16 |