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

From Second Life Wiki
< User:Ama Omega‎ | archive‎ | Office Hours
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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"