Simulator User Group/Transcripts/2012.01.17

From Second Life Wiki
Jump to: navigation, search


Prev 2012.01.13 Next 2012.01.20

List of Speakers

Andrew Linden Jonathan Yap Kadah Coba
Kallista Destiny Kaluura Boa LSL Scientist
Motor Loon Oz Linden Qie Niangao
Rex Cronon Sahkolihaa Contepomi Script Counter
Siana Gearz Simon Linden Stickman
TankMaster Finesmith Vincent Nacon


[12:01] Kaluura Boa: Hello...

[12:01] Motor Loon: ey andrewski

[12:01] Andrew Linden: Hello

[12:01] Siana Gearz: herrooo!

[12:01] Kallista Destiny: Ave Andrew

[12:01] Sahkolihaa Contepomi: Hey Andrew & Simon.

[12:02] Kallista Destiny: Ave Simon

[12:02] Motor Loon: so, did ya all have the day off yesterday?

[12:02] Stickman: Hi Simon, Andrew.

[12:02] Simon Linden: Hi everyone

[12:02] Stickman: Also Oz.

[12:02] Andrew Linden: Excellent, I've got a nice view of the simulator stats graph.

[12:02] Kallista Destiny: Of coruse they did, It was Lee-Jackson day in Virgina

[12:02] Vincent Nacon: can you share it with us?

[12:03] Vincent Nacon: we like graph.... very much

[12:03] TankMaster Finesmith: haha andrew

[12:03] Motor Loon: I thought it was like... martin luther king day or something

[12:03] Vincent Nacon: it was, Motor

[12:03] Andrew Linden: er... I mean the "Dilation Graph 14" object in front of me.

[12:03] TankMaster Finesmith: MLK was yesterday

[12:03] Vincent Nacon: oh..

[12:03] Vincent Nacon frowns with dashed hope

[12:04] Andrew Linden: usually the dilation graph is not in view for me

[12:04] Vincent Nacon: Kelly stopping by? since he wasn't at his office hour yestorday

[12:04] Kaluura Boa: 54

[12:04] Andrew Linden: but now I get to watch all the dips and dives whenever someone TP's in

[12:05] Sahkolihaa Contepomi: Heh..

[12:05] Simon Linden: I'm not sure he'll be here ... he had to leave the office for a personal trip a little while ago

[12:05] Motor Loon: that what you guys call bathroom breaks?

[12:05] Simon Linden: This was a bit more significatn

[12:05] Andrew Linden: As for news... we don't really have any news about progress since Friday.

[12:06] Andrew Linden: Are we rolling an update this week?

[12:06] Andrew Linden looks for info...

[12:06] Motor Loon: my sim got something today atleast..

[12:06] TankMaster Finesmith: [Grid Status] [Completed] Rolling Restarts Main Channel - [Completed 09:45am PST, 17 January 2012] Todays rolling restarts are complete. -

[12:06] Stickman: Yeah, offline IMs are working again on the whole grid now.

[12:07] Kaluura Boa: Are there any chance to see an update with llSetRegionPos() soon? Or another glitch?

[12:07] Motor Loon: chased me off as I was scripting those restart notices can be easy to miss

[12:07] Simon Linden: Yes, and there will be RC rollouts tomorrow morning, assuming we don't find any last-minute problems

[12:07] Kaluura Boa: Good to know...

[12:08] Andrew Linden: Yeah, looks like SVC-7540 was fixed on the main channel, and will be fixed in the RC's tomorrow (If I'm reading the announcement correctly)

[12:08] JIRA-helper:

[#SVC-7540] Offline email notifications received but never delivered on login.

[12:08] Simon Linden: LLSetRegionPos() should be on at least one of the RC channels - it's scheduled for 2 of them

[12:09] Jonathan Yap: Is some area going to have the Z-level bugfix?

[12:09] Jonathan Yap: I couldn't find it on Aditi yesterday

[12:09] Andrew Linden: Hrm... doesn't look like info is posted for LeTigre channel

[12:09] Stickman: SVC-7540 was on BlueSteel and Magnum last week. So it's just Le Tigre that needs it now, if it wasn't updated.

[12:09] Simon Linden: I'll check, Jonathan...

[12:09] Kadah Coba: Wow, busy today :O

[12:09] Sahkolihaa Contepomi: Yup. :p

[12:10] TankMaster Finesmith: yeah, and we got Oz today to...

[12:10] Motor Loon: sleeping

[12:10] Motor Loon: sleeping on the job

[12:10] TankMaster Finesmith: lol

[12:10] Motor Loon pokes Oz

[12:11] Andrew Linden: I guess the info for this week's updates is out of date. I'll ask Oskar Linden about that.

[12:12] Simon Linden: Jonathan - unfortuantely no, that missed the cut-off for the releases. I'll be in the next one, I think

[12:12] Jonathan Yap: Okay, thank you SImon. The region on aditi where it used to be now has -fake appended to the name, and that doesn't seem to have the change in it

[12:13] Simon Linden: Right, those get cycled through different versions pretty quickly

[12:13] Andrew Linden: Well, I guess the table is open for new topics.

[12:13] LSL Scientist: the table is a lie

[12:13] Vincent Nacon is tempted to bring out his fishing rod to catch Falcon with it.

[12:15] Stickman: Tangetal topic. The subject was raised recently on sldev about adding raw animation upload support to the client. Would this require any changes on the server to be done "properly?" As I understand it, it's possible to upload a bvh file when the server expects an internal animation (using a bulk upload patch) and upload a corrupt internal animation file.

[12:15] Jonathan Yap: jira name?

[12:15] Vincent Nacon: what "raw" animation are we talking about?

[12:16] Simon Linden: Jonathan - I was wrong, it looks like it will be in one of the channels. I'm not sure which one, however

[12:16] Stickman: Internal animation format. What the client converts BVH files to. Let me grab the Jira number.

[12:16] Jonathan Yap: Simon, I'll hunt around after the roll

[12:16] Stickman:

[12:16] JIRA-helper: [#VWR-28143] Adding raw anim file upload support to Second Life

[12:16] Siana Gearz: the binary LLSD animation format (used by asset).

[12:16] Andrew Linden: I actually took a quick look this morning at the asset-upload pipeline after seeing that email thread about BVH file upload speculation

[12:17] Andrew Linden: the current pipeline does not know what to do with a BVH file, AFAICT

[12:17] Jonathan Yap: This change is already in TPVs I think

[12:17] Andrew Linden: it would just drop it

[12:17] Siana Gearz: hum, it's possible to attempt to upload a .bvh directly as an asset? is that what you're saying Stickman?

[12:17] Jonathan Yap: Andrew, I think the idea is to upload a .anim file directly, bypassing .bvh processing

[12:18] Vincent Nacon: yeah but... just for .anim file?

[12:18] Jonathan Yap: yes

[12:18] Andrew Linden: hrm...

[12:18] Vincent Nacon: bvh is more standard than .anim though

[12:18] Siana Gearz: ehr yes .anim upload is a partial feature in many TPVs, in particular those which have an exporter.

[12:18] Siana Gearz: because we don't have an .anim -> .bvh conversion when export, we need an .anim upload feature.

[12:19] Stickman: BVH is utter crap. It's quite possibly the most destructive transitional format that could have been chosen to upload files to Second Life and was chosen, I am sure, strictly because of the plentiful motion capture files to quickly upload new animations to early Second Life and popular it, but was never updated later.

[12:19] Motor Loon: sounds like something that could be misused like crazy

[12:19] Stickman: It is long overdue for something. And this is an easy solution that puts the burden on the community.

[12:20] Stickman: I might be a little passionate about the issue. Sorry.

[12:20] Siana Gearz: Motor Loon, yeah? it's possible to misuse any asset creation feature, asset service has to be resilient to such attempts. there's no way around that.

[12:21] Jonathan Yap: As this is a viewer change going before the Product Team soon what is the question about it at this meeting?

[12:21] Rex Cronon whispers: greetings

[12:21] Andrew Linden: I was just now trying to understand how an animation is uploaded to our asset system

[12:21] Simon Linden: From our (server guys) point of view, it certainly would be better if the conversions could be done in the viewer before uploading a current format

[12:22] Stickman: The question was whether to do it "right," a server change was necessary. As I understand it, there's no checking to make sure an internal animation file that's upload is actually valid before converted to an asset. But I could be wrong.

[12:22] Andrew Linden: it looks too complicated for me to figure it out while attending this meeting

[12:22] Siana Gearz: conversion is done in the viewer.

[12:22] Stickman: "Converted" how I used it was meant to mean "put into inventory as an asset."

[12:22] Vincent Nacon: BVH is crap... but what other format is there that is only built on animation alone, without 3D models like DAE?

[12:22] Jonathan Yap: What type is stored on the server when you send a bvh file? -- the viewer changes it to .anim?

[12:23] Stickman: I don't know, Vincent. How about the internal animation format? That seems to be a pretty nice one that SL is compatible with.

[12:23] Siana Gearz: viewer reads .bvh, converts it to LLSD animation (same as what it uses to play back animation), packs that into a binary type LLSD and uploads that.

[12:23] Qie Niangao: If anim assets are up for a change, it Sure Would Be Nice if they could be modified after upload... especially priority; fade-in/fade-out, etc., too.

[12:23] Stickman: Yes, Siana. So the question was, which Andrew says it larger than the scope of this meeting, is about server checking to make sure the file is valid.

[12:23] Kallista Destiny: Priority for sure

[12:24] Siana Gearz: ah, i see, ok.

[12:24] Stickman: Qie, I've brought up that topic before, and even made a Jira about it. The way the animation is created makes it non-trivial. A new asset would need to be generated. And there's no way to do that right now.

[12:24] Andrew Linden: Yeah, I'm willing to try to answer that question before next Friday, but not within the next 30 min.

[12:25] Siana Gearz: at the very least it can validate LLSD, i suppose... beyond that, the animation engine in viewer should be fixed to rid it of old bugs...

[12:25] Rex Cronon: u mean that will have to enforce how and where joints can move?

[12:25] Stickman: Thanks for the answer, Andrew. I'll try to be here Friday.

[12:25] Siana Gearz: (and animation has been the only part of the viewer which has reliably, for all these years, leaked memory, visible on any tool)

[12:25] Vincent Nacon: Stickman: could.... but it wouldn't be as friendly with any editor programs

[12:26] Kallista Destiny: Ummmm how is not reasonable to enforce, where they pivot is reasonable

[12:26] Stickman: Vincent, just need some export tools for the major 3D editors. I'd pay to have some created for community use.

[12:26] Kadah Coba: Dont forget that animation crashers are one of the most abused.

[12:26] Vincent Nacon: BVH is the best choice it can get between programmers and artists, DAE would be top choice if they don't mind 3D models data

[12:26] Siana Gearz: because of horrible viewer code in that part.

[12:27] Simon Linden: What are the best animation tools for SL now, with the current format support?

[12:27] Stickman: BVH is a motion capture format that doesn't support keyframe information. It's meant for ugly, raw data, that's later processed by an animator.

[12:27] Vincent Nacon: Poser and QAvimator

[12:28] Stickman: Simon, Daz3D, Poser (not really anymore, superceded by Daz), some Blender.

[12:28] Vincent Nacon: I dunno about Blender...

[12:28] Stickman: 3DS Max and Maya don't natively support BVH exporting. Because it's NOT an export format.

[12:28] Rex Cronon: qavimator:)

[12:28] Simon Linden: Thanks

[12:28] Vincent Nacon: but so far... most people use QAvimator for static pose

[12:28] LSL Scientist: no good animation tools available, they are all horrible, most serious anim makesrs use motion capture

[12:28] Qie Niangao: (When up for a diff topic) Have there been any recent changes that slow the Map update process? North-south strips missing again (see, e.g., west of Catnip sim), and I think whole zoomed-out resolutions.

[12:28] Rex Cronon: u can use poser but u have to do some manual editing

[12:28] Vincent Nacon: and QAvimator isn't sharpest tool in the shed though

[12:29] Siana Gearz: unfortunately, all interpolation based data formats may be incompatible with each other in detail, so filtering down data from a .BVH by dropping subkeys such that they don't upset the result much with interpolation taken into account, is sort of a viable choice.

[12:29] Rex Cronon: u actually have to open file in notepad and do some copy-paste:)

[12:30] Siana Gearz: and that's what is being done.

[12:30] Meeter: Timecheck : User Group is half over

[12:31] Simon Linden: Qie - I haven't heard of any new map problems, fwiw

[12:31] Jonathan Yap: I found one the other day, but it is a viewer issue

[12:31] Kadah Coba: So what's going on with CourseLocationUpdate? It seems that how its going to change keeps changing each week.

[12:32] Simon Linden: ... but you're right, I don't see images for Catnip right now

[12:32] Qie Niangao: I could file a jira on it, then, I guess. This isn't viewer only: Catnip .

[12:32] Simon Linden: Maybe there were problems with a recent map-generation run

[12:32] Simon Linden: Kadah - so there has been a lot of discussion and one minor update for CoarseLocationUpdate

[12:32] Simon Linden: We're not going to change that message, it would break old viewers

[12:32] Qie Niangao: True. I could wait a day or so and see if it fixes itself.

[12:33] Siana Gearz: Rex, compatibility with poser .BVH can be improved on viewer end...

[12:33] Siana Gearz: so perhaps tell me more about it if you like.

[12:33] Simon Linden: I did fix a server bug about heights above 1020 m -- they are currently reported as 0 altitude

[12:33] TankMaster Finesmith: o;d viewers is in V1 or anything that exists at this moment?

