User:Babbage Linden/Office Hours/2009 08 05

Transcript of Babbage Linden's office hours:

[3:00]	Gamez Diesel:	meeting starts now :D
[3:00]	Gamez Diesel:	wrong linden lolz
[3:00]	Morgaine Dinova:	Wow, it's a new Linden!
[3:00]	Gamez Diesel:	but better then no linden :D
[3:00]	Scouse Linden:	Hi Babbage is on vacation today
[3:00]	Morgaine Dinova:	Hiya Scouse :-)
[3:00]	Scouse Linden:	Hi everyone
[3:00]	Morgaine Dinova:	Sounds like another Brit from the name --- woohoo, Brits are taking over LL ^_^
[3:00]	Gamez Diesel:	Greetings Scouse
[3:00]	Scouse Linden:	At this time yes :)
[3:01]	Morgaine Dinova:	How goes Scouse? :-)
[3:01]	Scouse Linden:	I've worked closely with babbage on mono
[3:01]	Morgaine Dinova:	Coolness
[3:01]	Gamez Diesel:	nice
[3:01]	Gamez Diesel:	thank for that
[3:01]	Scouse Linden:	I'm happy to answer some questions etc, but I don't know what the usual agenda is
[3:01]	Morgaine Dinova:	Hiya Sai!
[3:01]	Gamez Diesel:	to bad only 40% of the population know what mono is haha XD
[3:02]	Gamez Diesel:	i kid i kid
[3:02]	Scouse Linden:	I bet less than 40% really know
[3:02]	Nock Forager:	Hi Scouse
[3:02]	Morgaine Dinova:	Scouse: there's rarely one. Babbage just talks on any topic that comes up that interests him ... including making rock music :P
[3:02]	Gamez Diesel:	yea i was being nice...
[3:02]	Morgaine Dinova:	But mostly about assemblies and stuff, hehe
[3:03]	Gamez Diesel:	nice nice
[3:03]	Scouse Linden:	I'll do my best to answer any question, I know nearly as much as babbage ;)
[3:03]	Gamez Diesel:	>_>
[3:03]	Gamez Diesel:	<_<
[3:03]	Gamez Diesel:	lolz
[3:04]	Morgaine Dinova:	Oh noes! So we'll need to give you remedial training too! ^_^
[3:04]	Gamez Diesel:	Well I usually come to listen lately
[3:04]	Morgaine Dinova:	J/K :-)))))
[3:04]	lonetorus Habilis holds up a protest sign, "give us complete 'linked' functions"
[3:04]	lonetorus Habilis:	;)
[3:04]	Scouse Linden:	what is your proposal lonetorus?
[3:05]	lonetorus Habilis:	well, now we have setlinkedprimparamaters
[3:05]	Gamez Diesel:	the benefit :D
[3:05]	lonetorus Habilis:	would be nice with a getlinked..
[3:05]	Scouse Linden:	have you made a Jira?
[3:05]	Gunter Vandyke:	hi all
[3:05]	lonetorus Habilis:	especially so, if scripts are going to be limited
[3:05]	lonetorus Habilis:	there are jiras on it, lemme dig up the numbers
[3:06]	Gamez Diesel:	hello again Saijanai
[3:06]	Gamez Diesel:	:D
[3:06]	Gamez Diesel:	take a seat
[3:06]	Scouse Linden:	Scripts are already limited: they just lag your sim when you have too many ;)
[3:06]	lonetorus Habilis:	this is one: http://jira.secondlife.com/browse/MISC-268
[3:06]	Morgaine Dinova:	Hehe
[3:06]	lonetorus Habilis:	scouse, i was my understanding that the schedular chnaged to only let scripts have idle cycles
[3:07]	lonetorus Habilis:	or very near idle priority
[3:07]	Scouse Linden:	I'm not aware of any scheduler changes recently
[3:07]	Scouse Linden:	I think babbage wanted to group up some of the work we've been doing and run a beta to get the bugs out
[3:08]	Liandra Ceawlin:	( Thanks Sai! ^_^ )
[3:08]	lonetorus Habilis:	the limiting code?
[3:08]	lonetorus Habilis:	information on that has been rather sparse
[3:08]	Scouse Linden:	That's because its a long way off
[3:08]	Morgaine Dinova:	Scouse, when the limits are hit for a sim, and many scripts from many users are attempting to get a slice of time and competing against each other, how does the selection work? Or does everything get given the boot until resource utilization drops to usable levels?
[3:09]	Scouse Linden:	It works the same as prims
[3:09]	lonetorus Habilis:	well, dont you have some overall design goal/framework?
[3:09]	Scouse Linden:	Times slices are not rationed yet
[3:09]	Scouse Linden:	The aim is actually to allow large mono scripts
[3:09]	Morgaine Dinova:	You just let exhaustion act as negative feedback on all?
[3:09]	Gamez Diesel:	so if it rezed it gets first dibs
[3:09]	Scouse Linden:	The same as it works now
[3:10]	Gamez Diesel:	i feel like im wasting seats heres :(
[3:11]	Morgaine Dinova:	There's no limit on seats :P
[3:11]	Gamez Diesel:	hehe
[3:11]	Scouse Linden:	There is actually
[3:11]	Scouse Linden:	They're prims
[3:11]	lonetorus Habilis:	XD
[3:11]	Scouse Linden:	Prims are limited
[3:11]	Purfect BEANBAG - v1 WHITE: Press Page Up for the selection of the animation
[3:11]	Morgaine Dinova:	Doh, a pedant :P
[3:11]	Liandra Ceawlin:	Your seat quota has been exceeded. Now you have to stand for the rest of the day. D:
[3:11]	lonetorus Habilis:	only in our minds ;)
[3:12]	Scouse Linden:	Well, it is important to understand how script limits will work, we've tried to make it like prims
[3:12]	Scouse Linden:	We will be carefully anaylsing the data to ensure that the minimum number of regions are affected
[3:12]	lonetorus Habilis:	also in regards to worn scripts?
[3:13]	lonetorus Habilis:	like a extra pool for those
[3:13]	Scouse Linden:	You'll have a constant quota
[3:13]	Morgaine Dinova:	The difference is that with prims, you buy a specific allocation, whereas with scripts the limits are hidden.
[3:13]	Scouse Linden:	Morgaine: they won't be
[3:13]	Opensource Obscure:	EHLO
[3:13]	Imaze Rhiano:	bacj
[3:13]	Morgaine Dinova:	Hi OO
[3:13]	Morgaine Dinova:	Wb Imaze!
[3:13]	Gamez Diesel:	lol
[3:13]	Gamez Diesel:	:D
[3:14]	Opensource Obscure:	wow! a steamy Linden, who I didn't know yet. Hi Scouse!
[3:15]	Scouse Linden:	Hi babbage is on holiday today
[3:15]	Opensource Obscure:	silent meeting?
[3:15]	lonetorus Habilis:	only one day? ;)
[3:15]	Morgaine Dinova:	Also, script timeslice constraints are much more complex than primit limits, for example there are flywheel exploits with script slice allocation.
[3:15]	Opensource Obscure:	ok
[3:15]	Scouse Linden:	Morgaine: Script limits are only for memory
[3:16]	lonetorus Habilis:	no ggod, when there are no limits on number of scripts
[3:16]	lonetorus Habilis:	i belive it took some 10k+ scripts to force "crashme" into swapping
[3:16]	Scouse Linden:	Each script has overhead
[3:17]	Imaze Rhiano:	so any hard data yet - like how many bytes attachment are allowed to use and how about parcel limits?
[3:17]	Scouse Linden:	We're working on improving the sim in general
[3:17]	Scouse Linden:	Script limits is just a public facing one
[3:17]	Liandra Ceawlin:	I am sorry if this was discussed before I got here, and for beating on the dead horse, but I think that we kinda maybe need some language changes to allow us to script more efficiently in conjunction with the quotas. >_>
[3:17]	Scouse Linden:	Imaze: no data yet, we're still looking in to that
[3:17]	Morgaine Dinova:	Did you find the blocking network call that was causing 3 ms freezes when people TP in/out?
[3:18]	lonetorus Habilis:	liandra, like http://jira.secondlife.com/browse/MISC-268
[3:18]	Scouse Linden:	Morgaine: I'm not aware of that one
[3:18]	lonetorus Habilis:	ah yes, the lag spike thing is most irretating in high traffic sims
[3:19]	lonetorus Habilis:	every time someone tp's in we get a sim freeze of a few seconds
[3:19]	Liandra Ceawlin:	For one. It would also be nice to have a call that allows us to turn off the arbitrary limits that we hack around in silly ways anyway, too, but to leave them on by default for compatibility. >_>
[3:19]	Imaze Rhiano:	and did you figure out why rezzing mono scripted objects in high usage sim is slowing down entire sim?
[3:19]	Scouse Linden:	liandra/lonetorus: there are two issues here. One is the API the other is the language
[3:19]	lonetorus Habilis:	depends on the number of scripts/textures the arriving avie has
[3:19]	Scouse Linden:	Some avs have crazy numbers of scripts
[3:19]	Scouse Linden:	This really slows down TPs
[3:19]	Morgaine Dinova:	The "look for one that's accidentally gone blocking" was a best guess, from the length of the spikes, just the kind of thing that would cause it.
[3:20]	Scouse Linden:	or stops them working completelyt
[3:20]	Morgaine Dinova:	Yup
[3:20]	Sebastean Steamweaver:	Scouse! What have you done with my Babbage!
[3:20]	lonetorus Habilis:	scouse, i suppose its the burst when they sync up the scripts with the sim they are arriving at?
[3:20]	Scouse Linden:	Sebastean: He's on holiday
[3:20]	Sebastean Steamweaver:	Hehe, good evening :)
[3:20]	Gamez Diesel:	thats rare my scripts have yet to stop working unless in a no script sim
[3:20]	Morgaine Dinova:	That's why your sim scalability is, far from rising or staying level with population growth, is actually *dropping* ... because with the advance of time, attachments get more complex.
[3:20]	Scouse Linden:	lonetorus: no, I think it is serialization and verification
[3:21]	Sebastean Steamweaver:	Hey Morg :D
[3:21]	Morgaine Dinova:	Hiya Seb!
[3:21]	Sebastean Steamweaver:	Xugu, you just rezzed, hehe.
[3:21]	Sebastean Steamweaver:	Hello everyone *covers everything*
[3:21]	lonetorus Habilis:	scouse, could the the rate that is being done at, be slowed down?
[3:21]	Xugu Madison:	Good grief, I've been here 10 minutes! (hi everyone BTW)
[3:21]	Morgaine Dinova:	Hiya Xugu :-)
[3:21]	Morgaine Dinova:	All the usual suspects, hehe
[3:22]	Xugu Madison:	Scouse, I've mentioned this to Babbage,but I'm hoping with a move away from LSL for scripting we might see scripts be able to serialise/deserialise themselves
[3:22]	Liandra Ceawlin:	<3 C#, want. <3
[3:22]	Xugu Madison:	In particular, any of my stuff that simply resets on region change (teleporters) really doesn't need to serialise...
[3:22]	Gamez Diesel:	im still learning here :(
[3:22]	Gunter Vandyke:	My Sim has 80000 traffic and can hold 70 ppl if no one arrive more. All performance goes downwhen many arrive only.
[3:22]	Gamez Diesel:	and you gonna change it on me lolz
[3:22]	Gunter Vandyke:	ist the come and go
[3:23]	Scouse Linden:	Liandra: me too, we're trying internally to get the go ahead on the project
[3:23]	Liandra Ceawlin:	\o/
[3:23]	Morgaine Dinova:	Scouse: Imaze+Xugu and others are working on completing the CIL verifier to accelerate the move towards native C# scripting.
[3:23]	Xugu Madison:	Where do we send cookies/death threats as appropriate? :)
[3:23]	Imaze Rhiano:	did you manage to push all that monitoring code to 1.30 - that allows us to see scripts metrics in parcel and attachments? Babbage told something about it last meeting...
[3:23]	Scouse Linden:	That's great, babbage had mentioned this to me
[3:23]	Opensource Obscure:	Gamez: don't worry, LSL probably won't go away for a long time
[3:24]	Scouse Linden:	Imaze: it's going to be in 1.32
[3:24]	Gamez Diesel:	lolz
[3:24]	Gunter Vandyke:	when will that come, 1.32?
[3:24]	Imaze Rhiano:	2011
[3:24]	Gunter Vandyke:	L ? L
[3:25]	Gamez Diesel:	im not to worried haha ive seen how long it took to get globalize teleportation XD
[3:25]	Liandra Ceawlin:	Will C# have some of the same arbitrary but hacked-around limits that LSL has? Example being wasting code on WarpPos rather than just llSetPos anywhere in the sim. >_>
[3:25]	Scouse Linden:	I don't have the date, what was the time between 1.27 and 1.30?
[3:25]	Opensource Obscure:	we're not on 1.30 yet so .. ?
[3:25]	Scouse Linden:	I mean 1.26 and 1.27
[3:25]	Sebastean Steamweaver:	Hmm
[3:25]	Opensource Obscure:	i think 6 months? not sure.
[3:25]	Gunter Vandyke:	3 month i guess
[3:25]	Sebastean Steamweaver:	I think it was closer to 3, but that's a guess.
[3:26]	Scouse Linden:	I think 3 is what we're aiming for
[3:26]	Xugu Madison:	So... basically we'll have monitoring tools around November/December?
[3:26]	Scouse Linden:	Probably
[3:26]	Gunter Vandyke:	would be good
[3:26]	Xugu Madison:	"I can give you a definite maybe"
[3:26]	Sebastean Steamweaver:	Liandra, Andrew said they were going to come out with a replacement for warpPos/JumpPos that was "legal", so I think that's on the docket.
[3:27]	Sebastean Steamweaver:	I would like to know if the current scripting limits will still be in place though.
[3:27]	Sebastean Steamweaver:	Or if they'll be changed, even if somewhat.
[3:27]	Opensource Obscure:	3 months was the right one : 1.26.0 (2009 April 7) -> 1.27.0.127440 (2009-07-16)
[3:27]	Liandra Ceawlin:	What about other silly things like having to parallelize scripts to get around delays; I mean, the built-in delays will become useless, sorta, once there are CPU time quotas. >_>
[3:27]	Xugu Madison:	We really need calls to be throttled, and also to be more mergable (loading notecards, for example, should take a line number range)
[3:27]	Scouse Linden:	CPU time quotas are not coming soon
[3:27]	Liandra Ceawlin:	Noddles.
[3:28]	Sebastean Steamweaver:	So, will the same limits that exist now, also exist in the C#?
[3:28]	Scouse Linden:	yes
[3:28]	Liandra Ceawlin:	I guess it would open the door to too much malicious code if we were able to do things like... llGetObjectByUUID( some_uuid ).setPos( some_vector ); , huh? >_>
[3:29]	Liandra Ceawlin:	That would be really nice though, lol.
[3:29]	Scouse Linden:	Liandra: we would hope to allow people to create their own libraries
[3:29]	Imaze Rhiano:	C# is missing one important component - or Mono is missing - Metadata verifier - without that there is not going to be C# in SL
[3:29]	Liandra Ceawlin:	Noddles.
[3:29]	Morgaine Dinova:	The built in delays after a lot of calls are really crude, that really needs revisiting. It should only happen as a negative feedback mechanism on excess resource use, not on every single call.
[3:29]	Scouse Linden:	Morgaine: agreed
[3:30]	Liandra Ceawlin:	I'd hafta agree with morgaine on that one. >_>
[3:30]	Liandra Ceawlin:	We need some kinda window or something, mebbe... <_<
[3:30]	Xugu Madison:	oh, yes, for anyone who can help with the metadata verifier (especially anyone with MSIL/CIL experience): http://xugumadison.org/csharp-sl/
[3:30]	Liandra Ceawlin:	I dunno, I am too dumb to offer good suggestions about that kinda stuff, lol.
[3:32]	Gamez Diesel:	im gonn he need to prepare for work nice metting you Scouse Linden :D
[3:33]	Scouse Linden:	Xugu: if assemblies are properly verified it potentially means any language
[3:33]	Gamez Diesel:	im gonna head out*
[3:33]	Sabrinaa Nightfire:	yes, me too
[3:33]	Gamez Diesel:	chat lag*
[3:33]	Sabrinaa Nightfire:	this was interesting
[3:33]	Scouse Linden:	Bye!
[3:33]	Scouse Linden:	Slow typer
[3:33]	Scouse Linden:	:)
[3:33]	Scouse Linden:	Thanks for coming
[3:33]	Morgaine Dinova:	Would be nice if, in addition to our existing viewer Consoles, there were one available for monitoring one of our own scripts at a time.
[3:33]	Xugu Madison:	Scouse, yeah, but C# is an easier sale to most people :)
[3:34]	Gamez Diesel:	ill see you again im sure
[3:34]	Xugu Madison:	I fancy F#, but people would just look at us strangely if we started talking about F# in SL
[3:34]	Scouse Linden:	quite, one step at a time :)
[3:34]	Scouse Linden:	Or boo
[3:34]	Scouse Linden:	http://boo.codehaus.org/
[3:34]	Morgaine Dinova:	Boo's nice
[3:34]	Morgaine Dinova:	I have it running here
[3:35]	Scouse Linden:	They're all a way off, but they are the kind of thing we'd love to have
[3:35]	Liandra Ceawlin:	Do you think there will ever be any trouble with Microsoft's supposed software patent on some of the stuff in Mono? >_>
[3:35]	Scouse Linden:	No
[3:35]	Xugu Madison also likes the idea of a Chef compiler for SL, but that's because he's insane
[3:35]	Liandra Ceawlin:	Gewd. Lol.
[3:35]	Scouse Linden:	The patents are on parts of the libs that we don't use
[3:35]	Morgaine Dinova:	I also have Nemerle running here, another language for the CLR. There seem to be a lot of small new langs for the CLR popping up.
[3:36]	Scouse Linden:	And they've also made some explicit won't sue claims etc
[3:36]	Imaze Rhiano:	spell
[3:37]	Scouse Linden:	MS have also invested mono in Novell, who are the primary owners of mono
[3:37]	Morgaine Dinova:	Well everything has a risk. Hopefully the risk in this case from MS will be small. I think we're in more danger from that patent troll that's suing NCsoft for MMO technology. If they win, LL will be next, then Blizzard.
[3:37]	Liandra Ceawlin:	D:
[3:37]	Liandra Ceawlin:	I'll hafta google that.
[3:38]	Morgaine Dinova:	Oh I don't put it past MS to do something nasty, despite their promise ... their lawyers will probably find a loophole. But I don't think the risk is large.
[3:38]	Scouse Linden:	Patent trolls are a risk to anyone that makes technology. Fortunately, I'm just a software engineer and we have legal depts to worry about that!
[3:38]	Liandra Ceawlin:	Haha
[3:39]	Imaze Rhiano:	spell
[3:39]	Morgaine Dinova:	Scouse: yeah. And never look up a patent, to avoid triple damages.
[3:39]	Liandra Ceawlin:	I am most worried about open source projects, OpenSim in particular, but I guess this isn't the place for that topic, lol.
[3:39]	Sebastean Steamweaver:	MMO technology :P
[3:40]	Scouse Linden:	OpenSim has been backed by IBM of sorts, they have more lawyers than programmers ;)
[3:40]	Liandra Ceawlin:	\o/
[3:40]	Xugu Madison:	It does seem a bit odd the BSD-licensed OpenSim runs on a MS-owned language
[3:40]	Liandra Ceawlin:	Lol, ironic, innit?
[3:40]	Morgaine Dinova:	Seb: the usual, some bunch of non-productive lawyers acquire a patent and think they can make money from it by litigation despite producing no wealth themselves.
[3:40]	Scouse Linden:	MS did own it
[3:40]	Scouse Linden:	They're opened it up now
[3:41]	Scouse Linden:	It used to be MSIL
[3:41]	Imaze Rhiano:	any patent troll can sue me as they like... don't live in US
[3:41]	Scouse Linden:	It's now CIL
[3:41]	Morgaine Dinova:	They got it accepted as a standard at ECMA.
[3:41]	Scouse Linden:	exactly
[3:43]	Morgaine Dinova:	Scouse: if client-side scripting came about, by one path or another, would your team be likely to be involved in it at some point (if CLR-based), or are you 100% only interested in server side by intent?
[3:44]	Scouse Linden:	We're a small enough company that we would have some involvement
[3:44]	Sebastean Steamweaver:	Hmm
[3:44]	Scouse Linden:	I made a proof-of-concept embedding mono in the viewer
[3:44]	Morgaine Dinova:	The answer is possibly complicated by the fact that any client-side scripting is very likely to want to talk to server-side scripting, so there would at the very least be the matter of server-side API support.
[3:45]	Scouse Linden:	Yes, the reason mono is a good choice is because we have expertise in it
[3:45]	Scouse Linden:	And it should hopefully be secure
[3:45]	Liandra Ceawlin:	I'd kill to be able to have a bunch of HUD stuff running client-side, lol.
[3:45]	Morgaine Dinova:	Seems a good reason to me.
[3:46]	Sebastean Steamweaver:	It'd be nice to have more extensive client-interfacing capability for scripts, to be honest.
[3:46]	Sebastean Steamweaver:	Things like HUDS especially.
[3:46]	Xugu Madison:	I also can see a lot of fun trying to get the less experienced scripters to understand client-server script pairs
[3:46]	Scouse Linden:	For everything...
[3:46]	Morgaine Dinova:	I expect that we wouldn't need your assembly instrumentation technology for that ... Miguel's new coroutines would probably suffice.
[3:46]	Scouse Linden:	We have our own alternative to coroutines
[3:47]	Scouse Linden:	That's how we make them work on the server
[3:47]	Sebastean Steamweaver realizes there's an open seat, and nabs it.
[3:47]	Morgaine Dinova:	yeah, I know, Babbage has described how you instrument the assemblies with yield points extensively.
[3:47]	Scouse Linden:	It's better than coroutines, as you don't have to change your code
[3:48]	Morgaine Dinova:	But we probably wouldn't need that ... and there's the question of you opening it in any case
[3:48]	lonetorus Habilis:	can i show a hud i made recently, where i took great care not to use lots of slave scrips
[3:49]	Scouse Linden:	That's very nice
[3:49]	Morgaine Dinova:	It's no-mod, so can't see the code
[3:50]	lonetorus Habilis:	but coding and having no idea what form the limits will take is quite frustrating :)
[3:50]	Liandra Ceawlin:	Your HUD crashed him! Lawl. ;P
[3:50]	lonetorus Habilis:	i hope not ;)
[3:50]	Scouse Linden:	Have you seen llRequestURL
[3:50]	Scouse Linden:	That uses limits
[3:50]	Mojito Sorbet:	You can use the new XY-detect functions to considerably cut down on the need for child prims for buuttons
[3:51]	Sebastean Steamweaver:	Scouse, one thing I've been wondering
[3:51]	Sebastean Steamweaver:	What "units" will be used for script memory, in requesting "memory blocks"
[3:51]	Scouse Linden:	Probably KB
[3:51]	lonetorus Habilis:	moji, yeah, but i was coding on a dumy setup, the design of the hud is by a diff creator, thus i used prim buttons
[3:51]	Scouse Linden:	But that is TBD
[3:51]	Sebastean Steamweaver:	But, chunks of Kb? specific amounts of KB?
[3:52]	Morgaine Dinova:	Libraries of Congress per furlong. It's the unit for experts
[3:52]	Morgaine Dinova:	:P
[3:52]	Mojito Sorbet:	Just for a ballparkl figure, how many lines of LSL compile to 1KB?
[3:52]	Scouse Linden:	Mojito: depnds
[3:52]	Scouse Linden:	There is overhead
[3:52]	Liandra Ceawlin:	Script memory in mono is not allocated in contiguous pages, right? It just totals up how much a script is using from objects that a spread out whereever, right? >_>
[3:52]	Morgaine Dinova:	Oh hiya Mojito!
[3:52]	Xugu Madison:	Experience suggests states are really expensive, for example
[3:52]	Liandra Ceawlin:	*are
[3:53]	Sebastean Steamweaver:	I can confirm that, Xugu
[3:53]	Morgaine Dinova:	What makes states expensive?
[3:53]	Sebastean Steamweaver:	States seem to take up a lot more of a script's memory than ones which use "psuedo-states"
[3:53]	Xugu Madison nods to Sebastean
[3:54]	Xugu Madison:	I think because it has to handle switching states, and unlike LSL (old), it's done by the script itself
[3:54]	Scouse Linden:	I'm not keen on using states
[3:54]	Morgaine Dinova:	Scouse: are states handled in some special way?
[3:54]	Mojito Sorbet:	Each state has its own set of event dispatch vectors. Maybe that is why
[3:54]	Scouse Linden:	Using the state statement is like using goto
[3:54]	Scouse Linden:	The only reason I'd use them is to change handlers
[3:54]	Xugu Madison:	Scouse, want to give us llRemoveTouchListener() and llAddTouchListener() then? :)
[3:54]	Mojito Sorbet:	Being able to cleanly select a different set of event handlers is the primary reason to use states
[3:55]	Morgaine Dinova:	Well yeah, state tranmsitions in state machines are gotos ... it's not a crime against humanity :-)
[3:55]	Morgaine Dinova:	It's a clean goto, not Dijkstra style
[3:55]	Mojito Sorbet:	No, they are more than a goto - it swaps in the new event handlers
[3:55]	Morgaine Dinova:	Mojito: input has to get routed to the right state after all
[3:55]	Imaze Rhiano:	generally LSL is pretty much hating all good coding practices - like functions, "constant variable", proper error handling - because all that is taking awful amout of memory :(
[3:55]	Sebastean Steamweaver:	That's generally why I use it Mojito, as opposed to having a ton of if statements tangling things up, but I've had to rework more than one script because states caused it not to compile due to running out of memory.
[3:56]	Mojito Sorbet:	Now if they implemented it by having a big fixed dispatch vector for all possible events, and each state gets its own copy, then that is why ther memory hit
[3:56]	Scouse Linden:	Imaze: that's why we would like to use C#
[3:56]	Sebastean Steamweaver:	<3's functions
[3:57]	Morgaine Dinova:	State machines are very clean. As Seb says, the alternative is often spaghetti. And LSL's single real claim to fame is that it's a state machine language.
[3:57]	Scouse Linden:	The trouble is, code quickly becomes to complex to use those states
[3:57]	lonetorus Habilis:	hmm, i cant help but think about the added devide between pro content developers, and regular residents, re: C# and real mesh imports
[3:57]	Sebastean Steamweaver:	Scouse, just a little side-note, for those times I'm not using an IDE, would it be possible to add in some sort of highlighting in the in-client compiler for user-defined functions :>
[3:58]	Imaze Rhiano:	I don't use states in my scripts - mostly because chaning states will clear event queue - and you might be missing some event then
[3:58]	Scouse Linden:	Sebastean: patches are welcome :)
[3:58]	Liandra Ceawlin:	I look at it as... People just learning to program will be able to learn something they can use in areas other than SL, and won't develop the bad habits that LSL reinforces, no offense. >_> Lol.
[3:58]	Mojito Sorbet:	Also, state switches can be surprisingly slow
[3:58]	Morgaine Dinova:	Patches for server side? That's funny :P
[3:58]	Scouse Linden:	State changes cause your script to wait for at least a frame
[3:58]	lonetorus Habilis:	ah, and variable /function tab completion
[3:59]	Scouse Linden:	1/45 of a second
[3:59]	Mojito Sorbet:	I had a script use llSay to send a message to another object. Then it would change state and listen for the answer. The other Object script woke up, processed the message and sent its reply, all before the first object managed to get its llListen issued.
[4:00]	lonetorus Habilis:	liandra, i agree, but gotta be careful not to leave the general population behind, many ppl are not too fond of the whole "having to learn new things all the time" XD
[4:00]	Sebastean Steamweaver:	I usually use them for things that either want to avoid additional event triggers, and/or are on-trigger and only needed at certain times. They work wonderfully for things that, for example, require a multi-step setup process.
[4:00]	Mojito Sorbet:	I jostly use sattes to encapsulate handling of multiple llDialog menus
[4:00]	Scouse Linden:	Having c# would mean that people actually learn a skill that they can use elsewhere
[4:00]	Morgaine Dinova:	That needn't be so though. The handlers could be switched as a single unit into a state through indirection, one atomic bus cycle is enough.
[4:00]	Scouse Linden:	Ok. That's the hour up
[4:00]	Xugu Madison:	I'm going to have to run. Thanks for hosting Scouse, thanks for coming everyone else! I'm going to be off for a bit probably, but will see you all around the weekend I suspect :)
[4:01]	Scouse Linden:	Thanks everyone for coming
[4:01]	Sebastean Steamweaver:	Take care Xugu :)
[4:01]	Imaze Rhiano:	bye
[4:01]	Scouse Linden:	Bye!
[4:01]	Gunter Vandyke:	Thanks and bye
[4:01]	lonetorus Habilis:	scouse, i suppose lsl would keep running anyways, since doing anything else would break content
[4:01]	Sebastean Steamweaver:	I've nothing against C#, don't get me wrong. I look forward to C#
[4:01]	Nock Forager:	bye Scouse
[4:01]	Liandra Ceawlin:	Thanks Scouse! ^_^
[4:01]	Sebastean Steamweaver:	Later Scouse :)