Phoenix Viewer

Radar announced keys to hud no longer heard by attachments right after teleport

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Waiting on Linden Lab fix
  • Affects Version/s: Phoenix Viewer 1.5.1.225
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • SL Avatar Name:
    DarthBunny Petrov

Description

The keys announced on channel -777777777 are no longer 'heard' by my hud right after teleporting or crossing a region border in Second Life server 10.9.10.
The keys _are_ chatted on the channel by the client, an object in-world does hear it, but attached objects seem to be 'deaf' for a moment (or just not running yet) right after arriving into the other region in this new server version.

I've tested this on several teleports and region borders to rule out it just being lag, with me wearing just 1 script that listens on -777777777 and tested both LSL and Mono compiled.

While this technically is a LL issue (according to chat in Second Life Beta, because region crossing/tping is now done in multiple threads server side), and not Phoenix, one workaround might be to let those keys be chatted after a delay, so worn scripts have time to catch up.

Issue Links

Activity

Hide
Ethari Hallstrom added a comment - - edited

I've noticed this recently also. It's annoying as you have to uncheck and recheck the announce button for your scripts to get the keys again. Very inconvenient. Never used to have this problem pre-Phoenix so I wonder what has caused it. Would appreciate a fix!

Edit: This also affects 373. I'd edit/update the issue, but it seems I can't o_O... Why? We really need public edits like the LL Jira, or am I missing something?

Show
Ethari Hallstrom added a comment - - edited I've noticed this recently also. It's annoying as you have to uncheck and recheck the announce button for your scripts to get the keys again. Very inconvenient. Never used to have this problem pre-Phoenix so I wonder what has caused it. Would appreciate a fix! Edit: This also affects 373. I'd edit/update the issue, but it seems I can't o_O... Why? We really need public edits like the LL Jira, or am I missing something?
Hide
Jessica Lyon added a comment - - edited

You can trigger a re broadcast of av uuids using a specific sound uuid. Example here.

default
{
state_entry()

{ llListen(-777777777,"",NULL_KEY,""); }

listen(integer channel, string name, key id, string message)

{ llOwnerSay(message); }

changed(integer what)
{
if(what & CHANGED_REGION)

{ llTriggerSound("76c78607-93f9-f55a-5238-e19b1a181389", 1.0); }

}
}

I love how comments here fail to format scripts correctly...

Show
Jessica Lyon added a comment - - edited You can trigger a re broadcast of av uuids using a specific sound uuid. Example here. default { state_entry() { llListen(-777777777,"",NULL_KEY,""); } listen(integer channel, string name, key id, string message) { llOwnerSay(message); } changed(integer what) { if(what & CHANGED_REGION) { llTriggerSound("76c78607-93f9-f55a-5238-e19b1a181389", 1.0); } } } I love how comments here fail to format scripts correctly...
Hide
Jessica Lyon added a comment -

You can trigger a re broadcast of uuid's from the viewer using the following code.

changed(integer what)
{
if(what & CHANGED_REGION)

{ llTriggerSound("76c78607-93f9-f55a-5238-e19b1a181389", 1.0); }

}

Show
Jessica Lyon added a comment - You can trigger a re broadcast of uuid's from the viewer using the following code. changed(integer what) { if(what & CHANGED_REGION) { llTriggerSound("76c78607-93f9-f55a-5238-e19b1a181389", 1.0); } }

People

Vote (3)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: