Simulator User Group/Transcripts/2011.08.16
| Prev 2011.08.12 | Next 2011.08.19 |
List of Speakers
| Andrew Linden | Arawn Spitteler | Falcon Linden |
| Fancy Greeter | Flip Idlemind | Helena Lycia |
| Kadah Coba | Kaluura Boa | Kelly Linden |
| Leonel Iceghost | Liisa Runo | Mercille Linden |
| NeoBokrug Elytis | Pauline Darkfury | Qie Niangao |
| Ramona Criss | Rex Cronon | Sahkolihaa Contepomi |
| Simon Linden | Stickman | TankMaster Finesmith |
| Tiberious Neruda | Vincent Nacon |
Transcript
[12:03] Helena Lycia: Hiya Andrew
[12:04] Andrew Linden: Hello.
[12:04] Tiberious Neruda: hi :3
[12:04] Liisa Runo: hi everybody
[12:04] Kelly Linden: Stickman - I haven't heard of any yet
[12:04] Sahkolihaa Contepomi: Hey Andrew.
[12:05] Andrew Linden: Ok so the news...
[12:05] Andrew Linden: I'm pretty much all done with what I was working on for mesh
[12:05] Tiberious Neruda: and that is...?
[12:05] Rex Cronon: greetings everybody
[12:05] Andrew Linden: so maybe I'll move on to some other stuff, but more likely I'll be doing mesh maintenance for the next month or so.
[12:06] Andrew Linden: That is... making sure parcel accounting is correct, operations can't push parcel owners over their resource limits, and returning objects in the correct order whenever parcel owners do happen to go over their limits.
[12:06] Stickman: Kelly, no news is good news.
[12:06] Andrew Linden: However, all that work will go into a mesh update.
[12:06] Tiberious Neruda: ah... stuff that we need when PEwt balloons out of control :3
[12:07] Tiberious Neruda: awesomeness
[12:07] Vincent Nacon: what about physical object encroaching the parcel that's over the limit?
[12:07] Andrew Linden: In the current mesh RC it works pretty good, but there are a few ways land owners can go over their resource limits by accident.
[12:07] Andrew Linden: er... all that work will go into a mesh update in a few weeks.
[12:08] Rex Cronon: AFK...............................
[12:08] Rex Cronon: afk
[12:08] Andrew Linden: encroaching objects do not contribute to a land owners's resource limit
[12:08] Andrew Linden: they just encroach
[12:08] Andrew Linden: visibly, and physically
[12:09] Vincent Nacon: only from where they were rezzed at?
[12:09] Andrew Linden: Today, to fill in some empty space I decided to try to make an optimization pass on LSL script operations...
[12:09] Andrew Linden: there is a possibility of a performance increase by changing the type of data that is passed around deep inside the script engine
[12:10] Andrew Linden: so we can avoid a bunch of lookups
[12:10] Andrew Linden: so I'm going to try that out and see what happens
[12:10] NeoBokrug Elytis: Hooray
[12:10] Vincent Nacon: sweet
[12:10] Andrew Linden: I'm testing my work against some LSL benchmarks I found on the web
[12:10] Andrew Linden: that were used to compare LSL and MONO performance
[12:10] Kelly Linden: I have some benchmarks as well.
[12:11] Andrew Linden: If I actually make a difference then I'll submit it for test. If not, I'll abandon the work.
[12:11] Andrew Linden: It shouldn't take too long to do, but I'm doing in my copious spare time, so no promises for when it gets done.
[12:11] Vincent Nacon: fine with me. :)
[12:11] Andrew Linden: I think that is all the news I've got.
[12:12] Liisa Runo: SCR-162
[12:12] JIRA-helper: http://jira.secondlife.com/browse/SCR-162
[#SCR-162] Bounds error when calling PRIM_LINK_TARGET in a child prim
[12:12] Andrew Linden: So we'll open the table.
[12:12] Simon Linden: Yep, we've imported and will be getting to that one sometime, Liisa
[12:12] Andrew Linden: Go ahead Tiberious.
[12:13] Kelly Linden: Oops Liisa. That should be easy to fix.
[12:13] Tiberious Neruda: are there any reasons why a physical object made phantom via llVolumeDetect doesn't throw land_collision* events?
[12:14] Tiberious Neruda: does it have to do with how the collision with the ground works on a physical level?
[12:14] Helena Lycia: Poor Stickman - he's tired
[12:14] Andrew Linden: Yes. llVolumeDetect() actually uses a feature in the Havok physics engine called a "phantom listener"
[12:14] Ramona Criss: Hello all :)
[12:14] Andrew Linden: which is a shape that provided callback events when objects enter or leave
[12:14] Andrew Linden: but does not actually collide.
[12:14] Rex Cronon: back
[12:14] Rex Cronon: hi
[12:14] Simon Linden: Nice of you to drop in, Pauline
[12:15] Andrew Linden: note that Havok's term "Phantom" does not mean the same thing as "SL phantom".
[12:15] Pauline Darkfury: :)
[12:15] Andrew Linden: We use "phantom" to mean "collides with nothing but the terrain"
[12:15] Tiberious Neruda: reason I'm asking this is I have an object that uses llVolumeDetect to simulate bouncing and letting an av hit it without stopping....
[12:15] Andrew Linden: The reason we made it collide with the ground was that when we first delivered that feature it was totally collisionless, but people would make objects that would fall through the ground and get lost.
[12:16] Tiberious Neruda: but because of no land_collision*, I have to use a timer to simulate the simulation
[12:16] Fancy Greeter: Mercille Linden has arrived!
[12:16] Sahkolihaa Contepomi: :o
[12:16] Andrew Linden: So we made "phantom" objects collide with the ground.
[12:16] Vincent Nacon: late again, Mercille :)
[12:16] Tiberious Neruda: as you can see....
[12:16] Mercille Linden: I blame WIndows
[12:17] Vincent Nacon: muhaha!
[12:17] Liisa Runo: Tiberious. You could also link the VolumeDetect prim with normal phantom prim, that way it would stay above terrain and still let other stuff pass trough
[12:17] Andrew Linden: Tiberious, I take it you're using the llVolumeDetect callbacks to figure out when objects pass through?
[12:17] Tiberious Neruda: yes
[12:17] Stickman: Did I AFK all over the table? :x Sorry.
[12:17] Tiberious Neruda: it checks what it hits
[12:17] Andrew Linden: Otherwise, if all you want is non-collision with avatars you can use regular (SL) "phantom"
[12:17] Tiberious Neruda: an av trigegrs one routine, an object triggers another
[12:17] Vincent Nacon: naa
[12:18] Vincent Nacon: just don't want you miss it out
[12:18] Andrew Linden: Hrm...
[12:18] Andrew Linden: Well, there isn't an easy way for us to provide collision for VolujmeDetect objects
[12:19] Tiberious Neruda: okay, the question becomes...
[12:19] Andrew Linden: they really are collisionless (for collision purposes) in the physics engine
[12:19] Tiberious Neruda: how is the ground treated by the physics engine?
[12:19] Vincent Nacon: just use Position to find its range by volume then
[12:19] Andrew Linden: The ground is a "heightfield" which is just a shape that has an array of heights
[12:20] Andrew Linden: when objects collide with the heightfield the phys engine builds triangles from the heights where the objects collide
[12:20] Andrew Linden: and then does collisions between the objects and the triangle shapes
[12:20] Andrew Linden: each colliding "object" in the physics engine can be given a "collision group"
[12:20] Andrew Linden: and collisions can be selectively disabled between various groups
[12:20] Tiberious Neruda: see, the current 'hack' does a constant check of ground height (via llTimer and llGroundHeight), and does the bounce routine if it's below that with a tolerance
[12:21] Andrew Linden: which is how we provide "phantom" objects (collides with terrain only)
[12:21] Andrew Linden: the terrain object uses a particular group, and regular objects use a different one
[12:21] Andrew Linden: and phantom objects another still
[12:21] Andrew Linden: collisions between the first and third are enabled, but not between the second and third
[12:22] Tiberious Neruda: so there's no way, or it would be too server-intensive, to cause it to throw a land_collision* event when passing by the ground?
[12:22] Vincent Nacon: this collision group sounds like could have added into llCollisionFilter
[12:22] Andrew Linden: Hrm... good question. Could entry/exit events be provided for VolumeDetect and the terrain?
[12:23] Andrew Linden: I don't know off the top of my head. I'll try to remember to ask Falcon and/or look at the code.
[12:23] Tiberious Neruda: I doubt there's a land_collision_end event
[12:23] Andrew Linden: It could probably be done (guessing) but don't know how expensive (CPU-wise) it would be
[12:23] Tiberious Neruda: so it would throw land_collision_start, and then land_collision while it's underground
[12:23] Andrew Linden: Right, and work would have to be done to expose that feature.
[12:24] Tiberious Neruda: (I tried a llGroundRepel instead of the timer, but that murdered the velocity of the object)
[12:25] Andrew Linden: Right, llGroundRepel would not conserve engery upon impact.
[12:25] Vincent Nacon: speaking of which. SVC-4562 Maybe work around by adding land into the filter if CPU is too much with land_collision event
[12:25] JIRA-helper: http://jira.secondlife.com/browse/SVC-4562
[#SVC-4562] Depreciate llCollisionFilter in favor of llFilterCollisions (new functionality)
[12:25] Liisa Runo: Kelly wanted to share some benchmarks with us?
[12:25] Tiberious Neruda: anyway... I'm gonna let it go for now :3
[12:25] Vincent Nacon: may not be phantom I guess
[12:25] Tiberious Neruda: can't monopolize the time
[12:26] Kelly Linden: Oh, I was actually just letting andrew know I have more benchmarks for him to use to test his changes.
[12:26] Liisa Runo: ah
[12:26] Vincent Nacon: monopolize it, Tib!
[12:26] Kelly Linden: but I can upload a screenshot I shared at the scripting group yesterday
[12:26] Tiberious Neruda: do have an interesting idea for a couple new events and a prim 'type' (more like a setting) to go with it for later
[12:26] Flip Idlemind: So, my comment on SCR-162:
[12:26] Flip Idlemind: For that matter, calling llSetLinkPrimitiveParamsFast() on a prim that doesn't exist (such as "llSetLinkPrimitiveParamsFast(90, [PRIM_COLOR, -1, <1,1,1>, 1.]);" on a single prim object) silently fails, and doesn't generate an error. I don't think PRIM_LINK_TARGET should throw a bounds error at all, just silently fail if the prim it's targeting isn't there.
[12:28] Kelly Linden: This graph is average SimFPS on our Second Life Server channel.
[12:28] Kelly Linden: DRTSIM-75 was the scripting and sim performance release that went out a couple of weeks ago
[12:29] Vincent Nacon: hmmm sudden boost I see
[12:29] Kelly Linden: And DRTSIM-61 was the maint-server release before that.
[12:29] Pauline Darkfury: looks encouraging, Kelly
[12:29] Vincent Nacon: what made that such boost btw?
[12:29] Kadah Coba: Whats with the drops and sudden spikes?
[12:30] TankMaster Finesmith: ^
[12:30] Kelly Linden: Release days wreak havoc on our stats
[12:30] Kadah Coba: Effects of restarting?
[12:30] Kadah Coba: Aah
[12:30] Sahkolihaa Contepomi: Makes sense
[12:30] Andrew Linden: DRTSIM = Deploy Request Tracker SIMulator (or something like that)
[12:30] Vincent Nacon: still... it's quite a boost, regardless of the restarts
[12:30] Meeter: Timecheck : User Group is half over
[12:31] Andrew Linden: It is a jira category that our #release team uses for tracking projects that need to get tested and deployed.
[12:32] Vincent Nacon: Did you talk to Falcon about prim density issue yet, Andrew?
[12:33] Kelly Linden: Also the Scripting Maintenance branch from BlueSteel got released to the Second Life Server channel today and has some cool features and better script performance particularly for idle scripts.
[12:33] Andrew Linden: Yes a little bit Vincent. I can't repeat what he said here -- it would be too impolite ;-)
[12:33] Vincent Nacon: muhaha!
[12:33] Vincent Nacon: I know the pain I'm giving him
[12:33] Tiberious Neruda: prim density issue?
[12:33] Rex Cronon: i heard that now we have llSetMemoryLimit:)
[12:33] Kelly Linden: We do.
[12:33] Qie Niangao: speaking of prim density... it's maybe another thing to add to the growing list of prim parameters that aren't exposed to scripts... notably PROJECTION and SLICE
[12:33] Pauline Darkfury: I did some testing of the latest script engine on BlueSteel, Kelly. Seems like 100% load from idle scripts on an idle sim is up to approx 11,000-12,000 scripts now, for Class 5, and about 4000-4500 for Class 7
[12:34] Vincent Nacon: CTS-573
[12:34] JIRA-helper: http://jira.secondlife.com/browse/CTS-573
[#CTS-573] Incorrect Prim Density Value
[12:34] Sahkolihaa Contepomi: Unfortunately, a lot of sims I go to are Magnum and Mesh so...I can't use it on my scripts yet.
[12:34] Pauline Darkfury: That's a significant boost (more than double) for both cases
[12:34] Kelly Linden: yea Pauline.
[12:34] Andrew Linden: The "prim density" issue is a discrepancy between the density units used in the viewer UI and the LSL llGetMass() function.
[12:34] Liisa Runo: so today it is in bluesteel and main channel, myt not on tigre, mesh or magnum. am i correct? and it goes grid wide tomorrow?
[12:35] Vincent Nacon: and it's a easy fix for crying out loud
[12:35] Tiberious Neruda: ah
[12:35] Pauline Darkfury: And, I pushed BlueSteel Sandbox 2 up to 120,000 scripts out of curiosity. Other than timeslice factor going down to a little below 1/10th of normal, it seemed to perform just fine
[12:35] Kelly Linden: Liisa: correct
[12:35] Kelly Linden: that is quite a few scripts pauline.
[12:35] Pauline Darkfury: 110,000 scripts shows almost exactly 10x overload, in terms of timeslice
[12:35] Andrew Linden: Vincent, on that prim density issue we may need to get some Linden "UI/Experience" people to intervene...
[12:35] Pauline Darkfury: Yup, I wouldn't recommend running that number of scripts normally ;)
[12:36] Vincent Nacon: aye that too
[12:36] Flip Idlemind: Is there any reason a script using llSetMemoryLimit() would use more script time than an otherwise identical script that doesn't use it?
[12:36] Kelly Linden: flip: no
[12:36] Kelly Linden: not if it is set once and left.
[12:36] Arawn Spitteler: 10,000 resize scripts sounds like 40 models
[12:36] Andrew Linden: it is basically engineer UI design around a legacy "misbug" (feature that is really a bug) that is hard to actually change.
[12:37] Vincent Nacon: yeah... didn't your UI guy left the lab?
[12:37] Andrew Linden: We still have some. I'm not sure which one you're talking about.
[12:38] Vincent Nacon: oh.. it was a month ago or so, nevermind then
[12:39] Andrew Linden: I'm just sayin... I don't really foresee much progress on that issue until we get somone on the product side who really cares and is willing to push some engineers around until we actually compromise... or add new features to use instead.
[12:39] Vincent Nacon: isn't that your job, Mercille?
[12:40] Tiberious Neruda: ...new features?
[12:40] Andrew Linden: like llGetCorrectMass() or something
[12:40] Tiberious Neruda: ah
[12:40] Vincent Nacon: eh?
[12:40] Andrew Linden: llGetMass2()?
[12:40] Vincent Nacon: whjy?
[12:40] Vincent Nacon: why*
[12:40] Vincent Nacon: we don't need a new one
[12:40] Simon Linden: llGetTheOtherMass()
[12:40] Arawn Spitteler: llGetVolume?
[12:40] Andrew Linden: the LSL llGetMass() units are a misbug -- wrong units
[12:41] Andrew Linden: but llGetMass() can't be changed.
[12:41] Vincent Nacon: oh god... now he's confused too
[12:41] Tiberious Neruda: ...'cause it would break content
[12:41] Tiberious Neruda: I getcha
[12:41] Vincent Nacon: Andrew, llGetMass is fine, leave it alone
[12:42] Andrew Linden: No, that is part of the problem... llGetMass() is not fine... the units are way off from "real life" units.
[12:42] Tiberious Neruda: but speaking of mass and such...
[12:42] Andrew Linden: Meanwhile, we have nearly "real life" units for length and time (meters and seconds)
[12:42] Vincent Nacon: oh I know, SL is never correct with any unit given
[12:42] Arawn Spitteler: llGetMassInCubicMeters
[12:42] Tiberious Neruda: what about realistic water interactions?
[12:43] Arawn Spitteler: Realistic Water would also break content
[12:43] Vincent Nacon: err well... ok basically you're saying you want to give SL the correct unit while I was saying the label for density input is not correct, no matter what Unit is given.
[12:43] Andrew Linden: Tiberuous, I suspect we won't be getting realistic water interactions until we do a lot more physics on the viewer-side.
[12:43] Andrew Linden: Fluid dynamics is just too much for the server to handle for every avatar/object.
[12:43] Tiberious Neruda: not if it's done via water_enter and water_exit events?
[12:43] Liisa Runo: and llSetLinkPrimitiveParamsFast(i,[RENDER_AS_WATER,TRUE]);
[12:43] Tiberious Neruda: that would be awesome too
[12:44] Andrew Linden: Oh, you mean just water transition events for LSL scripts?
[12:44] Tiberious Neruda: actually kinda like the idea of a 'water' prim setting
[12:44] Tiberious Neruda: yeah
[12:44] Liisa Runo: just ability to make prim that looks identical to SL water
[12:44] Kaluura Boa: Ho yeah! Please!
[12:44] Vincent Nacon whispers: with shader effect?
[12:44] Helena Lycia: Yes please
[12:44] Tiberious Neruda: water_entry could be thrown when going lower than sim water height, or entering a prim with water effect enabled
[12:44] Liisa Runo: with all the same effects that the current water has
[12:45] Andrew Linden: those two (distinct) features could be done, yes.
[12:45] Kaluura Boa: No more ugly prim waterfalls!
[12:45] Helena Lycia: I raised a JIRA request for that years ago
[12:45] Vincent Nacon: well
[12:45] Sahkolihaa Contepomi: I think it's your JIRA I once read, heh.
[12:45] Fancy Greeter: Falcon Linden has arrived!
[12:45] Arawn Spitteler: Splash PArticles would be viewer side
[12:45] Andrew Linden: doesn't "fall" yet
[12:45] Andrew Linden: well... SL water doesn
[12:45] Tiberious Neruda: and water_exit for the reverse
[12:45] Andrew Linden: doesn'
[12:45] Vincent Nacon: I'd say forget that feature idea.... instead, let us have shader texture effect on any prim
[12:45] Vincent Nacon: and you can work around the LSL event for your need
[12:45] Tiberious Neruda: well, look at The Swimmer
[12:46] Andrew Linden: There you go Vincent. I think we've kicked that idea around the lab in the past.
[12:46] Tiberious Neruda: sometimes... it just breaks above sim water height
[12:46] Vincent Nacon: we also need shader on particle as well
[12:46] Vincent Nacon: then that would make a nice waterfall
[12:47] Andrew Linden: As far as I know we aren't working on shader material properties yet, but I know we've got some engineers who would love to work on it if they could.
[12:47] Tiberious Neruda: and, part of the HUD I'm working on that pretty much overhauls my av's controls/physics, it too deals with water
[12:48] Tiberious Neruda: I could REALLY simplify it with water events
[12:48] Andrew Linden: Tiberious, what events are you looking for?
[12:48] Andrew Linden: Er... I mean, why don
[12:48] Vincent Nacon: but of course.... I don't think 2.x or 3.0 viewer is ready for the next level of render resource
[12:48] Andrew Linden: why don't you create an SCR- jira issue with a description of what you want.
[12:49] Sahkolihaa Contepomi: Well.
[12:49] Leonel Iceghost: there is no way to set your desired velocity for your avatar when it is walking/running without lots of workarounds
[12:49] Tiberious Neruda: ...can I make it Linden-viewable only?
[12:49] Sahkolihaa Contepomi: Runitai is working on changing the viewer to OpenGL 3
[12:49] Tiberious Neruda: Leonel: I know
[12:49] Vincent Nacon: ....still
[12:49] Vincent Nacon: SL viewer is too heavy
[12:49] Andrew Linden: Tiberious, no but why would you want it "Linden only"? The jira issue would be a place for people to discuss it.
[12:50] Vincent Nacon: I think he doesn't want people steal his idea
[12:50] Tiberious Neruda: I had some issues with JIRA in the past, and I lost trust in it
[12:50] Vincent Nacon: or that
[12:50] Simon Linden: well, try the new llSetVelocity() ... I'm not sure how it will work,but it bypasses all the impluse/mass calcalutions and just sets the value
[12:50] Andrew Linden: Leonel is right. The avatar control protocol is limited and difficult to work with.
[12:50] Andrew Linden: I'm guessing llSetVelocity() won't work on avatars...
[12:51] Tiberious Neruda: may I IM you with the details, Andrew?
[12:51] Vincent Nacon: not to be rude, Tib... but just do it. :) (waiting for his payment from his sponsor)
[12:51] Liisa Runo: ...speaking of avatar controlling. i thnk it is finally time to enable http://wiki.secondlife.com/wiki/LlPointAt
[12:51] Helena Lycia: Andrew any feedback on my idea for vehicle-style movement functions for avatars?
[12:52] Vincent Nacon: Helena, did you make a jira on that?
[12:52] Vincent Nacon: would like to see that
[12:52] Qie Niangao: ooo, Liisa, yeah, and llMapDestination()'s look_at vector, and etc.
[12:52] Helena Lycia: Yes, a long time ago
[12:52] Andrew Linden: Helena, I like the idea. However, I'd prefer to implement it with an overhaul of the avatar control
[12:52] Helena Lycia: https://jira.secondlife.com/browse/SVC-4335
[12:52] JIRA-helper: [#SVC-4335] New features to improve movement options for agents
[12:52] Tiberious Neruda: ooh
[12:52] Tiberious Neruda: now THERE'S a thought!
[12:53] Stickman: That sounds exciting.
[12:53] Andrew Linden: such that vehicle avatars are enabled, as well as introducing some other long-overdue improvements to the avatar motion in general.
[12:53] Tiberious Neruda: maybe a 'control layer' that can be worn
[12:53] Vincent Nacon: you mean like puppeteer physic?
[12:53] Andrew Linden: The viewer currently controls the avatar by sending keystroke states.
[12:54] Helena Lycia: Please Andrew, would you keep in mind the potential benefits of allowing avatars and vehciles to be moved with similar settings. Couples walkers, animal saddles and so on would then be able to move the same way as avatars not using vehicles and vice-versa
[12:54] Andrew Linden: What we need is the viewer to be able to say "I want to be moving in this direction, at this speed"
[12:54] Liisa Runo: no wiewer popp, we want stuff we can script, so pure LSL awesomeness
[12:55] Arawn Spitteler whispers: VEHICLE_TYPE_AVATAR might be nice
[12:55] Falcon Linden: We'll get what andrew's describing if/when we're able to do Client Side Prediction
[12:55] Rex Cronon: it might be more usefull to have walk/run/fly to this pos in sim:)
[12:55] Andrew Linden: well, if the server could handle that kind of request, then it would be much easier for the script engine to provide similar input.
[12:55] Meeter: Timecheck : User Group is almost over
[12:55] Andrew Linden: You don't want to be writing script that say llSetButtonState("W", True)
[12:56] Andrew Linden: or do you? 8-0
[12:56] Leonel Iceghost: Andrew, currently there is a big difference between 3rd person moving (clicking your avie to turn) and mouslook, mouselook seems a lot more "stable" in terms of velocity and aceleration, is there a way for you to make 3rd person the same why 1st?
[12:56] NeoBokrug Elytis: I would take anymore buttons that you'd allow.
[12:56] Liisa Runo: no need to, most phys commands for prims alreay work when attached, just llVehicle stuff need to be tuned, and rotation must be made possible
[12:56] Leonel Iceghost: also it is more responsible in 1st
[12:56] NeoBokrug Elytis: Movement + pageup + pagedown is a bit limiting.
[12:57] Andrew Linden: Leonel, mouselook doesn't affect avatar motion really, but it does render better viewer-side
[12:57] NeoBokrug Elytis: Basically movement.
[12:57] Andrew Linden: there are a number of bugs that cause the avatar to jitter within the render'd view
[12:57] Arawn Spitteler: Doesn't mouselook change the vectors of button pushes?
[12:57] Andrew Linden: but those are viewer bugs and don't really have much to do with the server
[12:57] Leonel Iceghost: Andrew, it does.. 3rd person you turn and it takes a half second tu turn... while in 1st it is automatic
[12:58] Andrew Linden: Hrm... does it change the vectors? Lemme check the code...
[12:58] Leonel Iceghost: you may not notice, but when you're playing a game, it makes a lot of difference
[12:58] Arawn Spitteler: CAmera follows mouse, and the avatar movements should follow accordingly
[12:59] Arawn Spitteler: Forward should have a verticle component, in 1stV
[13:00] Andrew Linden: Hrm... I take that back: mouselook does actually affect the force vectors on the avatar
[13:00] Andrew Linden: for flying in particular
[13:00] Leonel Iceghost: try to aim a gun in 3rd person, and you'll see you'll never kill anything
[13:00] Andrew Linden: er... I mean "only when flying"
[13:00] Meeter: Thank you for coming to the Server User Group
[13:01] Rex Cronon: not true leonel
[13:01] Leonel Iceghost: you'll miss by 20 meters your target, that is
[13:01] Pauline Darkfury: Thanks, Lindens, have a good afternoon :)
[13:01] Andrew Linden: Yeah, well that mouselook aim is something different.
[13:01] Leonel Iceghost: well, guns takes cammera.. sorry
[13:01] Leonel Iceghost: some games take avatar rotation :P
[13:01] Tiberious Neruda: ohcrap...
[13:01] Andrew Linden: Thanks for coming.
[13:02] Liisa Runo: thanks everybody
[13:02] Tiberious Neruda: Falcon, got a quick question I need to ask you
[13:02] Tiberious Neruda: deals with physics
[13:02] Flip Idlemind: So, how ever you guize fix SCR-162, is it going to take my comment into consideration (or does anyone remember what it was?)
[13:02] JIRA-helper: http://jira.secondlife.com/browse/SCR-162
[#SCR-162] Bounds error when calling PRIM_LINK_TARGET in a child prim
[13:02] Vincent Nacon: oh now he shows up
[13:02] Andrew Linden: I've got to go. I've got someone pinging me to fix something pronto.
[13:02] Rex Cronon: tc all those leaving
[13:02] Sahkolihaa Contepomi: See you Andrew.
[13:02] Rex Cronon: tc andrew
[13:02] Vincent Nacon: take care Andrew
[13:02] Ramona Criss: *.. Bye Bye ..*`
[13:02] Ramona Criss: Andrew
[13:02] Helena Lycia: Take care
[13:02] Simon Linden: Thanks everyone for coming today
[13:02] Tiberious Neruda: how many points around a loop in a physics mesh does it take for the physics engine to treat it as round?
[13:02] Stickman: Thanks for the office hours.
[13:02] Qie Niangao: Thanks all
[13:03] Tiberious Neruda: fffff....
[13:03] Tiberious Neruda: he poofed
[13:03] Leonel Iceghost: infinite Tiberious
[13:03] Leonel Iceghost: you need to control that
[13:03] Vincent Nacon: he came.... saw me... and ran. I'm that awesome
[13:04] Vincent Nacon: but oh well
[13:04] Pauline Darkfury: Take care, all, have fun :)
| Prev 2011.08.12 | Next 2011.08.19 |