Content Creation/Scripting User Group/Transcripts/2011 06 06

From Second Life Wiki
Jump to: navigation, search

List of Speakers

flexi campfire Kitteh Scientist Latif Khalifa


[09:01] Latif Khalifa: how did it go with mono2 RC?

[09:02] tehKellz (kelly.linden): Pretty good. Discovered that on busy sims it was too easy to starve existing scripts for time when adding new ones

[09:02] tehKellz (kelly.linden): So we tweaked the logic a bit and I think it is much better now.

[09:02] Latif Khalifa: i've heard maestro pointed out the jira about it

[09:02] Latif Khalifa: scripts would stop completely

[09:03] tehKellz (kelly.linden): that won't happen any more.

[09:03] Kallista Arliss (kallista.destiny): That was the one with setting a title to the timestamp?

[09:03] tehKellz (kelly.linden): Scripts already running are gauranteed 50% of the available script time, minimum.

[09:03] Latif Khalifa:

[09:03] flexi campfire: [#SCR-88] Periods of very low (or nonexistent) script performance

[09:03] tehKellz (kelly.linden): Yup that one.

[09:04] draconis.neurocam (draconis.neurocam): thats great they have reserved time

[09:04] Latif Khalifa: so it looks like mono2 might be promoted to the main channel soon?

[09:04] tehKellz (kelly.linden): Not this week, since that fix has not seen RC yet

[09:05] Latif Khalifa: but it's getting there :)

[09:05] tehKellz (kelly.linden): Yup, it is getting there.

[09:05] Kallista Arliss (kallista.destiny): did the change that improved Lsl performance make it to an RL?

[09:05] Kallista Arliss (kallista.destiny): RC

[09:05] tehKellz (kelly.linden): What change is that Kallista?

[09:05] Latif Khalifa: SCR-88

[09:06] Kallista Arliss (kallista.destiny): Someon mentioned that he'd froun a tweek that gave ~5-10% performance improvement to LsL.

[09:06] tehKellz (kelly.linden): SCR-88 should make it to RC (I assume on Le Tigre again) this week, but isn't there yet.

[09:06] tehKellz (kelly.linden): I'm not sure Kallista, I'd need more details and context.

[09:06] draconis.neurocam (draconis.neurocam): i think it might have been simon

[09:07] draconis.neurocam (draconis.neurocam): i just barely remember it

[09:07] tehKellz (kelly.linden): The last tweak I heard from him I think was closer to 0.5% but maybe he found something else?

[09:07] tehKellz (kelly.linden): It would be best to follow up with him I think.

[09:08] Kallista Arliss (kallista.destiny): No that was it, slipped Decimal place

[09:08] Haravikk (haravikk.mistral): This kind of highlights an issue with beta-channels that SVC-6779 is intended for, I know it's not script related but do you know who I'd contact for that one?

[09:08] flexi campfire:

[#SVC-6779] Cycle regions that are in the beta/release-candidate channels

[09:09] Kitteh Scientist drops a pin to the silence: SCR-90

[09:09] flexi campfire:

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

[09:09] tehKellz (kelly.linden): It is not difficult to get out of RC channels. I'm pretty sure we honor all requests from estate owners. Cycling is kind of difficult though

[09:10] tehKellz (kelly.linden): Bring SCR-90 up at the Mesh UG and the Sim UG

[09:10] tehKellz (kelly.linden): (magnum is Mesh-Prep)

[09:10] Kitteh Scientist: okie

[09:10] Haravikk (haravikk.mistral): Well that's just it, my home region is on the mainland, and I don't really object to the use of them for this purpose, but it cuts into the value of the land and can be very annoying

[09:11] Latif Khalifa: land has no value anymore :P

[09:11] tehKellz (kelly.linden): Haravikk: I agree. I really don't like the frequency of restarts our release process causes. It is really annoying.

[09:11] Kaluura (kaluura.boa): Yeah...

[09:12] Haravikk (haravikk.mistral): I wouldn't have thought it'd be a big deal to just re-assign beta channels every month, or ever few months, so every mainland region gets a small share of time in one, rather than a handful being stuck there all the time.

[09:12] tehKellz (kelly.linden): Unfortunately right now building out the channels is a pretty manual process. (not as manual as editing a text file, but not automated in any way)

[09:12] Haravikk (haravikk.mistral): Is there any particular Linden that is best to talk to about it?

[09:12] Kallista Arliss (kallista.destiny): well it doesn't seem to matter if you're on RC or mains stream, you still get a weekly reboot.

[09:12] tehKellz (kelly.linden): I don't know who the spokesperson is for the release team.

[09:13] Latif Khalifa: you should probably ask at the server beta oh on aditi on thursdays

[09:13] Kallista Arliss (kallista.destiny): Oskar?

[09:13] Latif Khalifa: oskrar or maestro, one of thsoe

[09:13] tehKellz (kelly.linden): That is probably the best place.

[09:13] Haravikk (haravikk.mistral): k, I'll see if I can make it to one of those

[09:14] Haravikk (haravikk.mistral): Also, I was hoping to get SVC-215 imported to Scripting, as I don't think I can do it myself without cloning; seems silly that we can't move JIRA issues ourselves into open projects

[09:14] flexi campfire:

[#SVC-215] llRequestAgentKey (llName2Key)

[09:14] Kallista Arliss (kallista.destiny): Well my home region gets restarted pretty much daily because afther a lot of activity perfromance degrades.

[09:14] tehKellz (kelly.linden): Kallista: that is extreme. You shouldn't need to do that.

[09:15] Latif Khalifa: oskar said last week because there was no deploy on the main channel and it was running for two weeks the rolling restart was having trouble because it took forever for sims to save simstate

[09:15] Haravikk (haravikk.mistral): Actually Server Beta meetings are probably out for me, as 15:00 is about 10pm at least for me, don't suppose someone could raise the JIRA issue on my behalf?

[09:15] tehKellz (kelly.linden): Yes, that is another problem - weekly rolls mask issues that build over time.

[09:16] Latif Khalifa: memory leaks/fragmentation for long lived processes is pita :P

[09:16] Kallista Arliss (kallista.destiny): Yeah especally if they are little leaks

[09:17] Kallista Arliss (kallista.destiny): HarVIKK IS THAT 215?

[09:17] Latif Khalifa: Haravikk, the issue of cycling which regions belong to RC channels *was* raised several times there without any definitive answer.

[09:17] Kallista Arliss (kallista.destiny): Sorry caps.

[09:18] Kallista Arliss (kallista.destiny): or 6779?

[09:18] Haravikk (haravikk.mistral): Eh no, SVC-6779 (cycling beta channel regions). SVC-215 is llNameToKey(), just needs importing to Scripting project

[09:19] tehKellz (kelly.linden): k, it is SCR_91

[09:19] tehKellz (kelly.linden): SCR-91

[09:19] flexi campfire:

[#SCR-91] llRequestAgentKey (llName2Key)

[09:20] tehKellz (kelly.linden): but .... not likely to get attention soon.

[09:20] Haravikk (haravikk.mistral): Thanks! On that issue though, can you confirm what kind of user name and key databases SL actually has? There are at least two that seem like they'd be usable

[09:20] Kallista Arliss (kallista.destiny): well as far as DN is concerned they are not guarenteed to be unique.

[09:20] Haravikk (haravikk.mistral): Namely the one use when looking up users to add to groups and such, and also and search must have something usable

[09:21] tehKellz (kelly.linden): The 'people API' is the new source of truth for such things, including display names.

[09:21] tehKellz (kelly.linden): I'm not sure off the top of my head what queries it supports.

[09:21] Haravikk (haravikk.mistral): The Display Name functions are configured with that in mind Kallista, and will return a list

[09:21] Latif Khalifa: heh, there were name2key requests for years

[09:21] Kallista Arliss (kallista.destiny): Nods.

[09:22] Haravikk (haravikk.mistral): If it already has the necessary queries then in theory it wouldn't be a massive problem to implement name-to-key? But new interfaces would be a big deal, and load a potential issue?

[09:22] tehKellz (kelly.linden): yes, since before I was a Linden.

[09:22] Haravikk (haravikk.mistral): SVC-215 being one of the main ones Latif, it's pretty old =)

[09:22] Latif Khalifa: just expose avatar picker messaging that is exposed to the client, problem solved :P

[09:22] tehKellz (kelly.linden): It becomes an issue of load, if the queries exist.

[09:23] Latif Khalifa: if i remembrer correctly AvatarPickerRequest and Response

[09:23] Haravikk (haravikk.mistral): I suppose the real issue though is whether that load is more or less than routing HTTP traffic to outside sources, and the load they incur on collecting the data?

[09:23] Haravikk (haravikk.mistral): Because external name-to-key must generate a bit of traffic as it is right now

[09:24] tehKellz (kelly.linden): Those generally hit highly cached data, so it come back to the design of the calls.

[09:24] draconis.neurocam (draconis.neurocam): i think there would be more queries if it was something LL supported rather than a third party which could go down at any point

[09:25] Haravikk (haravikk.mistral): True, but it's definitely one where it's kind of ridiculous that it /isn't/ supported.

[09:25] Haravikk (haravikk.mistral): Would it better for the issue to be split into llGet* and llRequest* sub-tasks? As the local calls would be pretty useful anyway, and probably easier in the short-term?

[09:25] tehKellz (kelly.linden): I disagree that it is as far as 'ridiculous' especially since the services that would make it supportable (people API) are so relatively new.

[09:26] Haravikk (haravikk.mistral): Viewer has supported the ability to look-up an avatar by name for years…

[09:26] tehKellz (kelly.linden): There is already a local version, right?

[09:26] Latif Khalifa: the client api supported it all along

[09:26] tehKellz (kelly.linden): Haravikk: yes at use speed, not script speed

[09:26] tehKellz (kelly.linden): user*

[09:26] tehKellz (kelly.linden): And we have in the past adjusted throttle levels as needed.

[09:27] Latif Khalifa: the classical problem is a gift vendor, where it would ask, "type in name of the person you want to gift this item".

[09:27] Haravikk (haravikk.mistral): No local functions to get an avatar's key from their name, not without sensors anyway, unless I've completely missed something…?

[09:28] Latif Khalifa: Haravikk, there is local version of name2key that works if agent is in the same sim

[09:28] Haravikk (haravikk.mistral): Since when? What's it called? All I'm aware of are feature request functions on the wiki…

[09:29] Latif Khalifa: i cannot recall the name, my brain is slow. but it's been there forever

[09:29] tehKellz (kelly.linden): At the very leas llGetObjectDetails will do it

[09:30] Haravikk (haravikk.mistral): But llGetObjectDetails takes a key… ?

[09:30] tehKellz (kelly.linden): oh sorry

[09:30] Haravikk (haravikk.mistral): The issue is getting a key from a user's name, and now display-name or username as well I suppose

[09:30] Kallista Arliss (kallista.destiny): so make it the call pause the process for 5 seconds (as does llInstantMessage()

[09:31] tehKellz (kelly.linden): Those types of stalls don't work (see llEmail)

[09:31] tehKellz (kelly.linden): but we could heavily throttle it, yes.

[09:31] draconis.neurocam (draconis.neurocam): instant message is 2 i thought not 5

[09:32] Kitteh Scientist: if 3rd party services can do it. LL and their 500million yearly profit can do it too. LL could prolly make it even faster and more reliable. There is no technical problem.

[09:33] tehKellz (kelly.linden): wow that is a nice profit number, where did you come up with that?

[09:34] Kallista Arliss (kallista.destiny): yes bu you get the point

[09:34] draconis.neurocam (draconis.neurocam): also im pretty sure there is no function that lets you put in a name and it returns a key, even if they are in sim

[09:34] Kaluura (kaluura.boa): I'm sure too

[09:34] Kitteh Scientist: i calculated the profit, easy, just count the number of sims and do the math

[09:34] tehKellz (kelly.linden): Hrm, I coulda swore that was possible - but it must have just been with llSensor.

[09:34] Haravikk (haravikk.mistral): It just seems silly that the viewer's had the capability… well for at least the 6 years I've been here, yet scrips have never had that ability

[09:34] Kallista Arliss (kallista.destiny): That is the Gross not the Net

[09:34] tehKellz (kelly.linden): Oh. That would be closer to Gross income I guess?

[09:34] Kaluura (kaluura.boa): Sensors give you the name and the key at the same time.

[09:35] tehKellz (kelly.linden): Anyway that is way off topic for here.

[09:35] Kallista Arliss (kallista.destiny): Yeah but they get the Key...

[09:35] Haravikk (haravikk.mistral): Only way I know to get key by name is external, or from sensor or interaction (i.e - if a user touches it)

[09:35] Latif Khalifa could have sworn he's used it too in distant pass

[09:35] Kitteh Scientist: no, profit, pure cash to sit on. i counted off the money needed to run the show

[09:35] Kaluura (kaluura.boa): Alzheimer already?

[09:36] tehKellz (kelly.linden): You appear to be correct Haravikk. I coulda swore there was something else but I appear to have been mistaken.

[09:36] Latif Khalifa: Kaluura, quite possibly lol

[09:36] Haravikk (haravikk.mistral): Otherwise SVC-215 wouldn't have been unchanged for so long =)

[09:36] draconis.neurocam (draconis.neurocam): im looking over the list of function names at the moment, i see nothing remotely similar (i have most of the memorized anyway)

[09:36] Haravikk (haravikk.mistral): Anyway, my point was that even just the local functions would be nice in the short-term, would that have better chance if I divided up the issue?

[09:37] Haravikk (haravikk.mistral): i.e - made sub-tasks for local and global look-ups?

[09:37] tehKellz (kelly.linden): As far as I can tell llName2Key like services are definitely feasible, just a matter of development time.

[09:37] tehKellz (kelly.linden): Haravikk, yes maybe. It would both make the tasks smaller and the local versions are significantly easier.

[09:37] Kallista Arliss (kallista.destiny): That would, I think, be a wonderful enhancement

[09:38] Haravikk (haravikk.mistral): k, I'll do that after the meeting

[09:38] Latif Khalifa: well the new profiles have http url with the username, i bet you could parse the key out of it :P

[09:38] Haravikk (haravikk.mistral): If I can raise another, sort of related issue, I added SCR-87 recently

[09:38] flexi campfire:


[09:39] Kaluura (kaluura.boa): I'm not an object! I refuse!

[09:39] Kaluura (kaluura.boa): :P

[09:40] draconis.neurocam (draconis.neurocam): i dont see the point of tacking on functionality that already exists to other functions

[09:40] Kaluura (kaluura.boa): Sure...

[09:40] Kitteh Scientist: objectDetails already get the owner and the creator.

[09:40] Haravikk (haravikk.mistral): Sometimes you don't know if you're handling an object or an avatar with it, so it just seems an easier way to get a useful name out of the call

[09:41] Kaluura (kaluura.boa): It true that it would spare a call and a few ms of script time.

[09:41] Kaluura (kaluura.boa): It's*

[09:41] draconis.neurocam (draconis.neurocam): are you doing it in sim, the best filter ive found is llGetAgentSize

[09:41] tehKellz (kelly.linden): a few nanoseconds, not ms.

[09:41] Kaluura (kaluura.boa): Whatever...

[09:41] tehKellz (kelly.linden): :p

[09:42] Kitteh Scientist: llGetAgentSize works only in sim. better to test with if(llGetOwnerKey(id) == id){ // agent }

[09:42] Haravikk (haravikk.mistral): It's just that with legacy name essentially being deprecated then functions should surely have alternatives where possible?

[09:42] draconis.neurocam (draconis.neurocam): ah

[09:43] Alex Hickman (eric.dielli): o_o

[09:43] Alex Hickman (eric.dielli): am I interupting?

[09:43] draconis.neurocam (draconis.neurocam): oh thats sort of valid i guess haravikk

[09:43] draconis.neurocam (draconis.neurocam): i see your point

[09:43] Haravikk (haravikk.mistral): In this case you don't even need to test if it's an avatar, just try to grab their display name and see if it works, but it just doesn't seem like you should have to really

[09:44] Kitteh Scientist: not interrupting Eric, This is unofficial meeting to talk about LSL related stuff with our lovely Kelly, you are welcome

[09:44] Haravikk (haravikk.mistral): Very minor granted, but also probably very trivial to implement

[09:44] draconis.neurocam (draconis.neurocam): i will also just say that i miss llCollisionSprite even though i know it probably wont get fixed

[09:44] Haravikk (haravikk.mistral): Is there an issue for it? It's probably a viewer bug so easily fixable?

[09:45] Kaluura (kaluura.boa): Never seen that thing. What is that? An explosion of particles on collision?

[09:45] draconis.neurocam (draconis.neurocam): all colliding objects used to have particles

[09:45] draconis.neurocam (draconis.neurocam): by default, a loooong time ago

[09:45] tehKellz (kelly.linden): VWR-322

[09:45] flexi campfire:

[#VWR-322] llCollisionSprite broken in newer releases.

[09:45] draconis.neurocam (draconis.neurocam): that set the texture

[09:45] tehKellz (kelly.linden): viewer 2 removed all collision sprites, apparently

[09:45] Latif Khalifa: collision sounds still work, no?

[09:45] tehKellz (kelly.linden): user-set or not

[09:46] draconis.neurocam (draconis.neurocam): yes latif

[09:46] Kaluura (kaluura.boa): It disappear long before that! I'm 4 y.o. and I've never seen that.

[09:46] Haravikk (haravikk.mistral): Hmm, user-set ones should really stay though? Only workaround is rezzing an object with a particle system, which is a horrible fix

[09:46] Haravikk (haravikk.mistral): But it seems like something to bring up at the viewer evolution meetings maybe?

[09:47] draconis.neurocam (draconis.neurocam): possibly, oz is a one man team though, so i doubt it would get work

[09:48] draconis.neurocam (draconis.neurocam): i mean he has product engine people, but still

[09:48] Calcite (calcite.serendipity): 2 of those PE people are working for the mesh group now, leaving 1 programmer

[09:48] draconis.neurocam (draconis.neurocam): right

[09:48] Latif Khalifa: just don't tell oz it's something that was working in viewer1. he gets all upset :P selling it as new feature works better :p

[09:49] tehKellz (kelly.linden): haha

[09:49] draconis.neurocam (draconis.neurocam): "its a new feature, and magically the servercode exists"

[09:49] Kaluura (kaluura.boa): It's high time meshes come out of the closet. Not much get done while waiting for them.

[09:49] Kallista Arliss (kallista.destiny): laughs

[09:49] Haravikk (haravikk.mistral): Well if it's code that's just missing from the old viewer then it might be more of a copy/paste and tweak fix? Something an open source person could do through that project?

[09:49] Calcite (calcite.serendipity): Latif, is the server still sending those packets?

[09:49] Latif Khalifa: i have no idea. biti will take a look with a proxy later on

[09:49] draconis.neurocam (draconis.neurocam): actually the best part is

[09:50] draconis.neurocam (draconis.neurocam): i doubt the viewers that supported the particles were even opensource

[09:50] draconis.neurocam (draconis.neurocam): it was before we have viewer source to look at

[09:50] draconis.neurocam (draconis.neurocam): we had*

[09:50] Latif Khalifa: i don't need the source code to reverse engineer the protocol, in fact i only use traffic inspection

[09:50] Latif Khalifa: "clean room reverse engineering" ;)

[09:50] tehKellz (kelly.linden): I'm not seeing anything with 'sprite' or 'collision' in the message template.

[09:51] Calcite (calcite.serendipity): Wouldn't displaying the collision just be like the whily dots when an object speaks?

[09:51] tehKellz (kelly.linden): erm, that relate

[09:51] Latif Khalifa: perhaps it's a prim property.

[09:51] Haravikk (haravikk.mistral): It is

[09:52] Haravikk (haravikk.mistral): Just like collision sound

[09:53] tehKellz (kelly.linden): I don't think that collision sprite data ever makes it to the viewer

[09:53] tehKellz (kelly.linden): Congrats you just found a UUID you can store per script. Looks like is serializes out with the rest of it.

[09:53] Latif Khalifa: hehe

[09:53] draconis.neurocam (draconis.neurocam): per script, or prim?

[09:53] tehKellz (kelly.linden): oh but there is no accessor. bummer

[09:53] draconis.neurocam (draconis.neurocam): right

[09:54] draconis.neurocam (draconis.neurocam): i propose a new function

[09:54] draconis.neurocam (draconis.neurocam): muahahha

[09:54] Latif Khalifa: i wil inspect object update to see if it's in the key value pairs there

[09:54] tehKellz (kelly.linden): ok, looks like it is actually server side. We commented it out when we did the new particle system.

[09:55] tehKellz (kelly.linden): 'make_impact_cloud'

[09:55] draconis.neurocam (draconis.neurocam): booo!

[09:55] tehKellz (kelly.linden): *ages ago*

[09:55] Latif Khalifa: oh well :)

[09:55] draconis.neurocam (draconis.neurocam): so it is a svc issue then and not viewer

[09:55] tehKellz (kelly.linden): looks that way

[09:56] tehKellz (kelly.linden): 4 more minutes

[09:56] Haravikk (haravikk.mistral): Maybe import to SCR since it's a function?

[09:56] Latif Khalifa: it probably got killed in the viewer code too

[09:56] Haravikk (haravikk.mistral): That's very annoying though as it's a feature that you can't really simulate, not well anyway

[09:56] Calcite (calcite.serendipity): Kelly, can you say anything about improving the coarse object update protocol so we can see what heights things are at accurately?

[09:57] tehKellz (kelly.linden): Nothing very good Calcite.

[09:57] Calcite (calcite.serendipity): Simon mentioned something about something new being discussed

[09:57] tehKellz (kelly.linden): I think that system needs to be replaced, but I don't know when we would get to it.

[09:57] tehKellz (kelly.linden): I don't know anything about that.

[09:58] Calcite (calcite.serendipity): We only need 2 more bits in some packet to get by :)

[09:58] Latif Khalifa: i suggested adding another block to that message, but they were weary about it since that packet is sent a lot

[09:58] tehKellz (kelly.linden): the problem is we've been tacking things onto that system too much.

[09:59] tehKellz (kelly.linden): and we send too much info too often with it already, yes.

[09:59] Haravikk (haravikk.mistral): Time for binary xml messages for everything mb?

[10:00] Haravikk (haravikk.mistral): Or at least the big ones

[10:00] Latif Khalifa: there was a nice little bug introduced and fixed recently where a region would stop sending coarse updates to child agents if it was empty

[10:00] Latif Khalifa: this resulted in "ghost dots" on the map since when the last agent left the region, agents in the neighbours would never hear about it ;)

[10:01] tehKellz (kelly.linden): heh neat.

[10:01] tehKellz (kelly.linden): ok, I have to go. Thanks everyone for coming.

[10:01] draconis.neurocam (draconis.neurocam): thanks kelly

[10:02] Latif Khalifa: thank you for your time kelly :)

[10:02] Kitteh Scientist: traveling the grid left a trail of dots behind you ^^