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

List of Attendees

• Danilo Roi
• Elbereth Witte
• Ellla McMahon
• Fiuk Roi
• flexi campfire
• Gazanfer Jehangir
• Haravikk Mistral
• Kaluura Boa
• Kelly Linden
• Lares Carter
• Latif Khalifa
• Overbrain Unplugged
• Talarus Luan
• Techwolf Lupindo

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