Simulator User Group/Transcripts/2013.02.12

From Second Life Wiki
Jump to: navigation, search


Prev 2013.02.05 Next 2013.02.19

List of Speakers

Andrew Linden Honza Noyes Ima Mechanique
Inara Pey Jonathan Yap Kallista Destiny
Kelly Linden Latif Khalifa Motor Loon
Petteri Yiyuan Qie Niangao Rex Cronon
Simon Linden Whirly Fizzle Yuzuru Jewell


[12:02] Kallista Destiny notices that Kelly is not all blinged up, and so refrains from putting her sun glasses.

[12:03] Andrew Linden: ok, so Simon will be lurking for this session, while he attends two meetings simultaneously

[12:03] Kallista Destiny hands Simon the TSO/360 manual

[12:03] Andrew Linden: unfortunately, I'm not up to speed on what is going on for this week's release

[12:03] Ima Mechanique: ohhh a multitasker. wish I could do that ;-)

[12:04] Qie Niangao: (No comments to so must be going / have gone well so far)

[12:04] Motor Loon: Must be a forum bug... that's never happened before

[12:04] Simon Linden: right - we did the main roll this morning, and I didn't hear any screaming, which is good

[12:05] Andrew Linden: Yeah, what is on LeTirgre was promoted to the main channel.

[12:06] Andrew Linden: This morning I was testing some more intrestlist work that I want to get out in a new RC

[12:06] Simon Linden: There's another maintenance server release going into RC tomorrow, and the other 2 channels are getting updated

[12:06] Jonathan Yap: The shutdown notification will not display properly again? woohoo

[12:06] Jonathan Yap: *now

[12:06] Whirly Fizzle: I have a question about Le Tigre . I was just wondering what "Instant messages are now truncated to 1024 bytes to prevent certain types of delivery failure " was to fix

[12:06] Andrew Linden: but improvements for scene load time are small to non-existent in that work (which was what I was testing)

[12:08] Andrew Linden: Whirly, I'm guessing that the recipient code would sometimes fail to deliver the message at all if the sender packed too much data

[12:08] Andrew Linden: so now we truncate it and send the first 1024 bytes

[12:08] Simon Linden: There was also a case where you would get repeated IMs sent via email ... one that was too long was in the DB

[12:09] Simon Linden: Every time you logged in, it would try to send to you -- and fail, since it was too big. That would then get routed to your email

[12:09] Whirly Fizzle: ahhh!

[12:09] Simon Linden: and thus never go away in a nice little loop

[12:09] Whirly Fizzle: OKay thanks

[12:09] Qie Niangao: This is avatar-initiated IMs only? Wiki for llInstantMessage thinks it gets 1175 bytes.

[12:10] Andrew Linden: Good question, Simon or Kelly do you know?

[12:10] Simon Linden: I'm not sure about that

[12:11] Andrew Linden: I would guess that this change has truncated llInstantMessage() events with > 1024 bytes

[12:12] Qie Niangao: Okay, I'll try to remember to test it on LeTigre after the roll tomorrow and maybe update the wiki. Hopefully not too many are stretching that limit.

[12:13] Andrew Linden: Hrm... looking at the code changes it appears that only IM messages that get stored in a db for later delivery are truncated.

[12:14] Simon Linden: I believe the main problem there was that the DB supported larger IMs than the delivery system did ... I think the truncation now takes place going into the DB (preventing new ones) and out of it (cleaning up the existing problem ones, stuck in a loop)

[12:14] Andrew Linden: oops, no I take that back

[12:14] Rex Cronon: i don't get it. isn't the max IM length 1024?

[12:14] Andrew Linden: I see some code added to the simulator that may actually truncate

[12:15] Kelly Linden: Yup.

[12:15] Andrew Linden: Rex, I think that some code that build IM's would cap at 1024, but not all

[12:15] Whirly Fizzle: Max IM length is actually a viewer setting I think? I know we have it set up on Firestorm that if you trpe too mich in one IM the viewer will spilt it into separate Im's of max length & send all at once

[12:16] Andrew Linden: for example, the viewer will build an IM message, but the simulator script code can also do it

[12:16] Andrew Linden: so now the code that receives and processes IM's will enforce the 1024 byte limit

[12:16] Kelly Linden: IMs are sent on the network as a single packet. Messages that are too long cause Bad Things(tm), so what andrew says.

[12:16] Kelly Linden: single UDP packet that is.

[12:17] Latif Khalifa: that's 1400-something bytes, don't know how much is taken by other fields in ImprovedInstantMessage

[12:17] Andrew Linden: right, but our UDP packet payload limit is actually 1200 bytes, so some code paths might pack > 1024

[12:18] Andrew Linden: ok well I guess the table is open, I don't have any more news

[12:18] Latif Khalifa: I'm having issues trying to copy a number of inventory items to object contents, it seems to start to fail if the number is in the 50 range. Is this a known issue?

[12:18] Petteri Yiyuan: any information of getting fix to traffic bug. Sims traffic has been showing totally wrong actually frozen to fame figure for more than a week or two at least in Firestorm what i use

[12:19] Petteri Yiyuan: same

[12:19] Kelly Linden: fail how?

[12:19] Latif Khalifa: i get an error, and some random number of items end up in the object content

[12:19] Andrew Linden: Latif, this is the first I've heard of that -- I thought it was possible to save hundreds of items at a time

[12:20] Latif Khalifa: sometimes only one or two are missing, sometimes half

[12:20] Kelly Linden: I haven't heard of that before either.

[12:20] Whirly Fizzle: Do you have HTTP Inventory disabled Latif? Or did you change the HTTP Inventory setting at all without a cache clear? I wonder if you are seeing something related to (When HTTP Inventory is disabled, mass selecting a bunch of inventory items and attempting to add to an objects contents will fail. )

[12:20] Petteri Yiyuan: i think i have actually met this same thing. That you can have only certain amount of objects in content (or then window just shows certain number but you you actually have those items in content)

[12:21] Latif Khalifa: it just happened here now " Inventory creation on in-world object failed."

[12:21] Latif Khalifa: that's the notification that pops up

[12:21] Whirly Fizzle: Oh! ful with trying to pack too mauch like that into a box >.<

[12:21] Andrew Linden: I also haven't heard about traffic calculation problems, but I'm not on the main maintenance com channels these days

[12:22] Andrew Linden: lemme ask around...

[12:22] Whirly Fizzle: Theres a SEC for that *cough*

[12:22] Simon Linden: Traffic is stuck, Andrew

[12:22] Jonathan Yap: Traffic calculations were recently fixed

[12:22] Jonathan Yap: they broke again?

[12:22] Petteri Yiyuan: yep

[12:22] Whirly Fizzle: If you start getting the " Inventory creation on in-world object failed." message its a danger sign lol

[12:22] Latif Khalifa: Whirly, too much?

[12:22] Kallista Destiny: for some value of fixed?

[12:22] Latif Khalifa: i get it with like 30-50 items

[12:22] Simon Linden: The problem is somewhere between the simulators (which are OK) and the magic number coming out of the traffic system

[12:23] Latif Khalifa: it never used to be a problem packing that small a number of < 100

[12:23] Whirly Fizzle: You will Latif

[12:23] Latif Khalifa: Whirly, since when is this happening?

[12:23] Whirly Fizzle: Bit don't keep trying lol

[12:23] Whirly Fizzle: *But

[12:23] Whirly Fizzle:

[12:23] Whirly Fizzle: & yes it still repros

[12:23] Latif Khalifa: heh so it's a known bug, perhaps even crasher

[12:24] Motor Loon: ouch

[12:24] Jonathan Yap: no one can see that

[12:24] Latif Khalifa: i was trying to repack some of my "servers" yesterday

[12:24] Latif Khalifa: it's major PITA when you cannot reliably put stuff in objects

[12:24] Whirly Fizzle: Yeah. Ive set that off a few times accudently :/

