User:Andrew Linden/Office Hours/2008 01 08

Transcript of Andrew Linden's office hours:

[11:01]	Kitto Flora:	Hi Andrew
[11:02]	Andrew Linden:	hello kitto
[11:02]	Kitto Flora:	Stuck?
[11:02]	Andrew Linden:	hrm... are scripts running?
[11:02]	Kitto Flora:	Should be
[11:02]	Kitto Flora:	missing position packet?
[11:02]	Andrew Linden:	yeah, probably
[11:03]	Anders Falworth:	Hi.
[11:03]	Kitto Flora:	When will SL be rid of RTSP?
[11:03]	Andrew Linden:	Hello Anders
[11:03]	Arawn Spitteler:	Hi Anders; what's RTSP?
[11:03]	Andrew Linden:	RTSP? Please expand that acronym.
[11:03]	Kitto Flora:	Real Time Streaming Protocol
[11:03]	Andrew Linden:	Uh... you're joking,right?
[11:04]	Kitto Flora:	A system for sending fast but insecure packets over IP
[11:04]	Andrew Linden:	The position updates still go via UDP
[11:05]	Andrew Linden:	however positions of static objects... should be semi-reliable. In any case, it is all managed by our interestlist system, which needs work.
[11:05]	Kitto Flora:	Ah.. so.. when will we escape Datagrams?
[11:05]	Andrew Linden:	"object transport" is the project that will be dealing with those types of bugs
[11:06]	Kitto Flora:	We need Transport Of Delight :)
[11:06]	Andrew Linden:	it is a long-term project that will probably be delivered in chunks, and may be in-progress-and-partially-delivered for a year or more.
[11:06]	Andrew Linden:	dunno, it hasn't started yet
[11:07]	Kitto Flora:	I Think they already improved some of it.
[11:07]	Arawn Spitteler:	What's Transport of Delight? I know that Mr. Spock denies the possibility of The Happiness Pill
[11:07]	Kitto Flora:	Title of an old song
[11:08]	Andrew Linden:	Oh, the happiness pill is definitely a possibility.
[11:08]	Ryozu Yamamoto:	Woosh, lost track of time
[11:08]	Andrew Linden:	An eventuality, actually -- ten years off.
[11:08]	Ryozu Yamamoto:	Hey! Simon is here!
[11:09]	Simon Linden:	hi people
[11:09]	Andrew Linden:	Here's a quick summary of where the Havok4 project is at:
[11:09]	Sidewinder Linden:	hi simon
[11:09]	Kitto Flora:	Hi Sidewinder, Simon...
[11:09]	Sidewinder Linden:	hiya kitto
[11:09]	Andrew Linden:	There is an updated preview version that is currently in QA (Quality Assurance)
[11:10]	Andrew Linden:	I think this is the same update that I discussed last week, that was not delivered
[11:10]	Andrew Linden:	with a few new bugs fixed, since it has taken us a few QA iterations
[11:10]	Wind Key 2 ~ GAMBIT: BAM~!
[11:10]	Andrew Linden:	One of the bugs fixed is the one Ryozu was complaining about... "landing" animation defeating attachment forces
[11:10]	Rex Cronon:	hello everybody
[11:11]	Andrew Linden:	I forget the SVC# for it
[11:11]	Ryozu Yamamoto:	Sweet, thank you Andrew!
[11:11]	Sidewinder Linden:	/hi rex, redux
[11:11]	Andrew Linden:	lemme bring up the latest list of bugs fixed...
[11:11]	Andrew Linden:	SVC-1048 is the one I'm thinking of
[11:12]	Andrew Linden:	I haven't marked it as fixed in the public jira because last time I tried to login there it failed
[11:12]	Andrew Linden:	I'll try to update the pjira items later today
[11:13]	Andrew Linden:	perhaps also fixed, is one of the bugs bothering Kitto... SVC-1093 -- hollow objects getting returned for center too far underground
[11:13]	Kitto Flora:	Great :)
[11:14]	Andrew Linden:	Ok, I'll just list off a few other pjira #'s: SVC-102, SVC-1124, SVC-1120, SVC-1121, SVC-1071
[11:15]	Andrew Linden:	Perhaps a few of you will see some favorites in there. I've only fixed one vehicle bug... one to do with vehicles not turning when they are supposed to
[11:15]	Andrew Linden:	in particular the bug was to do with hover craft using banking, but it may also fix a few others
[11:16]	Andrew Linden:	I think we're going to try to update the preview today. Sidewinder, do you want to add anything?
[11:16]	Sidewinder Linden:	with this update, we have a build that addresses a lot of issues for non-vehicle regions, and it seems that we still have not found many new crash modes
[11:17]	Sidewinder Linden:	we've got a list of about 25 regions that would like to run havok4 on the main seconf life system as early adopters, and they'll get deployed after checking this build on the beta preview
[11:17]	Sidewinder Linden:	if that goes well, i'll be looking for a larger round of early adopter folks, including places like clubs and performance areas (we have a couple of those who are probably ready to go with this build)
[11:18]	Andrew Linden:	I think I'm going to shut up about Havok4 crash modes... there are several we know about an cannot fix atm -- they are not necessarily related to Havok4 and will be fixed in other projeccts.
[11:18]	Sidewinder Linden:	the blocker for them was an "avatar levitation bug" where avatars would spontaneously levitate
[11:18]	Sidewinder Linden:	hehe yup - there are still ways... but fairly few and far between
[11:19]	Sidewinder Linden:	we did have a combat crew test on the beta over the holidays and they were really happy with the results
[11:19]	Rex Cronon:	doesn't levitation usually happens when u r inside a prim?
[11:19]	Sidewinder Linden:	yes - under high load, but there have been a couple of changes that will helpwith that
[11:20]	Sidewinder Linden:	simon put in an enhancement so that only smaller prims will get simplified when physics is highly loaded, so that most prims you would be "in" would not show that behavior
[11:20]	Sidewinder Linden:	and
[11:20]	Sidewinder Linden:	there was a bug taht affected flat platforms that got resolved
[11:20]	Ryozu Yamamoto:	Nice compromise
[11:20]	Sidewinder Linden:	so in the near term we'll be updating the beta preview, and by the way reloading and refreshing the database on the beta, so that all inventories and user accounts will be brought up to date
[11:21]	Sidewinder Linden:	andrew and simon - have you heard whether our wednesday downtime is still on? last i'd heard it was...
[11:22]	Simon Linden:	I think it is, haven't heard any news otherwise
[11:22]	Sidewinder Linden:	ok
[11:22]	Andrew Linden:	I think it is still on, since it has to do with some relative emergency of the asset system
[11:22]	Sidewinder Linden:	so...just so you all know, we'll have some pretty significant downtime on wednesday, and both the main system and the beta preview will be offline
[11:22]	Rex Cronon:	there is something weird going on, each time i tp to a different sim i crash bad:(
[11:22]	Sidewinder Linden:	i think it is scheduled for 6am pst - 3pm pst iirc
[11:22]	Andrew Linden:	btw, all portions of the SL Grid will probably be down on Wednesday
[11:22]	Arawn Spitteler has been having trouble saving scripts, so hopes that to be the emergency in question
[11:23]	Andrew Linden:	that is, SL proper and any previews
[11:23]	Sidewinder Linden:	a large part of this downtime is to add capacity to the asset storage system, which has been near the edge lately
[11:24]	Kitto Flora:	Its the usual, for Wednesday work
[11:24]	Sidewinder Linden:	there are some other database issues being taken care of so hopefully things will be better afterwards
[11:24]	Sidewinder Linden:	heh
[11:24]	Rex Cronon:	btw, when will it be possible to create megaprims, using the gui?
[11:24]	Arawn Spitteler will have to talk to Zero, about the Asset Storage System having to go down for expansion services.
[11:24]	Kitto Flora:	Yes, script save, notecard save, object take and delete - all been a bit shaky at times
[11:24]	Sidewinder Linden:	@arawn - can talk offline about that
[11:25]	Andrew Linden:	actually, this downtime is somewhat unusual -- I don't think it is an update to any server/client software
[11:25]	Sidewinder Linden:	it's an ops/hardware issue
[11:25]	Kitto Flora:	The outage from the user POV is the same :)
[11:25]	Sidewinder Linden:	yes
[11:26]	Andrew Linden:	Rex, megaprims will not be supported in the ui until we fix the "encroachment problem" -- unwanted prims overlapping onto parcels from neighboring parcels
[11:26]	Rex Cronon:	that might take a few months
[11:26]	Kitto Flora:	Make it 15 yds and 1st down.
[11:27]	Andrew Linden:	Yes, and it won't start until Havok4 is "done".
[11:27]	Rex Cronon:	i hope u can do it with scripts?
[11:27]	Sidewinder Linden:	that's all i had...
[11:27]	Andrew Linden:	When megaprim liberation happens, scripts and ui will work.
[11:28]	Andrew Linden:	Ok, I don't have any other announcements. I'm just going to be working on vehicle bugs this week
[11:28]	Andrew Linden:	so hopefully we'll have something with more working vehicles next week
[11:28]	Arawn Spitteler hopes for Curved Track, with radius greater than 5 meters
[11:28]	Sidewinder Linden:	what is that issue about arawn?
[11:29]	Kitto Flora:	Mmm - I need a megaprim editor for that
[11:29]	Rex Cronon:	but, u can't really test havok4 until u can create/edit megaprims, using the ui and scripts
[11:29]	Andrew Linden:	"cant' really test havok4"... until megaprims?
[11:29]	Arawn Spitteler:	SL Railways are using straight tracks, end to end, with slight changes in direction
[11:30]	Rex Cronon:	some special case might rise when using the ui to create megaprims
[11:30]	Sidewinder Linden:	true but that is hardly "can't test havok4"... that would be a new feature set, one that might raise some new bugs...
[11:30]	Andrew Linden:	Well, full megaprim support and testing will just have to wait.
[11:30]	Rex Cronon:	i said "can't really"
[11:31]	Sidewinder Linden:	ok :)
[11:31]	Seifert Surface:	can test all the non megaprims stuff just fine
[11:31]	Sidewinder Linden:	has anyone seen any new construction or linkage problems in the last few weeks?
[11:31]	Ryozu Yamamoto:	Ah, yeah
[11:31]	Sidewinder Linden:	it seems that most of those issues are behind us - i just wanted to be sure that there aren't things out there that you've forgotten to log or something like that...
[11:31]	Andrew Linden:	I think I mentioned it already, but I've finished the mass-properties utilities so those should be in use in the next update
[11:31]	Ryozu Yamamoto:	Bounding boxes aren't being updated correctly
[11:32]	Ryozu Yamamoto:	The end result are items that appear to be partial phantom/non-phantom
[11:32]	Arawn Spitteler thinks it's probably old news to those here: My Teeter Totter is acting in ways I haven't seen documentation for, And my blasting cup tends to show a lagging sit position
[11:32]	Andrew Linden:	the main noticable result of the new mass properties code is that attachments should have the correct mass -- same as when dropped in-world
[11:33]	Seifert Surface:	do avatars get the mass of their av + attachments?
[11:33]	Ryozu Yamamoto:	Andrew: Does this mean scripts inside attachments will not be able to detect the mass of the avatar it's attached to using llGetMass?
[11:33]	Andrew Linden:	"bounding boxes aren't being updated"...
[11:33]	Rex Cronon:	so, if u have a megaprim attached, u should be super heavy?
[11:33]	Andrew Linden:	No, avatars do not yet pick up the mass of their attachments.
[11:33]	Andrew Linden:	I'm sure stuff would break if they did.
[11:33]	Ryozu Yamamoto:	Historically, llGetMass() in an attachment returned the mass of the avatar
[11:34]	Redux Decosta:	or zero =x
[11:34]	Andrew Linden:	Should avatar mass increase by their attachments?
[11:34]	Ryozu Yamamoto:	I've never seen it return 0 O_o
[11:34]	Redux Decosta:	or llFrand(llFrand(llFrand(PI)))
[11:34]	Ryozu Yamamoto smacks Redux.
[11:34]	Redux Decosta:	ive seen some really nutty results depending on if the script is attached when compiled
[11:34]	Seifert Surface:	would bring a whole new meaning to the relationship between weight and attractiveness
[11:34]	Seifert Surface:	all those massive prim hair attachments
[11:34]	Rex Cronon:	if u carry a heavy packet in rl, don't u get heavier?
[11:35]	Andrew Linden:	Hrm... you may be right about llGetMas(), however the attachment mass still affects the object's "script energy" which affects certain operations.
[11:35]	Seifert Surface:	i doubt it would make sense to add the attachment weights, furries arent supposed to be heavier than humans
[11:35]	Ryozu Yamamoto:	So Andrew, Attachments will no longer have unlimited energy?
[11:35]	Arawn Spitteler:	So, a larger volume would get more energy, without effecting mass?
[11:35]	Andrew Linden:	Did they have unlimited energy?
[11:35]	Ryozu Yamamoto:	They did
[11:35]	Rex Cronon:	how about an elephant, seifert:)
[11:36]	Andrew Linden:	Ryozu, do you mean in Havok4 only? or both Havok1 and Havok4?
[11:36]	Ryozu Yamamoto:	In Havok
[11:36]	Ryozu Yamamoto:	Err, Havok1
[11:36]	Andrew Linden:	No, they didn't have unlimited energy in Havok1. There was a bug about that...
[11:36]	Andrew Linden:	a guy had a push-gun that would change its size to pick up more energy
[11:37]	Andrew Linden:	but the size change wasn't providing it with more energy
[11:37]	Ryozu Yamamoto:	I've seen that before
[11:37]	Seifert Surface:	ok, so perhaps "correct" would be to deal with intersections of prims and avatars correctly when working out the volume of the avatar
[11:37]	Ryozu Yamamoto:	the MultiGadget uses a prim that changes size to get more energy
[11:37]	Seifert Surface:	but, far too much work for the benefit
[11:37]	Andrew Linden:	unless someone else "fixed" the bug by giving attachments unlimited energy in Havok1 -- I haven't heard about such a thing, but it could have gone in
[11:37]	Ryozu Yamamoto:	However, I've never once run out of energy with an attachment
[11:38]	Redux Decosta:	same; i've done some pretty heavy pushing with an attachment i built a while ago that i use to drag people around when i give newbies sim tours
[11:38]	Ryozu Yamamoto:	When I originally developed the OmniPhaze, I ran into some issues unrelated to energy, and started testing energy use: I never drop below 0.999
[11:38]	Redux Decosta:	i'd like to interject; i'm in favor of unlimited energy on attachments, it has a LOT of beneficial uses & not a lot of grief potential
[11:38]	Andrew Linden:	hrm... well perhaps that attachment-mass change will not be noticable after all.
[11:38]	Ryozu Yamamoto:	Actually, I'm only posturing that I'd even seen .9999
[11:38]	Kitto Flora:	Is there at present a calculation for the bounding box for an Avatar+attachments? Does that box change with attachment size? If so could one calculate a resonable Av+Attachment mass from that box volume?
[11:38]	Ryozu Yamamoto:	I don't remember ever seeing it drop below 1
[11:38]	Andrew Linden:	No, the collision shape of the avatar is not affected by attachments
[11:39]	Ryozu Yamamoto:	Anyways, Modifying child prims in an object isn't updating it's bounding box
[11:39]	Andrew Linden:	As I recall... rezzing a bullet takes energy, and a bullet with velocity takes more
[11:39]	Andrew Linden:	so attached guns should be limited by script energy
[11:40]	Andrew Linden:	that would be a simple way to test whether attachments have an energy limit, in any case
[11:40]	Ryozu Yamamoto:	If you take two spheres, make one sphere max cut, dimple, 10x10x10 in size, and link it as a child prim to another sphere, 1x1x1
[11:40]	Ryozu Yamamoto:	Then after linked, undo the cut and dimple on the big sphere
[11:40]	Ryozu Yamamoto:	You can walk into the large sphere, but bump into the small sphere
[11:41]	Andrew Linden:	Ryozu, this is a Havok4 bug you're decribing?
[11:41]	Ryozu Yamamoto:	When set to physical, it roll around as if partially phantom and physical
[11:41]	Ryozu Yamamoto:	Yes, Havok4
[11:41]	Andrew Linden:	Ok. Yes, sounds like a bug.
[11:41]	Rex Cronon:	wow, that is kind a weird, why should a bullet take energy from a gun?
[11:41]	Ryozu Yamamoto:	Dimple, Cut, Twist, etc: None of these changing are updating the collision surfaces/boundibg box/whatever it's called
[11:41]	Ryozu Yamamoto:	Only size is
[11:42]	Ryozu Yamamoto:	Rex: The idea was to limit the amount of bullets and the velocity they could be given
[11:42]	Andrew Linden:	The original logic for the script energy budget... it was mostly a sort of throttle on the "activity" that a script could have
[11:42]	Redux Decosta:	*coughcough* disposable bullet casing *coughcough*
[11:43]	Ryozu Yamamoto:	However, I'm 99% sure there's unlimited energy, and thus, you can push out as many bullets as you feel like, whatever size you feel, at max int velocity
[11:43]	Andrew Linden:	we were worried about goo objects flooding the world in a few seconds
[11:43]	Rex Cronon:	is still possible to do that
[11:43]	Andrew Linden:	however, that done long before parcels existed, or parcel permissions
[11:43]	Redux Decosta:	llRezObject("Bullet Casing That Launches A Bullet And Dies", llGetPos(), ZERO_VECTOR, llGetRot(), 42);
[11:43]	Redux Decosta:	*coughcoug*
[11:43]	Arawn Spitteler:	Was that Proior to the Grey Goo Fence?
[11:43]	Ryozu Yamamoto:	I can throw 30 physical 10x10x10 prims into a gun and shoot them at max velocity, using multiple rez scripts
[11:44]	Ryozu Yamamoto:	1 compound unlinked item of 30 prims in Havok1, More in Havok4
[11:44]	Andrew Linden:	hrm... the script energy is actually tied to the object, so in theory all scripts on the object tap into the same pool
[11:44]	Ryozu Yamamoto:	Right
[11:45]	Ryozu Yamamoto:	It's just that attachments never run out of energy
[11:45]	Andrew Linden:	I've only tested the energy consumption of the Hover action in Havok4
[11:45]	Andrew Linden:	ok Ryozu, I'll double check to see if that is the case. If there is an exception for attachments then it should show up in the code.
[11:45]	Ryozu Yamamoto:	I want to bring up avatar velocity limits if we have time, since Simon is here and I never got around to IMing him
[11:46]	Andrew Linden:	currently there is a pretty hard speed limit of 64 m/sec, right?
[11:46]	Ryozu Yamamoto:	For avatars in "Flight" mode
[11:46]	Andrew Linden:	er... that's for flying avatars, right
[11:46]	Ryozu Yamamoto:	128m/sec for non-flying
[11:46]	Andrew Linden:	128 for non-flying?
[11:47]	Redux Decosta:	*nods* i've verified that as well
[11:47]	Simon Linden:	yeah, it doesn't make sense but I think it's there because older objects are used to push the AV around
[11:47]	Ryozu Yamamoto:	I've talked to a lot of people about it. No one can agree on how high the limits should be, but everyone agrees that A) Having flying limit lower than walking limit seems strange and B) The limits are too low
[11:48]	Ryozu Yamamoto:	Everyone is used to, and expects the Havok1 behavior of seemingly unlimited avatar velocity
[11:48]	Ryozu Yamamoto:	While I don't agree it should be unlimited, I do think the current limits are arbitrarily low
[11:49]	Andrew Linden:	absolute unbounded avatar velocity is out of the question. There must be some limit lower than MAX_FLOAT
[11:49]	Simon Linden:	FWIW 64 m/s is 230km/hour
[11:49]	Ryozu Yamamoto:	I think bare minimum should be 250m/sec
[11:49]	Ryozu Yamamoto:	I appreciate the toss back to realism and all, but this isn't air I'm breathing ;)
[11:49]	Simon Linden:	900 km/hour?
[11:49]	Sidewinder Linden wonders if realism has a place in the discussion
[11:49]	Sidewinder Linden:	;)
[11:49]	Rex Cronon:	if i attach a jetpack i should be able to fly at leat at half the speed of sound
[11:50]	Sidewinder Linden:	what was the reasoning for low limits on this? are we trying to prevent some sort of bad behavior, or was it just the "realism" factor?
[11:50]	Ryozu Yamamoto:	I just know that a lot of people think the current limit is too slow
[11:50]	Rex Cronon:	ok, a quarter at least
[11:50]	Simon Linden:	I'm worried most about region crossings at that speed - it's going to get ugly fast
[11:50]	Sidewinder Linden:	uglier than h1?
[11:50]	Redux Decosta:	what it really boils down to for me at least isnt how many km/s someone's moving; a lot of us have no-clip tools to get out of objects we get stuck in... like if we wind up in a building with no doors. 64m/s disables them, so either we would need a way to engage no-clipping with a script, or we need a way to pop through a wall.
[11:50]	Ryozu Yamamoto:	That, I agree with, the region crossing issue.. however
[11:50]	Andrew Linden:	I think part of the reasoning was how fast an avatar could fly over a region and enter another one... region crossings per second
[11:51]	Ryozu Yamamoto:	Hard avatar movement limits aren't a good answer
[11:51]	Seifert Surface:	does anyone need sustained huge velocities, or is it mostly about jumping through walls?
[11:51]	Ryozu Yamamoto:	This is all bypassed by vehicles
[11:51]	Rex Cronon:	i want to go 1km high in less than 1 sec
[11:51]	Ryozu Yamamoto:	Seifert: Vertical sustained velocity for travelign to skyboxes
[11:51]	Andrew Linden:	since region crossings take some time, there is some max speed imposed by region crossings
[11:51]	Sidewinder Linden:	i would come back to the question - is the problem worse in havok4 than havok1, and if not, why not allow the havok1 limits?
[11:51]	Redux Decosta:	seifert: i have some relocation stuff that allows me to zip around my blocks of sims without teleporting using movement stuff. i find it to be much faster than teleporting in many cases and when TPs go down it allows for quick relocation
[11:51]	Ryozu Yamamoto:	It's not a physics engine issue, region crossings that is.
[11:52]	Sidewinder Linden:	understood ryozu
[11:52]	Ryozu Yamamoto:	Region crossing issues are purely a data serialization issue
[11:52]	Sidewinder Linden:	that's why i'm wondering why we are adding these limits as part of this project...?
[11:52]	Ryozu Yamamoto:	The sims serialize data in a poor manner before transfering it to another sim
[11:52]	Sidewinder Linden:	and if the behavior is no worse than with an h1 sim...
[11:52]	Sidewinder Linden:	and people are used to the side effects and bad behavior there, but find benefits from the high speeds
[11:52]	Sidewinder Linden:	why not leave it?
[11:52]	Ryozu Yamamoto:	Also considering, I'm hoping at some point sims can start breaking the 256x256 size limit ;)
[11:53]	Simon Linden:	Ryozu - yeah, that would be nice
[11:53]	Sidewinder Linden:	at some point, the region crossing issue may get some serious work, relieving a lot of this outside any specific physics engine version.
[11:53]	Ryozu Yamamoto:	That said, I believe a good answer would be to reset avatar velocity to 0, and cancel any current physics effects on them after a sim crossing
[11:53]	Redux Decosta:	any way we can just have people hit a uhh... speedbump when they get within 5 meters of the sim border?
[11:54]	Sidewinder Linden:	hmm maybe not if they're going too fast :)
[11:54]	Andrew Linden:	One of the reasons I put the soft 128 speed limit, hard 256, was that the way the new avatar control code works... if you start going that fast using attachments you get an oscillating speed as the objects push with varying success against a very steep damping curve
[11:54]	Simon Linden:	I don't really care about the limits, so if there's a consensus we can change them. However, the motivation was to change the h1 'acts bad' to something that acted better
[11:54]	Rex Cronon:	yes, the closer u get to border, the slower u can fly?
[11:55]	Simon Linden:	That's not going to work, since the motivation to go really fast is to skip all the physics checks on walls and such so you can jump to a new spot
[11:55]	Ryozu Yamamoto:	That's an interesting bit if info Andrew =D
[11:56]	Rex Cronon:	u don't necessarly want to jump into the next sim
[11:56]	Redux Decosta:	heres a possible alternative; what if we can TP an avatar from one location to another without using the map screen or the TP screen?
[11:56]	Sidewinder Linden:	so i have a related question though... is this discussion about "not fast enough" theoretical, or have you tried to do things and hit the top speed, and it "just doesn't feel nearly fast enough"?
[11:56]	Redux Decosta:	so if i give hard coordinates, like "put me at <10, 15, 200>", i can just pop there instantly without having to open the map
[11:56]	Seifert Surface:	llTeleportAgent redux?
[11:56]	Andrew Linden:	the short-distance tunnelling effect works best with high speeds
[11:56]	Ryozu Yamamoto:	Sidewinder: IN Havok1, just using my OmniPhaze, I can reach over 600m/sec
[11:56]	Redux Decosta:	that would not be a speed issue and wouldn't allow negative values so no moving across sim borders
[11:56]	Redux Decosta:	is llTeleportAgent a function?
[11:56]	Ryozu Yamamoto:	In Havok4, I hit 128/64 at best
[11:56]	Glitch Braess:	Now that Idea I like Redux :)
[11:57]	Ryozu Yamamoto:	Redux: It's been in the works for years
[11:57]	Seifert Surface:	its been a wanted function for years
[11:57]	Rex Cronon:	yes, for tpagent:)
[11:57]	Redux Decosta:	oh ok. lets make that.
[11:57]	Seifert Surface:	and there was apparently some work done on it
[11:57]	Redux Decosta:	i'd be satisfied with that + a speed limit =)
[11:57]	Ryozu Yamamoto:	The last I heard of it, the developer working on it wasn't sure what to do about permissions
[11:57]	Seifert Surface:	but it was held up, afaict for social issues rather than technical
[11:57]	Redux Decosta:	i dont need to cross teh border quickly, i just wanna be able to move around a sim quickly without having to sit on something or zip to <0, 0, 0>
[11:57]	Arawn Spitteler:	Where's the Jira to vote on?
[11:58]	Seifert Surface:	would llTeleportAgent solve all the issues people want high speeds for?
[11:58]	Glitch Braess:	If anything, I'd like it if it were just like llTeleportAgentHome.
[11:58]	Redux Decosta:	would in my book; the goal isnt to MOVE quickly, it's to GET THERE quickly
[11:58]	Glitch Braess:	Permissions wise.
[11:58]	Ryozu Yamamoto:	Seifert: I don't think it'd solve ALL of them, but a fair amount
[11:58]	Redux Decosta:	at least for me
[11:58]	Ryozu Yamamoto:	Well put Redux
[11:58]	Seifert Surface:	ryozu: well what are the exceptions?
[11:58]	Sidewinder Linden:	seifert - do you remember the social issues that were problematic for this?
[11:58]	Ryozu Yamamoto:	Seifert: I don't claim to know everyone's uses for speed ;)
[11:58]	Ryozu Yamamoto:	Unwanted teleports, I believe
[11:58]	Andrew Linden:	even if we had llTeleportAgent() some content is broken with speed limit. So if we drop the speed limit then we must agree that we're intentionally breaking the content.
[11:59]	Ryozu Yamamoto:	Hostile attachments that cause you to teleport so fast it raises issues
[11:59]	Rex Cronon:	i like to outrun a bullet:)
[11:59]	Redux Decosta:	if it ONLY work in attachments or touch, like llMapDestination, that may be useful. hostile attachments are always going to be problematic, i dont think we should try to base functionality around that
[11:59]	Ryozu Yamamoto:	The original design for llTeleportAgent involved sim-sim travel, but actually, I wonder if we could also get a function that's a simple in-sim positional set
[11:59]	Redux Decosta:	or have a 0.5 second sleep on it or something
[11:59]	Redux Decosta:	as much as i *hate* sleeps =x
[11:59]	Ryozu Yamamoto:	The real issue si that when teleporting between sims
[12:00]	Ryozu Yamamoto:	You could trigger a new teleport before my client even got loaded
[12:00]	Seifert Surface:	sidewinder: i think it was about permissions
[12:00]	Ryozu Yamamoto:	Preventing me from detaching the offending object
[12:00]	Seifert Surface:	as ryozu said
[12:00]	Sidewinder Linden:	ahhh... so a script that would relentlessly tp you in a way that you couldn't stop
[12:00]	Seifert Surface:	do you let them tp this agent somewhere
[12:00]	Seifert Surface:	right
[12:00]	Sidewinder Linden:	that would be a bit evil :)
[12:00]	Ryozu Yamamoto:	Yes
[12:01]	Andrew Linden:	So, we would need some way to override the attached scripts via the UI
[12:01]	Redux Decosta:	right, i woudl suggest not using the existing TP system since intra-sim TPs are busted anyway, and instead just try ot figure out a hack to rewrite client location
[12:01]	Ryozu Yamamoto:	That, or simply limit it some way to prevent continuous sim-sim teleport
[12:01]	Kitto Flora:	llTeleportAgent().... delays script for 10 seconds?
[12:01]	Sidewinder Linden:	but the limits couldn't be per-script - they'd have to be per avatar...
[12:01]	Rex Cronon:	u can have another script that would check how many continuous tp were performed, and start detaching all the other attachments?
[12:02]	Ryozu Yamamoto:	The other issue with llTeleportAgent would be teleporting into a solid object.
[12:02]	Seifert Surface:	why is that an issue ryozu?
[12:02]	Arawn Spitteler:	PERMISSION_TELEPORT_AGENT could request each time
[12:02]	Andrew Linden:	yes, lots of grief modes
[12:02]	Ryozu Yamamoto:	I haven't run into the issue myself, but some claim that an avatar inside an object causes a sim to lag
[12:02]	Seifert Surface:	ah
[12:02]	Ryozu Yamamoto:	Arawn: It can't be an "Each time" think in my opinion, or it's no more useful than map teleport
[12:02]	Ryozu Yamamoto:	Ah! How about this!
[12:03]	Rex Cronon:	tp into a solid is same as a solid rezzing around u
[12:03]	Ryozu Yamamoto:	PERMISSION_TELEPORT_AGENT is lost on regionc rossing
[12:03]	Redux Decosta:	avatar inside object: it causes a LOT of collisions, enough to crash the sim in some cases; i dont imagine that'd be trouble for H4 though....
[12:03]	Kitto Flora:	llTeleportAgent().... target must not interesect a prim, location must be ok for target AV.
[12:03]	Ryozu Yamamoto:	If you cross a region border, the script MUST present a dialog asking for permission to teleport again
[12:03]	Redux Decosta:	that'd get irritating, i'd rather not have to hit "yes" every time i cross a sim
[12:03]	Sidewinder Linden:	ok... this sounds like an interesting possiblity, but it sure sounds like it would need some real feature design to get even close to implementable, right?
[12:03]	Seifert Surface:	if its an attachment, automatically grant permission
[12:03]	Sidewinder Linden:	as opposed to a "simple fix"
[12:03]	Ryozu Yamamoto:	It would A) Not require a delay ont he function call and B) Prevent sim-sim teleport abuse
[12:04]	Ryozu Yamamoto:	Seifert: That doesn't sovle B
[12:04]	Glitch Braess:	Dialog would be a lot better than having the entire map up.
[12:04]	Seifert Surface:	if its not an attachment, why is it following you around between sims
[12:04]	Seifert Surface:	B?
[12:04]	Seifert Surface:	ah
[12:04]	Kitto Flora:	Sidewinder: yes, TeleportAgent ceratinly need a buch of checks to prevent it from being a griefer's tool.
[12:04]	Ryozu Yamamoto:	An attachment that teleports you from sim to sim before your client is loaded and thus unable to dettach
[12:04]	Arawn Spitteler:	llTeleportVehicle() would also be handy
[12:04]	Seifert Surface:	why arent people doing sim-sim teleport griefing with bots already
[12:04]	Seifert Surface:	?
[12:05]	Ryozu Yamamoto:	I do think simply losing permissions after a sim to sim teleport would be the simplest solution to that problem
[12:05]	Seifert Surface:	just throttle how often an av can tp between sims
[12:05]	Seifert Surface:	that should be in there already now, no matter why anything is getting tped
[12:05]	Ryozu Yamamoto:	Seifert: What to throttle at however? Based on what value? not every client loads the same
[12:05]	Seifert Surface:	ryozu: its the sim hit we care about
[12:05]	Ryozu Yamamoto:	I disagree, but that's because I couldn't use it as an OmniPhaze replacement
[12:05]	Seifert Surface:	presumably those are relatively constant
[12:06]	Ryozu Yamamoto:	Seifert: Sim hit? It's the inability to get out of the TP loop that I'm concerned about
[12:06]	Redux Decosta:	ryo: what about sim-to-sim teleport forcing a 10 second sleep, but otherwise no restrictions for teleporting inside same-sims?
[12:06]	Ryozu Yamamoto:	Relative as in my computer versus your computer
[12:06]	Seifert Surface:	oh, sorry, different sort of griefing
[12:06]	Sidewinder Linden:	this sounds like a great discussion to have with benjamin linden at his user experience office hours ;) http://wiki.secondlife.com/wiki/User:Benjamin_Linden
[12:06]	Ryozu Yamamoto:	My computer may take longer than 10 seconds to load, and thus I wouldn't have time to detach the trap object
[12:06]	Kitto Flora:	llTeleportAgent().... delays script for 10 seconds <--- this limit sim change rate AND allows escape.
[12:06]	Andrew Linden:	What if there were a way for the Resident to say "I want to STOP" and force all teleport attempts (and attachment pushes) to not take effect? It would have to be easy and clear for newbies.
[12:07]	Seifert Surface:	theres a cancel tp button isnt there?
[12:07]	Andrew Linden:	The "space" key currently stops the avatar for normal motion.
[12:07]	Redux Decosta:	i've brought up a panic buttone HUNDREDS of times
[12:07]	Ryozu Yamamoto:	lol
[12:07]	Andrew Linden:	What if you couldn't teleport while pressing the space bar?
[12:07]	Rex Cronon:	why can't u have a limit on continous tp?
[12:07]	Redux Decosta:	there needs to be a panic button in SL that makes you unpushable, unmovable, unTPable
[12:07]	Ryozu Yamamoto:	Andrew: Spacebar is a little known feature ;)
[12:07]	Seifert Surface:	damn useful feature :)
[12:07]	Ryozu Yamamoto:	Also not very useful for those who keep their chat bar open,
[12:07]	Sidewinder Linden:	@redux... not good for combat sims ;) awesome cheat
[12:07]	Andrew Linden:	What if we expanded spacebar to affect scripted teleports too, and advertised the feature.
[12:07]	Ryozu Yamamoto:	That could be useful
[12:08]	Seifert Surface:	a button on the tp loading screen would work
[12:08]	Ryozu Yamamoto:	I still think simply having to re-aquire permissions with a dialog after a sim crossing would be the most fundamental and easy of chocies
[12:08]	Andrew Linden:	Hrm... always a problem with giving residents full control over their motion.
[12:08]	Seifert Surface:	if your tp is taking long enough, you ll have time to hit it
[12:08]	Redux Decosta:	theres a trillian ways to cheat on combat sims; cheaters shoudl just be banned rather than allowing that to hinder everyones experience & open the doors for a trillion grief tools
[12:08]	Ryozu Yamamoto:	You just don't give permissions again if you don't want to teleport again
[12:08]	Glitch Braess:	Heck, hitting esc to get out of something wouldn't be too bad either.
[12:08]	Andrew Linden:	Perhaps you would have to give permissions to have the spacebar overrided/disabled.
[12:09]	Andrew Linden:	yes, esc might work
[12:09]	Redux Decosta:	hehe we are getting *way* off topic i think =x
[12:09]	Ryozu Yamamoto:	So at anyrate, before the segue into llTeleportAgent
[12:09]	Simon Linden:	Hey folks - I have to bail out, so I'll see you next time...
[12:09]	Redux Decosta:	next week are we meeting here or the new location?
[12:09]	Ryozu Yamamoto:	Are we agreed that av velocity limits are at least too low?
[12:09]	Andrew Linden:	There is a new location?
[12:09]	Sidewinder Linden:	if so, ryozu, what are the new numbers?
[12:10]	Ryozu Yamamoto:	I'd personally like to see 250m/sec mininum
[12:10]	Redux Decosta:	we had discussed setting up a new location on a h4 enabled sim that would give us more control over ambient traffic prior to the end of the last meeting
[12:10]	Ryozu Yamamoto:	128 is barely acceptable, I could deal with it, but it's not my preference
[12:10]	Redux Decosta:	if you do a places search for "havok4" i have a spot set up on the middle of one of my sims that sidewinder previously had enabled havok4 on for this purpose
[12:10]	Ryozu Yamamoto:	Either way, I don't think there should be a difference between flying and non-flying
[12:10]	Glitch Braess:	ESC would probably be an easier button to use instead of space considering, well, like someone else said, the space bar is used quite often by people who constantly leave their chat window up.
[12:10]	Seifert Surface:	ryozu: yeah on that the limits should be the same
[12:10]	Rex Cronon:	shouldn't flying be faster?
[12:11]	Ryozu Yamamoto:	Also, ESC = Escape, "I want to escape!"
[12:11]	Glitch Braess:	Exactly.
[12:11]	Glitch Braess:	Heh
[12:11]	Sidewinder Linden:	umm.... can we return to topic? ;)
[12:11]	Ryozu Yamamoto:	lol, sorry ;)
[12:11]	Sidewinder Linden:	np
[12:11]	Kitto Flora:	I had the new meet location landmarked... but now I have 50+ landmarks missing from Inv
[12:11]	Sidewinder Linden:	so we have a few open items
[12:11]	Sidewinder Linden:	redux - can you list the sim name and location here?
[12:11]	Ryozu Yamamoto:	Content to Hover, middle of the sim ;)
[12:11]	Redux Decosta:	sure, it's at Content to Hover, <128, 128, x>
[12:11]	Sidewinder Linden:	ok
[12:12]	Sidewinder Linden:	do we want to meet there from now on?
[12:12]	Redux Decosta:	if you open up search and search "havok4" under places it has the meeting time & officers
[12:12]	Ryozu Yamamoto:	If I'm here (Which unless I'm braindead at the time) for the meeting, I'll have a second account here to direct people tothe right place
[12:12]	Redux Decosta:	& up until the last grid patch we had h4 enabled on the sim, and a few of us were messing around there
[12:12]	Sidewinder Linden:	@redux - it'll be back asap... hopefully later today - or late weds if we have another build needed to pass qa
[12:13]	Redux Decosta:	*nods*
[12:13]	Rex Cronon:	list new loc here: http://wiki.secondlife.com/wiki/User:Andrew_Linden
[12:13]	Seifert Surface:	h4 is up on sims in the mg now? ive been out of the loop
[12:13]	Andrew Linden:	Well, if we change the location someone please let me know.
[12:13]	Andrew Linden:	It must be public. That is my only requirement.
[12:13]	Sidewinder Linden:	@seifert... anyone who wants to be an early adopter can choose to run h4 on the main grid
[12:13]	Seifert Surface:	awesome
[12:13]	Sidewinder Linden:	i've been putting regions on the beta grid for preivew
[12:14]	Sidewinder Linden:	so that folks can proof their entire build on h4 before deciding to deploy
[12:14]	Redux Decosta:	andrew: it's public, actually i think you were one of the people who had expressed interest in a dedicated h4 meeting area which is what this is for. plus if someone wants to set up a demo or something before the meeting that would be feasable
[12:14]	Sidewinder Linden:	the last rolling restart "paved over" the whole grid with havok1, but with this next deploy we'll start maintainin the havok4 regions ongoing
[12:14]	Seifert Surface:	i would ask for the future to go in, but im in the middle of moving to a new sim
[12:14]	Andrew Linden:	Yes Redux, but I got too busy to actually evaluate possible new locations.
[12:14]	Ryozu Yamamoto:	;)
[12:14]	Andrew Linden:	I'm happy to have someone move my own meetings for me.
[12:15]	Glitch Braess:	lol!
[12:15]	Talarus Luan:	Greetings. :) Is there a process for requesting a region be deployed with H4?
[12:15]	Redux Decosta:	alright. your meetings are hereby moved to Content to Hover at <128, 128, x>, by mandate of Redux. Time shall remain consistant.
[12:15]	Sidewinder Linden:	hi talarus - im me :)
[12:15]	Talarus Luan:	Okies :)
[12:16]	Rex Cronon:	is there something done about the attchments going borked when tp from havok1 to havok4, back and forth?
[12:16]	Andrew Linden:	Very good Redux. I'll make sure the changes got to that wiki page.
[12:16]	Glitch Braess:	brb more coffee
[12:16]	Redux Decosta:	*nods* i'll have ryo set up an account to hand out landmarks at this location next week incase people forget
[12:17]	Andrew Linden:	Ok, time for me to go.
[12:17]	Ryozu Yamamoto:	Take care Andrew!