Jump to content

PERMISSION_TELEPORT broken in LL Viewer March 15 release?


You are about to reply to a thread that has been inactive for 3607 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

UPDATE - Whatever it was, it's fixed! W00t!

Hi folks,

I don't get a teleport permission request anymore using the latest LL Viewer, Second Life 3.7.4 (288138) Mar 15 2014 17:10:17 (Second Life Release). Subsequently, I can't be teleported anymore by scripted objects (that I am the owner of).

Is it just me, or is the new viewer broken?

P.S. I'm on a Mac. Someone on Windows 7 was able to confirm this. Everything works fine on Firestorm, but not the latest LL viewer.

Link to comment
Share on other sites

I just tested on Second Life 3.7.4 (288138) Mar 15 2014 16:28:23 (Second Life Release) on Windows and it is working for me BUT if you had any offline inventory offers waiting when you logged in you will not see the popup asking for permission to teleport. The dialog will disappear straight into the notification chiclet.

This is a known bug - see BUG-5550 - Instant message toasts and certain kinds of popups (ex. group invites) fail to display if an offline inventory offer was received before logging in.

Link to comment
Share on other sites

No, the notification is not hidden in the chicklet. And there were no offline or online inventory offers. So it's not about this bug.

Also, the hud is made such that it will repeat asking permission upon clicking the tp button. Works fine in FS, NOT in the LL Viewer. In addition, I tried another teleport-capable HUD, which also does not work in the official viewer, but has always worked in the FS viewer.

Link to comment
Share on other sites

Hmmm.

Which HUD are you using?

This is the script I was testing with:

key  teleportee; default{    state_entry()    {        llSay(0, "Touch to teleport");    }     touch_start(integer total_num)    {        teleportee = llDetectedKey(0);        llRequestPermissions(teleportee, PERMISSION_TELEPORT);    }     run_time_permissions(integer perm)    {        if(PERMISSION_TELEPORT & perm)        {            llTeleportAgent(teleportee, "", <109.0, 98.0, 23.5>, <13.0, 12.0, 23.5>);        }    }}

 

Link to comment
Share on other sites

"Which HUD are you using?"

HUDs I made myself, with many destrinations. They have always worked for me and for others.

The latest HUD is the Dwarfins/MadPea Lost Mine hunt HUD. Most players are on Firestorm and it works fine for them. None of the users on the official LL viewer can be teleported with it. For them, I added a SLURL in chat, which sort of kills the immersiveness.

"MAINT-535 FIXED The teleport SLAPP is changed to UNTRUSTED_THROTTLE. Confirmation dialog for teleporting via slapp is added."

What is SLAP? There's no confirmation dialog whatsoever in the viewer.

Link to comment
Share on other sites

I tested on Second Life 3.7.4 (288138) Mar 15 2014 16:28:23 (Second Life Release) with the Lost Mine HUD and it is working fine for me.

I get the request from the HUD to allow teleport and once accepted, my teleports automatically happened.

I made sure I had received offline inventory offers and tested again and this time the "allow teleport" popup did not appear on the screen but disappeared into the notification chiclet straight away. It was easy to miss it.

After opening the past notifications and allowing teleport the HUD was working properly.

If you think there is a different bug happening from BUG-5550 though, you should file a JIRA issue.

Link to comment
Share on other sites


Arduenn Schwartzman wrote:

Again, it's nice that it works for you, but it's not for dozens of official viewer users, including me and two colleagues, one of whom is an experienced beta tester.

The HUD works perfectly for me on two different machines, one Vista and one Windows 7, using both the main-channel LL viewer and the Project Interesting RC viewer.  I tested it on both main-channel server and RC server regions, including both Mad City and Dwarfins. I've attached it and detached it repeatedly, hit "Stop Animating Me" while wearing it, relogged with it attached, relogged with it detached and then re-attached it. I've actually used it in the context of the hunt and collected "paper" and worn the collection bag while doing all of this. I can't break the little puppy.

So, this would indicate that your initial hypothesis is incorrect in assuming that the function is entirely broken in this particular viewer. What you're dealing with is an isolated problem based on an undiscovered variable. You don't actually know the extent of the problem. Though you say you have dozens of failure reports you have no way of knowing how many LL Viewer March 15 release users AREN'T having problems because people don't generally report something NOT failing. (This is assuming that you're not indulging in forum poster hyperboly and "dozens" is actually dozens and not, say, five.)

So, your next steip is to collect data on the setups of people whose HUD's ARE failing and see if there's a pattern.

Link to comment
Share on other sites

  • 2 weeks later...

"So, your next steip is to collect data on the setups of people whose HUD's ARE failing and see if there's a pattern."

Sounds like a good plan and a huge amount of work. Myself, I'm most certainly not going to put more energy into this, though. I'll refer anyone who encounters thi sin the future to this post.

Link to comment
Share on other sites

  • 4 weeks later...

Is there posted source code somewhere that causes this problem?

(I can't replicate it with Whirly's script on the latest Linden viewer on Linux, but that's just me. As already mentioned, there have been big server-side changes in how this works over the past few months, so it would be important to know what's happening if those have different effects on different viewers. Especially if "eXperience Permissions" are just around the corner as it seems.)

ETA: Did anybody who experiences the problem when using your HUD also test using Whirly's script and get the same problem? If so, then we have source to reproduce the problem (for some) and we're back to trying to find what combinations of viewer, account, and configuration will reproduce the problem. If not, then we still need such source code.

Link to comment
Share on other sites


Arduenn Schwartzman wrote:

I can't reproduce it anymore myself. A few weeks ago it failed for me on the official LL viewer. Now it works. Same viewer. I'll ask a few other people to try it again too.

There was a server-side issue with llTeleportAgent breaking HUDS and other attached objects and a fix for that issue was released in April:

https://jira.secondlife.com/browse/BUG-5533

 

The differences between viewers may just have been a red herring.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3607 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...