[12:25] Rex Cronon: too bad we don't have a lsl function that can take something from owner's invetory and put it in the inventory of the object that the script is in:(

[12:26] Kallista Destiny: Can you say nightmare?

[12:26] Kelly Linden: latif: appears to be an internal TCP error between sim and dataserver.

[12:26] Whirly Fizzle: [12:23] Latif Khalifa: Whirly, since when is this happening? <---- don't know but I accidentally triggered that in April last yr, so a while

[12:26] Rex Cronon: right. its a nightmare that we don't have such function:)

[12:26] Qie Niangao: Just for sanity, is the result just crashing the sim or something, or does it scramble inventory.

[12:26] Latif Khalifa: tehKellz, it's a major pain point for what I'm doing these days

[12:26] Whirly Fizzle: It doesn't mess your inventory at all

[12:27] Qie Niangao: okay.

[12:27] Qie Niangao: thanks.

[12:27] Latif Khalifa: it scrambles object inventory

[12:27] Latif Khalifa: not your main

[12:27] Kallista Destiny: llCopyFromInventory("Object");

[12:27] Qie Niangao: heh, yeah, I've seen the resulting mess in object inventory before, too.

[12:28] Rex Cronon: no kallista. u give an uuid:)

[12:28] Kallista Destiny: Hmmmm the it's one at a time, unless you make a list up, one at a time.

[12:29] Latif Khalifa: if we still had a functional JIRA I could've searched for this... follow status and stuff

[12:29] Ima Mechanique: Kallista, I think I would prefer llGiveInventoryCopy(ObjectID, AvatarID);

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

[12:30] Jonathan Yap: latif, can you see BUG jiras?

[12:30] Latif Khalifa: no

[12:30] Rex Cronon: not being able to search jiras is a PITA:(

[12:30] Latif Khalifa: Oz doesn't like me :P

[12:31] Jonathan Yap: Did you ask to be put on the list?

[12:31] Rex Cronon: ima. that function would be a good addition too:)

[12:31] Latif Khalifa: you don't want to give scripts the ability to give away your inventory :P

[12:32] Honza Noyes: Well, this partially is how the Merchant Outbox works on the Marketplace.

[12:32] Rex Cronon: i want scripts to be able to copy things from my inventory(as the owner) to the inventory of the object that the script is in.

[12:32] Ima Mechanique: I just don't want to have to pack boxes Latif ;-)

[12:33] Ima Mechanique: some function to reproduce the Marktplace outbox would be great

[12:33] Honza Noyes: Well, instead, the easiest way would be Marketplace API.

[12:34] Ima Mechanique: Honza, that would have security implecations. To have your own "mall" weould then require permission to give away other peoples goods. CAn't see the lab allowing that

[12:35] Rex Cronon: if there was an api to interract with our inventory things might get a lot easier for everybody:)

[12:35] Latif Khalifa: don't hold your breath ;)

[12:36] Petteri Yiyuan: As its quiet can i propose change request/feature development suggestion to server releases? Add and feature which allows estate manager of sim force minimap use off from estate. Roleplay sim owners would love that feature.

[12:36] Honza Noyes: Well, not if it gets done right. For example, you hit the link for sale something like and once Marketplace recieves that, viewer would pop a dialog to the user like "Looks like you wanted to purchase PRODUCT, click Yes to confirm"

[12:37] Andrew Linden daydreams about a virtual world with RESTful public API's for everything, and all stuff scriptable.

[12:37] Jonathan Yap: Petteri, there is no way the server could enforce that

[12:37] Honza Noyes: You have option to use RLV API.

[12:37] Petteri Yiyuan: one coder once said everthing is possible. Time is limit

[12:37] Rex Cronon: isn't the purpose of sl to have everything scriptable andrew?

[12:37] Andrew Linden: Yes, that is true.

[12:37] Whirly Fizzle: Yeah, make them use RLV & lock map access :D

[12:37] Jonathan Yap: The viewer has position data, you cannot stop that data from being used

[12:38] Ima Mechanique: Petteri that coder wasn't an employee of LL

[12:38] Andrew Linden: Petteri, forcing the minimap off... there is no way for the server to force the viewer to do that

[12:38] Latif Khalifa: Andrew, I have been asking for a simple thing, OpenID login for about 5 years now. Facebook, Twitter, and your mother let you login to 3rd party sites with their credentials, but not Second Life. And no development is required, just a config change

[12:38] Andrew Linden: it could suggest it, but one could always make a 3rd party version that ignored the suggestions

[12:38] Rex Cronon: the server could be sending fake pos data:)

[12:38] Honza Noyes: If I remember correctly the "gaming" features released was just Part 1 of those, is there any Part 2 coming soon?

[12:38] Qie Niangao: like Experience Permissions.

[12:39] Honza Noyes: That was Part 1.

[12:39] Qie Niangao: except we don't have them, so it must be Part 2

[12:39] Latif Khalifa: Andrew, you could just stop sending CoarseLocationUpdate messages, and mimimap is dead ;)

[12:39] Latif Khalifa: not that it would be useful :P

[12:40] Andrew Linden: oh right, I forgot about the CoarseLocationUpdate messages

[12:40] Honza Noyes: Experience Permissions, that was llTeleportAgent and so on.

[12:40] Andrew Linden: you're right... but doesn't the viewer still populate the minimap using avatars in view info?

[12:40] Qie Niangao: well, *lack* of XP is why llTeleportAgent is useless.

[12:40] Jonathan Yap: Yes Andrew, I worked a bit on that code a while ago

[12:41] Latif Khalifa: Andrew, nope, minimap is from CoarseLocationUpdate alone

[12:41] Jonathan Yap: That is how you see correct nearby agent data for height > 1020

[12:41] Latif Khalifa: viewer side "radars" use CoarseLocationUpdate and what's on their normal draw distance

[12:41] Andrew Linden: Petteri, are you more interested in getting the avatar dots off of the minimap? or the terrain and object data?

[12:41] Latif Khalifa: Jonathan, but that's just for avatars that you can see

[12:42] Latif Khalifa: i.e. are close enough

[12:42] Jonathan Yap: yes, which is I wrote "nearby" :)

[12:42] Petteri Yiyuan: avatar dots off the map. In many roleplay or combat sims sim owners would like to have this feature to turn "radar" off from people

[12:42] Simon Linden: That's an interesting feature ... I can see why you'd want it

[12:42] Rex Cronon: as latif said allow sim owners to turn off CoarseLocationUpdate:)

[12:42] Latif Khalifa: LSL "radars" would still work on huds, etc.

[12:42] Motor Loon: You'd probably be better of just asking people to turn off their minimaps

[12:43] Honza Noyes: You can't detect that.

[12:43] Petteri Yiyuan: i know this can be done in RLV API but many people have reservatons againts RLV viewer

[12:43] Simon Linden: well, if that info gives you some advantage, people would abuse it

[12:43] Honza Noyes: Completely agree with Petteri.

[12:43] Jonathan Yap: RLV assumes people will use that type of viewer, if they are going to cheat the still can by using another viewer

[12:43] Andrew Linden: Hrm... well as Latif pointed out, it is technically possible to eliminate the CoarseLocationUpdate messages at the server, which supplies minimap avatar dots for avatars that you can't yet actually see.

[12:43] Rex Cronon: lsl radars have limitiation. and scripts can be turned off

[12:43] Latif Khalifa: RLV is in almost every viewer by now ;) notable exception being linden stock, but who uses that :P

[12:44] Petteri Yiyuan: i belive this capablity to enforce minimap avatar location info has been on wishlist of many gaming and roleplay sim owners for long time and has been spoken topic

[12:44] Honza Noyes: Yet, you can script a simple 2D minimap using llGetAgentList

[12:44] Qie Niangao: right, llGetAgentList would pretty completely replace the minimap

[12:44] Honza Noyes: Or with use of some JS, Web on Prim and http-in

[12:44] Rex Cronon: if scripts work

[12:45] Jonathan Yap: A better solution would be to have client side scripting, then your lsl script could query the viewer and ask if the map is off or not

[12:45] Motor Loon: lol... if scripts are off, their combat weapons would be pretty useless too

