User:Ama Omega/archive/Office Hours/2010-10-11

From Second Life Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

List of Attendees

Transcript

[12:56] Gazanfer Jehangir: hi kelly
[12:56] Kelly Linden: hello
[12:57] Gazanfer Jehangir: your av says they worked you to death?
[12:57] Kelly Linden: heh
[12:58] Talarus Luan: Arrr.. 'e's a pirate!
[12:59] Latif Khalifa: hello
[12:59] Kelly Linden: Give it a couple more minutes for people to show up.
[13:00] Kelly Linden: was hoping to see Haravikk since he was the only one to post items to discuss: https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[13:01] Talarus Luan: Oh.. didn't realize
[13:01] Talarus Luan: sec
[13:03] Kelly Linden: All right. Hello everyone.
[13:03] Kaluura Boa: Cough cough! A minute of silence for the lost prims?
[13:03] Kelly Linden: For those that just arrived: https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[13:03] Haravikk Mistral: Am I the only one that added anything this week?
[13:04] Kelly Linden: Apparently so.
[13:04] Kelly Linden: This is the first trial of this process, so we will see how it goes.
[13:04] Kaluura Boa: Very busy Haravikk...
[13:04] Haravikk Mistral: d'oh, I meant to add some by other reporters that I was interested in too but I ever so slightly forgot...
[13:05] Talarus Luan: I added mine
[13:05] Latif Khalifa missed oh where the triage was anouced
[13:05] Kaluura Boa: I'm gonna vote for all of them...
[13:05] Overbrain Unplugged: howdy
[13:06] Kelly Linden: Well lets start with * SVC-4323[c] - Casting a list with a vector to string, differs from casting a vector to string - 1 vote - Haravikk Mistral
[13:06] flexi campfire: https://jira.secondlife.com/browse/svc-4323 [c]
[13:06] Overbrain Unplugged: is there going to be viewer 2 media shown here?
[13:06] Kelly Linden: the media just points to the wiki page I pasted: https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[13:06] Overbrain Unplugged: ok thanks Kelly
[13:07] Haravikk Mistral: Is a bit of a tricky one that, as it's hard to see any cases that would rely on the incorrect behaviour, there's nothing that I'm aware of anyway, it's super minor but /should/ be a simple fix to use the same function as everywhere else?
[13:07] Kelly Linden: So. I agree it is a bug, I also agree that it is a minor bug.
[13:07] Kelly Linden: Yeah should be pretty simple.
[13:07] Talarus Luan: Just a formatting bug
[13:08] Talarus Luan: %.5f to %.6f or whatever
[13:09] Kaluura Boa: * PUUURRRRZZZZ *
[13:09] Kelly Linden: I'll see if I can take a look soon, but no promises. I'll move it to .... um .....
[13:09] Kelly Linden: there is no option past 'awaiting review' that isn't resolving the issue?
[13:09] Danilo Roi: qulcuno italiano?
[13:09] Haravikk Mistral: I thought there was in-progress?
[13:09] Elbereth Witte: assigned?
[13:10] Kelly Linden: I assigned it, but it is still 'awaiting review' I will bug our jira people
[13:10] Latif Khalifa: perhaps to add "Accepted" status
[13:10] Kelly Linden: yeah I think that is just missing for the SVC issues
[13:11] Danilo Roi: italiani?????
[13:11] Haravikk Mistral: Hehe, thanks! Isn't many benefits to the fix, but it is useful for some quick comparisons that I like to do in favour of more involved checks for element type
[13:11] Ellla McMahon: Kelly, can you change the status to Acknowledged ?
[13:12] Kelly Linden: I don't think I can
[13:12] Kelly Linden: it is not an option for me
[13:12] Kelly Linden: maybe I'm not yet in the right jira group. Anyway I will resolve that later and fix it up.
[13:13] Kelly Linden: NEXT
[13:13] Kelly Linden: # SVC-924[c] - llSit() - scriptable ability to force an avatar to sit on an object - 7 votes - Haravikk Mistral
[13:13] flexi campfire: https://jira.secondlife.com/browse/svc-924 [c]
[13:13] Ellla McMahon: hmmm as a Linden you should be able to !!! :))
[13:13] Kelly Linden: I know ella. :)
[13:13] Kelly Linden: we are on to feature requests.
[13:13] Overbrain Unplugged: This one sounds like a script meant to make life easy for bots
[13:14] Latif Khalifa: This one would require a protocol and viewer change, imho too big a change
[13:14] Kelly Linden: This is probably a bit of work.
[13:14] Kelly Linden: I'm not sure if it would involve viewer change or not. I'd like to think I could cause an AV to sit w/o changing the viewer.
[13:14] Haravikk Mistral: Not my intention, it has a lot of other uses I think, and it's intended for use with sit-targets, surely that's mostly a server side thing?
[13:15] Latif Khalifa: Kelly, you need to ask for permission
[13:15] Talarus Luan: If it has to do dialogs, probably a viewer change too
[13:15] Kelly Linden: (also, Haravikk - I'm a him, not a her. ;) )
[13:15] Kelly Linden: It will require permissions, true.
[13:15] Latif Khalifa: there is no generic way in the protocol for server to ask viewer stuff
[13:16] Latif Khalifa: afaik
[13:16] Kelly Linden: I'm not up on the Viewer 2 ways, but pre-viewer2 we could add new LSL runtime permissions w/o modifying the viewer.
[13:16] Haravikk Mistral: It could be done as a permission, but that seems a bit too heavy for it
[13:16] Kelly Linden: It may not have been internationalized though.
[13:17] Kelly Linden: Ok, if it is *not* a permission then it requires even more work.
[13:17] Kelly Linden: but it acts just like an lsl runtime permission, so I'm not sure why it would be something else.
[13:18] Haravikk Mistral: Well, I'd just be happy if it were added, was just saying it doesn't like a permission type thing, but if that's the easier way then it'd suit me =)
[13:18] Kelly Linden: you want an object to be able to sit you, but only if you approve of that object doing it.
[13:19] Haravikk Mistral: Hmm, true, well, either way is great, especially if permission is easiest then ^^
[13:19] Overbrain Unplugged: hmm I can see this as something ripe for abuse
[13:20] Overbrain Unplugged: shooting spammed bullets which all demand the garget give permissions for you to sit on them
[13:20] Overbrain Unplugged: the target
[13:20] Haravikk Mistral: No more than any other permissions spam?
[13:20] Talarus Luan: Yeah.. animate you spam happens
[13:20] Talarus Luan: The viewer already limits those
[13:20] Kelly Linden: Right, that is an existing issue and wouldn't be new to this.
[13:20] Overbrain Unplugged: limits it per object
[13:20] Overbrain Unplugged: or per avatar?
[13:20] Talarus Luan: 5-10 requests, and the rest get ignored.
[13:21] Overbrain Unplugged: mkay
[13:21] Overbrain Unplugged: I remember once spending my afternoon buried in spam
[13:21] Haravikk Mistral: If you mute an object owner I think it mutes their objects too now as well I think?
[13:21] Overbrain Unplugged: so still have PTSDs over that
[13:22] Talarus Luan: It should
[13:23] Kelly Linden: Ok, I'm gonna add my comments and set a triage date, but I'm not gonna assign this one to myself as it is more work than I can just pick up.
[13:23] Kelly Linden: This is not an issue I would expect to see investigated further soon.
[13:24] Kelly Linden: NEXT
[13:24] Kelly Linden: # SVC-2988[c] - Convert llListSort() to use faster sorting methods! - 49 votes - Haravikk Mistral
[13:24] flexi campfire: https://jira.secondlife.com/browse/svc-2988 [c]
[13:24] Kaluura Boa: Please!
[13:24] Kelly Linden: that [c] screws up my jeffbot.
[13:25] Kelly Linden: For LSL or Mono?
[13:25] Talarus Luan: Both :P
[13:25] Kaluura Boa: Both... But Mono only would be a start
[13:25] Talarus Luan: Speeding up LSL is as good a reason as speeding up Mono
[13:25] Talarus Luan: Since it would be a drop-in change
[13:26] Kelly Linden: I have some plans to optimize mono's llList* functions which are insanely poorly optimized right now
[13:26] Talarus Luan: All existing scripts would be affected.
[13:26] Haravikk Mistral: Oh, well if this could be added to that then that'd be awesome ^^
[13:26] Haravikk Mistral: The way that llListSort() works unfortunately makes it more difficult, but a new sort function for non-strided lists could certainly be a LOT faster using merge or heap sort
[13:27] Talarus Luan: Should almost be a drop-in fix.. bubblesorting is not that much different than quicksorting at the functional level.
[13:27] Haravikk Mistral: Either speed up of llListSort or a new sort function would help a great deal though
[13:27] Overbrain Unplugged: this sounds like a great idea
[13:27] Elbereth Witte: sounds like just a special case for stride = 1
[13:27] Latif Khalifa: i wonder how you know which algorithm is used? and how can you tell the difference at LSL size scripts?
[13:28] Kelly Linden: That is a good question - LSL scripts rarely go above 100 elements, and will sort in a single frame.
[13:28] Kelly Linden: lists in LSL scripts that is
[13:28] Latif Khalifa: yeah, that's what i meant, sorting by hand at that size would be fast ;)
[13:29] Haravikk Mistral: LSL currently just uses bubble sort I believe, which is O(n^2) I believe, an O(log(n)) algorithm should still outperform that even with small lists
[13:29] Latif Khalifa: Haravikk, how do you know?
[13:29] Talarus Luan: Do the math :)
[13:29] Kelly Linden: It would be interesting to benchmark. At that list size, I bet the general overhead in LSL scripts overshadows the difference
[13:29] Haravikk Mistral: If it's a concern though then a separate function would be best, so we have the choice if it does become an issue of trade-offs
[13:30] Talarus Luan: It is O(n log(n)), btw
[13:30] Talarus Luan: The main issue with short lists is the difference in overhead setting up the quicksort, but it really isn't all that much extra.
[13:31] Talarus Luan: Probably 10 items' equivalent or so
[13:31] Kelly Linden: It is, for the record a bubble sort on a singly linked list.
[13:32] Kelly Linden: I'd like to wait on this one for the other list optimizations. I don't think a faster LSL sort is going to make a noticable difference
[13:33] Kelly Linden: not at the list sizes we are discussing
[13:33] Kelly Linden: If anyone has a benchmarking script they use for lists that they want to add to the jira that would be helpful. Especially if they can demonstrate how painful list sorting is.
[13:34] Kelly Linden: I'd like to mark this one as 'deferred'
[13:34] Elbereth Witte: just list element read/write is horrifically slow I think, could just be me though
[13:34] Gazanfer Jehangir: see you friends
[13:34] Haravikk Mistral: k, I'll try and make a simpler case of one of my worst scripts for sorting
[13:34] Gazanfer Jehangir: i got a flame to catch
[13:34] Talarus Luan: Quicksort on singly-linked is a little bit of a pain, but not significantly more than a bubblesort.
[13:35] Overbrain Unplugged: well lets go with the typical list you get from a sensor read, 16 avatars and their keys and other data
[13:35] Talarus Luan: http://www.flipcode.com/archives/Quick_Sort_On_Linked_List.shtml
[13:35] Latif Khalifa: i still don't think you're going to see much of a difference on lsl size lists
[13:35] Elbereth Witte: even that isn't a list :-/
[13:35] Talarus Luan: There's one for a doubly-linked list. Just have to add a bit of code to handle the singly-linked situation.
[13:36] Overbrain Unplugged: the sensor return is probably the most frequent list thats sorted
[13:36] Elbereth Witte: but first it has to be made into a list
[13:36] Elbereth Witte: :-/
[13:36] Fiuk Roi: vc é brasileiro?
[13:37] Kelly Linden: Ok, I've commented and marked as deferred and set the triage date.
[13:37] Kelly Linden: NEXT
[13:37] Kelly Linden: # SVC-6326[c] - Remove llInstantMessage delay for avatars in region - 1 vote - Haravikk Mistral
[13:37] flexi campfire: https://jira.secondlife.com/browse/svc-6326 [c]
[13:37] Fiuk Roi: quem é braisleiro aqui?
[13:37] Talarus Luan: That and llEmail
[13:37] Kelly Linden: Sadly we don't think we can remove delays on existing functions.
[13:37] Kaluura Boa: svc-6326
[13:37] flexi campfire: https://jira.secondlife.com/browse/svc-6326
[13:37] Elbereth Witte: oh, niceish, throttles may still be needed for flooding concerns though
[13:38] Haravikk Mistral: Ah, well a new one would be nice, like the other ll*Fast functions?
[13:38] Talarus Luan: Wasn't there an extension to the http project rate limiter that was going to be done for llInstantMessage and llEmail?
[13:38] Kaluura Boa: llInstantMessageFast()? =^_^=
[13:38] Kelly Linden: (testing) # SVC-6326[c] - Remove llInstantMessage delay for avatars in region - 1 vote - Haravikk Mistral
[13:38] flexi campfire: https://jira.secondlife.com/browse/svc-6326
[13:38] Kelly Linden: better
[13:38] Lares Carter: llReallyInstantMessage() ?
[13:38] Kaluura Boa: =^_^=
[13:38] Kelly Linden: llInstantMessageFastIfNearby
[13:39] Haravikk Mistral: It's preferable to use llInstantMessage over llSay for single person chat, but it's too slow meaning it needs helper scripts
[13:39] Talarus Luan: yeah, everyone gets around the delay anyway
[13:39] Overbrain Unplugged: llHayBuddeh
[13:39] Talarus Luan: 20, 50, 100 scripts
[13:39] Haravikk Mistral: llInstantMessageFastLocal()?
[13:39] Kelly Linden: We have llOwnerSay
[13:39] Kelly Linden: Maybe llTargetSay ?
[13:39] Kaluura Boa: Exactly... Or else your script is blocked for 2 seconds... That's an eternity for a script
[13:39] Elbereth Witte: at this rate, should probably make a function that controls function charactestistics, llUseUpgrade([FAST_IMS, TRUE]);
[13:40] Kelly Linden: Elbereth that will have to wait for a post-LSL language.
[13:40] Haravikk Mistral: Ah, that's a good point actually, target say might be a better solution, as it's rare to need the offline capability of llInstantMessage()
[13:40] Elbereth Witte: possibly won't be needed for post-lsl
[13:40] Kelly Linden: exactly
[13:40] Elbereth Witte: no would be fine then :-)
[13:40] Kelly Linden: :)
[13:40] Kelly Linden: I like "llTargetSay"
[13:41] Talarus Luan: Would be nice if you allowed that for objects, too :D
[13:41] Latif Khalifa: If we were to remove some sleeps I'd go with llEmailThrottled, i often need to send 4-5 emails rapidly, and then nothing for hours, 20 sec sleep in email is killing me
[13:41] Kelly Linden: Talarus I would see no reason not to.
[13:41] Elbereth Witte: well, following the ownersay thread, llAgentSay(id, text);?
[13:41] Kaluura Boa: Does the name imply that it could only be used in a script in the prim with the sit target?
[13:41] Talarus Luan: Well, I would presume it would need a channel
[13:41] Talarus Luan: Since it would logically go to the listen() event
[13:42] Talarus Luan: Nice secure object->object comms would be sweet
[13:42] Kelly Linden: llTargetSay(key id, integer channel, string message)
[13:42] Talarus Luan: Cool. :)
[13:42] Lares Carter: ohh i really like that
[13:42] Talarus Luan: and for avs, channel would be 0 or ignored?
[13:42] Elbereth Witte: hmm, this sounds like a change as big an llRegionSay()
[13:42] Kaluura Boa: If we can speak to objects, sure!
[13:43] Haravikk Mistral: Could take a ton of weight off of scripted object communications
[13:43] Talarus Luan: yus
[13:43] Haravikk Mistral: I didn't even think of that hehe, just wanted to speak to avatars faster =D
[13:43] Talarus Luan: Can roll several JIRAs into one! :D win!
[13:43] Elbereth Witte: hmm, which makes me wonder, is it better for teh server to have 1000 objects listening on teh same channel, or on all different channels
[13:44] Talarus Luan: Well, targeted says would bypass the listen deal.
[13:44] Haravikk Mistral: Different I assume, as filtering an integer is faster than leaving it up to the scripts to do themselves
[13:44] Kaluura Boa: Question: What or who would listen if you don't speak on channel 0 to an av?
[13:44] Talarus Luan: the part where it figures out if you are in range
[13:44] Kelly Linden: you can specify an ID for the agent, but it may not be helpful
[13:44] Talarus Luan: That's the CPU hog-part of the chat comms checks
[13:44] Kelly Linden: sorry, a channel I mean
[13:45] Kelly Linden: there is a script error channel, for example
[13:45] Haravikk Mistral: Sim would probably just discard non-zero to an avatar mb? Unless we wanted to support script communication with a viewer?
[13:45] Elbereth Witte: do viewers recieve off channel comms?
[13:45] Talarus Luan: Yeah, I would imagine that an agent wouldn't hear anything other than on channel 0, so I would just ignore the channel for agents
[13:45] Kaluura Boa: Ho yeah! That could be useful any way...
[13:45] Talarus Luan: Assume it is 0 if (key id) is an agent
[13:45] Elbereth Witte: eh, I'd let it get discarded to an AV, to allow it to work in the future
[13:45] Kelly Linden: I think we would do what we normally do with non-0 comms to an agent. We wouldn't ignore the channel, but it may only work well with 0.
[13:46] Talarus Luan: I don't think anything other than 0 and DEBUG_CHANNEL is sent to viewers
[13:46] Talarus Luan: Could be wrong though.
[13:46] Elbereth Witte: my main concern is that its another world shrinking function
[13:46] Talarus Luan: Objects get swirly particles when they talk.
[13:46] Kelly Linden: I'd rather drop non-0/debug_channel msgs on the floor now than create the expectation that channel 42 will always go to an agent.
[13:46] Elbereth Witte: agreed
[13:47] Talarus Luan: yup
[13:47] Kelly Linden: it will only work on objects that are within the region
[13:47] Kaluura Boa: Agreed too
[13:47] Talarus Luan: Yeah, it is a targeted llRegionSay
[13:47] Kaluura Boa: The servers will like it..
[13:48] Elbereth Witte: it defies nature, otherwise, neatish
[13:48] Talarus Luan: I would still love a way to do it across sims, like named pipes or something, but I'll take what I can get for now. :D
[13:48] Kelly Linden: I'm actually not sure how much more or less work it will be for the servers. I need to refresh my memory on our chat subsystem
[13:48] Elbereth Witte: I assume work on regionsay kiccked down some doors
[13:48] Kelly Linden: commented and triage date added.
[13:49] Kelly Linden: Does someone want to make a new jira for me for llTargetSay? If not I can make one later.
[13:49] Kelly Linden: I'm gonna mark this 'won't finish' for now, and link to the other when it is made
[13:49] Haravikk Mistral: Should I just repurpose that one?
[13:49] Haravikk Mistral: Is fairly new after all
[13:49] Elbereth Witte: I'm wary of teh name, given set target and move to tagret functions and such
[13:50] Kelly Linden: lets go for a new one, I think. <shrug> doesn't really matter. I will leave it up to you haravikk.
[13:50] Kelly Linden: time for 1 more I think
[13:50] Talarus Luan: baw. :P
[13:50] Kelly Linden: # SVC-6364[c] - Automatically optimise calls to llGetListLength(list) by replacing them with (list != []) - 1 vote - Haravikk Mistral
[13:50] flexi campfire: https://jira.secondlife.com/browse/svc-6364
[13:50] Kelly Linden: EWWW
[13:50] Techwolf Lupindo: Hi all
[13:50] Kelly Linden: I hate that ugly hack.
[13:50] Talarus Luan: Compiler optimizations... <.<
[13:50] Kelly Linden: Tell you what though, I can make the mono one nearly instant.
[13:51] Kaluura Boa: I love it... I don't even use llGetListLength() anywhere
[13:51] Haravikk Mistral: Me neither, a != [] is better all around at the moment
[13:51] Kaluura Boa: And it's much faster to type
[13:51] Kelly Linden: Right now mono sucks at lists because it converts them from a standard container to an LSL singly linked list when you pass it to (many) functions.
[13:52] Elbereth Witte: so many functions need to be rewritten, so suffered while a non-lsl is created
[13:52] Haravikk Mistral: Yeah, 'twas the main reason for any scripts that saw no improvement under Mono
[13:52] Kelly Linden: The optimizations I mentioned before are to move as much as possible to the managed-code (mono) side so we don't convert the lists. Getting the list length is a simple matter in mono.
[13:53] Kelly Linden: Other ones I want to get are llList2String and similar, and some math functions.
[13:53] Haravikk Mistral: Hmm, well if that'll end up adding a new (much better?) alternative then I'm all for that
[13:53] Kaluura Boa: Please, do... Anything to speed up our poor lists will be welcome!
[13:53] Elbereth Witte: kelly++
[13:53] Kelly Linden: I can't wait for a post-lsl world with real containers and objects and structs and and and
[13:54] Latif Khalifa: i hope you will be able to upgrade to profile2 at some point 1.1 is dead end, and it's even removed from mono 2.8
[13:54] Kaluura Boa: 2050... Don't hold your breath...
[13:54] Kelly Linden: I'm gonna mark that one 'won't finish' - touching the compiler at that level is tricky at best, and I'd probably screw it up. And I'm going to try and improve the mono list functions anyway
[13:55] Haravikk Mistral: k!
[13:55] Kelly Linden: Latif: profile 2 is (on the backend, for LSL on mono) in testing now.
[13:55] Kelly Linden: on mono 2.6.7
[13:55] Latif Khalifa: wow, great
[13:55] Latif Khalifa: generics ftw :)
[13:56] Talarus Luan: Next? :)
[13:57] Kelly Linden: ok one more
[13:57] Kelly Linden: # SVC-6357[c] - llGetUnixTimeNanos() - greater precision timing mechanism - 1 vote - Haravikk Mistral
[13:57] flexi campfire: https://jira.secondlife.com/browse/svc-6357
[13:57] Talarus Luan: Would rather have a nanosecond integer count.. float is a bit.. imprecise.
[13:57] Elbereth Witte: timestamp is not precise enough, given the poopy scheduling currently in LSL?
[13:57] Latif Khalifa: hmm trying to get that precision when sims randomly sleep for seconds at the time is... a bit optimistic ;)
[13:57] Haravikk Mistral: Possibly simple one, is just you need like six or seven function calls to get a milli or nano time from llGetTimestamp()
[13:59] Kelly Linden: I don't think it would be hard, but I too question the overall value when applied to LSL
[13:59] Kaluura Boa: You could use just llGetSubString()...
[14:00] Haravikk Mistral: Well right now you can't even time things down to the half-second properly as llGetGMTclock() only returns seconds, and llGetTime (the only function that provides greater accuracy?) is too unreliable
[14:00] Talarus Luan: Might come in handy for authentication/encryption stuff.
[14:00] Elbereth Witte: hmm, I agree, a good tiing method that works down to centisecs would be GREAT
[14:00] Overbrain Unplugged: llAtomicTime?
[14:00] Kaluura Boa: =^_^=
[14:01] Haravikk Mistral: And llGetTimestamp() is converting bits to text only to be converted back again =)
[14:01] Overbrain Unplugged: llPlanckTime
[14:01] Elbereth Witte: hmm, true, a function that ruterns chunks of time in a list might be nice
[14:01] Kelly Linden: I'm gonna think about this one and we will wrap it up first on the next triage.
[14:01] Talarus Luan: Well, since we won't get to my two today, please do at least have a look at them (and vote if you like them! :D ): SVC-5742 and SVC-6350
[14:01] Latif Khalifa: exposing Environment.TickCount might be easy (end almost free), just not sure how big a resolution you could get in LSL script
[14:01] flexi campfire: https://jira.secondlife.com/browse/svc-5742
[14:01] flexi campfire: https://jira.secondlife.com/browse/svc-6350
[14:01] Kaluura Boa: Yeah... It's true that llGetTimeStamp() is a weird thing with its string value...
[14:02] Kelly Linden: Thanks everyone for coming. I'm going back to 9am next week. Next week will be a general scripting discussion OH.
[14:02] Kaluura Boa: scv-5742, definitively!
[14:02] Elbereth Witte: if only string-fu was faster
[14:02] Talarus Luan: Aye, I want my av down far below its current 2.0ms script time. :(
[14:02] Kelly Linden: I think this triage went well, if anyone has any suggestions for the process let me know - kelly@lindenlab.com.
[14:02] Haravikk Mistral: Is why I went for a list with integer and float pair, the integer is usable alongside llGetUnixTime() just fine, and the float is useful since that's what llSetTimerEvent() expects
[14:02] Haravikk Mistral: More people adding items ^^
[14:03] Kelly Linden: Also yes, add items. We will get to them at the next triage in 2 weeks
[14:03] Talarus Luan: I'll definitely add some more :D
[14:03] Kaluura Boa: Next time...
[14:03] Overbrain Unplugged: I dont know if I'm ignorant, but I'd really really like llSetLinkPrimativeParams to allow you to put a list of link numbers in one function if you need to modify a number of prims the exact same way but not all of the prims in a linkset
[14:03] Haravikk Mistral: Cool, thanks very much Kelly!
[14:03] Latif Khalifa: thaks for your time Kelly
[14:03] Haravikk Mistral: I posted a JIRA for that Overbrain, ehm...I'll have to hunt for it
[14:04] Talarus Luan: Yeah, I would like that too, Overbrain, but I am content with llSLPPF in a loop for those.. without the delay, it is fast enough for me.
[14:04] Kaluura Boa: llSetListLinkPrimitiveParams() or something
[14:04] Overbrain Unplugged: loops....
[14:04] Overbrain Unplugged: gotta make it more complex
[14:04] Kelly Linden: We will at least discuss any issue on the triage list. :)
[14:04] Elbereth Witte: and in LSL's hands, slower
[14:05] Haravikk Mistral: SVC-2105 Overbrain
[14:05] flexi campfire: https://jira.secondlife.com/browse/svc-2105
[14:05] Elbereth Witte: but, I'm wondering how well the server/client handles lots of fast changes anyway
[14:05] Kelly Linden: Thanks all. I'm gonna grab the log to post and get back to (other) work.

Generated with SLog Wikifier

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Ama_Omega/archive/Office_Hours/2010-10-11&oldid=1142495"