User:Andrew Linden/Office Hours/2008 03 27

Transcript of Andrew Linden's office hours:

[17:04]	Cinthya Loveless:	Hey Andrew
[17:04]	Simon Linden:	Probably as physics ... it's likely to get to the same people in any case, but if you flag it as Havok4 it will get quicker attention
[17:04]	Andrew Linden:	hello
[17:04]	Creem Pye:	specifically it's about how llGetOmega returns <0,0,0> sometimes when you're physical :O
[17:05]	Creem Pye:	ah, this is both H1 and H4, apparently
[17:05]	Les White:	hiya Andrew
[17:05]	Atashi Toshihiko:	Hello Andrew :)
[17:05]	Cinthya Loveless:	I say you for the Svc-1520 in the fix list! thank you thank you thank you Andrew!
[17:05]	Cinthya Loveless:	say=saw*
[17:05]	Andrew Linden:	ah atashi. Did you see much lag today in your region
[17:05]	Creem Pye:	floating avs, cinthya?
[17:05]	Cinthya Loveless:	yes Thank you andrew
[17:05]	Simon Linden:	/
[17:05]	Simon Linden:	Did you try it, Cinthya?
[17:05]	Atashi Toshihiko:	A bit - I was testing different things... disabling collisions and rezzing etc
[17:06]	Cinthya Loveless:	no im going to after this meeting
[17:06]	Les White:	and <3 for the mass bug fix :)
[17:06]	Cinthya Loveless:	im going to see if Sidewinder will put my sim on the test grid
[17:06]	Rex Cronon:	hello everybody
[17:06]	Les White:	hiya Rex
[17:06]	Creem Pye:	I tried a vehicle today in H4, and it was indistinguishable from H1 performance, so good work =)
[17:06]	Sidewinder Linden:	hi guys
[17:06]	Rex Cronon:	hi
[17:06]	Les White:	hiya Sidewinder
[17:06]	Sidewinder Linden is hoping that at least one sentence tonight will be about something other than megaprims :))
[17:07]	Atashi Toshihiko:	:)
[17:07]	Les White:	we can talk about my huge...no wait
[17:07]	Andrew Linden:	Sidewinder and Simon, why don't you guys start if you have any announcements.
[17:07]	Sidewinder Linden:	naaah we fixed that les ;)
[17:08]	Andrew Linden:	I'm currently talking to Dan Linden on the side... he's testing something that I wrote.
[17:08]	Sidewinder Linden:	ok
[17:08]	Sidewinder Linden:	well i guess you've all seen the blog post today about the beta preview update
[17:09]	Sidewinder Linden:	it's what we are calling rc3, which is getting "prety darned close" to what we think is releasable code
[17:09]	Sidewinder Linden:	assuming that it's solid, this will be deployed to the early adopters tomorrow so that we can seehow it does
[17:09]	Sidewinder Linden:	along with the new 1.19.2 release server deploy that is continuing i think tonight
[17:10]	Sidewinder Linden:	i think this build resolves many of the open issues taht were brought up on the blog... short of a swimmer issue that has been re-raised but we'll have to look at that one again when we can
[17:10]	Sidewinder Linden:	umm after all the discussion about megaprims
[17:10]	Sidewinder Linden:	*holds his breath*
[17:11]	Sidewinder Linden:	i just wrote this comment, as a way to hopefully clarify and simplify the megaprim "policy issue" that keeps being raised..
[17:11]	Sidewinder Linden:	http://blog.secondlife.com/2008/03/27/havok%e2%84%a24-beta-preview-update-with-8-fixes-2008-03-27-rc3-of-the-new-second-life-simulator/#comment-592419
[17:11]	Sidewinder Linden:	wow sorry about that url
[17:11]	Sidewinder Linden:	how does this seem as a way of encapsulating the issues in an easy to deal with way?
[17:12]	Andrew Linden:	For those of you who attended or read the transcripts from earlier this week... basically I decided to NOT do anything about megaprims in the Havok4 release.
[17:12]	Andrew Linden:	Er... we decided. We had a small discusion about it internally
[17:12]	Les White:	i think it's clearly stated there sidewinder
[17:13]	Andrew Linden:	Any policy changes will be part of their own project, independent of Havok4
[17:13]	Creem Pye:	is it true that H4 loses some of its performance advantages over H1 when you using something like a 256m megaprim floor for a sim?
[17:13]	Sidewinder Linden:	i think it's fair to say that we don't know the specific characteristics yet
[17:14]	Creem Pye:	I recall andrew saying something to that effect a while ago, but I repeated it today and wasn't sure of myself =P
[17:14]	Sidewinder Linden:	and likely there are parts of that answer in the simulator and parts on the server
[17:14]	Sidewinder Linden:	err viewer
[17:14]	Sidewinder Linden:	i'll be doing some work on performance characterization coming up and hope to have some more objective answers going forward...
[17:14]	Creem Pye:	(I'm specifically referring to a megaprim with many dynamic objects on it)
[17:14]	Sidewinder Linden:	ahh
[17:14]	Andrew Linden:	Theoretically yes. However theoretically there isn't much difference between a 1024^3 megprim or a 256^3 megaprim, at least assuming that the number of dynamic objects overlapping are the same.
[17:14]	Sidewinder Linden:	(thought you meant just visual)
[17:15]	Sidewinder Linden:	and i guess the other question is - if you implement the same floor area with separate prims, with the same number of dynamic objects, is it any different?
[17:15]	Andrew Linden:	The broadphase cost is theoretically the same, since both will more or less extend out to the edge of the simuation world.
[17:15]	Les White:	right
[17:16]	Les White:	would a single prim with 10 vehicles be any different then 10 prims with 10 vehichles
[17:17]	Sidewinder Linden:	all good questions les... let's find out with some real testing :)
[17:17]	Andrew Linden:	In Havok4... if you create extra vehicles on one object then they all collapse into one vehicle action.
[17:17]	Andrew Linden:	But you can control the vehicle parameters from different scripts.
[17:17]	Rex Cronon:	so, u can't have races?
[17:17]	Andrew Linden:	Havok1 would create 10 distinct vehicle actions, each with potentially different parameter settings.
[17:17]	Andrew Linden:	So you could make the vehicles fight each other in Havok1
[17:18]	Andrew Linden:	and the final behavior would be largely undefined.
[17:18]	Simon Linden:	Les - are you talking about 10 different vehicles on a large-prim surface?
[17:18]	Les White:	yes
[17:18]	Andrew Linden:	hehe, oh
[17:18]	Andrew Linden:	I totally misundertsood the question
[17:18]	Gaius Goodliffe:	lol
[17:18]	Simon Linden:	I thought you were driving off into the weeds there :)
[17:18]	Creem Pye:	I told Les that a bunch of 32x32 prims might be better, but maybe I misunderstand the issue
[17:18]	Andrew Linden:	Les, perhaps you could rephrase it?
[17:18]	Creem Pye:	(than asingle 256x256)
[17:19]	Simon Linden:	/
[17:19]	Simon Linden:	It's megaprim road vs. many prim road, right?
[17:19]	Creem Pye:	yeah
[17:19]	Les White:	ok. if i produced a race track using a single 256X256 prim would it produce any different effect then using many smaller prims for the road surface under load?
[17:19]	Andrew Linden:	Simon, you want to answer that one?
[17:20]	Simon Linden:	I don't think it would make a difference, but it would be best to test to confirm
[17:20]	Gaius Goodliffe:	One difference is you wouldn't have to worry about the weird collisions at the seams problems...
[17:20]	Les White:	right. i've only seen advantages of no bouncing using it, but there were concerns
[17:20]	Simon Linden:	Havok can slow down if it can't seperate objects into different 'islands', where these are groups that are far apart enough so they aren't affecting each other
[17:21]	Gaius Goodliffe:	If a racetrack is continuous, it wouldn't be able to be seperated into "islands" anyway, would it? Assuming all the track prims touch their neighbors.
[17:21]	Simon Linden:	I _think_ it can still seperate the vehicles on top of a very large static prim, but am not 100% certain
[17:21]	Andrew Linden:	I think Havok4 would break the islands up in the 32x32 multi-prim floor
[17:22]	Andrew Linden:	whereas in the 256x256 floor it would be one big island
[17:22]	Andrew Linden:	but... I used to think that the island info was used by Havok to cull the collision data
[17:22]	Andrew Linden:	however... they have informed me that that is not the case
[17:23]	Andrew Linden:	it is really used to allow whole islands to be activated or deactivated together
[17:23]	Simon Linden:	I think the short answer is "we don't know" :)
[17:24]	Les White:	i can work with that :)
[17:24]	Andrew Linden:	and the island divisions are probably influenced by the *output* of the broand the division state of the islands is probably computed with the help of the output of the broadphase info
[17:24]	Creem Pye:	so the solution is to organize a 40-avatar bike race in Snowpeach to find out? :)
[17:24]	Andrew Linden:	gr... my keyboard is messing with me
[17:24]	Les White:	that's planned for this weekend, Creem :)
[17:24]	Creem Pye:	cool, keep your eyes on the physics frame time please
[17:25]	Andrew Linden:	so... if you had a 256x256 floor, with a pile of a few hundred dynamic objects in pile...
[17:25]	Andrew Linden:	and you rode a vehicle around on the surface...
[17:25]	Andrew Linden:	it would tend to keep the pile active
[17:25]	Andrew Linden:	which would slow the physics engine down
[17:25]	Andrew Linden:	because the vehicle would keep the entire simulation island active
[17:26]	Gaius Goodliffe:	Ah, so it can prevent things from becoming "settled"...
[17:26]	Andrew Linden:	which would constantly force the pile into the simulation
[17:26]	Andrew Linden:	right
[17:26]	Sidewinder Linden:	and in general increases the number of items the physics engine has to consider with every pass
[17:26]	Sidewinder Linden:	in combination
[17:26]	Creem Pye:	do avatars also "settle"?
[17:26]	Gaius Goodliffe is continuously unsettled. ;)
[17:27]	Andrew Linden:	and as for grief... if you slap a giant megaprim over a pile of dynamic objects... the pile should get pushed out by the physics engine
[17:27]	Simon Linden:	Creem - yes, you can do this trick - fly up as high as possible, without a flight assist
[17:27]	Andrew Linden:	so a megaprim can wake up a large collection of smaller dynamic objects... if they pre-exist in the region
[17:27]	Andrew Linden:	but there is special code for avatars
[17:27]	Simon Linden:	... you 'll start the drifting down when you release the "page up" button. Press space a few times to stop motion
[17:28]	Simon Linden:	you can get it to 'settle' and you'll hang in the air, not drifting down any more
[17:28]	Andrew Linden:	and if someone puts a big prim over your avatar, you stop colliding with it if you're too deep, and if the prim is convex
[17:28]	Creem Pye:	that's a good trick, Simon, thanks
[17:28]	Simon Linden:	We had a bug report to fix that, but it's very low priority since it doesn't hurt anything :)
[17:29]	Les White:	thanks for the info. i'll continue testing
[17:29]	Atashi Toshihiko:	Do these 'islands' only apply when you have dynamic objects touching static ones?
[17:29]	Atashi Toshihiko:	Or would a collection of dynamic objects all close together be an 'island'?
[17:30]	Andrew Linden:	yes, more or less
[17:30]	Andrew Linden:	the simulation islands represent the collections of objects that are woken up when any one in the collection goes active
[17:31]	Andrew Linden:	this is the main feature that solves the "the stack of objects don't fall when I delete the support from the bottom"
[17:31]	Andrew Linden:	however... we had to do special magic to make those wake up in SL since the object is "static" while you've got it selected
[17:31]	Andrew Linden:	which is the main way to delete an object out
[17:31]	Simon Linden:	Havok describes them as: "During the physics simulation separate groups of objects are partitioned into simulation islands. This allows them to be simulated independently for performance reasons. Simulating small groups of objects separately is good for CPU and memory utilization"
[17:32]	Andrew Linden:	and deleting a static object doesn't wake up the pile unless you make some specific calls
[17:32]	Andrew Linden:	hrm... something is messed up between that description and the info they were feeding me
[17:33]	Andrew Linden:	if that is true simon, then it sounds like they are using the islands to cull the collisions
[17:33]	Simon Linden:	Well, it's the docs, so I'm not sure how much to trust it :)
[17:33]	Sidewinder Linden:	heh
[17:34]	Andrew Linden:	perhaps they're only talking about the activation and deactivation issue... the islands activate and deactivate together
[17:34]	Simon Linden:	I think there isn't supposed to be any possibility of collisions between islands, so that does help. But the islands are re-calculated every frame, so it doesn't help if things are grouped together (in one touching pile)
[17:34]	Andrew Linden:	anyway... we can avoid the collapse of the simulation islands from the megaprims if we were to set the megaprims as "fixed" in havok parlance
[17:34]	Andrew Linden:	"fixed" objects (as opposed to "keyframed") are not integrated
[17:35]	Andrew Linden:	and do not contribute to the simulation islands because they cannot be on the active list
[17:35]	Andrew Linden:	This is something I've talked about before
[17:35]	Creem Pye:	but then the performance penalty of activating them is much higher when they start off as fixed, right?
[17:35]	Andrew Linden:	but that optimization is a little project by itself
[17:35]	Andrew Linden:	so we'll do it after Havok4 is "done"
[17:36]	Andrew Linden:	Yeah, the penalty for moving from keyframed to fixed and back again may be high
[17:36]	Andrew Linden:	so we might not want to allow some scripted content to ever go fixed
[17:37]	Andrew Linden:	Anybody have a topic for discussion? I didn't bring many of my own today.
[17:37]	Creem Pye:	I have seomthing relating to a recent bug fix
[17:37]	Creem Pye:	DEV-12320: llGetBoundingBox now includes the object the avatar is sitting on
[17:38]	Creem Pye:	llGetBoundingBox returns the values from the object's frame of reference,
[17:39]	Creem Pye:	sounless an attachment knows the rotation of the object the avatar is sitting on, it's difficult to know the bounding box in sim coordinates
[17:39]	Creem Pye:	* so unless
[17:39]	Creem Pye:	so I'm wondering what it's used for in attachments, usually =)
[17:40]	Andrew Linden:	yes. It is possible to compute it yourself in LSL for non-attachments
[17:40]	Andrew Linden:	but attachments aren't really in the physics engine anyway
[17:40]	Andrew Linden:	the simulator has only a vague notion of the current position of the attachment
[17:40]	Creem Pye:	right
[17:40]	Andrew Linden:	it knows its offset from the default, but nothing else
[17:41]	Creem Pye:	ah, so originally it was returning the same result that llgetagentsize would return?
[17:41]	Andrew Linden:	the simulator knows your current animation state, but not the geometry of it
[17:41]	Creem Pye:	ah ok, I misunderstood the bug
[17:41]	Andrew Linden:	simon, do you want to anser the questions about that bug? It says you fixed it in the records.
[17:42]	Simon Linden:	Yes, I was just reading the report ... I"m not sure where it came from (other than our testing) but it was reported as "it doesn't work the way it used to" without a real-virtual-world case
[17:43]	Simon Linden:	Basically, it wasn't looking for the 'root' object - the AV if it's an attachment, or what the AV was sitting on
[17:43]	Creem Pye:	hmm I thought though that the difference of the vectors returned by llGetBoundingBox(avatar_key) returned a similar result as llGetAgentSize(avatar_key), regardless of whether the av was sitting
[17:43]	Simon Linden:	and so it was returning the bounding box of the smaller part, rather than the larger whole
[17:44]	Andrew Linden:	Atashi had been noticing periodic bad lag, that often cleared up after several seconds.
[17:44]	Andrew Linden:	Has anyone else been noticing that?
[17:44]	Simon Linden:	In fixing it, I pretty much looked at the old code and made it do the same thing
[17:45]	Atashi Toshihiko:	I was testing some more, and I'm wondering if it is at least in part related to rezzing of objects -
[17:45]	Les White:	av's TPing into a region makes good spike for a few seconds
[17:45]	Atashi Toshihiko:	I could almost always get a performance dip by rezzing a lot of objects in short order - i.e. with a gun for instance
[17:46]	Simon Linden:	That will definitely cause a slowdown - we've found adding and removing objects from the physics sim is costly
[17:47]	Andrew Linden:	yeah, I've got a few ideas on how to optimize that, but don't think I can erase much of the costs of adding new objects
[17:47]	Cinthya Loveless:	like you mean objects that are using physics and not ones that are not using physics ?
[17:47]	Simon Linden:	A few objects shouldn't be noticable, but larger numbers (100+) will be. A lot depends on how and where they are placed
[17:47]	Rex Cronon:	does it matter if the rezzed objects are temp?
[17:47]	Andrew Linden:	No
[17:48]	Creem Pye:	oops I was mistaken about the H1 llGetBoundingBox() behavior, nevermind
[17:48]	Simon Linden:	Temp objects work just like normal ones, and are simply removed after some time interval
[17:48]	Atashi Toshihiko:	If I rez say 25 physical bullets in the space of a second, that will drop the FPS / dilation significantly
[17:48]	Simon Linden:	yep,that will do it
[17:48]	Creem Pye:	most of that could be script time, depending on the bullet
[17:49]	Arawn Spitteler will suggest a shotgun, to the next newbi inventor
[17:49]	Rex Cronon:	it takes more than 25 objects
[17:49]	Atashi Toshihiko:	:)
[17:49]	Atashi Toshihiko:	Yet it does not slow my havoc1 sims nearly as much?
[17:49]	Simon Linden:	Assuming they are coming from the same gun, it means each time one is added it might be colliding with the other nearby objects, so it can be a lot of calculations for the physics engine
[17:50]	Creem Pye:	and certain dynamic object shapes are lighter on the physics engine than others
[17:50]	Atashi Toshihiko:	It's about 12 a second from one rezzing object, but they are spaced apart, about 0.1m to the side and up and down...
[17:50]	Andrew Linden:	yeah, but you'd expect Havok4 to be as fast or faster than Havok1
[17:50]	Simon Linden:	Creem - very true. Simpler shapes (boxes and spheres) are better.
[17:50]	Simon Linden:	Yeah, the performance problems have been a disappointment
[17:51]	Creem Pye:	would a heavily dimpled sphere work well in your opinion, simon?
[17:51]	Gaius Goodliffe:	Is a hollow sphere expensive, even if it's not cut/dimpled (so the inside is unreachable)?
[17:51]	Andrew Linden:	yes gaius, there is no easy way for the simulator code to know that the inside is unreachable for many cases
[17:51]	Gaius Goodliffe nods.
[17:51]	Simon Linden:	Any twisted or hollowed object will be treated as a mesh, so it comes down to how curvy and big they are
[17:52]	Simon Linden:	When things are small, we also just treat them as a simple box
[17:52]	Arawn Spitteler:	The inside of a sphere is very reacheable, if a volume detect turns phantom off, in collision_end
[17:52]	Andrew Linden:	big spheres yes
[17:53]	Andrew Linden:	really really small spheres aren't
[17:53]	Sidewinder Linden:	andrew - i just an idea prompted by this discussion... maybe at some point we should have a discussion or workshop with weapons builders about optimizing for h4...?
[17:54]	Arawn Spitteler:	There's a spec question. If the objects have a four inch buffer, at what point would collision be detected?
[17:54]	Sidewinder Linden:	or maybe a capture of some of this on the wiki... i'm thinking that folks may want to rework some weapons after the new behaviors are understood better
[17:54]	Rex Cronon:	what is to optimize?
[17:54]	Sidewinder Linden:	bullet styles
[17:54]	Gaius Goodliffe nods.
[17:54]	Creem Pye:	I think that would be valuable
[17:54]	Sidewinder Linden:	timing
[17:55]	Atashi Toshihiko:	separation distance to keep the bullets from interferign with each other?
[17:55]	Sidewinder Linden:	random stream of consciousness idea - not fully formed - just a thought
[17:55]	Sidewinder Linden:	yes things like that
[17:55]	Gaius Goodliffe:	In the past I've often hollowed things to reduce mass, not knowing in increased physics load. I might or might not in certain cases anyway, but it's nice to know what the tradeoffs are in making that decision.
[17:55]	Andrew Linden:	Many residents have already explored that space and know what works well and what does not, perhaps better than the LL devs.
[17:55]	Sidewinder Linden:	could be...
[17:56]	Creem Pye:	certain circles tend to be secretive about that knowledge, however
[17:56]	Andrew Linden:	However, I know a few things that might be fixable in the simualtor code...
[17:56]	Rex Cronon:	if bullets have high initial speed is kind of hard for them to interfere
[17:56]	Creem Pye:	becuse they don't want the competition to learn their secrets of low lag =P
[17:57]	Andrew Linden:	for example, when rezzing bullets from a machine gun... the gun constantly rezzes the same asset again and again
[17:57]	Gaius Goodliffe nods.
[17:57]	Andrew Linden:	but we don't cache that asset in the simulator process. We cache it on the machine, but the simualtor has to re-parse the asset each time, and load it into an LLSD (LL Structured DAta) class
[17:58]	Creem Pye:	I read that Mono does some sort of asset caching for scripts when an object is rezzed multiple times
[17:58]	Andrew Linden:	wouldn't it be cool if we cached recently rezzed assets and checked for pre-existing LLSD structures to rez from
[17:58]	Creem Pye:	and it seems to be true after the 10th or so instance of the object
[17:58]	Gaius Goodliffe:	10th in what timeframe?
[17:58]	Creem Pye:	in a minute, maybe
[17:58]	Rex Cronon:	u can do that on server side andrew
[17:59]	Gaius Goodliffe nods.
[17:59]	Creem Pye:	I didn't test enough to get an accurante number, but the rate of fire iddn't seem to change the fact that it was the 10th one always
[17:59]	Arawn Spitteler:	Machine Gun should simply carry a repetition flag
[18:00]	Gaius Goodliffe:	Yes -- another place where scripters could help out a lot of LSL let us give you hints.
[18:00]	Gaius Goodliffe:	*if
[18:00]	Simon Linden:	It would be interesting to experiment with 'pre-rezzing' the bullets and keeping them somewhere, then the fire operation is just a matter of moving them
[18:00]	Andrew Linden:	we also do some building of the RigidBody for each new bullet. We cache and recycle the "shape" info, but not all of it. We could probably load objects faster if we recycle more of the shape, and perhaps even copied existing RigidBody's to get new instances.
[18:00]	Sidewinder Linden:	perhaps this is something that would be scriptable, rather than trying to guess the behavior - have a call that calls for a pre-rez of a certain number of an object
[18:01]	Sidewinder Linden:	then the builder can decide where the performance hit is?
[18:01]	Andrew Linden:	Havok RigidBody's have a shape, two RigidBody's might reference the same shape
[18:01]	Gaius Goodliffe:	llPreloadObject(...)
[18:01]	Sidewinder Linden:	right.... just as a thoght
[18:01]	Sidewinder Linden:	thought
[18:01]	Creem Pye:	but if it's cached, would there be a need to specify the quantity to preload?
[18:01]	Andrew Linden:	yes, that would help particularly for firt-time rezzes or very large/complicated assets
[18:01]	Arawn Spitteler:	Wouldn't bullets be two objects of different UUID, but objects of the same class, with a single UUID?
[18:01]	Rex Cronon:	like prelodsound, u can have preloadprim?
[18:02]	Creem Pye wonders how this might affect preloading of textures
[18:02]	Arawn Spitteler:	Preload Object
[18:02]	Simon Linden:	I actually think the delays we see are more of when the new prim is added to the physics engine, but in any case, this is good stuff to investigate sometime
[18:02]	Creem Pye:	otherwise the only way to "preload" textures is to apply the texture to hidden faces of existing prims
[18:02]	Andrew Linden:	No Arawn. Each object is unique and gets its own UUID, but it might be possible for two bullets to share their common info in one structure yes
[18:02]	Rex Cronon:	i was thinking that bullets are usually made of one prim
[18:03]	Andrew Linden:	That is sorta what happens with the object shapes
[18:03]	Gaius Goodliffe:	When I've made bullets before, they needed to be two prims.
[18:03]	Creem Pye:	why?
[18:03]	Gaius Goodliffe:	The visible prim, then a long invisible prim to prevent it from just flying through solid objects without a collision.
[18:04]	Arawn Spitteler:	@Rex, a bullet is typically one prim, but should not have to be. A Preload Object could preload the class of that object
[18:04]	Gaius Goodliffe:	Otherwise I could just shoot through things.
[18:04]	Atashi Toshihiko:	I just use a single long visible prim - they look like 'streaks' when they go :)
[18:04]	Andrew Linden:	right, elongated bullets is something that most game engines do under the hood for you
[18:04]	Andrew Linden:	to prevent tunneling because of the discrete timesteps of the simulation
[18:05]	Gaius Goodliffe nods.
[18:05]	Creem Pye:	you can calculate the necessary bullet length by figuring out how far it would travel in 1 sim frame
[18:05]	Andrew Linden:	well, I'm going to have to go soon
[18:05]	Creem Pye:	although it's good to add some margin in case the target is approaching you =)
[18:05]	Andrew Linden:	any last minute topics?
[18:05]	Atashi Toshihiko:	Does anyone have a working havoc4 train?
[18:06]	Andrew Linden:	Kitto Flora makes trains, and has some that work in Havok4 I think.
[18:06]	Arawn Spitteler:	Mocha has only a tag end of track
[18:06]	Simon Linden:	I have to run ... thanks everyone, will see you next week
[18:06]	Atashi Toshihiko:	I will look Kitto up :)
[18:06]	Atashi Toshihiko:	Thanks :)
[18:06]	Creem Pye:	thanks for your time
[18:06]	Les White:	thanks Simon
[18:06]	Rex Cronon:	b
[18:06]	Simon Linden:	bye
[18:06]	Arawn Spitteler:	I've found my Fast Hobo flying, in odd circumstances, but that's on Mainland
[18:06]	Rex Cronon:	bye simon
[18:06]	Atashi Toshihiko:	Bye
[18:07]	Andrew Linden:	alright then, see you all next week.
[18:07]	Les White:	thanks Andrew
[18:07]	Les White:	good stuff :)
[18:07]	Atashi Toshihiko:	Thanks very much :)
[18:07]	Les White:	thanks Sidewinder
[18:07]	Les White:	se you all
[18:07]	Rex Cronon:	bye everybody
[18:07]	Creem Pye:	let me know if you're interested in getting testers for a cached asset rezzing test
[18:08]	Cinthya Loveless:	im going to go test the fix you did andrew thanks for getting it
[18:08]	Atashi Toshihiko:	Bye everyone :)
[18:08]	Cinthya Loveless:	the svc 1520
[18:08]	Sidewinder Linden:	thanks all