[12:45] Honza Noyes: That's what RLV does.

[12:45] Honza Noyes: And you can still cheat scripts off with the llRequestPermissions and llTakeControls.

[12:46] Latif Khalifa: yeah RLV solves this nicely

[12:46] Rex Cronon: u can see how many scripts somebody is running:)

[12:46] Honza Noyes: Well, like Petteri said, people dislike RLV because of it's "nasty" usage in most cases.

[12:46] Petteri Yiyuan: but does llGetAgentList also produce agent xyz location or just distance?

[12:47] Honza Noyes: llGetAgentList produces list of avatars in sim/parcel.

[12:47] Latif Khalifa: that's their problem for disliking useful functionality

[12:47] Qie Niangao: just identity. then llGetObjectDetails

[12:47] Honza Noyes: Yes.

[12:47] Honza Noyes: And another problem is the lack of RLV in official viewer, so people would need to switch over to Exodus and other viewers which support RLV.

[12:48] Rex Cronon: there r ways to make lsl scanners/radars useless:)

[12:48] Honza Noyes: Speaking of features out of RLV, what about llForceSit or llRotateAvatar/llAvatarLookAt?

[12:48] Jonathan Yap: Do people hover the mouse over the mini map dots to see who is where, is that the problem?

[12:49] Jonathan Yap: A kind of a hack solution would be to send fake/more dots to blend with the "real" ones

[12:49] Rex Cronon: the problem is that in a game u don't want users to see where others are on the map

[12:49] Andrew Linden: Jonathan, I think it is hard to make a sneak attack when your opponents are watching the minimap.

[12:49] Honza Noyes: The problem would be that they highlight friendlies on minimap (different colors) and then just shoot the dots in most cases.

[12:49] Latif Khalifa: what is asked for is basically "fog of war" type functionality

[12:49] Simon Linden: we could send random names and positions :P

[12:49] Latif Khalifa: lol

[12:49] Whirly Fizzle: hehe

[12:50] Petteri Yiyuan: yes Latif, excactly Fog of war type function

[12:50] Kallista Destiny: Preferably configurable by an EM, dynamically.

[12:51] Honza Noyes: Well, another thing could be forced daylight settings.

[12:52] Petteri Yiyuan: i use forced windlight settings as a workaround now for daylight settings in my sims Windlight Sky: "Foggy"*/

[12:52] Rex Cronon: no way. i don't want to suddenly be blinded

[12:52] Qie Niangao: I think the easiest solution is the best: just rename RLV to RPLV and declare victory.

[12:52] Whirly Fizzle: How would forced daylight help? Just curious

[12:52] Kallista Destiny: Some people force Noon even at 'night'.

[12:52] Jonathan Yap: forced <pick a time> is the better request; I can see why you might want it to be night for everyone (harder to see)

[12:53] Whirly Fizzle: But I can just use wireframe mode :D

[12:53] Kallista Destiny: The Idea is to make the fight even and realistic.

[12:53] Petteri Yiyuan: whirly: "Its a dark and cold night and its raining hard". Hell no i have clear and sunny sky

[12:53] Kallista Destiny: Not real useful

[12:53] Honza Noyes: RLV can disable wireframe :P

[12:53] Whirly Fizzle: True :D

[12:53] Rex Cronon: u can enforce light values

[12:54] Kallista Destiny: Relame RLVa to RPLVa

[12:54] Honza Noyes: Well, all of this could be anyways overriden by custom client.

[12:54] Kallista Destiny: Good Idea

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

[12:55] Andrew Linden: so basically, in order to make compelling games in a virtual world you need to be able to control the viewer

[12:55] Honza Noyes: Yes.

[12:55] Whirly Fizzle: Yeah

[12:55] Andrew Linden: er... most compelling games

[12:55] Rex Cronon: no. u need to control the data the viewer is getting:)

[12:55] Petteri Yiyuan: yes or some settings of viewer how people see or feel estate

[12:56] Andrew Linden: well Rex, "dark and stormy night" data could be ignored

