User:Andrew Linden/Office Hours/2010 02 12

Transcript

[16:15]	Andrew Linden:	ack, sorry I'm late
[16:15]	Sebastean Steamweaver:	WE're saved!
[16:15]	Rex Cronon:	hi andrew
[16:15]	JB Hancroft:	Hi Andrew
[16:15]	Andrew Linden:	I was AFK so my google calendar notice did not find me
[16:16]	Sebastean Steamweaver:	It's all right Andrew, we were getting a little worried. It isn't like you to be absent without leavinga note or something.
[16:16]	Pixi Murfin:	waves
[16:16]	Andrew Linden:	Simon sent me IRC saying he can't make it. He's fighting fires.
[16:16]	Sebastean Steamweaver:	RL fires?
[16:16]	Rex Cronon:	when u get here late people start to think the grid is in trouble:)
[16:16]	Andrew Linden:	There is some emergency he has to deal with -- probably related to server-1.36 or some other project with a deadline.
[16:16]	Sebastean Steamweaver:	Ahh
[16:17]	Sebastean Steamweaver:	We're glad you could make it :)
[16:17]	Xugu Madison:	hey Andrew!
[16:17]	Xugu Madison:	and to repeat what others have said, no worries about the delay, we just worry about ya is all!
[16:17]	Andrew Linden:	also, I haven't done anything useful today -- been catching up on sending emails and filling out some paperwork and other stuff
[16:17]	Sebastean Steamweaver:	No problem :)
[16:17]	Andrew Linden:	ok
[16:17]	Andrew Linden:	lessee...
[16:18]	Andrew Linden:	server-1.36 is still on schedule as far as I know
[16:18]	Andrew Linden:	there was one small internal emergency for 1.36 that I found that was affecting the pilot regions, but it was an easy config fix
[16:19]	Andrew Linden:	the hardest part was getting the permissions to fix it
[16:19]	Andrew Linden:	in the past I would have just pushed out a new config
[16:19]	You decline	The Muse Fuse Dance Club & Owner, Gwangeo (93, 214, 91) from A group member named Kazaron Klata.
[16:19]	Andrew Linden:	but these days I need to coordinate with the people who protect the grid from accidental quick fixes that go wrong
[16:20]	Rex Cronon:	btw, doing maintanance on 13 sounds omnious
[16:20]	Sebastean Steamweaver:	Hehe
[16:20]	Sebastean Steamweaver:	You mean Lindens make mistakes!? :O!
[16:20]	JB Hancroft:	Who watches the watchers?
[16:20]	Andrew Linden:	I've uh... broken the entire grid by accident in the past... but that was a long time ago when it was much smaller
[16:20]	Sebastean Steamweaver:	The SErver gatekeepers.
[16:20]	Andrew Linden:	the watchers do their work in a LL irc #channel -- for everyone to watch
[16:21]	JB Hancroft:	I hear that IRC chat is a serious stream of how work is done, in LL
[16:21]	Sebastean Steamweaver:	It's kind of like St. Peter at the pearly gates I'd imagine: "Have you been a good developer lately? What good code have you written? Why should I let you modify the server?"
[16:21]	Andrew Linden:	yes it is true... most people in LL are accessible via IRC when they are working
[16:21]	Andrew Linden:	it is typically faster than email, but can still be asynchronous
[16:22]	Andrew Linden:	and it is lower overhead than running SL and using SL IM's
[16:22]	Sebastean Steamweaver:	Hehe
[16:22]	Sebastean Steamweaver:	Andrew, I had a few questions about collisions, if I may?
[16:22]	Andrew Linden:	sure go ahead Sebastean
[16:22]	JB Hancroft	listens, liking this topic
[16:23]	Sebastean Steamweaver:	I've been working on a (very small) AI in scripts, and one of the most recent things I've been working on is pathfinding and object avoidance. I've come across a few things I was wondering if it would be possible, because I can see many omore other uses that it could apply to.
[16:23]	Sebastean Steamweaver:	The first would be, a new version (for versioned scripts) of the collision event, which includes such information as the actual position in region, of the event.
[16:24]	Sebastean Steamweaver:	As in, where the collision took place.
[16:24]	Andrew Linden:	huh... Falcon asked last week if anyone was interested in a raytrace feature for LSL
[16:24]	Sebastean Steamweaver:	!!!!
[16:24]	Sebastean Steamweaver:	That was the second one!
[16:25]	Andrew Linden:	it seems to me that raytracing would be useful low-cost solution for some AI queries about nearby objects in-world
[16:25]	Andrew Linden:	hrm... could more info be provided to the collision event
[16:25]	Sebastean Steamweaver:	llRayCast( vector origin, vector offset, float stepsize) - returns a list of the key of the first object it intersects, and the point of intersection (that was my idea of it anyway)
[16:26]	Andrew Linden:	well, the collision event uses the default "detected" pipeline... so I think it gets the same info as all the other events that have detected info
[16:26]	Sebastean Steamweaver:	So feasibly, we could port the same kind of lldetected functions as were added to the touch event?
[16:27]	Andrew Linden:	the quick answer is, of course: it is certainly possible (you can make software do whatever you want), but you're more interested in knowing how hard it might be and whether I think LL would do it...
[16:27]	JB Hancroft	nods and smiles
[16:28]	Andrew Linden:	I mentioned before that Babbage is working on getting LSL versioning into the system, so you can chose to use an old legacy version, or a new shiny version of LSL that has bugs fixed.
[16:28]	Andrew Linden:	I think a feature like that, with either new info in the detected values, or a new event, would have to wait for new versioning
[16:29]	Andrew Linden:	so... that means, it probably wouldn't be too hard to do once versioning is done
[16:29]	Sebastean Steamweaver:	And personally, I would be fine with that.
[16:29]	JB Hancroft:	is the legacy LSL frozen now ?
[16:29]	Sebastean Steamweaver:	If Falcon is interested in doing a raytracing function, tell him, I wish him godspeed in getting it done. I know several other people who would be interested in having it besides myself, and there are many things it could be used for.
[16:29]	Andrew Linden:	I recently wandered into the C++ code that implements LSL sensors, and discovered how bad it is
[16:29]	Andrew Linden:	I wasnted to add new detection methods relating to some MISC-3077 feature requests
[16:29]	List of	Linden-Confirmed Easy Changes/Additions With Large Returns
[16:30]	Andrew Linden:	but the code was so bad I had to start cleaning it up instead. I got a fair way to unravelling the spagetti
[16:30]	Andrew Linden:	but did not manage to pull out the rotton code I was aiming for, yet
[16:30]	Sebastean Steamweaver:	Would the optimizations your doing to it help decrease lag?
[16:30]	Xugu Madison	wonders if he should get a fork to help, or just tomato sauce & meatballs....
[16:31]	Ardy Lay:	Not exactly what I think of when I hear developers talk of forking code.
[16:31]	Andrew Linden:	anyway... I suspect adding info to the detected return values would be a similar problem... the code would be so bad that these days we would have to wrap it with unit tests before we could actually *change* anything
[16:31]	Andrew Linden:	um... I think maybe the cleanup I'm doing would speed things up
[16:31]	Andrew Linden:	however we don't have any benchmarks for testing it yet
[16:32]	Andrew Linden:	I'd have to write the benchmarks, and they wouldn't be LSL benchmarks...
[16:32]	Andrew Linden:	I'd want to test the C++ classes in isolation with special benchmarks
[16:33]	Sebastean Steamweaver:	Originally I had my bot being guided by sensors, but I abandoned that for several reasons, and lag was one of them.
[16:33]	Andrew Linden:	so, I guess my answer would be... I'd love to supply more info in the collision event -- I'm in favor of the feature
[16:33]	Andrew Linden:	we could do it, but I'll bet there is some work yet to be done before we could start
[16:34]	Sebastean Steamweaver:	Would the raycasting/tracing function be easier to implement?
[16:34]	Andrew Linden:	meanwhile, Falcon really wants to do llRayCast(). Did you document how you thought it would work? The API you would like to see?
[16:34]	Xugu Madison:	Reminded by talking of sensors, which are known as a laggy thing... how bad is the code for scripts to listen on channels?
[16:35]	Andrew Linden:	yeah, I suspect the ray casting would be easier to add
[16:35]	Sebastean Steamweaver:	I posted it up above, one sec, I'll copy past.
[16:35]	Sebastean Steamweaver:	paste*
[16:35]	Sebastean Steamweaver:	llRayCast( vector origin, vector offset, float stepsize) - returns a list of the key of the first object it intersects, and the point of intersection (that was my idea of it anyway)
[16:35]	Andrew Linden:	hrm... point of intersection and you probably also could use the normal at the hit point
[16:35]	JB Hancroft:	Sebastean - what are you assuming about the diameter of the ray?
[16:35]	Sebastean Steamweaver:	Having a decoupled origin makes it easier to project paths for objects that are larger than a point.
[16:36]	Rex Cronon:	wouldn't raycasting be slower, since u can hav up to 15000 objects in a sim?
[16:36]	Andrew Linden:	er... actually the havok raycast returns distance to hit from start point, and normal at hit
[16:36]	Andrew Linden:	you compute the final point by adding the normal direction of the cast, multiplied by distance to hit
[16:36]	Sebastean Steamweaver:	JB: Let's say, like in the case of my bot, you have a spehre that has X radius. it makes it easier to calculate whether the bottom of your bot, or any of its extremeties, might hit something.
[16:37]	Andrew Linden:	Rex, no the Havok raycast is very fast
[16:37]	Andrew Linden:	the LL-written sensor code is much slower by comparison
[16:37]	JB Hancroft:	ok, that makes sense... I was wondering if there was an assumption that the "ray" was of infinitely small dimension
[16:37]	Andrew Linden:	uh... the ray has a diameter?
[16:37]	Sebastean Steamweaver:	I've been imagining it as a line that the server draws, basically, instead of it having a radius.
[16:38]	Sebastean Steamweaver:	Which is why I suggested having the origin decoupled, so you could simulate giving the radius a dimenion by testing various points.
[16:38]	JB Hancroft:	ok, then the ray is a line, and has no diameter, really.
[16:38]	JB Hancroft	nods
[16:38]	Andrew Linden:	yeah, you probably don't want to give the raycast a radius (that is, turn it into a cylinder)
[16:39]	Andrew Linden:	that requires multiple raycasts, or else is a "collision query" between a cylinder and the world
[16:39]	Sebastean Steamweaver:	One thing I'd like to mention that I -wouldn't- like to see, is having the return of the raycast function tied to an event.
[16:39]	Andrew Linden:	OTOH, a single raycast provides only a little bit of info
[16:39]	Sebastean Steamweaver:	Having it tied to an event, instead of info returned by the function itself, makes it much harder to use.
[16:40]	Andrew Linden:	give the raycast a callback function...
[16:40]	Andrew Linden:	hrm...
[16:41]	Sebastean Steamweaver:	The reason I suggested having it return the key and the hitpoint, is so that you can get most of the info you need (position, rotation, hitpoint/normal, etc) without having to depend on another query, and if you need to run multiple tests to see if an area is "free" you can do it all in one function without having to wait for it to be interrupted.
[16:41]	Andrew Linden:	you can't have the raycast run arbitarary code imediatly after, but you might be able to set up some ray_cast_hit() event handlers
[16:42]	Andrew Linden:	in order for the raycasts to return data immediatly they have to be run asynchronously against the physics engine (that is, run the casts while the simulator is in the middle of running scripts)
[16:43]	Andrew Linden:	that would be more expensive than running them batched, together, right before or right after the physics timestep
[16:43]	Sebastean Steamweaver:	Hmm
[16:43]	Andrew Linden:	so for casts that would trigger events... the casts themselves could be batched and very cheap
[16:44]	Andrew Linden:	however, they might generate so many events that your LSL script would slow down trying to handle them all
[16:44]	JB Hancroft:	so in the simulator, is it difficult or awkward to have a script be suspended while the results of an llAPI call are prepared?
[16:44]	Andrew Linden:	or so many events that they can't all be held in memory and some have to be dropped
[16:44]	Andrew Linden:	it is expensive to make physics engine calls "out of context"
[16:45]	Sebastean Steamweaver:	Hmm
[16:45]	JB Hancroft:	ok... I hadn't thought about the notion of a physics timestep... as "context". makes sense
[16:45]	Andrew Linden:	that is, when the code is deep in script land, to suddenly poke the physics engine and say "Hey, I need to run this ray cast" -- there are a lot or context switches
[16:46]	Sebastean Steamweaver	nods
[16:46]	Andrew Linden:	however... my memory is coming back to me...
[16:46]	JB Hancroft:	glad yours is... I wonder about mine, sometimes...
[16:46]	Andrew Linden:	Havok2 and higher is much much better at doing asynchrounous raycasts -- much faster
[16:46]	Andrew Linden:	than Havok1
[16:46]	Sebastean Steamweaver:	So it might be possible to do cheap raycasts that are still asynchronous?
[16:47]	Andrew Linden:	yes, I think so.... I was remembering limitations of Havok1
[16:47]	Andrew Linden:	which no longer apply
[16:48]	Andrew Linden:	anyway, Falcon wants to do raycasts for LSL -- I think they will get done eventually
[16:48]	Andrew Linden:	maybe even this year
[16:48]	Sebastean Steamweaver:	Well, if we could get asynchronous information, over it being tied to an event, I would prefer that myself. It's much easier using such a function in context with the rest of necessary code. If events are necessary though, I won't complain too much ;)
[16:48]	Andrew Linden:	I'll try to remember the idea for more info in the collision -- I'm going to revisit the sensor and detection code soon
[16:49]	Sebastean Steamweaver:	I could write up a JIRA for what I suggested if you like.
[16:49]	JB Hancroft:	Andrew - what will the sideeffects on sensors be, of the unravelling that you're doing?
[16:49]	Sebastean Steamweaver:	Actually, I shoudl probably do that for the collision event suggestion also.
[16:49]	Andrew Linden:	sure... I dunno if it should be linked to MISC-3077 -- that is reserved for easy projects right now
[16:49]	CPU Core:	make sensors detect the whole sim!
[16:49]	Sebastean Steamweaver:	I wouldn't have linked it without asking you first, but since you said now you aren't sure about it, I'll definitely leave it off.
[16:50]	CPU Core:	uh oh.. dejavu
[16:50]	JB Hancroft:	and break all those roving sensors? :)
[16:50]	Sebastean Steamweaver:	Heh, making sensors detect objects that cross in their line of vision, but don't have their centers in it, would be nice too, hehe.
[16:51]	CPU Core:	they wont need to rove anymore
[16:51]	JB Hancroft:	:)
[16:51]	Liisa Runo:	.. i forgot to keep track of time.. could someone paste me the discussion we been having so far
[16:51]	Andrew Linden:	I dunno if we could open up the entire region for sensor... that's a lot of objects to sort through
[16:51]	Andrew Linden:	it would have be be made much more efficient
[16:51]	Sebastean Steamweaver:	Hmm
[16:52]	CPU Core:	well we only really want to know where avatars are inthe tim
[16:52]	CPU Core:	sim
[16:52]	JB Hancroft:	oh?
[16:52]	JB Hancroft:	why not the objects? :)
[16:52]	Sebastean Steamweaver:	Perhaps a region-wide sensor that only applies to agents?
[16:52]	CPU Core:	because objects are boring lol
[16:52]	JB Hancroft:	oh, true ;)
[16:52]	Liisa Runo:	list llGetSimulatorAgentKeyList();
[16:52]	Andrew Linden:	perhaps you want viewer-side scripting that could throw as much CPU resources at the info that is being streamed to your client?
[16:53]	JB Hancroft:	now you're teasing us...
[16:53]	Andrew Linden:	er... as many CPU resources as you could handle?
[16:53]	Sebastean Steamweaver:	Hehe
[16:53]	Psi Merlin:	The viewer already has the agent info for the minimap etc
[16:53]	Andrew Linden:	well, I'm kinda wondering what all the sensing would be used for
[16:53]	Sebastean Steamweaver:	Getting a list of the people in a region would be handy, yes.
[16:53]	Jonathan Yap:	There must be some way the viewer can see distant avatars now--my radar is showing some people > 96m away
[16:53]	Andrew Linden:	gimme some example applications
[16:53]	Sebastean Steamweaver:	Andrew - there are a lot of "Sim-wide AV maps" that sim owners use to monitor traffic.
[16:54]	Rex Cronon:	viewer side scripting? with what resources? the viewer takes over 1gb:(
[16:54]	Sebastean Steamweaver:	Right now, they rely on overlapped sensors that traverse the entirety of the sim.
[16:54]	Jonathan Yap:	Viewer side scripting is a project that's being worked on
[16:54]	Rex Cronon:	or megaprims:)
[16:54]	CPU Core:	well that Liisa said an Agent Key list would help
[16:54]	Andrew Linden:	and what are the traffic maps uses for?
[16:54]	Sebastean Steamweaver:	Or, everyone landing on a certain TP point with a collision prim, which then sends the data to a script which tracks them with llGetObjectDetails
[16:55]	Sebastean Steamweaver:	Admin purposes mainly - you can ususually get links to profiles, boot them from the sim, ban, unban, etc.
[16:56]	Andrew Linden:	ok, well that would work well done on the client, if there were an API for executing all the operations the admin wanted to do
[16:56]	Rex Cronon:	i think that the scanner builtin the everald viewer gives all the avatars in the sim
[16:56]	JB Hancroft:	For merchants, they are used for sensing repeat/frequent customers
[16:56]	Sebastean Steamweaver:	Oh, oh, that does bring up one other thing I wanted to ask about.
[16:56]	Andrew Linden:	but if you wanted to have an admin robot in the region that was an object -- then it would have to be server sise
[16:56]	Andrew Linden:	side
[16:56]	Liisa Runo:	client can never do everything, i want to be able to script the behavior of my radar thingy to my self
[16:56]	Sebastean Steamweaver:	Andrew, what do you think about the possibility of something like llSameGroup(key avatar, key Group UUID)?
[16:57]	CPU Core:	yeah you put it in the client and its not sellable
[16:57]	Sebastean Steamweaver:	That would allow you to match a group UUID with the active group of the avatar.
[16:57]	Andrew Linden:	uh... llSameGroup() returns TRUE or FALSE?
[16:57]	Sebastean Steamweaver:	Err, llMatchGroup
[16:57]	Rex Cronon:	yes. i want the same function, sebastean:)
[16:57]	Sebastean Steamweaver:	I was confusing function names :)
[16:57]	Jonathan Yap:	llActiveGroup()
[16:58]	Andrew Linden:	why wouldn't you do... group_id = llGetGroup(); if (group_id == SOME_GROUP) {} ?
[16:58]	Rex Cronon:	i would also like llGroupInvite(key avatar, key Group UUID)
[16:58]	Sebastean Steamweaver:	You can't get the UUID of a person's active group.
[16:58]	Rex Cronon:	we don't have llgetgroup():(
[16:58]	Sebastean Steamweaver:	The only access you have to an avatar's active group, is testing it with llSameGroup, which is the issue.
[16:59]	Andrew Linden:	so llSameGroup() exists today?
[16:59]	Sebastean Steamweaver:	Yes
[16:59]	Rex Cronon:	we need llgetgroup
[16:59]	Sebastean Steamweaver:	It returns tRUE/FALSE if the object is the same group as the avatar's active UUID
[16:59]	Andrew Linden:	oh, well this just goes to show how often I actually write LSL scripts -- I don't know all the API
[16:59]	Sebastean Steamweaver:	Well, llGetGroup, or llMatchGroup -- llMatchGroup would still maintain some level of privacy.
[16:59]	Rex Cronon:	and also llGroupInvite
[16:59]	CPU Core:	i think that scripts should also be able to limit what the client receives
[17:00]	CPU Core:	i mean i want to be able to make a script that can disable minimap
[17:00]	Andrew Linden:	llGetGroup() has been declined for privacy issues?
[17:00]	Sebastean Steamweaver:	llMatchGroup, you have the UUID of the group, and can just check it against the UUID of the avatar, without needing to have the object be of that group.
[17:00]	Sebastean Steamweaver:	That was one argument on the JIRA topic.
[17:00]	JB Hancroft:	CPU - you mean disable your minimap, or disable your presence on someone else's minimap?
[17:00]	Sebastean Steamweaver:	http://jira.secondlife.com/browse/SVC-2670
[17:00]	Checks if	an object or agent is active in a specified group.
[17:00]	Sebastean Steamweaver:	As for use cases:
[17:01]	CPU Core:	no a script that will disable a minimap or make whatever you want appear
[17:01]	Sebastean Steamweaver:	I have a networked teleport system. One of the features is that you can network it via what group the person has hactive.
[17:01]	CPU Core:	for use in gaming
[17:01]	CPU Core:	or whatever you want
[17:01]	Sebastean Steamweaver:	If we had llMatchGroup, all of the teleporters cuold test the groups it had stored to see what the person should have access to.
[17:01]	CPU Core:	knowing where people are makes hide and sek impossible
[17:02]	CPU Core:	cant be stealthy in SL
[17:02]	Sebastean Steamweaver:	As it stands, the owners need to rez different teleporters for different groups.
[17:02]	Sebastean Steamweaver:	That's just one example of its use. CPU: those were good applications too.
[17:02]	Jonathan Yap:	You would want to think about what to do in the case where someone has their group hidden, I can see that as a privacy issue.
[17:03]	Sebastean Steamweaver:	Jonathan - it's only a privacy issue if you can get a group that the avatar does not have active.
[17:03]	Sebastean Steamweaver:	If the group is active, and you use llSameGroup, you can still find out if the person is in that group, which is the purpose.
[17:03]	Andrew Linden:	well I think llGetGroup() (or llMatchGroup() perhaps) should be implemented
[17:03]	JB Hancroft:	Just because the group is active, doesn't mean it's being disclosed... a tag can be anything.
[17:03]	Liisa Runo:	is there some real reason why we cant just detect in what group some agent is?
[17:03]	Andrew Linden:	if you don't want your active group fingered, then you shouldn't activate it (IMHO)
[17:04]	JB Hancroft:	I like MatchGroup(), because of the extra measure of protecting privacy
[17:04]	Jonathan Yap:	Good point Sebastean
[17:04]	Sebastean Steamweaver:	JB: llMatchGroup does the same thing as llSameGroup, the only difference is it allows an object to test against more than one group.
[17:04]	Andrew Linden:	hrm... mabye not... I suppose that some functionality is only available when you have your group activated
[17:04]	Andrew Linden:	such as making group-affiliated objects by default
[17:04]	Sebastean Steamweaver:	Being able to automate some group functions is something people have wanted for a long time also.
[17:05]	Sebastean Steamweaver:	i.e. being able to invite people or eject, etc, via script.
[17:05]	Andrew Linden:	yeah, I'll bet
[17:05]	Sebastean Steamweaver:	As much as I really hate auto-inviters :P
[17:05]	Liisa Runo:	would be fun to be able to automatically ban people in some specific group, without needing to have the object set to the griefer group
[17:05]	JB Hancroft:	people are used to some notion of delegation, via guid, etc. on other systems
[17:05]	Sebastean Steamweaver:	In some cases, they would be really handy: i.e. renting a plot of land and not having to wait for the owner to wake up/get back from work to get invited.
[17:05]	Andrew Linden:	sigh... there are a lot of features that we should do -- so much potential, so little time
[17:06]	Andrew Linden:	must work faster. versioning would help us work faster
[17:06]	Liisa Runo:	as i always say, demand for more minions
[17:06]	Jonathan Yap:	You'd have to take precautions so griefers don't use that function to spam someone with a zillion invites
[17:06]	JB Hancroft:	Andrew - what's at the top of your list of what you think should be worked on?
[17:06]	Ardy Lay:	Andrew, I would like to be able to have http-in provide a mime type of my choosing.
[17:06]	Andrew Linden:	good question JB...
[17:06]	JB Hancroft:	sensors... 'cuz you're mucking around in there, now...
[17:06]	Sebastean Steamweaver:	Andrew, I have a really great amount of respect for the amount of effort and work you do - I hope it never comes across as any less. I just also have a lot of respect for your knowlege and passion, which is why I come to you with these things, and I suspect others too.
[17:07]	Liisa Runo:	[13:01] Governor Linden: Liisa, right now it looks like I have millions and millions of L$. i should go shopping [13:01] Liisa Runo: i sent that money for you so you can hire more staff, to improve SL
[17:07]	JB Hancroft	agrees with Sebastean
[17:07]	Andrew Linden:	my main repsonsibility right now is to help fix bugs and make sure misc bug fixes by other devs get through QA
[17:07]	JB Hancroft:	++Liisa
[17:07]	Andrew Linden:	but I do side projects, and jump on emergency problems when necessary
[17:07]	Ardy Lay:	If I could set mime type I could use SVG to draw on parcel-media faces.
[17:08]	Andrew Linden:	uh... I've got some important side projects, some of which I can't talk about
[17:08]	JB Hancroft:	I'm curious then... why the venture into SensorLand?
[17:08]	Rex Cronon:	u paid the lindens in L$:)
[17:08]	Andrew Linden:	either they are internal tools or are features we don't want to announce yet
[17:08]	Andrew Linden:	so... anyway on my short list:
[17:08]	JB Hancroft:	ahhh... the fun stuff :)
[17:08]	Sebastean Steamweaver:	There were some requests for MISC-3077 that andrew was looking into for sensors JB.
[17:08]	Liisa Runo:	often when i hit on some annoying bug or behavior, i send money to governor
[17:08]	Andrew Linden:	this quarter I'm going to try to resurrect the "prim encroachment" project
[17:08]	Sebastean Steamweaver	cheers
[17:09]	Jonathan Yap	says "hooray"
[17:09]	Andrew Linden:	(one of the prerequesites for megaprims, as you probably remember)
[17:09]	Sebastean Steamweaver	grins.
[17:09]	JB Hancroft	hasn't been around long enough yet, clearly... lol
[17:09]	Andrew Linden:	uh... since we've claimed we want to deliver mesh objects...
[17:09]	Liisa Runo:	(we remember, and we still thing the 32meter for new prim limit is way too small, we want atleast 256meters)
[17:09]	Andrew Linden:	you might wonder... will we support megameshes?
[17:09]	Liisa Runo:	think*
[17:09]	Sebastean Steamweaver:	I have wondered that, yes.
[17:10]	Sebastean Steamweaver:	Just think of the caves you could make.
[17:10]	Andrew Linden:	well... megameshes would be cool
[17:10]	JB Hancroft:	(brb... RL call)
[17:10]	Rex Cronon:	u don't have to have hulk mesh of the size of a sim:)
[17:10]	Andrew Linden:	damn! we'd better get back to solving the prim encroachment problem
[17:10]	Sebastean Steamweaver:	Hehe
[17:10]	Andrew Linden:	uh... what else
[17:10]	Andrew Linden:	the other mentionable thing I want to work on this quarter is MISC-3077 stuff
[17:11]	Liisa Runo:	llSetPrimText(integer face, string text, vector color);
[17:11]	Andrew Linden:	and that is all I put on my 2010.Q1 goals
[17:11]	Andrew Linden:	the day to day fires and stuff aren't worth mentioning on the goals
[17:11]	Sebastean Steamweaver:	llSet/GetObjectScale <3
[17:12]	Sebastean Steamweaver:	Thank you very much for the talk on collisions and whatnot Andrew, I appreciate it. I don't suppose Falcon has office hours?
[17:13]	CPU Core:	rabbits make good pets in SL
[17:13]	Andrew Linden:	I'm going to have to get going
[17:13]	Jonathan Yap:	There would probably be enough interest for him to have his own
[17:13]	CPU Core:	because they bounce
[17:13]	Andrew Linden:	gotta be somewhere sometime soon
[17:13]	CPU Core:	nothing can walk
[17:13]	Ardy Lay:	Thanks Andrew
[17:13]	CPU Core:	bye
[17:13]	Sebastean Steamweaver:	Thanks again Andrew :) I always enjoy your OH - they're on par with Vektor's for me.
[17:13]	Xugu Madison:	Thanks Andrew!
[17:13]	Jonathan Yap:	Thank you Andrew
[17:13]	Andrew Linden:	See you all later

Generated with SLog Wikifier