User:Andrew Linden/Office Hours/2010 02 02

Transcript

[11:00]	Simon Linden:	Andrew should be here soon
[11:00]	Welcome to	Linden office hours
[11:00]	Simon Linden:	So let's get started ... I don't think there are any server changes in the works this week
[11:00]	Sebastean Steamweaver:	Hello all :)
[11:00]	Arawn Spitteler:	Arawn Spitteler hastily makes ritual mention of SVC-22 , SVC-93 , SVC-2931 and runs back to check on his breakfast.
[11:00]	llSetLinkPrimitiveParams content	breakage, only moves agents 54 meters now
[11:00]	llSetLinkPrimitiveParams content	breakage, only moves agents 54 meters now
[11:00]	ROTATION and	llSetRot incorrectly implemented for child prims
[11:00]	Vehicles crossing	region borders aren't always treated as vehicles and can get incorrectly returned if the destination parcel is no-entry or parcel-full
[11:00]	ROTATION and	llSetRot incorrectly implemented for child prims
[11:00]	Vehicles crossing	region borders aren't always treated as vehicles and can get incorrectly returned if the destination parcel is no-entry or parcel-full
[11:00]	llSetLinkPrimitiveParams content	breakage, only moves agents 54 meters now
[11:00]	ROTATION and	llSetRot incorrectly implemented for child prims
[11:00]	Vehicles crossing	region borders aren't always treated as vehicles and can get incorrectly returned if the destination parcel is no-entry or parcel-full
[11:00]	Sebastean Steamweaver:	> <
[11:01]	Questar Utu:	D::::::
[11:01]	Simon Linden:	Glad to get that out of the way :)
[11:01]	Sahkolihaa Contepomi:	o_o
[11:01]	Sebastean Steamweaver:	Sebastean Steamweaver coughs.
[11:01]	Arawn Spitteler:	Something amiss with the Meeter?
[11:01]	Sebastean Steamweaver:	Yes, me lol
[11:01]	Sebastean Steamweaver:	I left my attachment on again :P
[11:01]	Sebastean Steamweaver:	I've not been to Andrew/Simon's hours in so long I forgot I had to take it off.
[11:02]	Ardy Lay:	You were not the only one, Sebastian.
[11:02]	Sahkolihaa Contepomi:	Not that many people here today. :s
[11:02]	Arawn Spitteler:	Were the listeners responding to each other?
[11:02]	Questar Utu:	You should really have that thing detect other helpers..
[11:02]	Sebastean Steamweaver:	I haven't looked at the code actually, I'll do that sometime when I have a chance.
[11:02]	Questar Utu:	Heh.
[11:03]	Sebastean Steamweaver:	Moon gave it to me :)
[11:03]	Andrew Linden:	I don't think I've got any announcements today.
[11:03]	Questar Utu:	Well, it would basically be adding an on/off switch into the listener, with a sensor that switches that based on whether or not it finds helpers nearby.
[11:03]	Sahkolihaa Contepomi:	Techwolf got a new avatar. o.o
[11:03]	Sebastean Steamweaver:	How is work going on efficient scripting and the "easy functions" Andrew?
[11:03]	Techwolf Lupindo:	hello everyone
[11:03]	Arawn Spitteler:	Arawn Spitteler's on Facebook as Aaron Freeman: Farmville takes a lot of time, but might actually work better in this world, than on Facebook, and better than Scion Chickens.
[11:03]	Andrew Linden:	I'll go read my email and try to figure out when server-1.36 will be deployed...
[11:04]	Ardy Lay:	JIRA lookup tools should only respondt to speakers that own themselves.
[11:04]	Simon Linden:	I think those listeners will respond to each other, but since they should only echo the info once (with a long timeout to refresh) we don't get an endless chat cycle
[11:04]	Rex Cronon:	hello everybody
[11:04]	Arawn Spitteler:	I'd a weirdness, this morning, when I sat on a pose ball, and it asked my perms to animate
[11:05]	Andrew Linden:	Looks like server-1.36 is scheduled for mid Feb
[11:05]	Arawn Spitteler:	Pathfinder's Pffice, when I've a chance to repro
[11:05]	Andrew Linden:	I've seen some updates on fixed bugs as some QA engineers retest and pass them.
[11:05]	Techwolf Lupindo:	Techwolf Lupindo notices the "no voice title" "I've got 64-bit client with working voice"
[11:06]	Sahkolihaa Contepomi:	32-bit, you mean.
[11:06]	Sebastean Steamweaver:	Hey there Tech
[11:06]	Techwolf Lupindo:	no, 64-bit client build
[11:06]	Sahkolihaa Contepomi:	Yes but voice is 32-bit. :)
[11:06]	Techwolf Lupindo:	hi sebastean
[11:06]	Questar Utu:	SL client = separate from voice client.
[11:07]	Sebastean Steamweaver:	Andrew, I saw the JIRA on efficient scripting, and noticed that they were working on implementing llSetLinkPrimitiveParamsFast - I had some thoughts on that, if we have time to discuss it.
[11:07]	Sahkolihaa Contepomi:	He knows that, hon. :p
[11:07]	Questar Utu:	xP
[11:07]	Andrew Linden:	Yes, the "voice client" is a separate process.
[11:07]	Andrew Linden:	Sebastian, sure let's talk about it. Babbage Linden is working on it.
[11:07]	Linda Haber:	Hello, fogive my apearance but it is the only way I could get here
[11:08]	Sebastean Steamweaver:	I was really pleased to hear that they were working on it, but I got to thinking, since it's still in its fetal stages (as far as I know), now might be the time to make a bigger improvement.
[11:08]	Sebastean Steamweaver:	I originally posted this as a comment on that JIRA, but decided to open a separate JIRA for it instead.
[11:08]	Sebastean Steamweaver:	SVC-5329
[11:08]
[11:08]	Andrew Linden:	actually Sebastian it is code-complete and is only waiting for QA time -- won't be in server-1.36 -- probably 1.38
[11:09]	Sebastean Steamweaver:	Ah well, I guess the JIRA is a little late then.
[11:09]	Simon Linden:	What's your different approach?
[11:09]	Sebastean Steamweaver:	Basically, instead of having a link number at the beginning of the function, it changes the link number to be designated before each parameter in the list instead.
[11:10]	Simon Linden:	Ah, I see
[11:10]	Sebastean Steamweaver:	It allows you to set different prims, with different properties, in the same function call, or several prims to the same property. You can adjust it as you need to.
[11:11]	Sebastean Steamweaver:	Since we have "LINK_THIS" it negates the need for a plain llSetPrimitiveParams, there would be no delay, as planned for llSetLinkPrimitiveParamsFast, it's a lot easier to type, and uses less screen space as added bonuses lol
[11:11]	Andrew Linden:	Hrm... I don't know the details of how Babbage actually implemented it.
[11:11]	Sebastean Steamweaver:	Basically streamlining the code and killing several birds with one stone.
[11:11]	Sebastean Steamweaver:	From the JIRA, it appears to just be llSetLinkPrimitveParams with no delay.
[11:11]	Andrew Linden:	Oh right.
[11:12]	Sebastean Steamweaver:	SVC-5166
[11:12]
[11:12]	Sebastean Steamweaver:	(Sub-task opened by Kelly Linden)
[11:12]	Linda Haber:	Hmm looks like I am in the wrong place, I was hopeing that somebody would be able to help me in fixing the existing code rather than adding more
[11:12]	Andrew Linden:	yeah, it is too late to change however...
[11:12]	Andrew Linden:	Babbage's plan is to allow LSL versioning this year
[11:13]	Ovaltine Constantine:	And whats that again?
[11:13]	Andrew Linden:	which will allow us to actually change the LSL behavior -- you'll be able to specify the version you want to use
[11:13]	Simon Linden:	With versioning we would be able to evolve the language
[11:13]	Simon Linden:	So all scripts up to now would be version 1.0 (or similar)
[11:13]	Andrew Linden:	right, so for example we could actually fix SVC-93 rather than add a new function call
[11:14]	Sebastean Steamweaver:	Ah-ha, I really like the sound of that.
[11:14]	Simon Linden:	If we changed a function, we could call it 1.1, and the behavior changes only when running a script compiled with the new version number
[11:14]	Ardy Lay:	Yes, that does sound like a good plan.
[11:14]	Sebastean Steamweaver:	Updating broken functions while not breaking content = good.
[11:14]	Andrew Linden:	yeah, unfortunately I like the sound so much I'm now much more demotivated for actually trying to fix SVC-93 before versioning.
[11:14]	Simon Linden:	You could (for a while, at least) still compile with older versions so you can do maintenance
[11:15]	Rex Cronon:	how many versions will ll support/maintain?
[11:15]	Simon Linden:	I'm not sure ... the plans are still in flux
[11:15]	Andrew Linden:	uh... I suspect we would have to support all legacy versions
[11:15]	Arawn Spitteler:	SVC-93 will still require someone willing to brave the underlying code. It only requires a couple new integers, to do the job.
[11:16]	Simon Linden:	It's not too hard to support running older versions, but compiling may be tougher
[11:16]	Andrew Linden:	the only way we could drop old versions would be to roll out "new world" spaces where the old versions weren't included from the start
[11:16]	Simon Linden:	Right
[11:17]	Simon Linden:	This is at the "good idea being passed around" stage, so exact behavior still has to be worked out
[11:17]	Sebastean Steamweaver:	Weaning SL off of the older versions, then. Unfortunately, that wouldn't explain to people why the old item they just bought won't work in their new region.
[11:17]	Sebastean Steamweaver:	Unless of course, the server gives them some sort of message.
[11:18]	Sebastean Steamweaver:	"The item you are trying to rez uses scripts which are older than this simulator supports. The item will rez but the scripts will be non-functional."
[11:18]	Arawn Spitteler:	World Travel would be a P2P implementation, likely
[11:18]	Andrew Linden:	Well, droping old versions of script behavior won't happen for a long time in SL proper.
[11:19]	Andrew Linden:	LL is probably going to move into the enterprise space and sell small virtual worlds for private companies who want to run their worlds behind corporate firewalls...
[11:19]	Eddi Decosta:	heya Simon , how are you? ㋡
[11:20]	Andrew Linden:	such enterprise worlds might not include support for older versions of scripts... maybe.
[11:20]	Simon Linden:	Hello
[11:20]	Andrew Linden:	Perhaps that is just wishful thinking on my part.
[11:20]	Sebastean Steamweaver:	Well, since they'd be newly created and presumably isolated from SL as a whole, one could probably assume their scripts would also be new, unless they decided to copy paste it from a file on their PC.
[11:21]	Sebastean Steamweaver:	Or mac >.>
[11:21]	Simon Linden:	I have a question for scripters or land owners if we're ready to move on...
[11:21]	Adamburp Adamczyk:	sure si
[11:21]	Sebastean Steamweaver:	What's up/
[11:22]	Simon Linden:	How much of your in-world objects need to run when nobody is around?
[11:22]	Adamburp Adamczyk:	not a lot
[11:22]	Simon Linden:	... and what are those cases?
[11:22]	Eddi Decosta:	Simon, do you know if the firewall, can cause some lag issue with the linked prims on build and other?
[11:22]	Jonathan Yap:	Scanners
[11:22]	Adamburp Adamczyk:	only thing that runs full tiem is my chod-o-sel
[11:22]	Sebastean Steamweaver:	Some of mine do, but it depends on the case. Most of mine are user-oriented, so they only "do things" other than self-maintenance when someone is around.
[11:22]	Rex Cronon:	i didn't hear your question, simon:(
[11:22]	Epic Flux:	depends on what it's doing, if it's an in world data server whether someone is around or not is irrelevant.
[11:22]	Opensource Obscure:	almost all of them because my land is meant to host a public scripted installation - http://alisl.org/chromutate
[11:22]	Simon Linden:	What are the scanners scanning? For AVs?
[11:23]	Adamburp Adamczyk:	i have no scanners running
[11:23]	Rex Cronon:	u can set a scanner to scann for whatever u want
[11:23]	Opensource Obscure:	i have many scanners that detect presence and positions of avatars in order to trigger buildings movements , color changes and such
[11:24]	Arawn Spitteler:	Scanners don't hve to scan for avatars, in empty sims, but those Scion Chickens might
[11:24]	Ovaltine Constantine:	Update servers, stuff that sends you new versions of stuff
[11:24]	Simon Linden:	Opensrc ... that's an interesting demo. Do people usually sit in-world to watch the changes?
[11:24]	Sebastean Steamweaver:	Oh yes thanks for mentioning that Ovaltine.
[11:24]	Adamburp Adamczyk:	actually smon/andrew i have a GOOD question for you
[11:24]	Sebastean Steamweaver:	I do have several "servers" that have to operate around the clock.
[11:24]	Opensource Obscure:	at Chromutate, they often come inworld then open the web page to do things
[11:24]	Opensource Obscure:	also, I use lots of listeners - I almost only use llRegionSay for making sensors and moving structurs comunicate
[11:25]	Sebastean Steamweaver:	SLX servers are one example I think many people would be familiar with.
[11:25]	Arawn Spitteler:	It would increase the challenge, of having a prim run a bot
[11:25]	Simon Linden:	OK ... I've been playing with ideas on running regions at a lower priority if nobody is around, but we obviously want to be careful with it. It would free up more CPU for regions on the same machine that have AVs
[11:25]	Jonathan Yap:	Objects that can be the target of llRemoteLoadScriptPin
[11:25]	Eddi Decosta:	well, i think with a http request implant you can give to all the possibility to dectect some version of viewer ㋡
[11:26]	Sebastean Steamweaver:	If you make it optional, I think that might be good. But there are many things that have to run all the time, such as product servers, scanners, or some other miscellanea.
[11:26]	Sebastean Steamweaver:	Generally, I try to code anything of mine to shut off and use less resources when it needs to as it is.
[11:26]	Eddi Decosta:	optional on premium account? LOL
[11:26]	Arawn Spitteler:	That might work
[11:26]	Sebastean Steamweaver:	I feel safer relegating that responsibility to the scripter/user.
[11:27]	Simon Linden:	Right ... it wouldn't be a real shutdown or anything, but probably a lower frame rate. It can jump back to normal easily whenever some event happens ... someone enters the region, or a particular LSL call, etc
[11:27]	Arawn Spitteler:	If we could get Farmville in world, that would also function in absentia
[11:27]	Simon Linden:	Still working on the details
[11:27]	Simon Linden:	We have chickens :)
[11:27]	Rex Cronon:	just a sec. if i rent from somebody doesn't matter if i am free or premium. i am paying
[11:27]	CPU Core:	I ALWAYS WANTED TO MAKE A FARM IN sl
[11:27]	Opensource Obscure:	I guess many clubs use lots of scripts in a very small amount of time, then scripts get unused until next event.
[11:27]	Jonathan Yap:	You would have to be careful not to disturb scripts that use quasi-synchronized timers
[11:27]	CPU Core:	oops caps lock
[11:27]	Sebastean Steamweaver:	That might work Simon, but then you might have people scripting things specifically to use those LSL calls to keep the sim higher, which would defeat the purpose.
[11:28]	Sebastean Steamweaver:	Synchronization is a nightmare anyway, but I agree.
[11:28]	Epic Flux:	actually, I have a server related question. since anything that is already made by anyone that is already in world, why can't we drop item server nodes altogether, get some function that will distribute an item directly from linden servers but with it saying like, "avatar is giving you item"..
[11:28]	Simon Linden:	Right, or park a bot on the region to bypass it
[11:28]	Eddi Decosta:	CPU, buy an logitech keyboard :p
[11:28]	Andrew Linden:	Simon, your plan is not to stop the region altogether, but just to deschedule it a little bit, right?
[11:28]	CPU Core:	i like my keyboard too much to replace
[11:28]	Andrew Linden:	So scripts would still run, but at some lower FPS.
[11:29]	Ardy Lay:	Epic, that's already how it works.
[11:29]	Simon Linden:	Yes, give up a bit more CPU time to other regions, so it's running at a lower frame rate
[11:29]	Jonathan Yap:	How about letting the script declare its running priority (1..4)?
[11:29]	Epic Flux:	kind of a random suggestion, I don't know if that would help with your load issues or not, but dropping out every SLX box, and other item server box on the grid and exchanging them for a server function that directly delivers an item from one avatar to another.
[11:29]	Ardy Lay:	Oh, you mean remove the scripted triggers too?
[11:29]	Ardy Lay:	Hmm..
[11:29]	Andrew Linden:	So I guess the question is... what kind of scripts can we think of that would break at the lower FPS?
[11:29]	Andrew Linden:	Probably scripts with timers trying to measure sim performance ;-)
[11:30]	Rex Cronon:	llhttprequest
[11:30]	Sebastean Steamweaver:	Well, object servers wouldn't necessarily "break," but it'd take longer to deliver to users. At high volume, that could be a problem.
[11:30]	office hours	is half over
[11:30]	Simon Linden:	I really hope people aren't writing many scripts that break at low fps :)
[11:30]	CPU Core:	would be good if there was a function to deactivate scripts until someone is in the sim
[11:30]	Sebastean Steamweaver:	High volume object servers for vendors and such could get backed up and possibly break at lower fps, depending on the traffic.
[11:30]	Rex Cronon:	http_request(key id, string method, string body)
[11:30]	Simon Linden:	That might be another interesting threshold ... only give up extra CPU time if there _is_ extra time. IOW, if all scripts are done
[11:31]	Andrew Linden:	Hrm... per-script wakeup callbacks.
[11:31]	Andrew Linden:	brb...
[11:31]	Simon Linden:	This isn't on a per-script basis, but certainly some events might be a 'wakeup' that turns this off for a few frames
[11:31]	Rex Cronon:	the connection will be dropped if it takes too much tims for lsl server to repsong
[11:32]	Rex Cronon:	respond*
[11:32]	Simon Linden:	Rex - right, but that's a huge timescale, whereas this is more like running at 20fps rather than 45fps
[11:32]	Arawn Spitteler:	Arawn Spitteler's entertaining a question of Co-operative Scripting, but has no expeirience in that field: Is Co-Scripting possible in LSL, or is that more a C# or Python thing? Would a Co-Script RPG be signed up for by Lindens?
[11:32]	Simon Linden:	I'
[11:32]	Simon Linden:	I'm not sure exactly what you mean by Co-scripting
[11:33]	Rex Cronon:	right now it takes like 5 seconds for the lsl server to respond, if u make it slower:(
[11:33]	Arawn Spitteler:	Several people working on a single scripting project
[11:33]	Andrew Linden:	back
[11:33]	Simon Linden:	Arawn ... hmm, that would be better editing/sharing tools for scripting then?
[11:33]	Epic Flux:	the only reason I'd be keen to share my projects would be to have someone else to blame when it doesn't work :P lol.
[11:33]	Arawn Spitteler:	It wouldn't be programming 101, certainly
[11:34]	Arawn Spitteler:	I don't know if the tools exist, for LSL, or what tools are needed.
[11:34]	Simon Linden:	A shared script editor would be interesting, something like Etherpad
[11:34]	Sebastean Steamweaver:	A better script editor would be interesting X)
[11:34]	Simon Linden:	... but sounds like a pretty big project
[11:34]	Arawn Spitteler:	Shared Script Editing would certainly be valuable for teachers.
[11:34]	Simon Linden:	definitely
[11:34]	Andrew Linden:	Yes, co-scripting would be co-editing -- it would be language independent. But there are no co-editing tools in SL right now.
[11:35]	Epic Flux:	oh, if you're going to improve teh script editor, make it so it is accessable while offline by any system that can 'run' the SL client.
[11:35]	Sebastean Steamweaver:	Race-Condition Country, there.
[11:35]	Andrew Linden:	However... there are co-editing web pages these days.
[11:35]	Simon Linden:	There's been some talk about better viewer integration with external editors, which if done correctly might be something with a feature like that
[11:35]	Arawn Spitteler:	LSL could use a UDL, User Defined Library, for frequent hacks
[11:35]	Sebastean Steamweaver:	Babbage has talked about that at his hours.
[11:36]	Sebastean Steamweaver:	I think the ability to create our own libraries is already on the table.
[11:36]	Arawn Spitteler:	Is it Jiraed?
[11:36]	Sebastean Steamweaver:	I'm not sure to be honest, but Babbage says it's coming with C#
[11:36]	Epic Flux:	sometimes when I travel I wind up with my mac and no internet, and no easy reference while scripting offline. not sure if that would be more of a side issue though.
[11:36]	Andrew Linden:	Simon, I can't think of many scripts that would break terribly at 20fps.
[11:37]	Arawn Spitteler:	Five FPS would work with llSetPos
[11:37]	Simon Linden:	Andrew - yes, I agree. I think we just need to understand what type of systems (like object updaters) that might bog down
[11:37]	Sebastean Steamweaver:	How would it affect physics and physics scripts? Like for example, for floating objects?
[11:37]	Andrew Linden:	Ship it! Then fix it.
[11:37]	Andrew Linden:	(That was a joke)
[11:37]	Rex Cronon:	if we r going to use c# i want/need to upload precomiled doe, binaries or whatever c# uses:)
[11:38]	Epic Flux:	lol, going after the microsoft business motto?
[11:38]	Simon Linden:	And remember ... this would only kick in if nobody was on the region, or (probably) looking into the region
[11:38]	Epic Flux:	I can't say model cause they ship it and rarely if ever fix it.
[11:38]	Rex Cronon:	precompiled code*
[11:38]	Jonathan Yap:	Maybe the approach should be to make a smarter scheduler -- scripts that mostly sit around not doing computing get a temporary priority boost, the ones doing heavier computing have to contend for fewer cpu cycles.
[11:38]	Simon Linden:	I've done some tests, and it would definitely help OpenSpace region performace. Probably full regions too, but it all depends on the other regions on the same server box
[11:39]	Epic Flux:	isn't that backwards jonathan?
[11:39]	Andrew Linden:	Andrew Linden has been looking at the LSL sensor code to see if it can be cleaned up. Very messy.
[11:39]	Sebastean Steamweaver:	OpenSpace, you mean homesteads?
[11:39]	Jonathan Yap:	It's how the old VMS schedule worked in a basic sense
[11:39]	Simon Linden:	We typically end up with a lot of scripts waiting for an event
[11:39]	Sebastean Steamweaver:	OpenSpace sims are the sims we're supposed to pay 75$ just to look at :P
[11:39]	Epic Flux:	I try to keep my scripts as 'simple' as possible, but sometimes they wind up requiring to do a lot of calculations.
[11:39]	Arawn Spitteler:	Arawn Spitteler thinks Open Space would work better, if one owner could coordinate fours or sixteens
[11:39]	Simon Linden:	Yes, Homesteads. I'm using old terms :)
[11:40]	Andrew Linden:	Making scripts more efficient just means more stuff can run -- people will still pile the scripts on until the simulator starts to suffer.
[11:40]	Sebastean Steamweaver:	Well, here's a thought.
[11:40]	Arawn Spitteler:	Unitil?
[11:40]	Sebastean Steamweaver:	With the new memory management scheme coming in, won't that in itself help alleviate some of the problem you're trying to solve?
[11:41]	Andrew Linden:	So some sort of script limits would be ultimately required to prevent scripts from killing performance.
[11:41]	Andrew Linden:	Yes, such a script limit system is in the plan, I believe.
[11:41]	Epic Flux:	what about eliminating the llSetTimerEvent(X) altogether, and if one needs a timer, just put in the event and a counter, and have the script automatically tied into the server time, then you could really keep a good hold as to how long it takes for a script to do a function, etc?
[11:41]	Andrew Linden:	but descheduling the server means lower operations costs for LL -- are there any benefits for residents Simon?
[11:42]	Sebastean Steamweaver:	The way Babbage explained it was that yuo could allocate to a script whatever memory it needed to perform its task, meaning you could use larger amounts for more complex scripts, and less for those which carry on simpler tasks.
[11:42]	Jonathan Yap:	Script limits are for memory, it seems the issue here is reducing CPU load
[11:42]	Andrew Linden:	Yes Sebastian, that is in the plan too, but there must be some cap on total script resources, or the only limiting factor will be simulator performance.
[11:43]	Andrew Linden:	That is, you won't notice the scripts causing a problem until the simulator actually slows down.
[11:43]	Epic Flux:	are these script limitations going to be based on total script load or total script count?
[11:43]	Sebastean Steamweaver:	They were going to allocate it into amounts, similar to prims, if I remember, and you couldn't rez something that took you past your memory allocation.
[11:44]	Simon Linden:	Script limits are also about a more even distribution of scripting ... so one parcel on a region can't bog down the entire sim
[11:44]	Arawn Spitteler:	It's other people's scripts that cause the problems, always other peoples
[11:44]	Andrew Linden:	The script limits will probably be memory limits.
[11:44]	Andrew Linden:	Oh right, its about fairer allocation as Simon mentioned.
[11:45]	Sebastean Steamweaver:	Simon, is there anything on the table about making such limits an estate option for those that own the sim?
[11:45]	Xugu Madison:	Xugu Madison always felt scripts should share a thread with the owner. More scripts in your thread means your personal lag goes up
[11:45]	Simon Linden:	I don't know that ... I think it hasn't been fully designed yet
[11:45]	Arawn Spitteler:	Privilege of sim ownership, limit others
[11:45]	Andrew Linden:	Arg... right. Someone is going to want script limits as an option.
[11:45]	Simon Linden:	The current code is just gathering data, not enforcing anything yet
[11:46]	Epic Flux:	That would be a personal nightmare Xugu, what about those people that have objects that they have keep ownership of and they are all over the grid?
[11:46]	Sebastean Steamweaver:	I'm afraid you missed him Epic, hehe.
[11:46]	Andrew Linden:	The only benefit for residents I can see for the descheduled simulator idea is -- more environmentally friendly (saves some energy) and perhaps eventually cheaper prices for land.
[11:46]	Arawn Spitteler:	Think of Linden Labs as the estate holder, or the Grid Keeper, or the Server Operator, but realise that it isn't a single entity.
[11:47]	Sebastean Steamweaver:	Andrew, how would it affect physics and physics scripts?
[11:47]	Simon Linden:	Depending on the situation, it can also raise the server frame rate
[11:47]	Andrew Linden:	huh... good question, we can't really run the physics engine at longer timesteps
[11:48]	Andrew Linden:	so we would either have to run two phys frames per simulator frame, or else run physics slow
[11:48]	Andrew Linden:	(slow = at lower fps while the simulated world thinks it is at higher fps)
[11:48]	Simon Linden:	This idea was to just run with a lower FPS or higher physics time dilation, not touch the timesteps
[11:48]	Arawn Spitteler:	Allow Physics Engine to accommodate lower frame rates?
[11:49]	Epic Flux:	what about implementing functions in LSL that make it easier to offload script processing out world?
[11:49]	Simon Linden:	I agree about that timestep though ... touching that would be really scary
[11:49]	Andrew Linden:	Yup, so a script that was measuring gravity's acceleration while using real-time for its measurements would measure a lower gravity.
[11:49]	Rex Cronon:	epic. u already have functions that allow u to do that:)
[11:50]	Jonathan Yap:	Andrew, at the moment if TD is much less than 1.0 that is what happens
[11:50]	Epic Flux:	not easily, figuring out how to translate LSL to mysql via PHP is a total nightmare.
[11:50]	Simon Linden:	Andrew - right, but that's deliberately desiging a script that breaks with lag. Not a good SL strategy :)
[11:50]	Andrew Linden:	Adjustible timestep is scary -- it could introduce physics instabilities -- oscillations that pump energy into the system.
[11:51]	Simon Linden:	Yeah, let's not go there. Longer sleep is better
[11:51]	Rex Cronon:	u don't have to that epic. u can use RPC:)
[11:51]	Sebastean Steamweaver:	Hehe
[11:51]	Jonathan Yap:	Another thing to consider--how far away are you from Class 6 servers?
[11:51]	Andrew Linden:	Yes Jonathan, TD can drop. But this would be an intentional drop -- because the simulator was not busy.
[11:51]	Simon Linden:	We actually have some class 7s running now
[11:52]	Andrew Linden:	the question is... what kind of scripts, if any, would break in terrible ways when the region gets descheduled
[11:52]	Epic Flux:	here is another note, which would fit into your current thought path,
[11:53]	Simon Linden:	We're on a class 7 server here, fwiw. Sharing the system with 5 other regions
[11:53]	Sebastean Steamweaver:	Well, that's why I mentioned physics scripts. Things that have to constantly compensate for changes in sim physics, or else they'll be doing weird things/be in weird places when the owner returns. Is that a possible issue?
[11:53]	Becky Pippen:	Can we tell class 7's by the sim host name?
[11:53]	Ardy Lay:	Just 5 others? Why not 7?
[11:53]	Epic Flux:	there is a land owner near one of my parcels that has had some objects that are scripted and emit a really obnoxious green glow, however, the person has not logged on in quite some time, nor is there really any ryhme or reason to the object layouts/positioning.
[11:54]	Epic Flux:	what about checking parcels like that and if all they have on them is random garbage just wipe it off the land until the 'owner' logs in again.
[11:54]	Simon Linden:	Ardy - I'm not sure why, we might just be lucky and have an open slot or two on this machine
[11:54]	Sebastean Steamweaver:	Almost sounds likea throw-away griefer account, heh.
[11:54]	Ardy Lay:	Hehe... okay.
[11:55]	office hours	is almost over
[11:55]	Sebastean Steamweaver:	Sebastean Steamweaver remembers his first particle-griefer encounter. He thought it was a party.
[11:55]	Simon Linden:	Epic - that's really a job for the land owner. I don't think LL wants to decide what's random garbage
[11:55]	Simon Linden:	... and I don't think anyone wants us to
[11:55]	Epic Flux:	ok
[11:55]	Sebastean Steamweaver:	Sounds like a good option Simon lol.
[11:55]	Jonathan Yap:	Have any studies been done to see how CPU cycles get eaten up by scripts?
[11:55]	Epic Flux:	one more thing
[11:56]	Jonathan Yap:	Perhaps there is internal code that could be made to run faster
[11:56]	Andrew Linden:	What? Didn't you guys know? That is what the random content loss bugs are about -- they're really a "random garbage collector" AI.
[11:56]	Jonathan Yap:	/more efficiently
[11:56]	Simon Linden:	Jonathan - yes, we've looked a lot a performance. Scripts can be the bottleneck sometimes, at others it's physics, updates, or something else
[11:57]	Epic Flux:	how much lag do mega prims really cause server side?
[11:57]	Sebastean Steamweaver:	In a system as extensive as SL, I'm sure there are lots of places where that can come in.
[11:57]	Arawn Spitteler:	Arawn Spitteler doesn't know what the world would do, without Cancer or Heart Disease
[11:57]	Simon Linden:	We have learned that we have way too many scripts, which is what led to the 'efficient scripts' work Andrew mentioned earlier
[11:57]	Sebastean Steamweaver:	Which made my heart pitter patter with glee.
[11:59]	Andrew Linden:	Epic we don't know how much lag is introduced by megaprims. Probably not too much.
[11:59]	Arawn Spitteler:	Arawn Spitteler still wonders about static prims conveying islands of collision
[11:59]	Sebastean Steamweaver:	Speaking of, Simon, or Andrew, will llSetObjectScale llGetObjectScale be implemented as well?
[11:59]	Andrew Linden:	There are bugs and problems with megaprims, and good things too.
[12:00]	Andrew Linden:	Yeah, I just remembered that I wanted to invite Falcon Linden to these office hours.
[12:00]	Thank you	for coming to Linden office hours
[12:00]	Andrew Linden:	Maybe I'll remember for Friday.
[12:00]	Simon Linden:	Sebastean ... I don't know about that one, I don't think it's in the first changes
[12:00]	Sebastean Steamweaver:	I'll try to be there for Friday. I keep getting confused and missing Friday because my OH hud is out of date with your new hours lol.
[12:01]	Arawn Spitteler:	Nev3er grow too dependant on the things you absolutely need.
[12:01]	Simon Linden:	Last question ... did anyone come to office hours after seeing it on Twitter or Avatars United?
[12:01]	CPU Core:	nope
[12:01]	CPU Core:	hate social websites
[12:01]	Ardy Lay:	I din't use those.
[12:01]	Epic Flux:	off topic: the only real issue I have with mega prims is how SL determines where they are, I have a very nice nieghbor that has a 256m3 sphere that seems pretty much swallow my land, but the center is on his land.
[12:01]	Jonathan Yap:	I use the OH list on the wiki
[12:01]	Simon Linden:	Looks like none, that's interesting to know. I was wondering if it would have any effect
[12:01]	Sebastean Steamweaver:	I don't signed up for Avatar United so no one would take my name and pose as me :P
[12:01]	Arawn Spitteler:	Arawn Spitteler's supposed to look at the tweat on AU
[12:01]	Sebastean Steamweaver:	I only*
[12:02]	Simon Linden:	I have to run to another meeting ... thanks everyone for coming
[12:02]	Rex Cronon:	simon. u want to say that u r the only simon on AU:)
[12:02]	Simon Linden:	Bye All!
[12:02]	Andrew Linden:	Yes, I've got to go too. See you all later.
[12:02]	CPU Core:	i use the office hour hud someone gave me
[12:02]	Sebastean Steamweaver:	Later simon
[12:02]	Rex Cronon:	tc simon
[12:02]	Sebastean Steamweaver:	Take care Andrew
[12:02]	Becky Pippen:	Thanks Andrew and Simon!
[12:02]	Rex Cronon:	tc andrew
[12:03]	Jonathan Yap:	There has been some talk about being able to return prims that stick into your land, but there are issues, like linden trees, protected ways, etc
[12:03]	Arawn Spitteler:	Estate Prim Protections?
[12:03]	Sebastean Steamweaver:	That's one of the things they're working on with megaprims.
[12:03]	Epic Flux:	if only I was on estate...
[12:03]	Sebastean Steamweaver:	It's what Andrew calls the "encroachment problem"
[12:03]	Jonathan Yap:	It wouldn't be an issue on an estate
[12:03]	Epic Flux:	I've been contemplating one 'good' turn deserves another...
[12:03]	Arawn Spitteler:	It's not just a megaprim issue, but linden roads cross a lot of property lines
[12:04]	Sebastean Steamweaver:	Very true Arawn
[12:04]	Sebastean Steamweaver:	Megaprims, it's just easier to do with.
[12:04]	Arawn Spitteler:	I've bounced from A--Ho-- lines that crossed half the road
[12:04]	Sebastean Steamweaver:	Frankly though, part of that issue is caused by the limited number of megas we have at our disposal, though that was helped a lot by the more recent loophole :P
[12:04]	Epic Flux:	I have quite a collection of mega's myself, but I always make sure they stay over my property lines.
[12:05]	Ardy Lay:	http://jira.secondlife.com/browse/VWR-744
[12:05]	renters need	to be able to move prims that overlap over their land borders, even if the center of the prim is on the other piece of land.

Generated with SLog Wikifier