[12:33] Simon Linden: That's why the mini-map has wrong arrows for AVs that are up high

[12:33] Kadah Coba: Yeah

[12:34] Siana Gearz: i have had special handling in my viewer. altitude 0? display special style supertiny dots.

[12:34] Simon Linden: It's worse than that, Phoenix, because those are fixed-format UDP messages. It would break everything

[12:34] Stickman: Speaking of heights. this bug has existed for some time. VWR-6387 Showed up when the sim ceiling was raised.

[12:34] JIRA-helper:

[#VWR-6387] multi-prim attachments designed to move on command DO move but DO NOT show as moved when avatar's Z >= 420m

[12:34] Simon Linden: So that zero bug was due to a server math error

[12:34] Siana Gearz: which signify that we don't know where the avatar is and is possibly up in the sky.

[12:34] Siana Gearz: so you broke me i suppose :P

[12:34] Simon Linden: That's fixed, but due to the data limits (1 byte) any height above 1020m is reported as 1020m

[12:34] Stickman: It used to be fixed by right clicking on the attachment that didn't update. That doesn't work anymore. A script workaround to force a viewer update is required.

[12:34] Rex Cronon: i have a ooold verision of poser. that migh have something to with the incompatibility issues i have

[12:35] Jonathan Yap: Siana, just adjust your special handling to check for 1020 now

[12:35] Siana Gearz: okay -.-

[12:35] Kadah Coba: So you just moved the error height from 0m to 1020m

[12:35] Simon Linden: Right, if the reported AV altitude is the highest value (255 x 4 = 1020) it means "1020 and up"

[12:36] TankMaster Finesmith: im a but confused, are you saying that by properly fixing it and allowing more digits, itll brake more than just viewers?

[12:37] Kadah Coba: I guess thats only differently broken when being above 1020m

[12:37] Vincent Nacon: it's already broken as it is now though... so why not?

[12:37] Jonathan Yap: Tank, there are 2 things being talked about here

[12:37] Simon Linden: No, I mean it would break a lot of viewers because everything now relies on the fixed-format message that doesn't give enough resolution

[12:38] Jonathan Yap: Could the server negoiate with the viewer over a more precise / different coarselocation type packet and use the improved one if the viewer supported it?

[12:38] Oz Linden: We probably should have set the real ceiling at 1020 so that this could not be a problem, but that's water over the dam

[12:39] Simon Linden: Yes, we'd have to do something along those lines

[12:39] Vincent Nacon gives Oz a very cold stare...

[12:39] Jonathan Yap: Is that easy to do Simon, given what is out there now?

[12:39] Kadah Coba: Could a couple more bytes be added to the end of the message for heights above 1020m? Shouldn't old viewers be fine and just read the first byte and newer viewers can decode the last couple bytes at the end for additional resolution?

[12:39] Oz Linden: No, that's not easy to do

[12:39] Stickman: Could do what Eve Online did, and say everything outside of the new range will be deleted.

[12:39] Kallista Destiny: Or perhaps emit a second larger range mesage that would be ignored by non compliant viewers

[12:39] TankMaster Finesmith: we dont mind updating the viewer to handle new code that properly reprots the height, and we do have the means of forcing users to update, we just dont like to use it

[12:39] Vincent Nacon: muhaha! no Stickman

[12:40] Stickman: (As a note, they had to change their stance on that because of the outcry.)

[12:40] Jonathan Yap: Kadah, the coarselocation packet is not just 1 packet per avatar, it is a lot of data points all jammed together

[12:40] Vincent Nacon: it's just an update, Tank.

[12:40] Kallista Destiny: Yeah and you have a different packet that gets sent 1/second or something with more range

[12:40] Simon Linden: One reason this bug has sat around for so long is that the fix is somewhat complex (new messages, detecting compatible viewers, etc) and that seems to out-weigh the costmetic nature of the bug

Total Avatar Scripts - 552

Highest - TankMaster Finesmith: 78 (14%)

Lowest - Oz Linden: 0 (0%)

[12:40] Kadah Coba: Jonathan, ah ok, I wasn't sure if it was sent as one per av or many avs per packet.

[12:40] Vincent Nacon: but maybe best to save it for later when there are other updates that make a big difference to go together

[12:41] Oz Linden: I think we've got more important things to fix than whether or not minimap dots have good altitude resolution....

[12:41] Simon Linden: When push comes to shove, we end up working on more important problems liek crashers, lag, etc

[12:41] Vincent Nacon: yeah, save it for later

[12:41] Qie Niangao: or... what if the resolution were 4 times as coarse. Would that make sadness?

[12:42] Jonathan Yap: the current packet has to remain unchanged, otherwise you break all viewers

[12:42] Simon Linden: It would for older viewers that use the current calculations

[12:42] Kadah Coba: Sounds good to me, I was only wondering what was going on with it since every time I looked at the related jiras, everything had changed.

[12:42] Oz Linden: This much of a fix was low hanging fruit... negotiating a better fix and preserving some compatibility is not

[12:42] Qie Niangao: Well, the arrows would be *wrong*, but it wouldn't break the comms.

[12:43] Jonathan Yap: The Z height is sent as an unsigned byte; it's the viewer that multiplies that value by 4

[12:43] Simon Linden: It's possible to code the viewers now with correct up, down arrows, a dot, or adding a 4th graphic that means "up high somewhere"

[12:43] Siana Gearz: why would you even want half the people to see arrows wrong?

[12:44] Kallista Destiny: One of the problems that I see is that longstanding issues of low priority eventually get swept into the bit bucket, perhaps there should be a longevity multiplier for priority?

[12:44] Siana Gearz: Simon, that's what i do.

[12:44] Siana Gearz: and Henri's CoolVL has similar.

[12:44] Simon Linden: I think that's the best method for now

[12:44] Jonathan Yap: There's a LL viewer change in the pipline for showing the 4th "unknown relative altitute" state

[12:44] Kadah Coba: I had my own chevrons back in the day for "avatar is really far above you"

[12:45] Simon Linden: The other possibility on the viewer side is to look for other information -- if you're close enough to those AVs, you'll get real update messages. I'm pretty sure that info is not taken into account in the mini-map

[12:45] Jonathan Yap: hmmmm

[12:46] TankMaster Finesmith: some viewers are having to rely on lsl scripts to get the proper height

[12:46] Siana Gearz: Simon, i think it is since recently.

[12:46] Siana Gearz: at least we got that in when we ported over some newer code half a year ago.

[12:46] Simon Linden: ok, I definitely may be wrong .... I just poked a little bit in that viewer code to see the effect of this change

[12:47] Siana Gearz: so whenever an avatar has been ObjectUpdated to us, we show his real altitude on minimap.

[12:47] Siana Gearz: (we also had a hilarious bug which placed everyone on minimap in a single line if they were in view)

[12:47] Simon Linden: Is that "we" the LL viewer, or yours?

[12:47] Jonathan Yap: I didn't see that happening in the LL viewer when I made this Z coding change

[12:47] Siana Gearz: we = only my viewer, not LL.

[12:48] Simon Linden: ok, that makes sense. I didn't see that either, Jonathan

[12:48] Oz Linden: test viewer with the change Jonathan is talking about is at

[12:48] Oz Linden: (as of just a few minutes ago)

[12:50] Andrew Linden: I just took another look at the CoarseLocationUpdate message format. I really don't see how to modify its format to fit in higher resolution

[12:51] Jonathan Yap: It's a simple packet

[12:51] LSL Scientist: SVC-301

[12:51] JIRA-helper:

[#SVC-301] Meta-issue: New LSL Functions

[12:51] Rex Cronon: append a new byte at end that when is present mean that additional info is available:)

[12:51] Andrew Linden: however I had an idea... I was wondering if we're already sending any data in the ViewerEffect messages that could be used to improve the minimap resolution. Probably not, but I haven't ruled it out yet.

[12:52] Kadah Coba: It would be nice if the viewer could say "I would like a better CoarseLocationUpdate please" and get some new formated one

[12:52] Jonathan Yap: Rex, there are many many coarseupdates packed together, so no way to extend an individual packet

[12:52] Simon Linden gets deja vu

[12:52] Kallista Destiny: all over again

[12:52] Rex Cronon: there is always at least one way to do anything, even though quite often is not obvious:)

