User:Andrew Linden/Office Hours/2007 12 04

From Second Life Wiki
Jump to navigation Jump to search

Transcript of Andrew Linden's office hours:

[11:01] Ryozu Yamamoto: Good morning
[11:01] Gaius Goodliffe grumbles, fumbling for coffee.
[11:01] Chair: Press Page Up to move chair up, or Page Down to move chair down
[11:02] Ryozu Yamamoto: Sorry I haven't been around the last couple weeks. Moving in RL, no internet
[11:02] Andrew Linden: Hi everybody.
[11:02] Kitto Flora: Hello
[11:02] Seifert Surface: ew, no internet
[11:02] Harleen Gretzky: Hi Andrew
[11:02] Rex Cronon: hi everybody
[11:03] Ryozu Yamamoto: Actually still no internet, I'm using a free wifi AP
[11:03] Andrew Linden: Ha! No internet... a tough trial.
[11:03] Ryozu Yamamoto: A very unstable AP at that, so if I drop out, apologies ahead of time
[11:03] Ryozu Yamamoto: Yay, 4000 sim ping
[11:04] Seifert Surface: i tested out the llpushobject things again, after the energy fix
[11:04] Andrew Linden: wow, 4 second ping
[11:04] Rex Cronon: i tried to tp here and i was logged out
[11:04] Seifert Surface: seem to be working much better, although its hard to tell if its exactly the same as in h1
[11:04] Ryozu Yamamoto: Yeah, AP is over 100m away, it's only throught he good graces of a 3 antenna linksys card I can connect at all
[11:05] Andrew Linden: Ryozu, you should set up a nice passive repeater, with a fancy directional antenna pointed at the AP
[11:06] Andrew Linden: Ok, so the state of Havok4... is that the preview is closed
[11:06] Ryozu Yamamoto: Well, DSL to be installed on Thursday, so probably not worth the money for now ;) I'll just deal until then
[11:06] Andrew Linden: still. Dan Linden didn't like the "avatar moves funny" bug
[11:06] Ryozu Yamamoto: "moves funny" eh?
[11:06] Andrew Linden: so he "failed" the QA pass
[11:06] Andrew Linden: I'm working on the bug now
[11:06] Andrew Linden: and I kinda know what is happening... but not why, or where it is starting.
[11:07] Andrew Linden: I hope to have a fix today.
[11:07] Andrew Linden: I almost forgot this office hour because I was working on the bug.
[11:07] Ryozu Yamamoto: XD
[11:07] Squirrel Wood: ^^
[11:08] Squirrel Wood: I will have to do some serious roller coaster testing once its back up
[11:08] Andrew Linden: by "moves funy" I mean... the avatar can wobble sideways when it tries to walk forward. This usually happens right after a teleport.
[11:08] Ryozu Yamamoto: Funky
[11:08] Ryozu Yamamoto: More av rotation issues
[11:08] Gaius Goodliffe: Usually happens to me after my third gin & tonic. ;)
[11:08] Rex Cronon: like a sailor walking on the land:)
[11:08] Ryozu Yamamoto: Haha
[11:09] Andrew Linden: The problem is that the avatar's rotation is tilting off the z-axis. The avatar moves around as if llSetStatus(STATUS_ROTATE_X and Y, FALSE) all the time
[11:09] Ryozu Yamamoto: I'm assuming you mean the AV object, not graphically
[11:09] Andrew Linden: yes, sorry... the avatar's collision body
[11:09] Andrew Linden: anyway,that is the main bug that is blocking the preview atm
[11:10] Ryozu Yamamoto: Andrew: Is it happening only on the heightfield or on any object?
[11:10] Andrew Linden: There was another bug about piles of objects drifting to the east... that bug is fixed.
[11:10] Andrew Linden: er... piles of dynamic objects.
[11:10] Andrew Linden: ok, so that is the news
[11:10] Ryozu Yamamoto: Two weeks ago, I noticed wonky AV rotation only when walking on the heightfield, but not on top of objects
[11:11] Andrew Linden: Hrm...
[11:11] Seifert Surface: thats the same bug as we have in h1, with feet sunk into the ground if you teleport to a high altitude destination?
[11:11] Ryozu Yamamoto: Seifert Same result, but I think the cause is different
[11:12] Andrew Linden: I'm assuming that Ryozu is talking about some other cause.
[11:12] Andrew Linden: The heightfield is still transmitted to the client with lossy compression
[11:12] Ryozu Yamamoto: In production build, it pretty much only happens on teleport. Last time I was on beta h4, it happened for a variety of other reasons
[11:12] Andrew Linden: originally we thought we would be sending "dynamic" heightfields... way back when we started in 2000 or so
[11:13] Andrew Linden: so we implemented a lossy compression scheme... for dynamic water
[11:13] Andrew Linden: but then we pulled it out
[11:13] Andrew Linden: but the lossy compression remains for heightfield
[11:13] Ryozu Yamamoto: That affects avatar movement?
[11:13] Andrew Linden: so near very sharp features of the heightfield you can have "ringing" caused by the loss of higher order frequencies
[11:13] Squirrel Wood: prim alignment through shift-x will align objects to x/y coordinates on the grid but it is off by 0.004m so instead of 198.000 you get it aligned to 198.004 (not a havok bug though...)
[11:14] Andrew Linden: that problem can cause the visible heightfield to differ from its actual collision shape
[11:14] Ryozu Yamamoto: Ah, I see. Actually Andrew, it IS a collision body issue with rotation in H1
[11:14] Andrew Linden: so it causes the avatar's feet so sink into the terrain, or for it to stand too high
[11:14] Seifert Surface: does that include the weird bent legs animation on the av?
[11:14] Ryozu Yamamoto: It also affects things like local ApplyImpulse on avatars
[11:15] Ryozu Yamamoto: Seifert: That's a client side thing where the client tries to keep the graphical avatar from sinking into the ground on hills or something
[11:15] Squirrel Wood: heh.. my terraformer must be the pure terror for heightfield stuff when it mangles an entire sims terrain ^^
[11:15] Andrew Linden: yes, the weird bent legs problem in Havok1 is usually due to lossy terrain compression
[11:15] Andrew Linden: but if you see it on a wide flat or smooth surface... it is something else
[11:16] Andrew Linden: Ryozu... what was that about the avatar's collision body in H1?
[11:16] Andrew Linden: Are you saying you know of an H1 bug that can bork the avatar's rotation?
[11:17] Andrew Linden: Squirrel, that shift-x align bug... that is an H4 bug?
[11:17] Squirrel Wood: nope. not h4
[11:17] Squirrel Wood: I get it in the windlight viewer
[11:17] Rex Cronon: btw, why when u r on the edge of an object, either one or sometimes both of your legs are set at a very strange angle?
[11:17] Andrew Linden: Oh. Is that bug entered in the public jira with a "repro recipe"?
[11:18] Squirrel Wood: I have not checked yet
[11:18] Squirrel Wood: but will do now
[11:18] Andrew Linden: Rex... atm the server sends a collision plane to the viewer, and the viewer uses it to align the avatar's feet.
[11:18] Ryozu Yamamoto: Uhg
[11:19] Andrew Linden: When you're standing on the edge of an object... the collision plane is a slope... not straight up, and not straight out.
[11:19] Andrew Linden: We really need 100% viewer-side feet placement.
[11:19] Ryozu Yamamoto: Anyways, Yes Andrew, there's a bug in Havok1 where, on teleport, there's a small chance your avatar rotation will be borked
[11:20] Ryozu Yamamoto: I found out in developing my teleporter, that often, I'd try to teleport straight up but go up at an angle due to local llApplyImpulse
[11:20] Andrew Linden: I hadn't heard of such an H1 bug. Maybe it is "new" (less than no year old ;-).
[11:20] Andrew Linden: er... one year
[11:20] Rex Cronon: ok. thanks
[11:20] Seifert Surface: nah, thats an old old one
[11:20] Ryozu Yamamoto: Well, it's at least several months old
[11:20] Ryozu Yamamoto: It just wasn't very major
[11:20] Seifert Surface: teleporting to a high altitude destination
[11:20] Ryozu Yamamoto: High altitude eh?
[11:21] Seifert Surface: sitting on something then standing fixes it
[11:21] Andrew Linden: Ok, well I'm trying to safegaurd against that failure mode in H4.
[11:21] Seifert Surface: i usually teleport low and fly up to a platform now
[11:21] Seifert Surface: likely thats a bug that will vanish
[11:21] Andrew Linden: Oh... here's some news that you guys should know...
[11:22] Ryozu Yamamoto: Odd
[11:22] Andrew Linden: another developer ventured into the avatar control code and asked, "Why is the avatar allowed to go so fast? 256 m/sec seems too high."
[11:22] Ryozu Yamamoto: uhg
[11:22] Andrew Linden: This was all instigated by a bug where H1 attachments would tend to push you too fast in H4.
[11:22] Rex Cronon: that is not too high
[11:23] Andrew Linden: So... new limits are in place.
[11:23] Ryozu Yamamoto: remind this guy it's a platform, not a platformer game? ;_;
[11:23] Andrew Linden: I think the fly speed limit is 64 and the walk speed limit is 128... both of these under the influence from attachment or pushers.
[11:23] Andrew Linden: the higher speed for walking is because that is how it was in H1
[11:24] Andrew Linden: and we didn't want to break the OmniPhaze too bad
[11:24] Seifert Surface: i had always assumed that the speed limit was supposed to be 50
[11:24] Ryozu Yamamoto: hehe
[11:24] Rex Cronon: doesn't make sense. u can walk faster than u can fly?
[11:24] Andrew Linden: so... I dunno if any new stuff is broken around avatar moving really fast.
[11:24] Ryozu Yamamoto: Suppose we'll find out when it comes back up
[11:24] Gaius Goodliffe: That's when *not* sitting on something moving I take it?
[11:24] Andrew Linden: yes
[11:24] Squirrel Wood: I dislike limits on fly speed.... but then again I do have a rather extreme flight assist ^^
[11:24] Andrew Linden: yes... when not sitting on an object
[11:25] Kitto Flora: Um.... does that imply that if you sit on an object, and havea jet assist attachment too, then you *CAN* go very fast?
[11:25] Rex Cronon: andrew, so how are people supposed to bust out of cages?
[11:25] Gaius Goodliffe: That's reasonable -- at 256m/s, you'd have only one second in a sim before you were transfering into the next one. I've tried flying that fast before, you usually end up just hanging on getting logged off when the next sim transfers fails utterly...
[11:25] Rex Cronon: or go throught walls?
[11:25] Seifert Surface: is this speed limit a cap off when something moved too fast last frame, or does it come up before an av moves that far in a frame?
[11:26] Seifert Surface: rex: sit on something and edit the prim pos?
[11:26] Ryozu Yamamoto: That's true Gaius, but there's mroe to it than that
[11:26] Squirrel Wood: its not about quickly crossing sims but to fly up/down
[11:26] Ryozu Yamamoto: It's not about quickly crossing sims, but quickly moving from PointA to PointB
[11:26] Rex Cronon: there are cages u can't sit on anything when u r inside them
[11:26] Ryozu Yamamoto: How will this affect llMoveToTarget?
[11:26] Gaius Goodliffe: Ah good point.
[11:26] Squirrel Wood: I like the peace and quiet at 40km altitude ^^
[11:26] Andrew Linden: the speed limit is enorced by the avatar motion code... which handles LSL scripted pushes from attachments and external scripts
[11:27] Seifert Surface: rex: rez something outside the cage with a sittarget then sit on it?
[11:27] Andrew Linden: that is... the speed cap is strictly enforced over llPushObject and llApplyImpulse, but not over collisions
[11:27] Gaius Goodliffe: BTW, I'm *certain* I've been orbitted at much fast speeds than 256m/s -- was this check broken?
[11:27] Squirrel Wood: There are cages that drag you all across the sim... can't rez anything reliably with those..
[11:27] Seifert Surface: and it takes the aggregate push from all lsl scripts acting on the av that frame?
[11:27] Gaius Goodliffe: *faster
[11:27] Rex Cronon: u can't sit on things if there is an object in front of them
[11:28] Andrew Linden: The caps I'm talking about are very new. You'll see them when the preview re-opens.
[11:28] Gaius Goodliffe: Ah ok
[11:28] Andrew Linden: I'm not attached to the new caps. If content is broken we can re-address the limits.
[11:28] Squirrel Wood: If you have 10 scripts pushing you at 500m/s then the total speed should still only be 500m/s and not 5000m/s
[11:28] Ryozu Yamamoto nods.
[11:28] Ryozu Yamamoto: I'll let you know
[11:29] Andrew Linden: I've got some ideas on how to reduce the push-in-no-push mode where an object is rezzed into the avatar's center
[11:29] Andrew Linden: and some of those ideas may be applicable to some cages... but I'm not sure
[11:29] Kitto Flora: What about llPushObject() on an Av, on Stand Up? That seems to have become broken recently in H1. Any fixes in H4?
[11:30] Andrew Linden: I don't know how that is broken in H1
[11:30] Seifert Surface: thats a really nasty way to fix a problem
[11:30] Andrew Linden: It is likely that it is NOT broken in H4... or broken for a totally different reason.
[11:31] Kitto Flora: I rewrote code in H1 to make push-on-stand-up work again. Customers report it broke in the last couple weeks or so
[11:31] Andrew Linden: Seifert, that is a really nasty way to fix what problem?
[11:31] Kitto Flora: I can test the old stuff in H4
[11:31] Seifert Surface: well, ive heard of push being used to extract an av from a vehicle when the av stands up
[11:32] Seifert Surface: i assume thats what kitto is referring to
[11:32] Kitto Flora: Seifert: That is the application
[11:32] Gaius Goodliffe: Yup, I've done that.
[11:32] Seifert Surface: is it reliable?
[11:32] Andrew Linden: Ah... I see. A workaround for bad sit-up behavior.
[11:32] Gaius Goodliffe: No
[11:32] Seifert Surface: i would imagine not
[11:32] Kitto Flora: Not any more - in local. Local is broken
[11:32] Gaius Goodliffe: I switched to using animations with a z-offset.
[11:32] Seifert Surface: thats delicate stuff, too dependent on timing and so on
[11:33] Kitto Flora: Have to use Global, and fired off some big prim - not a tiny sit ball - and compute the vector real time. And make the vehicle phantom for a while
[11:33] Kitto Flora: Then you can get the av out of the vehicle
[11:34] Andrew Linden compiles again on the side
[11:34] Seifert Surface: yikes
[11:34] Seifert Surface: hmm
[11:34] Seifert Surface: could you use the move av in linkset trick to move it out first?
[11:34] Gaius Goodliffe: Yeah, I resorted to two tricks: on some models, I just make the vehicle phantom for 3 seconds, on others, I make the sit target outside the vehicle, and use an animation to move the av back in. Then no problem when they sit up.
[11:34] Andrew Linden: Kitto, this is all to fix what exact shorfall of the sit-up behavior? Getting the avatar snagged in the middle of the vehicle/seat?
[11:35] Seifert Surface: llSetLinkPrimitiveParams hack
[11:35] Gaius Goodliffe: I'll have to look at that hack -- you're just setting the position of the linked object # beyond the end of your actual object?
[11:35] Kitto Flora: Andrew: Yes, either sangged, or does not get pushed, or sometimes geths thrown far away. And it depends on the angle of the seat.
[11:35] Ryozu Yamamoto: Seifert: I don't think it'd help on unsit, since they'd already no longer be a part of the link set, but it may have application by having the sit target above the vehicle then moving them into position after sitting... depends on where they unsit, the sit target or their actual link set position.
[11:36] Kitto Flora: lag...
[11:36] Gaius Goodliffe: Ah yes, good point.
[11:36] Seifert Surface: ah, you cant run any code before the unsit
[11:36] Gaius Goodliffe: Nope.
[11:36] Ryozu Yamamoto: But if they "Unsit" at the sit target, NOT at their actual link set position, that may work
[11:36] Seifert Surface: unless you make a button for unsit on your hud or whatever
[11:36] Ryozu Yamamoto: But I doubt that
[11:36] Seifert Surface: yes
[11:37] Ryozu Yamamoto: It's worth looking into though
[11:37] Gaius Goodliffe: They do unset at the sit target -- the trick of fixing it using an animation depends on that behavior.
[11:37] Kitto Flora: Lost connection to sim...
[11:37] Gaius Goodliffe: *unsit
[11:37] Andrew Linden: I think any workaround that actually works is fair game until we fix the unsit to put the avatar in a safe spot.
[11:37] Kitto Flora: What was the last unanswered question to me?
[11:37] Ryozu Yamamoto: Gaius: right, but what if you use the SetLinkPrimParam hack to move them, do they still unsit from the sit target after that?
[11:38] Gaius Goodliffe: Good question. I'll have to experiment...
[11:38] Kitto Flora: Andrew: There is no particular satnd up safe spot for an av when the interior of the vehicle is small
[11:38] Ryozu Yamamoto: Andrew: There may not be a good answer. Sometimes, you Do want them to unsit inside the object (but not inside a collision box) such as the inside of a space ship
[11:39] Ryozu Yamamoto: So each instance would be vehicle specific
[11:39] Kitto Flora: Hence we have to push the avatar out of the vehicle body
[11:39] Andrew Linden: Yeah, I guess I was thinking about the snagging problem.
[11:39] Kitto Flora: Theres snagging to
[11:39] Andrew Linden: The avatar should unsit into a spot that is not penetrating anything
[11:40] Ryozu Yamamoto: The closest non-penetrating spot may work fine
[11:40] Andrew Linden: so if they fit inside the spaceship... then they would unsit there.
[11:40] Kitto Flora: I think the failed push on stand up has also bitten the engines, because the last couple of weeks I am getting foot snagging in the roof again.
[11:40] Gaius Goodliffe: My own problem was that usually people with end up trapped inside the fuselage (which tends to be rather spacious in an airship. :)
[11:40] Seifert Surface: hmmm
[11:40] Ryozu Yamamoto: ;)
[11:40] Seifert Surface: you know, an UnSitTarget would fix this
[11:40] Ryozu Yamamoto: That would be ideal, probably
[11:40] Gaius Goodliffe nods.
[11:40] Andrew Linden deploys a test simulator to Havok4 preview "Sandbox Newcomb"
[11:40] Kitto Flora: Yep - may de able to stand inside the body just - but then cant walk out
[11:41] Seifert Surface: dont try to automate it, there are too many cases
[11:41] Ryozu Yamamoto still votes for toggleable phantom avatars ;)
[11:41] Kitto Flora: Setable unsit target would be great
[11:41] Andrew Linden: right, and the unsit and it targets should be editable via the UI -- shouldn't require a script.
[11:41] Seifert Surface: yes
[11:41] Gaius Goodliffe: Is there a JIRA request for an llUnSitTarget? If not, there should be.
[11:42] Ryozu Yamamoto: Probably isn't one, but it's never too late to make one ;)
[11:42] Andrew Linden: I think the current sit-target is settable via the script, but does not live with the script... it stays with the object. Anybody tested that?
[11:42] Squirrel Wood: unsittarget should be in local coordinates though
[11:42] Ryozu Yamamoto: This is true Andrew
[11:42] Andrew Linden: Just like the llSetText() text
[11:42] Seifert Surface: i think thats true
[11:42] Ryozu Yamamoto: It's a prim property
[11:42] Andrew Linden: Ok, then my memory of the code is correct.
[11:43] Kitto Flora: yes its a well known property of a prim (sit target)
[11:43] Squirrel Wood: yep. prim property
[11:43] Seifert Surface: have a local/global flag somewhere too
[11:43] Seifert Surface: http://jira.secondlife.com/browse/SVC-886
[11:43] Squirrel Wood: https://jira.secondlife.com/browse/VWR-3624 (SHIFT-X Align to Grid does misalign by 0.004m on X and Y axis and does NOT align on Z axis at all.) - If you want to vote... feel free to ^^
[11:43] Gaius Goodliffe: Not sure where global would be useful, but if it ain't hard to implement, why not. :)
[11:44] Seifert Surface: sittarget is local atm?
[11:44] Squirrel Wood: llUnSitTarget(<0,0,0>) <= estate/sim coords :p
[11:44] Gaius Goodliffe: Ah, thanks.
[11:44] Seifert Surface: if sittarget is local then unsittarget should be too
[11:44] Ryozu Yamamoto: It's local to the object
[11:44] Ryozu Yamamoto: Yes, indeed
[11:44] Kitto Flora: Unsit target would sure save a bunch if time and LSL lines
[11:44] Gaius Goodliffe: Yes, llSitTarget is local. It would be useless for me otherwise -- almost impossible to use in vehicles if it was global.
[11:44] Seifert Surface votes
[11:44] Ryozu Yamamoto: Otherwise, vehicles would have to constantly re-set the unsit target every time it moved
[11:44] Andrew Linden: just curious... what should the distance limit for unsit_target be?
[11:45] Ryozu Yamamoto: Same as sit target, 300m
[11:45] Andrew Linden: details details
[11:45] Seifert Surface: seems sensible
[11:45] Rex Cronon: 2000m:)
[11:45] Ryozu Yamamoto: Heh
[11:45] Andrew Linden: hehe, the sit_target limit is 300?!
[11:45] Gaius Goodliffe: In almost every possible way, it should work exactly like llSitTarget. :)
[11:45] Ryozu Yamamoto: And, llUnsitAvatar should unsit them at the unsit target
[11:45] Seifert Surface: thats how your short range teleporters work
[11:45] Ryozu Yamamoto: Andrew: Yes, this is a common way to do sit teleporters
[11:45] Kitto Flora: <10M would do for vehicles
[11:45] Seifert Surface: depends on the size of the vehicle
[11:46] Gaius Goodliffe: As for why llSitTarget has the weird limits it does, no one knows. If they can be eliminated, the unsit ones should similarly go away. :)
[11:46] Kitto Flora: But if the vehicle is THAT big then walking out is the option
[11:46] Gaius Goodliffe: 10M would be WAY to small.
[11:46] Ryozu Yamamoto: Kitto: If built that way
[11:46] Seifert Surface: within the same sim is probably a good idea for the sitting and unsitting
[11:46] Squirrel Wood: sit targets are often used for teleporters so I think it should be extended to 1024m :p
[11:46] Andrew Linden: I suspect llSitTarget had NO limit once, and we eventually capped it... but people were already relying on very distant teleports by then.
[11:46] Squirrel Wood: on the z axis at least
[11:47] Ryozu Yamamoto: Probably
[11:48] Kitto Flora: If you made the unsit target capable of crossing sim boundary would that complicate its developemnt?
[11:48] Seifert Surface: can sittargets cross sim bdries?
[11:48] Andrew Linden: yes perhaps... if the avatar could be put more than one region away I think it would cause problems
[11:48] Ryozu Yamamoto: I believe so
[11:49] Squirrel Wood: I guess sim border should cap the offset "automagically"
[11:49] Gaius Goodliffe: "Within the same sim" is meaningless for a vehicle. Although my back of the envelope calculation says 1086.11m would be maximum same-sim distance
[11:49] Ryozu Yamamoto: Be careful not to code any hardset 256m limits on that though, heh
[11:49] Rex Cronon: how about if the sit target is 2024m at least on z?
[11:49] Kitto Flora: So - becareful what fancy things you ask for in a new feature - you may defeat ever getting the new feature developed!
[11:49] Gaius Goodliffe: Remember llSitTarget is a prim local property. "sim border" is a variable
[11:50] Harleen Gretzky: You can go 519 meters away, but it is screwy, you can't see teh sim you are in, though the map is correct and standing up leaves you in limbo
[11:50] Ryozu Yamamoto still hopes for variable sim size some day.
[11:50] Andrew Linden: Yeah, you're best bet is to just ask for the feature without any caps, then exploit it to the max and declare broken content when we try to cap it.
[11:50] Seifert Surface: heh
[11:50] Ryozu Yamamoto: XD
[11:50] Gaius Goodliffe: Hehe
[11:50] Andrew Linden: I was just asking the distance limit because features like that have design details.
[11:51] Andrew Linden: There are some people who are "in charge" of UI changes at LL sorta... they care a great deal about changes to the UI
[11:51] Andrew Linden: but there isn't anyone yet who is "in charge" of general feature design... that is left up to the devs and others working on the feature
[11:51] Kitto Flora: Andrew, Any likely changes in the load capability of H4 - for big physics events?
[11:51] Seifert Surface: hmm, ui isnt that obvious for something like setting sittargets
[11:52] Squirrel Wood: Just like llSetPos only moves up to 10m at once towards the target coordinates, the same mechanism could be used to "cap" or "limit" the unsit / sit point to stay within the current sim
[11:52] Seifert Surface: oh, and theres currently a bug with sittarget, it needs a sittargetcorrect really
[11:52] Andrew Linden: Kitto, we aren't focusing on the load capability yet... actually I worry about what the H4 avatar load is on a region.
[11:52] Andrew Linden: we haven't done an avatar load test on H4 yet
[11:52] Kitto Flora: Party time?
[11:53] Andrew Linden: And... I suspect there is a bug in the "interestlist" code that sends object position/rotation updates... it seems to be sending too many of them
[11:53] Andrew Linden: that probably means there is a problem with large crowds of avatars
[11:53] Andrew Linden: and we'll have some bugs to fix when we get around to testing it.
[11:53] Squirrel Wood: havok should treat avatars like big boxes :p
[11:53] Andrew Linden: The main problem with large crowds is the interestlist code... not the physics engine
[11:54] Andrew Linden: so no... no significant changes to numbers of avatars per region in H4
[11:54] Andrew Linden: however, once H4 is done there is a project that will start that we call "object transport"
[11:54] Kitto Flora: Would that increase packets sent?
[11:54] Andrew Linden: which is going to overhaul the interestlist and probably also some border crossing stuff and object updates to the client
[11:54] Kitto Flora: (that interest list bug)
[11:55] Andrew Linden: Yes, I suspect there is an interestlist bug in H4 that is causing too many pos/rot update packets to be sent
[11:55] Andrew Linden: the bug is in the interestlist code, some of which had to be overhauled in H4, but not much of it.
[11:56] Kitto Flora: Just in H4? ie its not also a problem on H1?
[11:56] Andrew Linden: Yes, just H4.
[11:56] Andrew Linden: Well, I'm not positive about that. I was just assuming it was H4. I had "object updates" enabled last week and noticed that I seemed to be getting too many updates for certain objects
[11:57] Andrew Linden: I didn't verify that it isn't in H1, but I'll fix it in H4 and then I'll know if it was an H4 bug or not.
[11:57] Andrew Linden: If it isn't an H4 bug, I'll backport the fix to H1
[11:57] Andrew Linden: I've already done that a few times over the last year for various bugs
[11:58] Squirrel Wood: object updates.... as in full prim updates?
[11:58] Andrew Linden: No, "terse updates". The blue ones.
[11:58] Squirrel Wood: ah
[11:58] Kitto Flora: I got a complaint about monorail cars bouncing up and down in a sim... it was the packet loss thing, I was getting continual packet loss there - and the sim had 60 Avs at a party in it. Hence the possible connection.
[11:59] Squirrel Wood: 60 avs partying, possibly dozens of everchanging particle sources....
[11:59] Andrew Linden: Ah Kitto, that is an interestlist bug. The bouncing probably isn't real, but an artifact of the lost (or throttled) packets.
[11:59] Kitto Flora: Avs were out of site for em
[11:59] Gaius Goodliffe: Bouncing vehicles are a well known lag issue.
[11:59] Ryozu Yamamoto: Sounds like interpolation
[11:59] Kitto Flora: Yes - its a well known client artifact
[12:00] Kitto Flora: But all too common. I get lot of complaints about it
[12:00] Andrew Linden: As I mentioned before, we'll do some initial trials of H4 on private estates with willing estate owners.
[12:00] Gaius Goodliffe: I do find it funny that, absent packet info, the client draws things as following a different trajectory than they had on its last real update.
[12:00] Andrew Linden: We've already got enough brave estate owners for the initial trial I think
[12:01] Kitto Flora: I have an owner chomping at the bit to get H4 :)
[12:01] Kitto Flora: But that sim dont crash much....
[12:01] Andrew Linden: which should happen before the end of the year. That's what I'm trying to do anyway.
[12:01] Ina Centaur blinks innocently... what are some dangers of betatesting H4 on a private estate?
[12:01] Gaius Goodliffe: Hopefully there will be a sandbox somewhere we can all use.
[12:01] Ryozu Yamamoto: Ideally, Ina, None
[12:01] Ryozu Yamamoto: But prior bugs prove that there could be some danger to link sets, for example
[12:02] Andrew Linden: The dangers are... possible content corruption (although this is something that we test for). That is the worse-case scenario
[12:02] Andrew Linden: the worst-case is content corruption that then gets into inventory
[12:02] Squirrel Wood: heh. a good place to trial H4 would perhaps be one of the furnation sandboxes
[12:02] Gaius Goodliffe: Yes, currently, Havok4 is going to break the linking of a number of my own objects.
[12:02] Ryozu Yamamoto: Link order using llCreateLink is still different?
[12:02] Rex Cronon: or SWT, or rausch?
[12:02] Andrew Linden: that is... you rez a unique no-copy object in H4 and take back to inventory... and it derezzed in some borked state.
[12:02] Gaius Goodliffe: At least assuming it comes to the main grid like it was in beta last time I checked.
[12:02] Ryozu Yamamoto: Err, "fixed"?
[12:03] Andrew Linden: The lesser risks are...
[12:03] Andrew Linden: broken region content has to be rolled back, and the region put back onto H1
[12:03] Andrew Linden: such as... some crucial content in the region doesn't work right in H4 yet
[12:03] Ina Centaur: hmm, how quickly would content corruption be detectable?
[12:04] Andrew Linden: however, on the initial trials we would gladly do any rollback or other repairs should that happen
[12:04] Ina Centaur: and, assuming that there's automatic detection, as opposed to manual...
[12:04] Andrew Linden: uh... automatic detection of what?
[12:04] Ryozu Yamamoto: Corruption
[12:04] Gaius Goodliffe: Unknown unexpected breakage. :)
[12:04] Andrew Linden: We don't have any automated detection of corruption... the possible modes of corruption are too many to count.
[12:05] Gaius Goodliffe: Automatic detection of unknown problems is always one of my favorite feature requests. :)
[12:05] Ryozu Yamamoto: ;)
[12:05] Andrew Linden: The fastest way to find out about content corruption is to pay attention to resident reports.
[12:05] Rex Cronon: corruption of scripts, or of objects?
[12:05] Ina Centaur: lol, assumed you've got more tricks up your sleeves ;-P
[12:05] Andrew Linden: both scripts and objects fall into the "corruptable" category
[12:05] Kitto Flora: Common featuer is stuff will no longer rez from Inv.
[12:05] Ryozu Yamamoto: Rex: I don't think it's possible to detect unintended changes without knowing the creator's intent,
[12:05] Ina Centaur: say, a no copy object is corrupted... say it's some expensive vehicle or something that no one notices is messed up for a while
[12:06] Gaius Goodliffe: Or rezzes delinked...
[12:06] Ryozu Yamamoto: So automatic detection is likely impossible
[12:06] Ina Centaur: yeah, so that would be a problem for sims with content to beta test..
[12:06] Ina Centaur: yeah i was assuming the same
[12:06] Ryozu Yamamoto: Just need people hosting H4 sims to pay attention pretty much
[12:06] Rex Cronon: how can u corrupt an object or an script, using another script?
[12:07] Andrew Linden: The fact of the matter is... we don't have the QA resources to fully test changes from a project such as H4, using inhouse resources
[12:07] Ina Centaur: similar to how sim rollbacks - it's difficult to know for sure no one has rezzed anything in the past hour they're certain they don't care to lose
[12:07] Andrew Linden: the "possibility space" of SL is too large. An army of QA testers couldn't explore it fast enough
[12:07] Ryozu Yamamoto: Looks like the table's going to be returned here soon
[12:07] Ina Centaur: when would H4 be implemented gridwide?
[12:07] Ina Centaur: and, is there a way to opt out?
[12:08] Ryozu Yamamoto: Ina: Philip is talking within a few months, I think
[12:08] Andrew Linden: H4 will go gridwide sometime in 2008 Q1, I would guess
[12:08] Ryozu Yamamoto: And chances are, once it's out, it's out
[12:08] Gaius Goodliffe: Yet another problem that could be solved with an infinite number of monkeys. :)
[12:08] Ina Centaur: i remember he said voice would be ready in 6 weeks... but it was more like 3 months... so i guess by 2009 ;-P
[12:08] Squirrel Wood: What about mono?
[12:08] Andrew Linden: As soon as it is proven to be "better" than H1 we'll be trying to phase H1 regions out
[12:08] Andrew Linden: Mono is also finishing soon.
[12:08] Ryozu Yamamoto: Mono coming to the beta grid sometime soon?
[12:08] Andrew Linden: I think early trials of Mono have either started or will start soon.
[12:09] Andrew Linden: Yes, in fact.. that is a little problem for the H4 project....
[12:09] Squirrel Wood: I do have a product that at the moment eats up to 1.4 million script ips
[12:09] Ryozu Yamamoto: Probably not "soon" then
[12:09] Kitto Flora: When can we get at a Mono Beta grid?
[12:09] Ryozu Yamamoto: Oh?
[12:09] Andrew Linden: we've been on the beta grid so long that other projects now need to share it with us
[12:09] Andrew Linden: There was a recent email going around the lab... just yesterday or this morning...
[12:10] Squirrel Wood: I hope you don't mind sharing like, half a sim or so ;)
[12:10] Ryozu Yamamoto chuckles
[12:10] Andrew Linden: about how MONO was only 7x faster than LSL at computations... because of too many timer calls
[12:10] Ryozu Yamamoto: Odd
[12:10] Andrew Linden: they removed some of them and got it back up to 70x or higher
[12:10] Ryozu Yamamoto: Timer calls?
[12:10] Andrew Linden: yeah, some low-level timer call to the kernel
[12:10] Ina Centaur: WOW
[12:10] Kitto Flora: Wheee! Trains can go faster :)
[12:11] Ina Centaur: 7x is still better though :-D
[12:11] Andrew Linden: the linux kernel made that call too expensive recently, to work around some bad hardware bugs
[12:11] Ryozu Yamamoto: Any improvement is welcome
[12:11] Ina Centaur: but how much gooeier will the gray gooey wall be to prevent rez attacks?
[12:11] Ina Centaur: whhhheeeeeeeellll
[12:11] Andrew Linden: What is interesting is that someone estimated that we could make LSL about 3x faster by optimizing its same timer calls
[12:11] Velve Hax: shhh cali
[12:11] Seifert Surface: all the delays on functions will still be there
[12:11] Velve Hax: lol
[12:11] Ryozu Yamamoto: Well, that's a rez issue, I imagine it'd kick in just as fast as rezzing
[12:12] Rehab whispers: Playing...
[12:12] Andrew Linden: but the project is complicated enough that they prefer to just finish MONO instead
[12:12] Ryozu Yamamoto: Sounds reasonable to me
[12:12] Seifert Surface: but good for chunky computation
[12:12] Squirrel Wood: you can at the moment rez over 200 prims before the grey goo filter kicks in
[12:12] Andrew Linden: uh... we'll probably have to modify the greygoo stuff once H4 becomes commonly used
[12:13] Andrew Linden: I suspect there were some truely virulent goo that used to crash a H1 region so fast that it did not spread... but now spreads just fine in H4 and causes lag
[12:13] Squirrel Wood: It takes all but two prims to crash a H1 sim
[12:13] Ina Centaur: lol
[12:13] Ryozu Yamamoto: Heya Marv
[12:14] Squirrel Wood: and I'm talking instant crash
[12:14] SignpostMarv Martin: boo
[12:14] Ina Centaur: oob <3
[12:14] Ryozu Yamamoto: Heh, we know Squirrel ;)
[12:14] Andrew Linden: Well, I'm going to get back to fixing bugs... gotta get this preview open today.
[12:14] Ryozu Yamamoto: Good luck Andrew
[12:14] Seifert Surface: good luck
[12:14] Andrew Linden: Thanks for coming everyone.
[12:14] Velve Hax: yw:)
[12:14] Gaius Goodliffe: Thank you. :)
[12:14] Kitto Flora: Thanks for the words, Andrew
[12:14] Squirrel Wood: You have fun squishing bugs ^^
[12:14] Ina Centaur: lol yes thanks for the news on mono
[12:14] Rex Cronon: nice having u here
[12:14] Ina Centaur: that's exciting! :-D
[12:15] Andrew Linden: For more news on MONO, try attending Babbage Linden's office hours.
[12:15] Andrew Linden: MONO is his project. I think Donovan is also working with him.