remote_data in attachments

I'm trying to create a HUD that receives data via xmlrpc and the remote_data() event. I'm running into problems when people teleport into another sim.

When the HUD receives a changed(REGION) or changed(TELEPORT) event, it re-registers the channel by calling llOpenRemoteDataChannel() again. And that seems to work fine as long as the av just flies from sim to sim. But when you teleport, the channel goes dead (attempts to send data to it just timeout). And it stays dead until you take the HUD off and put it back on, when it then gets a new channel (with a new key).

So either

1. re-registering channels has never worked in attachments
   
2. or, something broke in 1.9
   
3. or, there's some other problem with my code
   

Does anyone have a working HUD that keeps an xmlrpc channel open across teleports?


Follow-up:

I've done some more experiments with interesting results.

If I teleport within the sim, or to an adjacent sim, the channel still works. It's only when I teleport to a far-away sim that the channel goes dead.

However, if I teleport to a distant sim, and then fly back to a sim that's ajacent to the sim I originally teleported from, the channel starts working again! And it will continue to work as long as I just fly from sim to sim.

So it looks like something's not getting handed off properly on teleport.
Can anyone verify?

Hrm, that sounds like a bug as it should be triggering regardless of how far you go. Have you tried putting the same code into the on_rez event to see if that triggers instead?
But yeah, 1.9 jimmied things around I think so that on_rez shouldn't trigger after teleports anymore, but changed will instead with the two new constants.

However, just to clarify, you are using bitwise operators with separate ifs or ORing them?

e.g:

changed(integer x) {
    if (x & (CHANGED_REGION | CHANGED_TELEPORT)) llResetScript();
}

Should definitely work, if not then something is screwy and you should bug report it, perhaps along with your code (or the relevant events)

The problem isn't that the changed() event is not triggering. The changed() event works fine, and triggers on teleports as it should. I can see it trigger with llOwnerSay()s.

Inside the changed() event though, is a call to llOpenRemoteDataChannel(), and that's the part that's not working. It should re-register the data channel with the new sim, but it's not.

Hrm, is the remote_data event failing outright then or returning a nonsense result? One thing I've been uncertain about XML-RPC is that the llCloseRemoteDataChannel function doesn't work, and I don't know if this is maybe causing issues? When you receive the changed event, are you resetting the script, or just calling llOpenRemoteDataChannel again?

I've tried it both ways. The wiki does indicate that llCloseDataChannel() does nothing, and it doesn't seem to affect my script if that call is in there or not.

The call to llOpenDataChannel() seems to work, but it doesn't actually open the channel. I do get a remote_data event, with a channel key. It's the same channel key as it had before. And that works just fine, as long as you're flying into a new sim and not teleporting.

But on a teleport, the changed event calls llOpenDataChannel, which raises a remote_data event, which returns the same channel key as it had before (all the same as flying into a new region, which works), except now any attempt to send data to that channel key from an outside source times out.

Simply resetting the script doesn't help. The default state_entry calls llOpenDataChannel which returns the same dead channel key.

If I detach and reattach the HUD, on_rez calls llOpenDataChannel, which raises remote_data, this time with a brand-new channel key, and that works. But obviously I can't ask people to detach and reattach their HUD every time they teleport.