[12:52] Kadah Coba: Even if that new formated one was just using a larger multipler

[12:52] Jonathan Yap: Does this issue effect anything more than the mini-map?

[12:53] LSL Scientist: yes, we already went trough this altitude discussion last week

[12:53] Andrew Linden: No, only the minimap and maybe a tracking beacon.

[12:53] Kadah Coba wasn't here.

[12:53] Jonathan Yap: Seems to be a popular subject at this meeting

[12:53] Jonathan Yap: Nearby list is calculated differently?

[12:53] Kadah Coba: Does nearby use it at all? I know it caused problems before

[12:54] Vincent Nacon: yeah there are problems with it

[12:54] Andrew Linden doesn't know about nearby info.

[12:54] Simon Linden: If we're going to beat this dead horse, there's one other change I'd like to make for that message: the region currently sends it every 1.33 seconds. I'm going to slow that down if the region fps drops to help lighten the load

[12:54] Vincent Nacon: fine with me

[12:54] Kadah Coba: Yes please

[12:54] Jonathan Yap: Is that one of the most frequently sent packets?

[12:55] Simon Linden: Perhaps slow it down too if the region get crowded, since that adds bandwidth too

[12:55] TankMaster Finesmith: thats fine

[12:55] Rex Cronon: every 1.33 senconds sends a list of avatar UUIDs and their pos?

