|
|
|
I've found a fourth failure mode. If you descend onto the top of an access controlled parcel in a vehicle, rather than bouncing off (as happens when you're flying or falling) or getting stopped (as usually happens when you hit it from the side) you get the message "You are no longer allowed in this parcel" and are unseated and ejected, while the plane continues flying (just as if you hit the access controls from the side at a high velocity).
At one point I got stuck between two access controlled parcels and couldn't move at all. llSensor/Follower objects that belong to the parcel owner fail to follow another avatar into the parcel. Quite unhelpful.
Could that effect be due to the object using llScriptDanger()?
Doesn't just affect Havok 4
The great bain of pilots in SL... Aside from Home Security Orb, of course, but I haven't seen many of those around anymore... Either way, voted. Thanks for reporting this in greater detail and understanding than I could.
The unseating aspect is horrid since it leaves the avie locked in rigor mortis while the vehicle continues moving into the access restricted parcel. A full stop all animations and release controls script needs to then be run (or the avie relogged) to undo the aftereffects. There is no mitigation for this problem because there is no interface to determine is an avie is permitted in an area, hance no way to modify a vehicle's behavior to not attempt entry into a parcel or region with access restrictions. The best I can do is add an expensive periodic check of the avie, and if the vehicle no longers finds him/her, stop all movement.
BTW, this behaviot is not H4 related. It has been that way since I first entered SL over a year ago. Sailing mainland waters is practically impossible (try that in the SIMs near "Balance") because the myriad ban lines guarantee a loss of vehicle and a forced relog. It's not possible to rez a stop-anim object because along with the ban lines the parcels are no-build. What are you doing to detect that the avatar is not there? I don't get any events when this happens.
I've been getting another problem recently where, when crossing the border, either me and the vehicle will fly off into infinity, or we will fly off into infinity for a way, then my camera will start to rotate in a wide, multisim circle around my deceased vehicle where it was left on the sim border, or me and the vehicle will fly into infinity for a way, then the camera will pop onto a panoramic shot of the area, stay there for a few moments, then pop to another angle of the area, as if switching between weather cam and traffic cam on the news or something. In all situations, the controls are locked out, and there is no fix I can see once this happens except a relog.
Basically, it's general wonkiness when crossing borders, and it's happening in 55-75% of all border crossings. It's killing my vehicle bussiness, and it's trying my patience, as it's gotten to the point where I can't even travel in my own vehicles, and what's sad is, I can remember when vehicles WORKED. To see the decline of both vehicle performance in SL and LL's interest in them, and making sure they work properly, saddens me. The ONLY good thing that has happened to vehicles since I joined SL was H4, and now these border crashes have negated that improvement. Argent, I have tried various techniques, but the one that seems to work is to remember the key of the sitting agent then periodically use llGetObjectDetails to query for position. If the function returns an empty list (or the element is <0,0,0>) for some threshold time, say 1 second, then the pilot did not get handed off at the crossing. llGetObjectDetails has been changed several times since I used this technique. There was a time when it returned information even when the avatar was in another SIM. At that time, the code looked at the distance between the avatar and the vehicle. Then llGetObjectDetails was changed to return zeroes (or stale data) when the avatar was in another SIM. At that point it was possible to discern whether the avatar was wrenched off versus logged off. Nowadays llGetObjectDetails usually returns a null list if the avatar is in another SIM, even if they are centimeters away but on the other side of a SIM boundary. Alas, security issues have damaged useful functions.
So, given the inability to mitigate this nasty SIM crossing bug, this needs to be fixed. A vehicle with a sitting avatar should bounce off of any access restricted areas in the same same manner that they do when a vehicle hits the edge of the world. There should be no difference and the behavior in all cases should never be to unsit, derezz, TP home, or do anything horrid - just bounce back. Just so folks don't forget this darned thing is still broken.
This is getting beyond annoying. It is still broken, and worse is that with the severe memory leak which makes for a glacial viewer, I cannot react fast enough to avoid getting dumped when I do see ban lines loom ahead. And, of course, estate/region bans do not show any lines at all. Those are the worst with this bug.
I've found that if you're real quick, you can sometimes tp into the new region where your vehicle was crossing into, and your avie will sometimes be "rejoined" with it when the new server finally gets it's thumb out of its electronic butt and figures out that you're there. It doesn't always work, but I've had it work about 60% of the time, and it sometimes works for passengers who get lost in the shuffle, too.
This bug is a pain in the neck, and it's unconscionable that it hasn't been fixed after all this time. Is there some rationale as to why this has been ignored for so long?
Are vehicles simply not important enough to fix? Or do we only care about sports coupes and motorcycles on mole-built roads on protected land? I've had this happen when following roads, Maggie.
@Argent--
Didn't mean to imply there aren't still problems on roads...and railroad rights-of-way for that matter. A flying vehicle is more likely to be moving at a speed as to encounter a ban line before a pilot could reasonably be expected to see it. That said, it seems to me that the public nature of roads tend to cause people to erect ban lines, and when they do they are often the "red sawtooth of death" type because the roads aren't straight but parcel boundaries must be. The section of GSLR that passes though Maroon and Monroe is an example. These ban lines barely offer rail clearance; other portions of GLSR have terrain interference problems under H4 collision rules. It's also a major problem on waterways, because you can't even see parcel borders through the water.
There are only 3 SVC issues older than this still open:
Islands not showing up on the world map. Unable to find this thread in search I started SVC-3363. Considering its age it had long ago scrolled off the bottom.
The suggested solution to maintain legacy compatibility with existing NO-ENTRY barriers, in particular when they are adjacent to a region boundary, is to provide a 1 meter cushion inside the barrier so the vehicle could sense the parcel in front and take evasive action before being trapped. Another approach that may be even simpler to implement is to build in a 10 second delay before ejecting from a NO-ENTRY parcel. That would give time to fly through or take evasive action without compromising privacy too much. With remote cameras there IS NO privacy in SL so NO-ENTRY seems to be superfluous anyhow. Attempts to solve the problem. 1. I had the vehicle fire unmanned temporary probes ahead that indicated a hazard if they failed to continue sending reports back. It kinda worked but that had the problem of rezzing probes in no-build parcels. I solved that by having the vehicle load an arsenal of attached probes and releasing one when required. The vehicle replenished the arsenal whenever if was over land that permitted rezzing. That worked except releasing a probe unseats the passenger(s). I had unmanned vehicles traverse 3 or 4 sims before crashing but no fun if yo can't ride it. So I started to make a vehicle to follow the path of the scout that went ahead firing probes but abandoned it for obvious reasons. 2. Next approach I'm working on is to anticipate a region crossing and make sure the vehicle is above the NO-ENTRY height until it determines if it is safe. Keeping sufficient hover height appears to be a problem and it may have to go non-physical. This still doesn't solve the problem of security systems that can't be detected. 3. Have the vehicle lay a temporary egg every 10 meters. If the vehicle fails to intentionally abort its eggs before they expire, the egg knows mother has died and rezzes a replacement vehicle. That would be fairly easy but recovering the avatar from <14000,150,-15000> after a crash can take 60 seconds and a couple of teleports to restore functionality. My vehicle is a Blimp that moves quite slowly and is entirely self navigating without a pre-programmed trajectory. It is working fairly well, managing sometimes to navigate over many regions for 10 to 15 minutes without a crash at an average altitude of about 30m. It is a really cool ride if I can just get it to be a little more reliable. All these mitigations just do not work. A common problem is that a region or parcel disallows avatars but permits objects to enter. This is quite common in multiregion areas where an estate access control is in effect. Consequently all the fancy sensing techniques, and I've tried them all, will find safe passage and yet be incorrect in its assessment. Then when the vehicle crosses into the no-avie zone, the person gets wrenched off and the vehicle sails, flies, or floats merrily along into the avie banned parcel or region.
The purpose of this bug report is not to find mitigations but to fix the fundamental problem. No access processing in vehicles should be treated in the same manner as edge of world crossings, bounce off, don't wrench an avie, and don't leave them in limb locked rigor mortis with a vehicle damaged because the system thinks someone is attached to it and the scripts don't. this is the single most irritating and absurd problem for me in SL. WHY can we not simply be bounced back? Perhaps it is my technical ignorance, but avatars are bounced back; is it truly THAT difficult to do the same with vehicles?
I've heard of some other virtual worlds on the net; perhaps one of them will provide a better environment for vehicles. Who would have thought that AdFarms would have been dealt with before this issue? After ONE YEAR (SVC-1070), this issue is still "unassigned"...and prevents travel on the LDPW Route 1.
I had some brief input from Kelly Linden that explains a reason for the problem. We were discussing the problem as it applies to prim-full parcel adjacent to a region boundary where the prim cushion is not made available to the vehicle due to it not being a vehicle at the moment the permission is checked. Here is the quote.
Yeah that is a known bug. It is a race condition that I was never able to fully track down. The problem is the vehicle gets serialized over to the other region before the rider, so there is some short time when it isn't a "vehicle" and if the wrong check happens then things go badly. It actually doesn't happen 100%, although it has been a long time since I looked into it, so maybe it is 100% or close enough now.
So that's a design flaw.
Being a vehicle is part of the object state that needs to be serialized so that a vehicle can be treated as one even if its riders haven't arrived yet. AnnMarie (and by proxy, Kelly) thank you. So we have a design flaw in which crossing sematics are not idemptotent. This is a severe flaw, and I can see how a great deal of effort needs to be expended to get it repaired.
I imagine that the priority of this problem falls well below new development. In the companion JIRA, SVC-472, I see good analysis in which passive agent development, which enables better corp/biz scenarios, are favored over active agent development typically found in the game-like fun-like physics laden scenarios. Now I am unhappy with that direction and roadmap, but I understand the Lindens have made business decisions for their platform. At least now I know we have reached a limit to vehicle development. We'll continue to see flakey lower perceived value products because the infrastructure is severely flawed. I only ask the Lindens to respond with an estimate when or if this bug will get addressed. Then I can determine when I should bother to expend my time and energy to developing viable products. Blog that please. @Balpein--
If you're referring to the comment Matthorn Avro - 15/Nov/08 05:17 AM in SVC-472, I read that as being somewhere between sarcastic and tongue-in-cheek. I really don't think it's an accurate reflection of Linden policy. That said, vehicle crossing issues have clearly been much lower in priority than things more key to server stability, like H4 and Mono. I personally think Server 1.25 will go a long way to improving the "game-like fun-like physics laden scenarios" we do love. In fact, lately it's been my experience that sim border crossings even without a vehicle are troublesome in the extreme. Severe rubberbanding and expired_region_handoff are very common. Given how long these things have been known issues, I don't expect to see direct action anytime soon. So many of these problems are related to inter-server latencies that the situation may turn out to be very different after FJ's LLNet project is implemented in the New Year's time frame. Now that Kelly Linden seems to be back in action it would be nice if this got some attention again.
I have been "back in action" since the start of the year. However I am not working on or looking at these kinds of bugs right now, which is unfortunate. I'd probably rather be looking at them. Sorry.
You are right that LLNet may help some, we should be able to tell soon. I have at least two School Bus crashes per day where they cross a region boundary into a full parcel adjacent to the line so the prim cushion is not available before the rider(s) and the vehicle get linked again.
We've not had any fatalities yet but if the news media hears about this bug there could be SERIOUS REPERCUSSIONS. I notice that when you cross over in a nonphysical vehicle, you get killed if the parcel is no object entry. If you're sitting on an object it should let it in regardless of whether no object entry is turned on or off, and regardless of whether the object is physical or not.
Yes. The problem (bug) is that when you cross the sim boundary, the servers hand over the avatar and the object they are sitting on individually, not as a package. So for a moment it is not an attached object. If the no-entry script catches it before it links up with the avatar it gets killed.
Key: SVC-22
Type: Bug Status: Open Priority: Critical Assignee: WorkingOnIt Linden Reporter: Argent Stonecutter Created: 12/Feb/07 11:09 AM Updated: 08/Apr/09 08:53 PM Votes: 101 Watchers: 25 Let's have a party to celebrate this being open for over two years. I have about 30 Flying School Bus sites throughout SL that get used frequently. Despite care and warning to drivers we sacrifice thousands of school children on SVC-22 every year. It is wanton disregard for life. The awful part is the agonizing death that typically involves shooting at thousands of meters a minute into dark blue Purgatory with no simple recovery.
The best recovery solution I've found is to start TPing to random destinations in different sims. Usually by the third or fourth TP you get back into virtual reality instead of virtual Purgatory. If anyone knows another recovery method other than log out and log in I will pass it on to our school children. Any idea if "workingonit linden" is still alive? should there be a funeral or wake or something?
I find it STAGGERING that an issue which is assigned can go for two years without comment by Lindens. But then I seem to stagger a lot on SL lol. Its also curious that the one comment from a Linden is from someone who is not working on the problem! well, Joyofric, we deal here with a strange little bit of Linden Zen.
The name "workingonit Linden" (invented by the relentlessly, maniacally, delusionally cheerful Torley) these days does not in fact indicate that anyone is working on the issue. It indicates that somebody might work on it someday; that it has passed the triage process and been copied into the internal JIRA that the Linden devs actually use. It's a nearly-tacit admission that a particular JIRA might actually represent a defect in a Linden Research product. There's lots of aspects of vehicle operation that are severely broken. Some of them, being due to design flaws, will require deep refactoring of core SL internal protocols. I'm sure they will get right to them when they're done doing important stuff like implementing an extra level of "maturity" ratings, fixing the bugs in the new LSL interpreter that's almost as good as the old LSL interpreter, and enabling inbound cell calls to your avatar. Changing the description on this one. While what was there was indeed correct, it wasn't very specific. Hoping that something more detailed will get this a little more attention...
I have 2 regions that vehicals can cross but still has the detached n pray u make it issue. So it not just a no object entry or a sim already maxed out in prims that does it or that u cant enter it. It the servers suck is all.
That's several other different issues, Sparket, not this one. See issue links.
PANIC TIME!
I think they need to fix SVC-22 before they roll this out! Personal use stuff needs to be avatar pool only unless they own the parcel they are over. Why should a parcel owner give other avatars the right to gob up parcel script resources.
The way that log reads any malcontent can hover in your parcel at altitude preventing anything else from working. Smooth move. Why not just ban scripts, vehicles, and attachments and be done with it. Slightly-related forums thread: http://forums.secondlife.com/showthread.php?p=2549363
/me quotes /me: "Personally, I would rather hit a wall/stop than have everybody on the vehicle get tossed and the vehicle returned. Having the brakes get slammed on seems a whole lot less disruptive than getting thrown from the car..." Charging vehicle resources to a parcel runs counter to how vehicles have always behaved in Second Life.
This "solution", being discussed only literally in the dead of night unless you live in Europe, is completely broken. It will end Aviation in Second Life. It endangers sailing. Vehicles have been a vibrant, lively and interesting part of Second Life culture, and there is absolutely no excuse to ruin them because of a bloated script engine. Whoever Babbage works for needs to reel him in. [3:22] Babbage Linden: when you rez a vehicle it uses the parcel pool
[3:22] Babbage Linden: (as there is no way to determine it is a vehicle) [3:22] Babbage Linden: when you sit on it, it still uses the parcel pool [3:22] Babbage Linden: (it might be a chair) [3:23] Babbage Linden: then when you drive over a parcel boundary it first tries to use the attachment pool of a sitting avatar [3:23] Babbage Linden: if it can't it will try to use the new parcel pool What are the limitations of the attachment pool? Was Babbage talking of the way it is or the was it is planned to be? I think that a vehicle should take always its prim allocation from the avatar pool as soon as it moves off the parcel on which it had been rezzed - even if it returns to that parcel. Your Enjoyment, Your Prims. That could be abused of course ETA: Ah! But if the vehicle 'arrives' in a new sim before the sitter, then there isn't an avatar pool to cover it.... Sling: Babbage is discussing planned quotas for script memory, not prims. But what he describes is much more restrictive than how vehicle prims are supposed to be treated.
Babbage acknowledged back in April that fixing SVC-22 is a prerequisite for the script memory limits, per http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2009_04_22
:
"[3:49] Babbage Linden: i agree that SVC-22 needs to be fixed as part of this by the looks of it" Admittedly, I haven't been able to attend many meetings recently so if there has been backsliding about that it would be time to panic again. Instead of applying rules to each object as it arrives, how about putting ALL objects entering a parcel in the attachment pool for 5 seconds with a "purgatory" flag to give enough time for everything to transfer. Any objects that have not linked to an avatar can then have the ejection rules applied.
That all depends on what a "fix" is. Like changing the rules on vehicle prims is much easier than actually fixing the code, for the same reason: you can't tell a vehicle is a vehicle until a vehicle LSL call is made.
Oh, and Sling? Since when does an avatar have a prim pool? Or do you know about another stealth rule slouching towards implementation? The internal jira for this issue was marked as resolved about 2.5 years ago, before havok 4. As I understand it, there was a group of things that re-broke after havok 4; this might have been one of them. I re-opened the internal jira about a month and a half ago, but it is currently unassigned. I'm unassigning the pjira to reflect the internal status.
Aaaaaand....back to the end of the line.
SVC-22 has been a standing joke at Andrew's office hours for at least a year. And now you're telling us it was marked closed internally?
As I have been saying for quite some time, the one-way flow of info from PJIRA to JIRA is probably the most severe flaw in how PJIRA is run. Dante: this was not broken with Havok 4, rather it has NEVER been fixed. It was introduced years ago when a "fix" to temp rezzing prims broke sim crossing for vehicles, badly. Since then there has been no time, ever, when this has not been a major problem in Second Life. It has been brought up with multiple Lindens, who have acknowledged that it's a problem, over and over again. If this has been left "closed" for 2.5 years then there's INTERNAL problems at Linden Lab that need to be dealt with. It should never have been closed, and it should have been opened again years ago. In the meantime, this needs to get a MUCH higher internal priority given its importance and how long it's been neglected.
AnnMarie: the problem appears to be that there is no flag or annotation on a vehicle to indicate that it's a vehicle. It's only treated as a vehicle if there's someone sitting on it. If it happens tat the vehicle gets transferred from one sim to another before the rider, boom. Adding a short delay won't help until they fix sim crossing so it only takes a short period to complete. The "vehicle nature" of an object needs to be an attribute of the object, only cleared when the sim has confirmation from the agent that it's no longer seated. I think this is intimately related to the lag spikes that occur when an avi enters a sim. I assume similar occurs even if the moving object is not being sat upon when it leaves one sim to enter another. If a vehicle is moving at any significant speed when it crosses a sim border, it is likely to rubberband completely across the destination sim before being picked up.
If then. Now that Zindra is implemented, can we please get some serious attention paid to this cluster of issues? You know, if simulators now take more memory than they used to post-Havok 4 or more likely post-Mono, perhaps it's time for Linden Research to cover the cost of that bloat with more real memory in the server boxen, instead of blaming the users and punishing them with "script memory quotas". In a conversation with one of the Lindens, he indicated that it was a timing problem, presumably the race between the rider and the vehicle getting there and in the same computer cycle. He said that it did not happen 100% of the time. So if the rider and the vehicle are there before the entry legality analysis is done they link back up and become a vehicle again and are permitted to stay.
1. If there could be a short delay of a few seconds before all objects are processed to see if it can enter legally, this would give riders and vehicles time to re-connect. We would need a purgatory flag applied to all objects entering. After decrementing for x cycles they are then checked to see if they can enter legally or are vehicles. Then if legal they enter, if illegal they are returned. or 2. I guess this is not much different to objects "flagged" as vehicles for the purpose of region crossings but you would still have the timing problem of when to stop treating the object as a vehicle because of the flag and start checking if it is still linked. The flag would override the rider link check but has to be turned off at some stage to resort to a normal vehicle. So perhaps a list of pending vehicles would be needed. It doesn't seem either of these would be difficult but unfortunately they are not trivial changes. AnnMarie Yes, there is a timing problem... to be precise, it's a race condition.
Adding delays to "fix" a race condition just reduces the likelihood of triggering the problem. It also opens up other race conditions from the other side, for example letting people tunnel weapon prims into a no-access parcel by coming through a sim wall. The correct fix is to change the behavior so that it's not timing-dependent. That's what I'm suggesting, making "vehicle nature" an aspect of the prim, rather than a check to see if someone's sitting on it. It wouldn't need to get "turned off", you wouldn't stop "treating an object as a vehicle because of the flag" and start "checking whether someone's sitting on it", you would instead have the flag be the primary state, and have the flag turned off when the avatar stands or the agent disconnects. They're already doing something like this for the script limits... vehicles will be prims that are being sat upon AND have crossed a parcel boundary. This would be the perfect time to fix it. Attempting to charge script memory in a moving vehicle to parcels as it enters is a recipe for disaster. Why do this when it's not done for the prims? Or are we headed that way too?
They're NOT going to charge script memory in vehicles to the parcel, UNLESS the avatar has no script memory available. The problem is that when a vehicle enters a parcel across a sim border the sim doesn't know it's a vehicle until the avatar crosses as well. That's the flaw that also causes all the other SVC-22-related problems,.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Critical
Vehicles crossing region borders aren't always treated as vehicles and can get incorrectly returned if the destination parcel is no-entry or parcel-full
The ban line problems are still there.