Scripting User group/Transcripts/2011-03-14

== List of Attendees ==
*
*
*
*
*
*
== Transcript ==
[09:06]	:	hello Kelly
[09:07]	:	hello.
[09:07]	:	Hi Kelly
[09:07]	:	good morning. Sorry for being late.
[09:07]	:	morning
[09:07]	:	Kal, buy me RL gas chromatography system
[09:08]	:	Afternoon... Or maybe early evening...
[09:08]	:	=^_^= Sure... No problem...
[09:08]	:	everyone have a good weekend?
[09:08]	:	yea ^^
[09:08]	:	yeah, did you?
[09:09]	:	enh. I survived.
[09:09]	:	;)
[09:09]	:	so today is general topics.
[09:10]	:	First a project update: mono2-aware (to make way for new mono version and the stall fix went out to all of agni 2 weeks ago.
[09:11]	:	Is there a date for when it will go out on aditi?
[09:11]	:	Working now on getting all the versions on aditi updated so we can begin testing the actual mono2 upgrade there, hopefully later this week. But I wouldn't be surprised if it ended up pushed out to next week.
[09:11]	:	good to hear its soon at least
[09:12]	:	Bleh... Group chat failure... Can't ring the end of the recess...
[09:13]	:	The xmpp server was running again this morning
[09:13]	:	I haven't had a chance to play with that - how has it been working for you?
[09:13]	:	That may explain the "Starting session" and nothing after that
[09:14]	:	Doesn't work well so far...
[09:14]	:	heh
[09:14]	:	There were bugs but the basic function was there
[09:15]	:	"Unable to start a chat session... blahblah Go f*** yourself!"
[09:15]	:	I think that's what the headless viewer project is being done for -- to load test the xmpp stuff
[09:15]	:	Heh. Well I don't have any further scripting updates today. So open for general Q&A
[09:16]	:	We are also using it to load test the server, in combination with some bot-army stuff.
[09:16]	:	Why not llIntegerToHex()? This shouldn't be complicate...
[09:16]	:	Not complicated but rendered redundant with TheNextLanguage.
[09:17]	:	when we get the next language then?
[09:17]	:	Do you have a confirmed date for the arrival of The Next Language?
[09:17]	:	Nope, but eventually. Sometime. Probably. :)
[09:17]	:	hehe
[09:17]	:	Soom(tm)...
[09:17]	:	Soon*
[09:17]	:	untill then, we want new LSL functions to keep us intrested
[09:18]	:	I'm very resistant to adding functions that will pollute the namespace / api with functions that are trivial or already covered in more robust languages.
[09:19]	:	atleast give us some stuff we desperately need, like the ability to return with LSL
[09:19]	:	More interested in functions that specifically relate to interaction with the SL specific systems.
[09:19]	:	return objectsÄ
[09:19]	:	Yes, like that.
[09:19]	:	The problem with that is that LSL misses those basic things... And TheNextLanguage is not coming any time soon
[09:19]	:	set return timers, reclaim on estate owned land ,etc
[09:20]	:	It is only a few lines of code to do that anyway Kaluura.
[09:20]	:	Wasted memory...
[09:20]	:	I have a decision chart I should probably share, I think I just need to remove some names from it.
[09:21]	:	speaking of memory. YUou think it owuld be possible to get more script mem before the next language?
[09:21]	:	I will see if I can multitask to do that quickly.
[09:21]	:	-typos
[09:21]	:	Yes Well first 'small scripts' (set a lower upper-bound for mono scripts then limits then bigger scripts.
[09:21]	:	then the next language
[09:22]	:	Can we have PRIM_SLICE?
[09:22]	:	ah yes better control of prim deformations
[09:23]	:	I took a quick look at PRIM_SLICE. Adding it as a paramter on the existing shapes is way more difficult than it should be.
[09:23]	:	I also would like all params to be extended up to 0.98 instead of 0.95...
[09:23]	:	Would be easier to have the separate PRIM_SLICE parameter but ugly too.
[09:23]	:	0.99*
[09:23]	:	We don't mind ugly... as long as it usable.
[09:24]	:	yea, if we cant take the easy way, we rather take hard way than to not anything at all
[09:24]	:	I'll take another look at it then.
[09:24]	:	I think the issue is the hard way means x, y, and z don't get worked on for a while
[09:25]	:	There are also a lot llSetLink*( missing functions.
[09:25]	:	What do you mean kaluura?
[09:25]	:	llSLPP[F] is supposed to fill the gap but I still miss llLinkTextureOffset( for example
[09:26]	:	Ah, the ability to set some individual paramters for llSLPP?
[09:26]	:	particle and omega for example still missing from llSLPPFast
[09:26]	:	Yes...
[09:26]	:	Yes llSLPPF is still missing some.
[09:26]	:	TargetOmega, I'd like that one!
[09:27]	:	kelly have you ever thought of an automated system to update the syntax highlighting keywords in the viewer, so if something does change it wont lag behind, for instance we still don't have highlights for PRIM_ NAME, PRIM_DESC
[09:27]	:	Yes, I have.
[09:28]	:	or, even if it wasnt in the viewer, a keyword list file hosted somewhere that could be used to keep external editor syntaxs up to date
[09:28]	:	I'd love to have the sim send down a hash or version for a keword file and for the viewer to be able to request the file via cap if it had changed
[09:29]	:	The file now is an xml stored in the viewer tree?
[09:29]	:	not quite There are two files (at least one a plain text list of non-function keywords
[09:30]	:	And then the function/event keywords are pulled from the LSL compiler directly
[09:30]	:	It was partially if not totally reintegrated in the viewer source... Meaning: Not easy to change on the fly.
[09:30]	:	and kaluura what about setlinkparticlesystem, why does it need to be in primitiveparamsfast?
[09:30]	:	so the viewer would need to change to use a complete LLSD as the highlighting wsource
[09:30]	:	Not my words... It was Liisa's... And the wiki says: http://wiki.secondlife.com/wiki/LlLinkParticleSystem
[09:30]	:	err liisa nor kaluura sorry
[09:31]	:	(I checked)
[09:31]	:	i prefer everything to work trough primparamsFast so i can do the change in one hit and get better sync on stuff
[09:32]	:	particle systems are too complex
[09:32]	:	but i could be happy with separate function too. anything that helps me take out silly lil child scripts
[09:32]	:	I don't think you can achieve any synchronisation with particles... Too random.
[09:33]	:	You shouldn't need child scripts for particles with that function above.
[09:33]	:	yea, i would not, but untill we get it we need the child scripts
[09:33]	:	its out now
[09:33]	:	It's available already
[09:33]	:	im using it in my staff
[09:33]	:	it is? neat
[09:34]	:	yeah
[09:34]	:	:)
[09:34]	:	then the omega
[09:34]	:	You should check the list from time to time...
[09:34]	:	something we cant to is targetomega
[09:34]	:	yeah
[09:35]	:	also, and i imagine it isnt entirely your department, but even syntax highlighting on the wiki is lacking
[09:36]	:	hmm hmm, also llGetSimulatorAgentKeyList( eould be great improvement towards more efficient scripts
[09:36]	:	would*
[09:36]	:	I have comments on the jira for that. It isn't as easy as you would think!
[09:36]	:	There are interesting script and simulator memory repurcusions.
[09:36]	:	the easier solution would probably be a feed from the viewer
[09:37]	:	LL refuse to implement RLV in the official viewer...
[09:37]	:	it wouldnt be rlv
[09:37]	:	just entering or leaving, and key sent on a channel
[09:38]	:	RLV allows the viewer and script to talk to eachother
[09:38]	:	That's the interesting part.
[09:39]	:	Scripted clothing management might be interesting too...
[09:39]	:	Here is the new LSL function decision chart I left with my coworkers when I started my leave last november - it isn't perfect but pretty close to my general thinking http://screencast.com/t/9uLfvTwa
[09:39]	:	maybe not as easy as i think, but LL been in the path on improving performance and removing hundreds of flying sensors from the sims would prolly improve the performance a bit
[09:40]	:	yeah. Some event that triggered when agents entered or left the region and/or parcel would probably be the better approach.
[09:40]	:	though it makes it difficult to get the list on a region that already has people in it. Guess you fall back to sensors in that case.
[09:40]	:	yup
[09:41]	:	but i bet the sim has the list already, it must have, why cant we call it?
[09:41]	:	kelly do you mean by lines of sl, the input required, or the overall line count when formatting to be readable isnt an issue
[09:41]	:	lsl*
[09:41]	:	How does the viewer do for its radar? There must be a way to insert a hook...
[09:41]	:	It is just a rough first estimate of how difficult it is to do it in LSL
[09:42]	:	viewer uses CoarseLocationUpdate for "radar"
[09:42]	:	the server *has* a list of agents, that isn't the hard part.
[09:42]	:	It sounds like we are dancing a bit around client side scripting
[09:43]	:	We've been dancing for a while already...
[09:43]	:	The hard part is that returning a list that could right now be 100 uuids long is significant memory size for scripts, and means that if we ever increased the servers capabilities we may break scripts. While that probably falls in the 'tough love' case we'd really rather just not get into that case at all.
[09:43]	:	client side script would be ideal for this, except CoarseLocationUpdate is flawed
[09:44]	:	8-bit resolution
[09:44]	:	rather than return a long list how about a data server event response?
[09:44]	:	What, you want more than 8bits of resolution for height?
[09:44]	:	Who got that idea to store keys in strings instead of long integers? Sigh...
[09:44]	:	It would still be a long list
[09:45]	:	tehKellz, 8 bits gives you only 0-1024m with 4m resolution
[09:45]	:	yeah. I know Latif.
[09:45]	:	it should be 4096 really
[09:45]	:	and you can buld up to 4096... bunch of jiras about it
[09:45]	:	I know. I was joking.
[09:45]	:	It is horrible behavior for the current world.
[09:46]	:	so even client side would have trouble with it
[09:46]	:	how hard would it be to extend the packet from the server with some higher resolution fields added to the end?
[09:46]	:	AFAIK, the minimap of all the client show ppl underground when they are above 1024m
[09:46]	:	clients*
[09:46]	:	thats why
[09:46]	:	it would be better to replace it with a new packet.
[09:46]	:	it's very easy to add another block... but lindens were worried about the size of that message
[09:47]	:	yeah, we send those very frequently
[09:47]	:	Can't the current just be extended with a new value that will be invisible to older clients not aware of it?
[09:47]	:	current block*
[09:48]	:	adding blocks to message template can easily be done in backwards compatible way... i'd just add another byte per z, that would add 1 byte per agent on sim
[09:48]	:	you could add 1 byte which would show what group of ranges to use 0..1023, 1024..2047, etc
[09:48]	:	We did that once already to add UUIDs I think.
[09:48]	:	yes
[09:49]	:	OK! Sold! :P
[09:49]	:	heh
[09:50]	:	the viewer should really know about the current state of the server, leaving it unknowing like that is terrible in my opinion
[09:50]	:	10 minute warning.
[09:51]	:	Meaning: Type faster, Liisa! :P
[09:51]	:	btw, you know anything about the possible limits to llVolumeDetect? some linden told us that it will be removed from megaprims.
[09:52]	:	Falcon or andrew would know more about that.
[09:52]	:	currently volumedetect is the only way to make object really phantom, the kind of phantom that dont collide with terrain
[09:52]	:	VolumeDetect is really crappy performance wise so it wouldn't surprise me
[09:52]	:	The would break things...
[09:52]	:	That*
[09:52]	:	Falcon says all sorts of things... and then recants ;)
[09:53]	:	Liisa, I think the latest is that it wa't be removed
[09:53]	:	won't
[09:53]	:	it is crappy performance wise, but hot air balloon with volumedetect take 0.1ms from the sim while the same thig as normal phantom lag the sim like hell
[09:53]	:	I think they are adding more ways to adjust the physics representation of things with mesh.
[09:53]	:	anyway, if you dont know about it, lets talke about something else
[09:54]	:	ok. :)
[09:54]	:	What is the next function we should see arrive?
[09:54]	:	I don't have any in the pipe right now.
[09:55]	 	holds breath
[09:55]	:	I'm currently working on what happens to abandonded land.
[09:55]	:	i got 3 surveys from linden lab last week, whoever made them knows SL well, very good questions. i wrote c# scripting as my nr. priority for enhancing content creation in sl. hopefully others did too :)
[09:55]	:	Latif is that the 85 million question one?
[09:55]	:	i just think its odd to consider replacing lsl when there are no public plans at the moment
[09:55]	:	hope springs eternal :)
[09:55]	:	tehKellz yes
[09:55]	:	I couldn't believe the size, but I did give input on the scripting questions.
[09:56]	:	it had a lot of questions, but they were not silly like most surveys are.
[09:56]	:	showed that a lot of thought went into it
[09:56]	:	yeah, I just fear it is too long for many to bother finishing. Glad you did.
[09:56]	:	Is there a url for that survey or is it one of those random login ones?
[09:56]	:	I don't know how it was distributed
[09:56]	:	i finished it too, i hope the feedback is actually used
[09:57]	:	email i believe
[09:57]	:	i got two (and i have two premium accounts so it seems they went only to select group (premuim?)
[09:57]	:	I haven't been surveyed since the last time I refused...
[09:57]	:	They were targeting content creators, so I'm not sure how they chose the participants.
[09:57]	:	ah
[09:57]	:	Maybe they choose ppl from MarketPlace
[09:58]	:	could be
[09:58]	:	Maybe.
[09:58]	:	i disliked the word limit on some of write ins, heh
[09:58]	:	heh
[09:58]	:	heh, i never run into word limit
[09:59]	:	i hope you guys actually use the feedback though
[09:59]	:	well hopefully mono2 goes out live, and then it would be even more silly not not have c# scripting than it already is :)
[09:59]	:	I'll definitely read it.
[10:00]	:	i mean soon. if the mesh ppl wake up and merge it into their own ode
[10:00]	:	+c
[10:00]	:	Please, no! No more things tied to meshes!
[10:00]	:	well mono2 rollout is now tied to them
[10:00]	:	I'm actively working to keep scripting improvements from having a dependency on any other project, mesh included.
[10:01]	:	yea, people will hate mesh even before it arrive if mesh is to blame for not getting megaprims and stuff that has nothing to do with mesh
[10:01]	:	Right now, meshes are blocking a lot of things
[10:01]	:	tehKellz, then need -aware patch since half of aditi is mesh
[10:02]	:	yeah, we have two approaches to fix it. They are working on getting their dev branch suitable for aditi deploy, and on friday I merged the version already on aditi with the mono2-aware. Hopefully one of those can be deployed shortly.
[10:02]	:	fingress crossed :)
[10:03]	:	Ok! Thanks for coming. I'll figure out how to get this on a calendar.
 
Generated with SLog Wikifier