[12:55] Simon Linden: Yep, that's about it, Rex

[12:55] Meeter: Timecheck : User Group is almost over

[12:55] Andrew Linden: No, nothing useful in the ViewerEffect pipeline. The server doesn't really pack those, although it does do some sanity checking these days.

[12:55] TankMaster Finesmith: if the server is lagging, its kinda expected the update info would suffer anyway

[12:55] Kadah Coba: Shouldnt it only send updates for avs that have moved?

[12:56] Rex Cronon: why not send it only if pos changes or nr avatars changes?

[12:56] Simon Linden: Then you have to figure out which viewer has what info, Kadah. It's easier to just send the same thing to everyone

[12:56] Andrew Linden: Uh oh Simon, now you might as well modify that 1.33 sec period and only send updates.

[12:57] Kadah Coba: I mean if one agent hasn't moved, does anyone need an update on them ever tick?

[12:57] TankMaster Finesmith: just send everything on entry via one process, then updates thereafter to everyone seperatly

[12:57] TankMaster Finesmith: ?

[12:57] Jonathan Yap: Tank, what about if the 1 packet is dropped/lost?

[12:57] TankMaster Finesmith: use HTTP?

[12:57] Simon Linden: Right, but if you just walked into view, I have to make sure you have the data on the AVs that haven't moved

