Simulator User Group/Transcripts/2012.07.10
| Prev 2012.07.06 | Next 2012.07.13 |
List of Speakers
| Acheron Gloom | Andrew Linden | ANSI Soderstrom |
| Baker Linden | DesolateStudios | Draconis Neurocam |
| Jonathan Yap | Kelly Linden | Kennylex Luckless |
| Melvin Starbrook | Motor Loon | Nalates Urriah |
| Rex Cronon | Sahkolihaa Contepomi | Simon Linden |
| Squirrel Wood | Yuzuru Jewell |
Transcript
[11:59] Yuzuru Jewell: Hello
[11:59] Sahkolihaa Contepomi: Oh, and Andrew.
[11:59] Sahkolihaa Contepomi: Who's still holding a crayon launcher... oh dear god.
[11:59] Simon Linden: Hello everyone
[12:00] ANSI Soderstrom: hi all
[12:00] Andrew Linden: Yeah, for some reaon I really love the crayon launcher.
[12:00] Meeter: Welcome to the Server User Group
[12:01] ANSI Soderstrom: hi kenny
[12:01] Kennylex Luckless: Ahhhh, looks like a Linden shall shout me.
[12:01] Rex Cronon: hello everybody
[12:02] Andrew Linden: Ok I'll get started with some news...
[12:02] Andrew Linden: I'm starting to look into the server-side interest list with some other devs
[12:03] Andrew Linden: the plan being to figure out how it works or does not, and come up with a way to fix it, or rewrite it
[12:03] Andrew Linden: the whole thing will probably take a couple months, but really needs to be done
[12:03] Motor Loon: sounds good
[12:03] Andrew Linden: Pathfinding may actually go into official RC this week, so that project is winding down
[12:04] Motor Loon: "may" ?
[12:04] Andrew Linden: I'll probably switch over to fixing bugs in that part time over the next few weeks
[12:04] Andrew Linden: yeah, I say "may" because it is possible that something might block it last minute or it might get rolled back after RC attempt
[12:05] Andrew Linden: it has happened before on this and other projects
[12:05] Motor Loon: ah true...
[12:05] Andrew Linden: Someone came to this user group last Tues with a report of corrupted inventory
[12:05] Andrew Linden: and I said I would try to look into it
[12:06] Andrew Linden: I did a bit of work on that and found only minor inventory problems, a few folders that don't have a home
[12:06] Andrew Linden: so what I suspect is really happening is that their inventory is just too big, and they are using a 1.23 version viewer to try to see it
[12:06] Melvin Starbrook: only minor problem for this avatar or overall?
[12:06] Andrew Linden: which has problems actually getting all of your inventory to you
[12:06] DesolateStudios: Not related to the garbage cleanup efforts?
[12:07] Andrew Linden: so really big inventories just never show up complete
[12:07] Andrew Linden: definitely not related to asset garbage collection work DesolateStudios
[12:07] Rex Cronon: what size is considered big?
[12:07] Melvin Starbrook: mm is there a maximum inventory for 1.x users?
[12:08] Andrew Linden: Melvin, I'm not really sure where the old 1.23 inventory starts to break
[12:08] Andrew Linden: but this case had 25k+ folders
[12:08] DesolateStudios: Hah!
[12:08] Melvin Starbrook: folders
[12:08] Melvin Starbrook: ok
[12:08] Motor Loon: omg
[12:08] Andrew Linden: yeah, thats just the folders
[12:08] Andrew Linden: so my general advice would be...
[12:08] Motor Loon: clean up ya crap?
[12:09] Andrew Linden: for best results clean up your inventory
[12:09] DesolateStudios: I don't know much about the viewer end of things, but is HTTP inventory compressed at all in the transfer?
[12:09] Melvin Starbrook: keep less then 25k folders ::)
[12:09] Andrew Linden: especially if you really want to use viewer-1.23 codebase
[12:09] Andrew Linden: That's all the news I've got. Simon?
[12:09] Simon Linden: None from me
[12:09] Melvin Starbrook: thank you for sorting out andrew :)
[12:10] Melvin Starbrook: (and i start cleaning my inventory (again)) :)))
[12:10] Andrew Linden: (I'll ping the inventory owner directly, but just thought I'd share some of the results)
[12:10] Rex Cronon: i don't remember v1.23 ever telling me that i souldn't have over x amount of items. nor is that info on the sl site, or is it hidding too well?
[12:10] Andrew Linden: btw, empty your inventor trash too
[12:10] Motor Loon: just curious... how many inventory objects did the person have?
[12:11] Melvin Starbrook: mm my trash....
[12:11] Melvin Starbrook: lol
[12:11] Andrew Linden: I think these days it is eventually cleared out, but most people have plenty of stuff in the inventory trash folder
[12:11] Andrew Linden: Loon, I didn't actually query that number yet.
[12:11] Simon Linden: I doubt it's a hard limit, Rex, and probably gets affected by the system speed, network and other factors
[12:11] Andrew Linden: However, there were no lost inventory items.
[12:12] Andrew Linden: Er... that is, there were no items that did not have a proper folder.
[12:12] Draconis Neurocam: Who wrote the original interest list?
[12:12] Andrew Linden: ... no items that didn't have an *existing* folder.
[12:12] Andrew Linden: Draconis, the original interestlist was, I think, Philip, Cory, and maybe Frank.
[12:12] Motor Loon rolls up a newspaper
[12:13] Andrew Linden: Then Doug did an overhaul in 2002 I think.
[12:13] Motor Loon: wow thats old
[12:13] Andrew Linden: yup
[12:13] Draconis Neurocam: so the current one has been the same since 2002?
[12:13] Simon Linden: No, it's evolved
[12:13] Andrew Linden: for the most part it hasn't changed
[12:13] Andrew Linden: some bug fixes have been done over the years, and minor changes
[12:14] Jonathan Yap: It would be nice to have close objects sent first, and also an option for text-only viewers to not have unnecessary data sent
[12:14] Motor Loon: is it a public list?
[12:15] Baker Linden: I'm still working on improving the group management system. I've reduced the length of time the query takes significantly, and I'm working on new solutions to ensure the data is transmitted reliably and as compact as possible. That's all the news I have.
[12:15] Draconis Neurocam: that is still awesome news baker
[12:15] Rex Cronon: if i am not mistaken an interest list, is a list of all objects visible to u?
[12:15] Andrew Linden: we'll definitely consider how to send close objects first, but very advanced subscription models will only be possible if we decide on a major overhaul.
[12:15] Andrew Linden: yeah, "interestlist" is just the name we give the server-side "visibility and culling" code that decides what updates to send to the viewer
[12:16] Motor Loon: aah
[12:16] Andrew Linden: Oh, that's right, Baker and I have a question for you all...
[12:16] Baker Linden: I've managed to get groups of 20k people down to about a 2-3 minute query if you're in the group, and about 30 seconds if you're not. I'm working on ways to reduce that further
[12:16] Andrew Linden: When managing groups, one of the fields that is sent to group members (or officers?) is the last_login date of other memebers
[12:16] Andrew Linden: is that field useful?
[12:16] Andrew Linden: could the veiwer do without it?
[12:17] Motor Loon: yes
[12:17] Andrew Linden: How is it uses?
[12:17] Motor Loon: I use that alot
[12:17] Andrew Linden: used?
[12:17] Jonathan Yap: yes, it is used to cull out old members, or to see who is recently active in case you are trying to get in touch with them
[12:17] Motor Loon: to see when people have last been around... and to clean up our big groups for people that has not been in for a long time
[12:17] Baker Linden: Would it be ok to perhaps not have that loaded right away, and perhaps get batched, or update more slowly "in the background" (I use that term quite loosely) instead?
[12:17] Andrew Linden: Oh ok. That is what Baker surmised.
[12:18] Motor Loon: yeah speed to polling those online times is not a major factor
[12:18] Jonathan Yap: yes, later arrival of that data would work
[12:18] Motor Loon: must more important that list of groupmembers load - and groupchat can start without 20 failed tries
[12:18] Andrew Linden: As it turns out, collecting the last_login data makes queries against very big groups more expensive than we'd like.
[12:18] Baker Linden: I haven't completely confirmed it, but it seems like querying every member's last login is what is taking a long time
[12:18] Jonathan Yap: if that puts a load on the backend you could even have a button in the group panel to "Fetch last login time"
[12:19] Motor Loon: perhaps a button you can click if you want it loaded?
[12:19] Jonathan Yap: that data is not used all that often
[12:19] Baker Linden: I had the idea for a button to explicitly load it
[12:19] Motor Loon: yeah
[12:19] Baker Linden: also, would it be useful for non-managers?
[12:19] Motor Loon: that'd be a good solution
[12:19] Rex Cronon: u get the last login in group chat, or the last login in world?
[12:19] Jonathan Yap: yes, I have used that data as a non-manager
[12:19] Motor Loon: non managers would have no need that I can see for lastonline data
[12:19] Baker Linden: ok
[12:20] Andrew Linden: Is the group member data sortable by last_login in the viewer UI?
[12:20] Draconis Neurocam: yeah
[12:20] Jonathan Yap: Instead of a button that option could go into the gear menu. The group panel is already too "busy"
[12:20] Motor Loon: yes
[12:20] Andrew Linden: and I"m guessing that when looking for old members you often sort on that column
[12:20] Draconis Neurocam: yes
[12:20] Jonathan Yap: I have sorted on that column often
[12:20] Andrew Linden: which means we'd have to get all of the last_login data at once ideally
[12:21] Draconis Neurocam: yes
[12:21] Andrew Linden: ok well good to know
[12:21] Baker Linden: I was either going to have a button in the viewer, or have it so when the rest of the data is sent, it will automatically batch up member IDs and start right away (well, as long as the group window is open). Do it at maybe 500 at a time
[12:21] Andrew Linden: that will help us work on a solution that still meets needs of group managers
[12:22] Baker Linden: doing it the second way would mean that sorting by last login won't be much use until everything is loaded (which might take a few minutes)
[12:22] Motor Loon: its like that now too anyway
[12:22] Motor Loon: often have to wait a while before all group members have loaded before doing anything in regards of sorting
[12:22] Jonathan Yap: If someone needs the date field they will learn to wait for it. Having the group load faster would be a big improvement
[12:23] Motor Loon: agree
[12:23] Baker Linden: also, groups in excess of 12k people will actually load (hopefully)
[12:23] Baker Linden: I've managed to reduce the data size of the XML from my curl command from 11MB to 5MB already, and that's for a group of 40k people. I haven't checked how much smaller it will be without last_login data yet (though I suspect it'll be a couple megs less)
[12:24] Baker Linden: compressed, it's probably about 1MB of data that will need to be sent through HTTP (I'm moving it off UDP)
[12:24] Jonathan Yap: hmmmz, is that data data being sent as text rather than a binary value?
[12:24] Jonathan Yap: *data data
[12:24] Jonathan Yap: **date data haha cannot type
[12:24] Baker Linden: Honestly, I have no idea
[12:24] Baker Linden: andrew will know most likely
[12:24] Baker Linden: I think it's binary, so the size is actually smaller
[12:25] Andrew Linden: yes it is text XML, but once gzipped it doesn't matter much
[12:25] Jonathan Yap: will this new downloading system be compatible with older viewers?
[12:26] Baker Linden: we are going to keep the legacy system in there as well
[12:26] Baker Linden: so no
[12:26] Andrew Linden: unfortunately we don't have great support for the "notation" format of LLSD in someo of our non-C++ libraries, so I wouldn't want to try to move the data format to that
[12:26] Andrew Linden: since I think we'll eventually want to move this group management data service over to some other codebase/server-stack
[12:27] Baker Linden: but newer viewers can implement the necessary functionality. I'll be making the SL viewer compatible with this though. I can also update the SL dev wiki with info on how to parse the file and such.
[12:29] Andrew Linden: Simon, any news about a server release today?
[12:30] Simon Linden: I haven't been paying close attention, but since I didn't hear any screaming and shouting, I think it went OK this morning
[12:30] Andrew Linden: Oh right, I forgot that Simon did a pass on the interestlist a couple years ago. Adding some debug code, fixing some bugs, and tweaking some parameters.
[12:30] Simon Linden: The forum post is here: http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2012-07-09/td-p/1595111
[12:30] Andrew Linden: Ok, I guess the table is open.
[12:30] Meeter: Timecheck : User Group is half over
[12:30] Motor Loon: mostly the intersting part comes tomorrow
[12:30] Nalates Urriah: Well logins are a royal pain right now... I just spent 30+ minutes logging in
[12:31] Andrew Linden: hrm... login problems.
[12:32] Andrew Linden looks for chatter about that problem...
[12:32] Motor Loon: http://status.secondlifegrid.net/2012/07/10/post1695/
[12:32] Simon Linden: yeah, there appears to be something going on
[12:32] Motor Loon: yep
[12:32] Motor Loon: "unscheduled maintenance"
[12:33] Simon Linden should probably stockpile supplies here, in case we get marooned
[12:33] Rex Cronon: motor. u took the words out of my mouth:)
[12:33] Motor Loon: sorry, didnt know you were eating those
[12:33] Rex Cronon: lol
[12:33] Andrew Linden: ah I see, yup some network fixing is going on
[12:34] Nalates Urriah: Are the login servers separate from the SIM servers?
[12:34] Simon Linden: Yes Nal
[12:34] Andrew Linden: Yup, there is a stack of login servers behind a load balancer.
[12:34] Squirrel Wood: Mmmm. Popcorn!
[12:35] Nalates Urriah: I very rarely have any login issues.
[12:35] ANSI Soderstrom: i never has login probs but a ping > 200ms from europe
[12:36] Rex Cronon: could it be related to that problem about malware that resets your dns?
[12:36] Melvin Starbrook: draw,1
[12:36] Andrew Linden: Someone was asking me today... "What percentage of avatars in SL would be considered "heavy" with attachments and scripts?"
[12:36] Andrew Linden: I guessed about half.
[12:36] Acheron Gloom: Conservative guess I'd say ;p
[12:36] Nalates Urriah: No... if DNS Changer was it you would down across the net.
[12:37] Andrew Linden: No Rex the DNS malware is a problem for infected windows computers, right?
[12:37] Rex Cronon: if u go to a combat sim, than everybody there is "heavy":)
[12:38] Simon Linden: I'd guess about half the AVs have above average weight :P
[12:38] Nalates Urriah: I was askng Nyx about whether that could be an LSL function that would let residents check Render Cost as we do script weight. The reason was mesh clothes are way more complex than needed.
[12:38] Melvin Starbrook: lol simon
[12:38] Object: Hello, Avatar!
[12:38] ANSI Soderstrom: Hello Object with the UUID of 8dbf3bce-a5b9-bdc0-c364-bb98b3c22955
[12:38] Squirrel Wood: there is an option that shows render cost ?
[12:38] Rex Cronon: i think it affects macs too. but i realize u wouldn't be able to connect at all
[12:38] Squirrel Wood: At least there used to be...
[12:38] Jonathan Yap: There already is an option to show render cost
[12:38] Acheron Gloom: llGetObjectDetails has some stuff like that. I'm honestly not sure what it does if you do it to an agent key.
[12:39] Jonathan Yap: I fixed it a while ago so the point at which it goes red made sense
[12:39] Nalates Urriah: There is an item in the Dveloper menu.
[12:39] Motor Loon: wow mesh clothes are "expensive" on rendercost
[12:39] Motor Loon: Im 92K
[12:39] Acheron Gloom: It depends on how the mesh clothes are made... My jacket at the moment is only ~4 or 5k if iirc
[12:39] Acheron Gloom: 'only'
[12:40] Motor Loon: 21K total on you Ach
[12:40] Acheron Gloom: The jacket itself I meant ;p
[12:40] Rex Cronon: u can also have the body/skelleton made of mesh
[12:40] Motor Loon: Inusaito is 225K
[12:40] DesolateStudios: I've got multiple mesh clothes, and I'm only at 7k
[12:41] ANSI Soderstrom: i guess andrew has the lowest avatar-costs....
[12:41] Motor Loon: yeah... will vary with polycount, lod and textures etc
[12:41] Rex Cronon: how heavy am i?
[12:41] Motor Loon: 56k Rex
[12:41] Rex Cronon: i am made only of prims and sculpties
[12:41] Melvin Starbrook doesnt want to know lol
[12:41] Nalates Urriah: Advanced->Perfromance Tools->Show render cost
[12:41] Rex Cronon: thanks
[12:42] Kennylex Luckless: Render Cost is a scary thing to look at.
[12:42] Rex Cronon: how can mesh give u only 7k?
[12:42] Acheron Gloom: Mesh if made well isn't usually an issue.
[12:42] Motor Loon: low poly + few textures rex
[12:42] Acheron Gloom: Its just a matter of how its made.
[12:42] DesolateStudios: Well made mesh. :)
[12:42] Simon Linden: That's changed to "Show Draw Weight for Avatars" in the latest SL beta viewer, fwiw
[12:42] Rex Cronon: considering that each emsh is custom made and needs custom textures
[12:42] Rex Cronon: each mesh*
[12:43] Acheron Gloom: Going to brave a relog... be back in a moment.
[12:43] Andrew Linden: When it comes to lots of scripts on attachments... the main culprit is still prim-hair with per-prim resize scripts, right? Are their other reasons/categories where avatars tend to be very script heavy?
[12:43] Rex Cronon: combat huds r quite heavy
[12:43] Nalates Urriah: Jewlry
[12:43] Melvin Starbrook: fins lol
[12:43] Nalates Urriah: Combat every thing
[12:43] Draconis Neurocam: combat huds, jewelry, shoes
[12:43] DesolateStudios: Depends on the HUD too. Everything really depends on the creator of the items.
[12:43] Motor Loon: feet
[12:43] Acheron Gloom: Things that need to get around delays tend to be high on scripts.
[12:44] Acheron Gloom: Just by nature.
[12:44] Simon Linden: I have a nice but heavy HUD that's mostly UI scripts to make HUD buttons
[12:44] Rex Cronon: AO
[12:44] Squirrel Wood: Andrew, its jewellry too
[12:44] Acheron Gloom: I think if the scripter knows what they're doing, its simply delays that get in the way
[12:44] Acheron Gloom: I have a full AO with a script time of 4 microsecond.
[12:44] Andrew Linden: What script features does jewelry use?
[12:44] Rex Cronon: lets not forget shields. those can use lots of resources especially when u r being shot at
[12:44] Motor Loon: shouldnt use any
[12:44] Melvin Starbrook: a script in every prim....
[12:45] Squirrel Wood: bling, resize, recolor mostly
[12:45] Draconis Neurocam: theres no reason aside from sounds, animations (and even that is sketchy), and to want to use multiple events to use more than one script
[12:45] Acheron Gloom: I've seen servers that use llTeleportAgentHome slaves because of the 5 second delay. I've also seen slaves for llGiveInventory and llGiveInventoryList in vendors and other item-giving creations.
[12:45] Acheron Gloom: Also guns need slaves for llRezObject
[12:45] Andrew Linden: The per-prim script pattern is used for resizing objects, I know. Is that the only way to do recolor as well?
[12:45] Acheron Gloom: llRezObject has a delay of ~0.11 to 0.1333 in LSL
[12:46] Acheron Gloom: No
[12:46] Acheron Gloom: llSetLinkColor
[12:46] Acheron Gloom: or llSetLinkPrimitiveParams(Fast)
[12:46] DesolateStudios: A region to avatar on another region llGiveInventoryList would be nice.
[12:46] Draconis Neurocam: no recoloring and scaling are both possible now without using more than one script
[12:46] Squirrel Wood: Its mostly old, cobbled together scripts methinks
[12:47] Andrew Linden: ok so what are the resons for per-prim scripts besides scaling the entire object and laziness?
[12:47] Draconis Neurocam: sounds, and animations
[12:47] Rex Cronon: well. if u want to recolor each prim differently at the same time u need one script per prim
[12:47] Acheron Gloom: Laziness.
[12:47] Squirrel Wood: the major complaint why several scripts are used: It would not be instantaneous otherwise
[12:47] Acheron Gloom: Or lack of awareness/knowledge.
[12:47] Draconis Neurocam: no prim_link_target
[12:47] Motor Loon: loots of lazyness
[12:47] Draconis Neurocam: rex
[12:47] Andrew Linden: ah I see, faster operation, or near-atomic operation
[12:47] Squirrel Wood: at least that is what an avatar creator told me when I asked
[12:47] Jonathan Yap: I have seen per-prim scripts for particle emitters, so each prim sends out different particles
[12:48] Draconis Neurocam: there is setlinkparticlesystem now though
[12:48] Acheron Gloom: Andrew we have a constant caleld PRIM_LINK_TARGET if you want faster/near-atomic operation. I still am going to say lack of awareness is the issue :p
[12:48] Motor Loon: yeah
[12:48] Motor Loon: we pretty much only need ability to play attached sounds for other linkset prims now
[12:48] Motor Loon: almost everything else can be done centrally
[12:49] Squirrel Wood: just cause it can be done does not mean it will be though :(
[12:49] Motor Loon: true
[12:49] Squirrel Wood: I have a script that works. y should I write a new one?
[12:49] Draconis Neurocam: i still think multiple animation permissions that are asymetric would be nice for scripts
[12:49] Squirrel Wood: Its easier and faster to just use what I have,
[12:49] Motor Loon: thats up to the creator... or his/hers customers
[12:50] Andrew Linden: right. scaling an entire linkset can still require multiple calls to llSetLinkPrimitiveParams() and it may fail partway through, right?
[12:50] Squirrel Wood: yarr
[12:50] Motor Loon: I made a boat that handles 32 passengers with 1 script Drac
[12:50] Rex Cronon: if u do it right it doesn;t fail
[12:50] Draconis Neurocam: andrew not if people use PRIM_LINK_TARGET, yes motor but are they all playing different animations that can change on the fly
[12:50] Motor Loon: yes
[12:51] Andrew Linden: ok thanks
[12:51] Motor Loon: all have their own animation and can change them at any time
[12:51] Motor Loon: can be done - just takes a little extra scripting
[12:51] Draconis Neurocam: well then good job, and i would like to see that script, but business secrets and all, i understand
[12:52] Motor Loon: yep
[12:52] Squirrel Wood: sit on the ring :p
[12:52] Draconis Neurocam: motor what if two people change at the same time, i am guessing you have an update queue
[12:53] Motor Loon: but basically you just re-request perms whenever you need to start a new animation for the person - instead of having a script that "keep" them all the time
[12:53] Motor Loon: works fine
[12:54] Acheron Gloom: The only things I see that can't be done any better are things that require slaves to avoid delays. This includes llRezObject (guns usually require 2-4 slaves that all pop up link_message events every shot, if done in that manner), llTeleportAgentHome (servers that need it for game systems and the like), llGiveInventory (vendors and update servers often have extra scripts just for this. I think hippoupdate has ~9?).. Also sounds in linked prims can be an issue since there is no llPlaySoundLinked or llTriggerSoundLinked to my knowledge
[12:54] Acheron Gloom: There are probably other things I am forgetting
[12:54] Acheron Gloom: but those are the only issues I ever have with speed or efficiency as of late
[12:54] Draconis Neurocam: sounds really then are the only things that would require more than one script
[12:54] Motor Loon: yeah... might aswell remove those delays when people use extra scripts to get around them anyway
[12:54] DesolateStudios: The delay for llRezObject should be removed, because there's that grey goo fence
[12:55] DesolateStudios: And people will get around it
[12:55] DesolateStudios: The delay, not the fence
[12:55] Acheron Gloom: https://jira.secondlife.com/browse/SCR-154?focusedCommentId=294292&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-294292
[12:55] JIRA-helper: [#SCR-154] llRezObjectFast() and llRezAtRootFast(), rezzing functions with zero delay
[12:55] Motor Loon: nods
[12:55] Acheron Gloom: see above
[12:55] Draconis Neurocam: yeah you would think they would want serverside control over rez limits and not script delays
[12:55] Acheron Gloom: The fence is the only real protection
[12:55] Meeter: Timecheck : User Group is almost over
[12:55] Motor Loon: I know its a HORRIBLE command... but llEmail with its 20sec delay is another example
[12:56] Motor Loon: so people just use 4-8 scripts with emailers instead to get around the delay
[12:56] Motor Loon: makes no sense
[12:56] ANSI Soderstrom: afaik llEmail dont go with 20secs
[12:56] Draconis Neurocam: yeah, some other form of sim to sim communication besides email, and making use of an external server, or the dns issues of http-in would be nice
[12:56] Motor Loon: there's alternatives yes
[12:56] Simon Linden: Right, any limits can't be enforced if they only apply to individual scripts, otherwise we just get more scripts
[12:56] Motor Loon: but lots of stuff still uses llEmail
[12:57] Rex Cronon: if u really want to send fast email, u could just rent a server outside sl...
[12:57] Motor Loon: but thats the point
[12:57] Motor Loon: people dont
[12:57] Motor Loon: instead they use 10 scripts to do what they want
[12:57] Acheron Gloom: Guns are particularly annoying because you can use loops to fire faster and more efficiently than link message spam (which honestly isn't that efficient if multiple scripts are hearing every message)
[12:57] Acheron Gloom: but loops stack up
[12:58] Acheron Gloom: and then the bullets stack
[12:58] Kelly Linden: I'm in favor of llRezObjectFast and llEmailFast but they definitely require extensive testing.
[12:58] Draconis Neurocam: guns wouldn't even be an issue if we had raycasts that do damage
[12:58] Acheron Gloom: Oh, well also raycasts stop working in low TD
[12:58] Acheron Gloom: or they're supposed to.
[12:58] Motor Loon: I dont think you'd need a new funtion for llEmail... nothing relies on that delay
[12:59] Draconis Neurocam: kelly you would need llRezAtRootFast as well
[12:59] Rex Cronon: there r weapons that don't fire in a straight line
[12:59] Acheron Gloom nods
[12:59] DesolateStudios: Instead of adding new functions, why not just remove the delay?
[12:59] Kelly Linden: You'd think so, but any script set up to round robin to multiple scripts is gonna change behavior when the delay is gone
[12:59] Acheron Gloom: Agree with Kelly there definitely
[12:59] Acheron Gloom: bad idea to do that ;p
[12:59] Motor Loon: actually I dont think it will
[13:00] Acheron Gloom: I know plenty of guns that do while(llGetObjectDesc() == "FIRE"){ fire(); }
[13:00] Acheron Gloom: and the delay removed would make them all break
[13:00] Acheron Gloom: and just fire as fast as possible until grey goo breaks them
[13:00] Motor Loon: the scripts are triggered by a mainscript, that just sends the command to each of the slavescripts... however fast the slavescripts execute dont really matter
[13:00] Acheron Gloom: Keep in mind there is more than one style ofg un :)
[13:00] Acheron Gloom: and more than just guns.
[13:00] Meeter: Thank you for coming to the Server User Group
[13:01] ANSI Soderstrom: *:-.,_,.-:*'``'*You're Welcome!!!!*:-.,_,.-:*'``'*
[13:01] Motor Loon: was different for stuff like llSetPrimitiveParams because some stuff was counting on the delay it brought...
[13:01] Acheron Gloom: I've already stated that there ARE things that use the delay though
[13:01] Acheron Gloom: guns that use looping slaves, for one
[13:01] Motor Loon: so llSetLinkPrimitiveParamsFast was a good way to go there
[13:02] DesolateStudios: I think do while(llGetObjectDesc() == "FIRE"){ fire(); } is pretty wreckless
[13:02] Acheron Gloom: Is it better than spamming linkmessage in a timer
[13:02] Acheron Gloom: to 2-3 scriptsa
[13:02] Acheron Gloom: all of which are receiving link message events, checking an integer twice to determine if its their turn to fire, and then if it is their turn, firing?
[13:02] Simon Linden: Thanks everyone, see you next time
[13:02] Motor Loon: I'd agree
[13:03] Rex Cronon: tc simon
[13:03] ANSI Soderstrom: tc all
[13:03] Motor Loon: good code should be written so it didn't rely on suchs things
[13:03] Rex Cronon: tc everybody and have a good day
[13:03] Motor Loon: alrighty
[13:03] Squirrel Wood: good code..
[13:03] Motor Loon: lateeer
[13:04] Rex Cronon: and now andrew is going to excute us, with crayons:)
[13:04] Baker Linden: have a great week everyone. I'll be out of the office on friday, so I'll see you next week
[13:04] Squirrel Wood: the majority of the sl population does not even know what bad code looks like :p
[13:04] Motor Loon: true Squirrel
[13:04] Kennylex Luckless: https://my.secondlife.com/kennylex.luckless/snapshots/4ffc854d3118e32da8000001
[13:04] Acheron Gloom: You should be able to rely on the way a script works not changing fundamentally
[13:05] Acheron Gloom: Changing a delay on an existing function is changing its fundamental operation
[13:05] Kennylex Luckless: Crayon Bazooka, it is a utility for Lindens.
[13:05] Andrew Linden got sidetracked by some othe chat channels
[13:05] Andrew Linden: Ok thanks for coming.
[13:05] Nalates Urriah: Thx Andrew. Please remember to post minutes :)
[13:05] Andrew Linden: Yeah, I'm way behind on that.
[13:06] Andrew Linden: I will try to get it done today.
[13:06] Nalates Urriah: Thank you so much!
| Prev 2012.07.06 | Next 2012.07.13 |