Scripting User group/Transcripts/2011-03-07

== List of Attendees ==
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
== Transcript ==
[09:03]	:	okay. I think we are on triage today
[09:03]	:	Calendar is broken because it sorts days alphabetically
[09:03]	:	https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[09:03]	:	Anyone in touch with haravikk?
[09:05]	:	Maybe if I start messing with his jiras he will magically show up.
[09:06]	:	GodLoginAndTeleport heh
[09:06]	:	SVC-6432 seems like a no brainer. Only trick is that sometimes the displayname won't be available
[09:06]	:	https://jira.secondlife.com/browse/svc-6432
[09:06]	:	not tiny friendly
[09:07]	:	(Use your AO)
[09:07]	:	the sofa can be tiny friendly, just select from the menu to not animate you, will remember your setting so you dont need to do it every week
[09:07]	:	Kelly, will you fix your fireplace jira-helper with the one I am about to give you -- the new one knows how to display the Summary correctly
[09:08]	:	SVC-1432
[09:08]	:	https://jira.secondlife.com/browse/svc-1432
[09:08]	 	
[00:00]	:	(#SVC-1432) llDetectedNormal() - provide normal vectors (or rotations) for collision events
[09:09]	 	has entered the area.))
[09:09]	:	Might eventually be useful... tho I don't for what right away...
[09:09]	:	I'd have to defer to Falcon for this one.
[09:10]	:	would be good for anything really, probably mostly mesh
[09:10]	:	https://jira.secondlife.com/browse/SVC-4632 ?
[09:10]	 	
[00:00]	:	(#SVC-4632) People getting past Estate and Land bans
[09:10]	:	On the LSL side - extending the data returned in llDetected* functions is kind of tricky, unfortunately. It isn't a very extensible system.
[09:11]	:	Neo: I keep a triage wiki page here: https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage feel free to add yours to the end of the new features section.
[09:11]	:	Thanks
[09:12]	:	For everyone else - I am working through that page now. :) moving on to the third.
[09:12]	:	SVC-377
[09:12]	:	http://jira.secondlife.com/browse/SVC-377
[00:00]	:	(#SVC-377) LSL functions to access the description of objects in an object's inventory
[09:12]	:	I wish that was easy.
[09:12]	:	Is that even possible?
[09:12]	:	Please, pretty please...
[09:12]	:	for some definition of possible, yes.
[09:13]	:	However the description is part of the asset, so we would have to fetch the inventory asset (akin to rezing it) to get that information, I think.
[09:13]	:	dataserver call?
[09:14]	:	Actually I may be wrong.
[09:15]	:	I think we could get the description.
[09:15]	:	We couldn't set it, but we could get it. Is that really useful?
[09:15]	:	Done and edited.
[09:15]	:	That would be a start...
[09:16]	:	isnt that how llRequestInventoryData for landmarks works?
[09:16]	:	well, it would be an 'end' too probably.
[09:17]	:	is the Set problem just as bad for the script's own description? ( https://jira.secondlife.com/browse/SVC-2382)
[09:17]	 	
[00:00]	:	(#SVC-2382) lsl functions llGetScriptDesc() and possibly llSetScriptDesc()
[09:17]	:	so you wouldn't be able to use it as a datastore. Yes Qie
[09:17]	:	okay, never mind. Thanks.
[09:18]	:	It'd be useful even without a setter function.
[09:18]	:	Ashur: can you give me some examples, all the ones in SVC-377 only make sense if you can set it as well I think.
[09:20]	:	Well, Haravikk makes a good case for storing parameter data for animations in their description.
[09:20]	:	I haven't read that JIRA, but I make my own vendor board when I need to sell something for example. A lot of times I'll butcher the objectname with a CSV to say...ItemName,VersionNumber
[09:21]	:	and if I could put some of the ugliness in description that'd be one case it'd make sense; where I had to manually set the description once anyway and not have to set it in any automated way.
[09:21]	:	There are two subtasks .... I'll comment on those specifically
[09:21]	:	I could have 5 objects named the same thing, with different metadata like version number.
[09:21]	:	alright
[09:21]	:	SVC-5892 and SVC-5893
[09:21]	:	http://jira.secondlife.com/browse/SVC-5892
[00:00]	:	(#SVC-5892) string llGetInventoryDesc(string name)
[09:21]	:	http://jira.secondlife.com/browse/SVC-5893
[00:00]	:	(#SVC-5893) llSetInventoryDesc(string name, string description)
[09:22]	:	especially since you cant edit the name of an attachment while its on you and have it saved, so people would have to live with the butchered object name
[09:22]	:	You can't have identically named items in object inventory I think.
[09:22]	:	Right I forgot about that; so that wouldn't change that aspect.
[09:22]	:	it adds numbers to the end i thought
[09:22]	:	but I like the idea of storing meta data or other properties in the description.
[09:22]	:	Yeah it does. My bad.
[09:26]	:	(ping)
[09:26]	:	PONG
[09:26]	:	Would it be possible to have a new differently handled property that would be settable in an inventory, or would they all suffer from the same problem?
[09:26]	:	sorry, updating jiras as we go.
[09:26]	:	They'd all suffer the same problem.
[09:26]	:	:( Thought you'd say that.
[09:27]	:	im still curious how it knows the position from landmarks then
[09:27]	:	draconis: it does an inventory fetch with the dataserver event
[09:27]	:	that doesn't mean it is a great idea.
[09:27]	:	ah
[09:27]	:	sorry for getting here late... is there an agenda?
[09:27]	:	I think I should hold off on SVC-6300 for Haravikk
[09:27]	:	http://jira.secondlife.com/browse/SVC-6300
[00:00]	:	(#SVC-6300) llStartAnimationSynced() - start an animation synchronised with a given timestamp
[09:28]	:	Working through triage today cummere https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[09:28]	:	ty
[09:28]	:	So, moving on to SVC-6441
[09:28]	:	http://jira.secondlife.com/browse/SVC-6441
[00:00]	:	(#SVC-6441) Allow us to decide which llDetected*() functions are populated to save on memory/processing
[09:29]	:	er, just a sec
[09:29]	:	what happened to start animation synched?
[09:29]	:	of sorry, you said
[09:29]	:	That is haravikk's baby. He is extremely invested in it - it would be unfair to discuss without him.
[09:29]	:	missed the comment
[09:30]	:	just want to say I'm really interested too
[09:31]	:	Feel free to comment/watch the issue. We'll get back to it some time when he is here.
[09:31]	:	kk
[09:32]	:	I think this jira over estimates the memory and processing involved in the llDetected* data
[09:32]	:	Would that actually result in a lot of savings? i.e. is llDetectedPos always populated even if I'm only ever getting llDetectedName?
[09:32]	:	probably.
[09:33]	:	That is correct - all the llDetected data is populated for each 'hit'
[09:33]	:	dumb question but ... why?
[09:33]	:	The biggest savings is probably the name - it is the only string value.
[09:33]	:	Maybe that would be useful not to populate everything.. from the sim point of view...
[09:34]	:	I'd think there'd be some overhead in having variable format event records.
[09:34]	:	You'd probably need a filter like llCastRay has.
[09:34]	:	I would think the number of touch events/second is not going to be very large, or am I missing something?
[09:34]	:	stuff like collision() happens a lot, and sensors.
[09:35]	:	even so changing any of how it works could possibly break existing content, so unless it just knew what was needed, it would just be a new set of functions anyway
[09:35]	:	but its a question of whether sim changing savings are actually there, doesn't sound like it.
[09:35]	:	Honestly it is about 100 bytes plust the name.
[09:36]	:	i guess the proper way to tune it is to make the compiler see what llDetected* functions are used when it comples, and the tunes go to the server. So that would not need any changes to the actual LSL code
[09:37]	:	that would be even trickier.
[09:37]	:	you would have to unroll everything
[09:37]	:	that sounds horribly unfun
[09:37]	:	The server would have to keep a lookup list for every script and check it for every event
[09:38]	:	i feel like this is just not worth it.
[09:38]	:	doesn't sound like it.
[09:38]	:	thats kinda my impression to
[09:38]	:	*too
[09:38]	 	v0.25: ((dantia Gothly's meter has been detached.))
[09:39]	:	Ok.
[09:39]	:	all im saying, why should we decide what llDetected* is populatesd when the compiler already see that just fine, it can be automatic, and that way it would also help with old scripts
[09:39]	:	Because it is more difficult to do that. :)
[09:39]	:	severly so
[09:39]	:	Changing LSL btecode is a no-no...
[09:40]	:	bytecote*
[09:40]	:	maybe the name could be retained internally as a handle, instead of a string, and only dereferenced when llDetectedName is called... if that would save enough mem to be worth the effort.
[09:40]	:	difficult for 3 hours for a linedn vs difficult for the future scripters to the end of the time
[09:40]	:	3 hours?
[09:41]	:	no its not the time it would take Liisa its the extra strain on everything it would place.
[09:42]	:	Ok, next
[09:42]	:	SVC-6532
[09:42]	:	http://jira.secondlife.com/browse/SVC-6532
[00:00]	:	(#SVC-6532) agent() event for detecting changes in avatar state, ideal for animation overriders
[09:42]	:	i dont see the difference in automated thing vs user settable thing, both create the same strain when being run on server, only difference is when the script get compiled
[09:43]	:	agent() would be great
[09:43]	:	yes
[09:43]	:	Yep!
[09:43]	:	yeah, this *would* be great
[09:43]	:	yeesss
[09:44]	:	That or just a function to replace the default anims...
[09:44]	:	that
[09:44]	:	its useful for more than animations though
[09:44]	:	lot more
[09:44]	:	Kaluura - yeah I'd love to see animation overrides more fully supported
[09:45]	:	okay so just to make crystal clear the only thing these could be used for is to better time and clean up animations?
[09:46]	:	no, it could be used for objects changing anything about them if an agent was doing x
[09:46]	:	theres more than just animations that this is useful for
[09:46]	:	The permissions issue isn't touched on here - who should a script be able to observe?
[09:46]	:	I think it'd be particularly useful if agent() had change flags for things we poll for in llGetAgentInfo
[09:46]	:	probably who is worn or sat upon kelly
[09:47]	:	hmmm. perhaps a new permission, auto-granted for attachments and sat-upon things.
[09:47]	:	Owners Only.
[09:47]	:	Could it bet setup to work like sensor? llSetAgentEvent(key agent)?
[09:47]	:	just make it use the same perms system everything else already have, autogrant when attached or sat and dialog grant otherwise
[09:47]	:	yeah... i -could- see where like huggers/sex huds could use it too.... but in that case it would need to trigger a dialogue
[09:49]	:	(just in passing: those skirt-sitter scripts, whatever they're called, also sample agent state frequently)
[09:49]	:	The use case I'm thinking of is say I want to detect if someone is flying, who's just in my sim. If I could attach an agent event to them and get a change flag of AGENT_FLYING, I could do something.
[09:49]	:	Well, is the pemissions needed? I don't think llGetAgentInfo and llGetAnimation require any permission to check
[09:49]	:	Or an AWAY, etc.
[09:49]	:	THat's a good point, since it doesn't act upon an avatar.
[09:49]	:	yeah
[09:50]	:	Yes... No perms... That's even better
[09:50]	:	I think that's correct. no need for perms.
[09:50]	:	someone will cry about privacy, but yea i agree, no need to keep those secret. no need for permission check
[09:50]	:	This is a fairly large undertaking
[09:50]	:	llgetagentinfo is sometimes abused though isnt it?
[09:50]	:	this is just a replacement for calling those anyway with some other form of call
[09:51]	:	Ppl are already cryiing about privacy because we have radars who can say where they are...
[09:51]	:	Entering god mode, level 200
[09:51]	:	don't see how, Cummere. although llRequestAgentInfo() is controversial because it gets online status remotely.
[09:51]	:	Well its just change events.
[09:51]	:	because of svc-4823 and others...
[09:51]	:	http://jira.secondlife.com/browse/SVC-4823
[00:00]	:	(#SVC-4823) block online status at server level
[09:51]	:	Well, since Web Profiles don't show if people are on or offline...
[09:52]	:	or since you can entirely stop your web profile from being seen
[09:52]	:	sorry but agent info and anything that replaces it should trigger a dialogue imo
[09:52]	:	As an estate owner, it's hard to try to contact people if they all appear offline.
[09:52]	:	indeed
[09:53]	:	you drop them an offline
[09:53]	:	problem solved
[09:53]	:	agrees with Cummere
[09:53]	:	Not everyone forwards IMs.
[09:53]	:	so?
[09:53]	:	ANd some things are time sensitive.
[09:53]	:	like whether or not a sim is kept or sold
[09:53]	:	so drop them a notecard
[09:53]	:	even capped ims that is always forwareded
[09:53]	:	but two very different things, GetAgentInfo and RequestAgentData... unless we're thinking of agent() events seeing online state transitons, too.
[09:53]	:	If you're gonna block online status at the server level you'll have to block sensors as well. If a sensor sees you, you're online.
[09:53]	:	even if they dont forward ims
[09:53]	:	Would what' s being proposed make this worse?
[09:54]	:	Or parcel, etc.
[09:54]	:	no this evolved into something else, this would not change anything
[09:54]	:	It would change anything
[09:54]	:	its gotten off topic actually
[09:54]	:	That's what I thought, Drac
[09:54]	:	wouldn't*
[09:54]	:	it would be an improvement
[09:54]	:	I guess the problem is I don't understand why it's a bit deal to hide if you're online or not.
[09:54]	:	to have agent()
[09:55]	:	so a timer could be free from polling other functions
[09:55]	:	or anything else for that matter
[09:55]	:	yeah... but it needs to be restricted only to the owner or trigger a dialogue when its not (except when sat upon)
[09:55]	:	unless agent() events are raised for online status changes, I don't see the point... and that's not realistic, if I understand the presence system at all.
[09:55]	:	My point was that we already have llGetAgentInfo(), but to get the key we usually get it through other events like collision, touch, sensors etc.
[09:56]	:	So it could make some sense to set an agent key with 1 function and have that agent() event work thusly.
[09:56]	:	it would only be per agent anyway, so it would be tied to a key
[09:56]	:	only on the current sim (and possibly the immediate surrounds)?
[09:57]	:	definately jonno
[09:57]	:	Same constraints as llGetAgentInfo; we can already get that stuff.
[09:57]	:	nice demo, flip. A plywood box is worth a thousand words. :D
[09:57]	:	Its just how we get it.
[09:57]	:	ild argue MORE constraints ashur
[09:57]	:	Ok, I think that is all we have time for today.
[09:57]	:	Any last minute topics?
[09:57]	:	and that box is a great example of why I would argue for more constraints
[09:58]	:	llIntegerToHex()... Any chance?
[09:58]	:	The proposal is only to do something more efficiently
[09:58]	:	Kaluura no not really
[09:58]	:	Not sure what you mean but llGetAgentInfo only shows us what we can see plain as day with our eyes; such as if someone is AFK, its not a privacy breech.
[09:58]	:	ild still like to see some-thing done with svc-4823 kelly
[09:58]	:	Bleh...
[09:59]	:	Cummere, I know. I definitely don't have time to get into that today
[10:00]	:	next time?
[10:00]	:	It isn't on my triage list, but I'm also not sure how applicable it is to my triages
[10:00]	:	Wil the remaining items carry over to next week
[10:00]	:	I know, when people disable their online visibility, automatically TP them to cornfield (or similar) and block all commun iocations and everything, so they can be very alone and in privacy
[10:00]	:	heh
[10:00]	:	jonathan yup that is how it works. Well, in two weeks. Next week is freeform discussion
[10:00]	:	Liisa, look at my profile picks
[10:00]	:	there's plenty of valid uses for online status such as customer service in stores and so forth
[10:01]	:	(look at my picks)
[10:01]	:	Ok, thank you everyone for coming. See you all next week. :)
[10:01]	:	Have a good day kelly.
[10:01]	:	thanks kelly
[10:01]	:	see you next week.
[10:01]	:	thank you Kelly
[10:01]	:	ty
[10:01]	:	Thanks Kelly!
[10:01]	:	ty kelly
 
Generated with SLog Wikifier