[12:57] Rex Cronon: sending only pos for each ave doesn't take that much data

[12:58] Kadah Coba: Yeah, sounds like it would add too much extra logic for little affect, nvm x3

[12:58] Rex Cronon: especially since u don't have more than 100 avatars per sim

[12:58] Jonathan Yap: You can get updates from nearby regions, too

[12:58] Simon Linden: It's much, much easier in this case to just pack and send the same data to everyone - part of the reason why changing that x4 factor for just some viewers is a pain. Now we'd have two messages to build, one old and one new

[12:58] TankMaster Finesmith: im just thinking the server would send info on everytone, moved or not, when the client connects tot he region

[12:58] Siana Gearz: actually updating everyone is OK since it doesn't worsen the worst case.

[12:58] TankMaster Finesmith: then just send updates thereafter

[12:59] Siana Gearz: and everything you do to improve the average case isn't gonna help when the inevitable worst case happens.

[12:59] Simon Linden: It's a lot of complexity for little gain

[12:59] Andrew Linden: oh right, the overhead of custom packets

[12:59] Qie Niangao: well, it does use bandwidth.

[12:59] TankMaster Finesmith: perhaps

[12:59] TankMaster Finesmith: just seems like it would be less than sedning everything to everyone all the time

[13:00] TankMaster Finesmith: but w/o knowing how its done, I dont really know

[13:00] Siana Gearz: coarse locations are the least of the troubles.

[13:00] Meeter: Thank you for coming to the Server User Group

[13:00] Jonathan Yap: thank you everyone

[13:00] Rex Cronon: i think if u increase the update interval the rubberbanding might get worse

[13:01] Vincent Nacon: thanks for coming out

[13:01] Siana Gearz: Rex, it doesn't matter, because those are only agent coarse updates.

[13:01] Simon Linden: This is only the mini-map, Rex. It won't affect the world view

[13:01] TankMaster Finesmith: i dont mind the change of increasing the intervul of updates basedon server load

[13:01] Andrew Linden: I've got a meeting that starts now. Gotta go.

[13:01] Andrew Linden: Thanks for coming.

[13:01] TankMaster Finesmith: tc andrew

[13:01] Siana Gearz: bybye runners.

[13:01] TankMaster Finesmith: thx for coming

[13:01] Rex Cronon: tc andrew

[13:01] Vincent Nacon: later all

[13:01] TankMaster Finesmith: tc simon, and Oz

[13:01] Stickman: Thanks for the office hours!


Prev 2012.01.13 Next 2012.01.20