User:Andrew Linden/Office Hours/2008 06 19

Transcript of Andrew Linden's office hours:

[17:01]	Teravus Ousley:	it's the XML format that defines the interface in the client
[17:01]	Strife Onizuka:	oh its the interface
[17:01]	Arawn Spitteler:	Hi, Simon; what's the news on llGetAgentLanguage?
[17:01]	Teravus Ousley:	Hello Simon
[17:01]	Simon Linden:	That's news to me - what is it?
[17:01]	Simon Linden:	Hello everyone
[17:01]	Thomas Shikami:	it's funny what llTextBox sends to the client
[17:02]	Thomas Shikami:	it's actually an llDialog with a single button !!llTextBox!!
[17:02]	Rex Cronon:	hello everybody
[17:02]	Creem Pye:	somebody brought dinner?
[17:02]	Arawn Spitteler:	Is the dialog accepting typed in data?
[17:02]	Teravus Ousley:	Hi Rex
[17:02]	Sindy Tsure:	hi folks
[17:03]	Rex Cronon:	hiii
[17:03]	Arawn Spitteler:	First, we have to toss him into the Blender, to make Butter
[17:03]	Thomas Shikami:	it isn't even implemented yet
[17:03]	Yuu Nakamichi:	hi simon, sindy
[17:03]	Rex Cronon:	what function r u talking about?
[17:03]	Sindy Tsure:	zomg, it's strife! hiya!
[17:03]	Thomas Shikami:	at least, not in the client I compiled myself
[17:03]	Thomas Shikami:	some 1.20.6.0 with a release number I forgot
[17:04]	Simon Linden:	So, Andrew is on vacation today, so I'm the MC
[17:04]	Sindy Tsure:	a coup!
[17:04]	Thomas Shikami:	ohh
[17:05]	Creem Pye:	heh well if you know the dialog's channel, you can always type data into the normal chat bar
[17:05]	Simon Linden:	There are a few bug fixes in the pipeline, but nothing dramatic. Linden Lab has been trying to slow down our simulator releases a little as it was getting a bit too rapid for a while
[17:05]	Thomas Shikami:	or check your script for !!llTextBox!! and then ask again with the legacy input method
[17:05]	Sindy Tsure:	thought i heard last week about a svc bug where phantom vehicles still bump into stuff.. is that coming soon?
[17:06]	Thomas Shikami:	well, doing an llGetAgentLanguage(id) before and you know if the viewer may support text boxes
[17:06]	Teravus Ousley:	well, yay for not having to shut the grid down with a simulator update..
[17:06]	Yuu Nakamichi:	I hope this does not slow the release of mono?
[17:06]	Teravus Ousley:	:D
[17:06]	Simon Linden:	I had one question for everyone ... if you're a land owner, how much do you care about the region slowing down to a low fps if nobody is there?
[17:06]	Simon Linden:	Yuu - no, it doesn'
[17:06]	Simon Linden:	... doesn't affect Mono
[17:06]	Thomas Shikami:	mean, caused by oneself?
[17:07]	Creem Pye:	ah are you talking about load balancing with openspace regions?
[17:07]	Strife Onizuka:	Simon: I don't mind if physics are dropped
[17:07]	Sindy Tsure:	how long would it take to ramp back up to 45 once people arrived?
[17:07]	Arawn Spitteler isn't Everyone: I'm not a landowner.
[17:07]	Strife Onizuka:	I'd mind if my scripts got slower if i were running a vender
[17:07]	Simon Linden:	No, caused by us ... the idea is that we have multiple regions all sharing a box, but we're running the empty ones at 45fps even when nobody is there
[17:08]	Simon Linden:	If we could give up some time in the empty ones, the full ones might perform better
[17:08]	Sindy Tsure:	or a server anyway, strife.. just a vendor that gives stuff would be idle since nobody was there
[17:08]	Thomas Shikami:	ohh, as long as script time stays the same, the sim could go idle
[17:08]	Arawn Spitteler's wondered about the efficiency of that.
[17:08]	Thomas Shikami:	or even, as long as the scripts don't do any comms like http
[17:08]	Sindy Tsure:	so.. this is a 'green sims' project?
[17:08]	Creem Pye:	I wouldn't want script performance to drop to 0 if the scripts handle email or http events, but I could live with a little extra latency
[17:08]	Teravus Ousley:	yeah.. I suppose 'physics' wise.. there would also have to be no physical/active prim
[17:08]	Yuu Nakamichi:	how would you go about implementing this?
[17:08]	Simon Linden:	It's just an idea/experiment at the time ... probably drop an empty sim down to 10 or 20 fps
[17:09]	Thomas Shikami:	are you going to run the sims on virtual appliances in the futue to quickly consolidate empty sims and redistributing them on idle machines when they need power?
[17:09]	Sindy Tsure:	just physics?
[17:09]	Simon Linden:	Yuu - extra sleep time at the end of each frame
[17:09]	Yuu Nakamichi:	hmm
[17:09]	Creem Pye:	extra sleeping could cut down on hosting costs too, rihgt?
[17:10]	Simon Linden:	Possibly it can lower power consumption a bit ... we're not sure how big the effect would be
[17:10]	Rex Cronon:	aren't there sims that run simulations of plant/insect/animal life cycle?
[17:10]	Thomas Shikami:	isn't Xen capable of moving a live virtual machine from one physical machine to another?
[17:10]	Simon Linden:	The immediate goal is more CPU power available for other regions on the same system
[17:11]	Arawn Spitteler:	System or Server?
[17:11]	Simon Linden:	We're not looking at virtualization right now
[17:11]	Thomas Shikami:	okay
[17:11]	Simon Linden:	... same box
[17:11]	Sindy Tsure:	the key would be if the region had people on it?
[17:11]	Thomas Shikami:	Let's do that with open space sims first, I guess
[17:11]	Simon Linden:	Right - if someone TPs or walks in, it would return to normal
[17:11]	Teravus Ousley:	well, it sounds like.. say you've got a class 5 server and there are 4 other sims hosted on it. The empty sims would be slowed down to provide more CPU for the active sims.
[17:11]	Strife Onizuka:	openspaces is the way to go
[17:11]	Creem Pye:	yeah openspace sims would benefit the most from that, probably
[17:12]	Simon Linden:	Yes, OpenSpaces helped point out the problem of one region affecting others on the same computer
[17:12]	Sindy Tsure does not have vendor servers but it seems like that'd be the biggest concern - slowing those down
[17:12]	Strife Onizuka:	We really need some way to detect openspace regions
[17:13]	Yuu Nakamichi:	top-level info, strife?
[17:13]	Simon Linden:	There are some regions we know of that are running simulations that need to run normally, even if nobody is around. Those are the worry
[17:13]	Strife Onizuka:	especially if they are going to slow down
[17:13]	Yuu Nakamichi:	yeah
[17:13]	Simon Linden:	Vendors are probably OK - if nobody's around, I'm not sure what they would be doing
[17:13]	Sindy Tsure:	http://jira.secondlife.com/browse/SVC-1554 or http://jira.secondlife.com/browse/SVC-2431 , strife
[17:13]	Teravus Ousley:	Well, how about an estate flag?
[17:13]	Thomas Shikami:	couldn't that be determined by the amount of physic and communication script calls?
[17:14]	Rex Cronon:	do u think that those peopole would like it when their sims go into slowmo?
[17:14]	Teravus Ousley:	.. or rather an estate tools flag
[17:14]	Teravus Ousley:	.. for the region.
[17:14]	Creem Pye:	well, vendor servers would be used if nobody's in the region (like a "product update server")
[17:14]	Strife Onizuka:	i've commented on both of those proposals Sindy
[17:14]	Sindy Tsure:	oops
[17:14]	Strife Onizuka:	no worries ^^
[17:14]	Teravus Ousley:	I'd be okay with it assuming that it was a configurable option :D
[17:15]	Sindy Tsure:	that doesn't help us mainland dwellers, tho
[17:15]	Thomas Shikami:	I was thinking of getting a mainland parcel just for hosting prims with scripts
[17:15]	Creem Pye:	then group sims according to whether the estate managers enable/disable variable FPS?
[17:16]	Strife Onizuka:	you could consider communications going in and out of a sim as a way of determing if speed stepping is the right thing to do at a moment in time
[17:16]	Simon Linden:	Well, it becomes a "if a tree falls in a virtual forest, should we play the sound" question. If nobody is there, would the lower FPS affect anything?
[17:16]	Creem Pye:	I wonder if going to 15FPS would affect any simulations people run
[17:16]	Simon Linden:	It wouldn't stop, just be a lower frame rate, so communication in and out shouldn't change.
[17:16]	Thomas Shikami:	is the FPS configurable in 1.22.4.89467?
[17:16]	Yuu Nakamichi:	how would it affect vehicles crossing into such a region?
[17:16]	Arawn Spitteler thinks it could be a documented feature.
[17:16]	Creem Pye:	I mean do <70ms timers in LSL actually run that faswt in the first place?
[17:17]	Teravus Ousley thinks there are scripts which detect the fps and do things differently based on them.
[17:17]	Simon Linden:	Not at all ... it's just an idea. I did some experiments today and can slow down the sim by giving up CPU time
[17:17]	Strife Onizuka:	if you lower the FPS but not change the timedilation, you will need to tripple the buffer used to stop interplation
[17:17]	Thomas Shikami:	events in LSL scripts happen at about 22 per second
[17:17]	Simon Linden:	It had one side-effect I have to fix (some of the physics code kicked in and objects lost LOD) but that shouldn't be too hard to adjust
[17:17]	Creem Pye:	object penetration, strife?
[17:18]	Strife Onizuka nods to Creem Pye
[17:18]	Strife Onizuka:	Thomas, that depends on the event, some events are slower then others
[17:18]	Strife Onizuka:	atleast historically they were, i haven't checked it in a while
[17:18]	Simon Linden:	The TD would slow down as well - it would be like a loaded region
[17:18]	Thomas Shikami:	with some experimentation, it was possible to do a full sim scan sweep in 0.9 seconds
[17:18]	Thomas Shikami:	sensors for agents
[17:19]	Strife Onizuka:	i assume that is at ground level only and not the complete volume
[17:19]	Yuu Nakamichi:	so how fast would the region come back up?
[17:19]	Arawn Spitteler:	There wouldn't be any agents to sense.
[17:19]	Thomas Shikami:	complete volume up to 768m
[17:19]	Creem Pye:	how frequently are dynamic objects updated across sim borders usually, Simon?
[17:19]	Strife Onizuka:	the volume goes up to 4096 now
[17:20]	Sindy Tsure:	right away, yuu..
[17:20]	Thomas Shikami:	I know, no flying vehicle zones any more
[17:20]	Simon Linden:	Hmm, that's an interesting point. That update code might be affected
[17:20]	Yuu Nakamichi:	yes, rendering across region borders has been spotty
[17:20]	Simon Linden:	It shouldn't be any different than if you were sitting on one region at 45 fps, and the adjacent one was running at a lower rate. I'm not sure how that looks
[17:20]	Yuu Nakamichi:	as it is
[17:21]	Teravus Ousley still suggests an estate tools checkbox... a new or reuse a regionflags flag.
[17:21]	Thomas Shikami:	so it counts main agents
[17:21]	Sindy Tsure:	you're welcome to come to any of the neighbor sims around my place if you want to see it, simon.. :)
[17:21]	Simon Linden:	Yes, it's certainly something we'd want a switch so it could be turned off
[17:21]	Yuu Nakamichi:	you cannot follow a vehicle's path in an adjacent region reliably , you have to be in the same region to see it update
[17:21]	Thomas Shikami:	so it's an opt-out feature then
[17:21]	Strife Onizuka:	we are running out of region flags fyi, only got one left before we have to reclaim the retired
[17:21]	Yuu Nakamichi:	reasonably quickly
[17:22]	Sindy Tsure:	just make lsl 64-bit.. easy!
[17:22]	Thomas Shikami:	I hope you don't need the MSB
[17:22]	Arawn Spitteler:	32-Bit?
[17:23]	Teravus Ousley shakes head.. it's 'hard' to change the space in the packet.. and would probably break older clients.
[17:23]	Simon Linden:	Well, thanks for the ideas ... as I said, it's just an idea that might help performance of non-empty regions. We spend a lot of CPU time running empty regions
[17:23]	Simon Linden:	So ... any topics or questions?
[17:23]	Sindy Tsure would vote for it, simon.. some people who do the 'evolution' type simulations might get annoyed, tho
[17:23]	Strife Onizuka:	https://jira.secondlife.com/browse/SVC-1773 is reported to be still kicking around
[17:23]	Arawn Spitteler's been fighting Asset Server Issues, in Spirit City, that seem to be simulation specific.
[17:24]	Teravus Ousley:	why the maximum prim in the region gets told to the client through the 'sim stats' packet :P hehe
[17:24]	Simon Linden:	I haven't seen SVC-1773 before - that's a good one. I'll bring that in-house
[17:24]	Thomas Shikami:	my touchable boxes jump around on 1.22.4.89467 and 1.22.4.90000 when touched
[17:24]	Creem Pye:	yeah that's an annoying bug to work around =)
[17:25]	Sindy Tsure:	news on http://jira.secondlife.com/browse/SVC-2485 , Simon? that should be in the next sim update, right?
[17:25]	Strife Onizuka:	over 90000 o_o
[17:25]	Teravus Ousley:	any news on the home grown raycaster that Andrew was talking about previously?
[17:25]	Simon Linden:	That's been fixed Sindy, but I"m not sure of the release pipeline.
[17:26]	Sindy Tsure:	ok
[17:26]	Sindy Tsure hopes it's soon..
[17:26]	Thomas Shikami:	I'm testing the bug
[17:26]	Arawn Spitteler:	Block Grab doesn't effect the entire object, when used in the Root Prim?
[17:26]	Creem Pye:	yes
[17:27]	Thomas Shikami:	I hope SL doesn't crash now
[17:27]	Thomas Shikami:	logged in twice on the same account right now
[17:27]	Arawn Spitteler had to log off, to escape Spirit City
[17:27]	Creem Pye:	and if you try to block grab in a child prim, there is no effect (so you need to delink the object before blocking grab)
[17:28]	Strife Onizuka:	i don't know why the issue has evaded triage
[17:29]	Thomas Shikami:	okay, the bug isn't fixed on 1.22.4.90000
[17:29]	Strife Onizuka:	i try to bump issues with updates every so but sometimes it's hard
[17:30]	Simon Linden:	OK, I got the virtual paperwork done - https://jira.secondlife.com/browse/SVC-1773 is imported and we'll look at it
[17:30]	Teravus Ousley:	:D
[17:30]	Strife Onizuka:	cool ^_^
[17:31]	Creem Pye:	thanks =)
[17:31]	Simon Linden:	Thomas - what does your bug look like? You say the boxes jump when you touch them?
[17:31]	Teravus Ousley:	any other news on the resource management front? resource protection from use by greifers?
[17:32]	Thomas Shikami:	I just tested SVC-1773 on Behtel which is Second Life Beta Server 1.22.4.90000
[17:32]	Thomas Shikami:	Bethel even
[17:32]	Simon Linden:	No Teravus, no news on that
[17:32]	Object: Hello, Avatar!
[17:32]	Thomas Shikami:	wait, I'll test on the new Havok 4
[17:32]	Simon Linden:	I've been working on some TP arrival code ... trying to smooth that out so it doesn't cause a dip in frame rate when someone arrives
[17:32]	Thomas Shikami:	maybe it's fixed there
[17:33]	Teravus Ousley:	cool, that's a big issue on the IOW :D
[17:33]	Teravus Ousley:	course, people are also teleporting in with rather large avatar
[17:34]	Thomas Shikami:	nope, new havok 4 has same bug
[17:34]	Arawn Spitteler:	Attachments are said not to matter
[17:34]	Simon Linden:	It turns out attachments seem to be the biggest slowdown
[17:34]	Simon Linden:	I found parsing the attachment data was the biggest time-user
[17:34]	Thomas Shikami:	it's about the scripts I guess
[17:34]	Simon Linden:	Yes, scripts make it worse
[17:35]	Thomas Shikami:	and with mono, we have 4 times the data for scripts
[17:35]	Sindy Tsure:	slower than showing up naked and then attaching?
[17:35]	Sindy Tsure:	attachment-naked, anyway
[17:35]	Simon Linden:	In general, the more complex the AV and attachments are, the bigger the delay
[17:35]	Arawn Spitteler wonders, if his one prim wagging tail is a good thing, or a bad thing
[17:36]	Creem Pye:	is there a way to give attachment loading a lower priority somehow? so that even if it uses up the same total CPU time, you can spread out the inverted spike in performance?
[17:36]	Simon Linden:	That's probably not too bad, Arawn. One prim with a simple script isn't much
[17:36]	Simon Linden:	That's exactly what I'm trying.
[17:36]	Thomas Shikami:	have a dedicated thread just for object data parsing?
[17:37]	Sindy Tsure always turns on 'show updates' when she asks that question, arawn
[17:37]	Simon Linden:	I have it working now so that instead of getting all attachments at once, it adds one per frame
[17:37]	Strife Onizuka:	there are worse things Arawn
[17:37]	Strife Onizuka:	like sensors
[17:37]	Thomas Shikami:	are sensors really that slow?
[17:37]	Creem Pye:	cool, that should help and be pretty unnoticable too; youo'd get all attachments in under a second
[17:37]	Simon Linden:	Unfortunately, if one is the bottleneck, you still get a dip, so I'm looking at using another CPU thread for the parsing
[17:38]	Teravus Ousley:	well, presumably the sim you're leaving also has to get a message back that the attachments got transferred... before it removes them from it's own memory.
[17:38]	Simon Linden:	I think it's going to mess up vehicles and flying, however
[17:38]	Sindy Tsure:	:(
[17:38]	Thomas Shikami:	I think that data is kept for about 30 seconds anyway
[17:38]	Arawn Spitteler:	We'll b e back to flying, with our heads up our butts?
[17:38]	Simon Linden:	Yes, TP has been a source of loss before, so it needs to be robust
[17:39]	Simon Linden:	Depends if your butt has rezzed or not
[17:39]	Teravus Ousley:	:D great answer :D
[17:39]	Sindy Tsure nods!
[17:39]	Creem Pye:	hmm how would it mess up vehicles? It would spread out vehicle loading to 1 inventory item per frame or something?
[17:39]	Arawn Spitteler:	"Center of Bounding Box"
[17:39]	Thomas Shikami:	something that also causes a loss in attachments is detaching and immediately reattaching the attachment
[17:40]	Simon Linden:	I was thinking about flight assists ... if that gets delayed a little, you'll fall a bit. It may be possible to just delay finishing the TP and adding everything until it's all ready
[17:40]	Thomas Shikami:	wasn't the avatar hovering especially anyways during TP?
[17:41]	Creem Pye:	Andrew was talking about allowing flight at any altitude without a flight assist..
[17:41]	Teravus Ousley:	well not necessarily.
[17:41]	Creem Pye:	so if he did that, you'd have one less thing to worry about
[17:41]	Teravus Ousley frequently jumps over borders so as to ensure that he ends up on top of the prim on the other side.
[17:41]	Simon Linden:	Yes, we'd like to remove the flight limits. There's really no point since there are so many assist objects available
[17:42]	Arawn Spitteler:	Keeps newbies on the ground, until they discover something's there.
[17:42]	Strife Onizuka:	the flight limits are such a pain but i don't really want noobs flying up to my work space
[17:42]	Simon Linden:	Not sure when it might happen, but the code that does the limit is a headache
[17:42]	Teravus Ousley:	hehe.
[17:42]	Thomas Shikami:	what is about the zone where bans are effective, I've seen this still going up 768m above ground only
[17:42]	Creem Pye:	well there's always the option of restricting flight over a parcel, so that only people who know about the ctrl+alt+v trick can fly =P
[17:42]	Sindy Tsure nods - i'm always finding people putting beds on my build floor :\
[17:43]	Rex Cronon:	they just have to sit on a prim, and can get anywhere in the sim very fast
[17:43]	Teravus Ousley nods
[17:43]	Simon Linden:	Ah, pushing the sitting AV? I think that fix is in the pipeline as well
[17:44]	Arawn Spitteler has a teleporter, that blows the 300 meter limit away.
[17:44]	Strife Onizuka:	Sindy: Auto return is your friend :p
[17:44]	Sindy Tsure:	just editing the z position
[17:44]	Simon Linden:	ah, right, that would do it
[17:44]	Rex Cronon:	what do u mean "pushing the sintting av"?
[17:44]	Teravus Ousley:	right, just edinging the position of the prim while you're sitting on it :D
[17:44]	Sindy Tsure:	yepyep, strife.. i keep it at 30 minutes, though.. a little weird when i tp up to build something and there's a party up there.. apparently 30 minutes is enough....
[17:45]	Strife Onizuka:	i had some fun the other day writing a spinning object that then moved the avatar out and unsat them so they would take on the inerta... fun way of throwing people around
[17:45]	Simon Linden:	There was a bug with pushing that was kicking in if the AV was sitting
[17:45]	Rex Cronon:	i have never been able to push somebody that was sitting
[17:46]	Creem Pye:	well, you can pusha a sitting avatar if the chair is physical =)
[17:46]	Simon Linden:	Ah, my bad. It was setting the link postion of a sitting AV
[17:46]	Thomas Shikami:	still working
[17:46]	Sindy Tsure:	oh.. no limits on that now?
[17:46]	Teravus Ousley remembers when OpenSImulator first implemented sit. It broke the chat distance limiter code because the avatar's potion was 0,0,0.. relative to the prim that they're sitting on.
[17:46]	Arawn Spitteler:	Not reliable, to far beyond 1 km
[17:47]	Rex Cronon:	i know u can push a physical sit
[17:47]	Sindy Tsure:	hi ellla
[17:47]	Ellla McMahon:	Hello Simon ... everyone :)
[17:47]	Thomas Shikami:	no limits on 1.22.4.90000 either
[17:47]	Simon Linden:	Hi Ella
[17:47]	Rex Cronon:	hi ella
[17:47]	Arawn Spitteler:	Heh-llo- Ell-Ah
[17:47]	Simon Linden:	Yeah, it's in the release pipeline
[17:48]	Ellla McMahon:	LOL :)))
[17:48]	Teravus Ousley:	Hi Ellla
[17:48]	Strife Onizuka:	hi ellla
[17:48]	Thomas Shikami:	the release pipeline is which sim? Bethel or Island for Unit Tests?
[17:48]	Arawn Spitteler:	So, the fact that we can TP VAst distances, by SLPP is new?
[17:48]	Strife Onizuka:	relatively
[17:48]	Strife Onizuka:	sometime in h4
[17:49]	Arawn Spitteler:	Sure beats sit-target
[17:49]	Simon Linden:	Release pipeline is our internal release process - getting all the code changes together, building it, putting on the beta grid, pushing live, etc
[17:49]	Strife Onizuka:	heck yes
[17:49]	Teravus Ousley repeats SLPP = SetLinkPrimitiveParams.
[17:49]	Strife Onizuka:	i wrote a script the other day that doesn't use sit targets at all
[17:49]	Strife Onizuka:	scans the link set on sit changes
[17:49]	Simon Linden:	I'm not sure it's new or not, but it needed some limits (like the max link distance)
[17:49]	Arawn Spitteler:	llSetLinkPrimitiveParams(integer, list)
[17:49]	Teravus Ousley:	:D
[17:50]	Sindy Tsure:	you still get a changed() if llSitTarget hasn't been called?
[17:50]	Thomas Shikami:	a working limit would be a 600x600x600 box
[17:50]	Arawn Spitteler:	I use Sit Targets, still, because my TPs are Phantom, to save the physics engine, but otherwise unneeded.
[17:50]	Thomas Shikami:	with the prim in the center
[17:50]	Creem Pye:	I don't think you'd want to move an avatar acdross 2 sim borders in 1 step, either
[17:50]	Object: Hello, Avatar!
[17:51]	Teravus Ousley:	haha, I've done it.
[17:51]	Strife Onizuka:	definately needs a limit to about 4200 for the magnitude
[17:51]	Simon Linden:	The current code can put you way out in no-where
[17:51]	Teravus Ousley:	It's 3 where it gets 'really hairy'
[17:51]	Creem Pye:	I've done that across a single sim border, and the trip was a bit rough ;)
[17:51]	Simon Linden:	The new code has a limit of the max link distance, which I think is 54m
[17:51]	Strife Onizuka:	(4128 is about magnitude of <256,256,4096>
[17:51]	Arawn Spitteler sees no problme, in multiple sim crossings: Think what it could do, when there's a gap in the railroad
[17:51]	Thomas Shikami:	enough for the poseball less furniture
[17:51]	Strife Onizuka:	that sucks Simon
[17:51]	Strife Onizuka:	thats worse then a sit target
[17:52]	Strife Onizuka:	which is 300 on each axis
[17:52]	Thomas Shikami:	and the limit works on unlinked prims?
[17:52]	Teravus Ousley:	warpPos
[17:52]	Teravus Ousley:	:D
[17:52]	Rex Cronon:	only 54m, that is going to break some things
[17:52]	Arawn Spitteler:	WarpPos would involve rezzing a new prim, for each person teleported
[17:52]	Thomas Shikami:	no furniture is more than 54m
[17:52]	Strife Onizuka glowers "i'm sorry but warpPos doesn't seem like a good use of sim resources"
[17:53]	Thomas Shikami:	I have a warpPos teleporter that doesn't rez a new prim
[17:53]	Strife Onizuka:	but you can only TP one person at a time Thomas if you dont' rez new prims
[17:53]	Teravus Ousley:	agreed, but.. alas, it's the only option provided..
[17:53]	Thomas Shikami:	yes, but that's same with those other teleporters, too, that rez prims
[17:53]	Strife Onizuka:	and warpPos is a hack in it's own right
[17:54]	Thomas Shikami:	a "supported" hack
[17:54]	Strife Onizuka:	a misfeature
[17:54]	Teravus Ousley recalls the outcry when it was limited :D
[17:54]	Arawn Spitteler:	WarpPos is an established hack. Limiting our new tp distance is going to hurt Spirit City.
[17:54]	Thomas Shikami:	and my things then quickly worked again, with a fall back method
[17:55]	Strife Onizuka grumbles "have to repeatedly hit LL over the head to get them to unbreak things when it comes to LSL"
[17:55]	Simon Linden:	The thought was to limit the link position to the link size limit. As with every change, it seems to break things
[17:55]	Strife Onizuka:	If there were a way to reliably TP avatars there wouldn't be this problem
[17:55]	Arawn Spitteler:	I don't see any problem, with the current lack of limits, unless we try to remain linked.
[17:55]	Teravus Ousley:	that is true.
[17:55]	Rex Cronon:	so simon, it isn't going to be possible to move sitting avatars further than 54m, using llSetPrimitiveParams?
[17:56]	Strife Onizuka:	the problem with the current lack of limits is you can orbit people
[17:56]	Strife Onizuka:	get them stuck at 100000 meters
[17:56]	Simon Linden:	It can be used for griefing, putting someone up at really, really far distances
[17:56]	Strife Onizuka:	(was that the right number of zeros?)
[17:56]	Thomas Shikami:	2 billion
[17:56]	Simon Linden:	Something like that distance - far away, very drak
[17:56]	Simon Linden:	dark
[17:56]	Arawn Spitteler:	I don't think it works that far, but breaks down between a km and a mile
[17:56]	Sindy Tsure:	how common is that really, tho? has to be far less than the old orbit crap..
[17:57]	Strife Onizuka:	it's not 2 billion, it's a 1 followed by several zeros
[17:57]	Rex Cronon:	simon, that happens only if somebody sits on something
[17:57]	Strife Onizuka:	and you cannot tp down
[17:57]	Thomas Shikami:	depends on the script
[17:57]	Strife Onizuka:	haven't seen the two billion version then
[17:57]	Creem Pye:	Well Strife, a few meetings ago Andrew asked about adding a "teleport avatar" function for estate managers to be able to teleport agents around an estate. But that proposal had a mixed reaction
[17:57]	Arawn Spitteler:	When it's broken for me, I used my map
[17:57]	Simon Linden:	So what distances are being used now? Would the sim size be viable?
[17:58]	Arawn Spitteler:	An estate might have multiple sims, such as Mystical Mastery
[17:58]	Strife Onizuka:	sim size would be totally viable
[17:58]	Thomas Shikami:	I stay with my non-rezzing warpPos version. I see no disadvantages from the rezzing teleporters
[17:58]	Strife Onizuka:	multiple customers Thomas
[17:58]	Thomas Shikami:	it has even less limits than most rezzing teleporters
[17:59]	Arawn Spitteler:	Spirit City has stuff as high as 700+, that should be reacheable
[17:59]	Thomas Shikami:	it handles multiple customers better than the rezzing ones
[17:59]	Simon Linden:	I'll point out that the limit may cause problems for stuff like warpPos. No promises on what we'll do, but it's good to learn what it might break
[17:59]	Strife Onizuka nods
[17:59]	Rex Cronon:	.
[17:59]	Strife Onizuka:	it would be benificial if there were a jira or a wiki page discussing the changes
[17:59]	Sindy Tsure:	seconded
[17:59]	Arawn Spitteler:	I don't think TPAgent is a bad function to have, but there's fear of griefing. 54 meters, is enough to grief a person.
[17:59]	Rex Cronon:	did somebody requres this simon?
[18:00]	Thomas Shikami:	you sit on it, a dialog opens with destinations and when pushing the button, you are at the destination
[18:00]	Rex Cronon:	request*
[18:00]	Teravus Ousley:	well, we could institute a teleport permission, like animation permission.
[18:00]	Teravus Ousley:	.. that would be useful....
[18:00]	Thomas Shikami:	how about the permissions being similar to llMapDestination
[18:00]	Sindy Tsure:	i'd still be nervous if there wasn't a way to revoke that permission...
[18:00]	Strife Onizuka:	Thomas, unless you are on mono you cannot tp the entire sim distance in a single llSetPrimitiveParams call
[18:00]	Simon Linden:	I'm not sure of how it was reported ... the example as shown was pretty ugly, so it seemed like some limits made sense. Keeping it unbounded isn't good
[18:01]	Thomas Shikami:	well, 1km in one call, so you can go 4km in a second
[18:01]	Arawn Spitteler:	Was it a Jira?
[18:01]	Strife Onizuka:	How about something that replaces sitting option on the object and when you click it the object can TP you?
[18:02]	Rex Cronon:	so when is this going to happen?
[18:02]	Arawn Spitteler:	TP is already the Sitting Option, unless you mean Map-TP
[18:02]	Teravus Ousley:	well, the tp would remove the permission, and it would have to ask you again.
[18:02]	Rex Cronon:	did it already happen?
[18:02]	Thomas Shikami:	llTeleportDestination(vector pos, vector lookat); llSetClickAction(CLICK_TELEPORT);
[18:02]	Creem Pye:	I guess you could still grief that way if there's an option for left-clicking on the object to cause a TP
[18:02]	Simon Linden:	Yes, really the right solution is some functionality that could offer a TP and have all the right permission checks so it can be useful but not abused
[18:02]	Teravus Ousley:	.. if it were going to try to tp you again. If you can grid wide teleport an avatar.. would you need to do it twice?
[18:02]	Thomas Shikami:	that'd replace the llSitTarget things
[18:02]	Strife Onizuka:	Exactly Thomas
[18:03]	Thomas Shikami:	and it would teleport the agent within the same sim only
[18:03]	Simon Linden:	Yes, llSitTarget and prim position is really for putting the AV in the right spot on some object
[18:03]	Strife Onizuka nods
[18:04]	Strife Onizuka:	the sittarget to postion calculation is ugly (having written the wiki code for faking sittarget updating)
[18:04]	Thomas Shikami:	like llSitTarget with sim local position and limits <0,0,0> to <256,256,4096>
[18:04]	Simon Linden:	Time is pretty much up ... any last quick questions or bug reports?
[18:04]	Thomas Shikami:	could be implemented like llSitTarget, so no client update needed
[18:04]	Arawn Spitteler:	We can't put the avatar on hte correct target, because we don't have the appropriate functions.
[18:04]	Sindy Tsure:	with permission that lasts forever or just one tp?
[18:04]	Strife Onizuka:	Mind if I make a Jira for it Thomas?
[18:04]	Simon Linden:	Yeah, the devil's in the details
[18:04]	Thomas Shikami:	well, think it through before
[18:04]	Teravus Ousley:	I'd be happy with just one teleport per permisison question
[18:05]	Thomas Shikami:	llTeleportTarget(vector pos, vector lookat) is just an idea
[18:05]	Strife Onizuka nods
[18:05]	Teravus Ousley:	.. If I can get an avater anywhere in the grid where they are allowed, then I'd be happy with a single teleport per permission
[18:05]	Sindy Tsure:	me too, teravus.. unless people then use it as a spam vector
[18:05]	Simon Linden:	Opening a jira and gathering ideas and notes on where problems lie is the way to go
[18:06]	Sindy Tsure:	or a forums thread.. :)
[18:06]	Thomas Shikami:	and for compatibility with old viewers, it would be handled like sitting on the object
[18:06]	Rex Cronon:	so, do i have to spam myself with dialog boxes when i move around the sim?
[18:06]	Simon Linden:	"SuperGizmo wants to teleport you to <someplace>. Is this OK?"
[18:06]	Arawn Spitteler:	I've been wondering, why my TPs were unknown. But something will still be needed for spread out etates.
[18:06]	Thomas Shikami:	including needed timers to stop the goto effect
[18:06]	Creem Pye:	yeah, telling the teleport destination would be a good feature for the permission dialog
[18:07]	Teravus Ousley:	right. it can use setpos or warppos or whatever in the same simulator.
[18:07]	Creem Pye:	especially if it were to include inter-sim teleporting
[18:07]	Teravus Ousley:	.. or it can just tp you to the correct place
[18:07]	Teravus Ousley:	no need to move it after that.
[18:07]	Thomas Shikami:	current in-sim teleporters work without permission dialog, so why add a nuisance?
[18:07]	Simon Linden:	OK, I have to run ... thanks everyone for coming and the good feedback and ideas [18:07] Strife Onizuka: HThomas would it be easier if lookat were a direction instead of a postion?
[18:07]	Sindy Tsure:	cya, simon. ty!!
[18:07]	Strife Onizuka:	take care Simon
[18:07]	Strife Onizuka:	thanks for updating us
[18:07]	Creem Pye:	thanks for your time
[18:07]	Rex Cronon:	bye
[18:07]	Teravus Ousley:	lookat is a normal
[18:07]	Arawn Spitteler:	WarpPos is just a chair, not even Physical, but SLPP is just convenient. It's the forced TP, that should need perms
[18:07]	Sindy Tsure runs, too.. bye, all!
[18:07]	Simon Linden:	Bye everyone ... see you next time
[18:08]	Rex Cronon:	bye sindy
[18:08]	Teravus Ousley:	take care