[12:56] Honza Noyes: Well, control the viewer the way that it cannot be abused for griefing but used for so called gaming projects.

[12:56] Petteri Yiyuan: well we dont feel it yet. Maybe after Oculus Rift when you guys introduce support for it... ^^

[12:57] Rex Cronon: right adrew. u can even make the scene lighter by changing your monitor values:)

[12:57] Rex Cronon: andrew*

[12:57] Honza Noyes: What about llRotateAvatar, would that be possible?

[12:58] Honza Noyes: Since we can move the agent using llMoveToTarget, control camera and controls, this is missing quite a lot.

[12:58] Andrew Linden: Honza, it would be pretty hard...

[12:58] Andrew Linden: at the moment the avatar tries really hard to turn in the direction of your camera

[12:58] Andrew Linden: so we'd have to decouple that behavior... sometimes

[12:59] Honza Noyes: This way you need avatars to sit an object (not that bad solution), but you need to force sit it sometimes and we are back at RLV, haha.

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

[13:00] Qie Niangao: although... llTeleportAgent does have a functional "look_at" parameter, unlike llMapDestination (which has one, but it doesn't do anything)

[13:00] Andrew Linden: Thinking it through... yeah a lot of work to sometimes control the avatar server-side, and sometimes follow the viewer's lead

[13:01] Andrew Linden: I doubt it could be done without breaking a lot of content just trying to update that code.

[13:01] Honza Noyes: I see.

[13:02] Honza Noyes: Back when meshes were introduced, we were hoping to get a feature to animate meshes (without being attached) by standard animations in SL, are there any plans for it?

[13:02] Andrew Linden: Actually, right now the viewer specifies the camera view in the world frame

[13:02] Andrew Linden: but if it were to specify the camera view in the avatar's local frame...

[13:03] Whirly Fizzle: This is the lookat crosshairs?

[13:03] Andrew Linden: then we could rotate the avatar server-side, and the viewer would have to supply a sort of reactive correction in order to maintain a steady world frame transform

[13:04] Andrew Linden: I wonder how frustrating that would be for normal operations, especially when your avatar was knocked willy nilly by some collision

[13:05] Andrew Linden: When your avatar is standing here...

[13:05] Andrew Linden: your viewer is supplying a "forward" axis in update packets to the server

[13:06] Andrew Linden: and the avatar on the server basically slaves its rotation to what the avatar is supplying

[13:06] Andrew Linden: if any external object tries to rotate the viewer, the slaving behavior will overwhelm the outside force

[13:06] Honza Noyes: Just like llLookAt requires the prim to be non-physical, right?

[13:07] Andrew Linden: I thought llLookAt worked on dynamic (physical) objects

[13:07] Qie Niangao: it does

[13:07] Qie Niangao: and if you're sitting on such an object, you get rotated.

[13:08] Andrew Linden: its just that the llLookAt() behavior is so strong, it will tend to snap the dynamic object to the desired position very quickly

[13:08] Honza Noyes: Ah, yes.

[13:08] Andrew Linden: right, in that case the avatar's rotation is locked to the seat

[13:08] Ima Mechanique: gotta run, bye all

[13:08] Andrew Linden: and the viewer is slaving the camera to the avatar's position as specified by the server

[13:09] Rex Cronon: tc ima

[13:09] Andrew Linden: Yeah, time for me to go too.

[13:09] Andrew Linden: See you all later.

[13:09] Honza Noyes: Actually, I just noticed that RLV supports such a feature:

[13:09] Rex Cronon: tc andrew

[13:09] Petteri Yiyuan: Thank you for all

[13:09] Qie Niangao: Thanks Andrew

[13:09] Yuzuru Jewell: Thank you, Andrew.

[13:09] Honza Noyes: Thanks a lot.

[13:09] Whirly Fizzle: Thanks :)

[13:09] Rex Cronon: tc all those leaving

[13:10] Latif Khalifa: take care

[13:10] Qie Niangao: and thanks Simon, in multi-meeting mode. :)

[13:10] Inara Pey: Thanks, Andrew & Simon


Prev 2013.02.05 Next 2013.02.19