How to use llBreakLink

I have a teleport pad, I want to link it into the wall of my house (the house moves, I want the pad to move with it. To clarify: ALL the rooms of the house, (separate objects) move independent from each other, each room has a teleport pad on the wall, the telepads talk to each other and report their current positions). My teleport pads work great when they are single prims. When they are linked to a room they don’t work, (which is just as well since they work by warpPos, UnSit, warpPos which doesn’t work unless they are the root prim, and even if they were they would drag the whole room with them). No problem, I’ll just llBreakLink before I warpPos and llCreateLink when I get back. But this requires permissions.
No problem, I’ll ask for permission during on_rez(). The owner of the house will grant it once, and then I can call llBreakLink all I want. The documentation about llBreakLink says “Once the PERMISSION_CHANGE_LINKS permission is granted there is no way to revoke it. The script will only lose the permission if it is reset or the object derezzed (deleted, detached, or taken)”. Well, this doesn’t work. Putting a call to llRequestPermissions() inside on_rez() does not result in the permissions dialog box coming up when the linked object is rezed!
No problem, I tried moving the call to llRequestPermissions() into state_entry() and now the dialog appears. I click OK, but despite the documentation that says “never loose the permission”, I get the debug channel message “permission not set” when I call llBreakLink().
The example code always shows this strange thing: Instead of asking for permission once, they ask permission every single time they want to break a link, and put the call to llBreakLink inside the run_time_permissions() event. Well, this is weird. If “there is no way to revoke”, why ask again EVERY SINGLE TIME? But OK, I tried it that way and the result was that the dialog box appeared EVERY SINGLE TIME and then llBreakLink failed to break the link every single time. No debug channel message, but my prim does not unlink.
What do I have to do disconnect my prim from the linked object? (I haven’t even gotten to the llCreateLink, is that going to be this much trouble?)

How are the rooms moving? By selecting and then editing? Or do you have a system set up to move the rooms? If it is the later then just tie that into the individual teleport pads so that they move when the room does.

Anther possibility is to have a touchpad on the wall that will rez a new tp pad in front of it when you move the room and can also send a die command so that you don't have to manually delete them.

- I posted a question here asking how to make moving/floating houses once, but apparently this isn’t common. I’ve tried several different ways myself. This thread probably isn’t the forum for this, but YOU ASKED so here is my litany: The rooms, which each look like a soap bubble with a floor in it, move according to a chaotic algorithm. They rise like in an updraft over a fixed base with the front door telepad in it. At a preset altitude they drift sideways then float down slowly. At a lower preset altitude they drift towards the base room until they hit the updraft and zoom up again. I have modeled this behavior with empty rooms already. But how to implement this with avatars in the rooms?
- Well, I tried making each room an autonomous vehicle, using balloon as a model. Unfortunately, vehicles seem to expect everyone to sit in them and not try to walk around. An unseated avatar acts like a physical rock added to the balloon, it drifts down unless I compensate by increasing the Z of my linear motor force, but how much to do this is unknown. Three unseated avatars makes my room fall out of the sky. This is not good. I want to invite lots of people to my house, I want all of them to be able to walk around or dance, not be required to sit all the time to keep the room afloat. I considered writing adaptive algorithms: Increasing the linear motor Z until the gosh-darned vehicle hovered at the altitude that I told it to. But this seemed silly at first. (I’m reconsidering doing that now). Also, vehicles have limits on the number of prims. I want to be able to put furniture in my rooms. Furniture linked to the room overflows the prim count. Furniture not linked to the room stays behind when the room moves.
- So I tried making each room a physical object. The nice thing about this is that there seems to be a kind of friction: When the physical room moves, avatars standing on it get dragged along with it. If the room moves too fast, the legs of the avatars move as if they are walking. When the room moves up or down too fast the knees of the avatars bend. If I keep the drift of the room to a slow rate this decreases to a level that is not objectionable. But when the room turns, there is no rotational friction and the avatars stand still while the room rotates around them. (Vehicles are physical objects and have linear friction but no rotational friction also). But the killer objection is that physical objects have “energy” which runs out and then the room falls out of the sky. This is not good.
- So I made my rooms non-physical objects since they stay where you llSetPos them and don’t fall down. Unfortunately, llSetPos has a 0.2 second delay, but multimove and other scripts suggest ways to get around this. (Having multiple scripts synchronized somehow that each applies an llSetPos at different times). However, non-physical objects don’t even have linear friction. I tried implementing this using llPushObject. I did an llSensor() to find all the avatars inside my room (which is spherical so llSensor finds them all) and then I used llPushObject to push them in the direction of drift and rotation. (Since vehicles and physical objects don’t have rotational friction I would have to do part of this anyway). Then I learned that llPushObject has VERY STRANGE BEHAVIOR with respect to energy. If an avatar is near the center of a room, llPushObject does what you would expect if it worked like llApplyImpulse, except avatars have several kinds of friction or drag that are difficult to predict. Even ignoring friction and drag, at only a few meters away from the center of the room the amount of “energy” required for llPushObject increases until the room runs out. Running out of energy causes a discontinuity in the force equation and makes it difficult to calculate how much to push. The Wiki’s claim that the amount of push falls off with 1/r^3 but this is not correct. The amount of energy increases with 1/r^3 while the amount of push is constant until you run out. If you run out of energy pushing the avatar in the edge of your dance floor (far from the center) then you have none left to push the other 9 dancers and their friction stops working until your energy rises back up again. They slide frictionlessly into the wall as the room moves. This is not good.
- So the dance floor cannot use llPushObject from the center of the room to implement friction for a room full of non-seated dancers. I could have a phantom object that llSetPos’es to the center of each avatar and pushes them from there. llPushObject from a distance of 0.0 uses very little energy and one small prim could push a room full of dancers around. But llSetPos has that delay of 0.2 seconds! Ten dancers would have a 2 second delay on the friction with the floor. This is not good. I could use the multimove solution but organizing the pushers and deciding how to push a variable number of avatars is a difficult project. I’d have to have a fleet of phantom prims that assign themselves to each avatar in the room. Or rez a pusher every time I detected another avatar arriving and have them die when their assigned avatar left..
- I finally decided on the following solution: The front door has a telepad to get you into all the other rooms. This telepad will refuse to let you in unless you are wearing a “key” to the house. The key is a prim with a script that listens to commands from the floor and llApplyImpulse’es the avatar around to implement friction. How much to push is still a function of the built in friction and drag of avatars, which I have not measured yet.
- UNLESS YOU CAN SUGGEST A BETTER SOLUTION!!!
- As you did suggest, the teleport pads could listen to the “friction channel” and move along with the room. (I was going to have the rooms pause during teleports so the telepads could get back to where they started). But for now I’m working on the llBreakLink solution, and I can’t get llBreakLink to work at all! hasn’t anybody else ever called this function? What am I doing wrong there?

Interesting project!!!!

When debugging, if all else fails (Or actually before you try anything else), SIMPLIFY!!!!!!

This works fine and only asks permission once. Create two prim and link them:

Root Prim:

key tpKey = paste key here;

integer a = 1;

default {
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS);
    }
    touch_start(integer total_number)
    {
        if(a)
            llBreakLink(1);
        else
            llCreateLink(tpKey, TRUE);
        a = !a;
    }
}

Child Prim:

default {
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS);
        llOwnerSay((string)llGetKey());
    }
}

Paste the key from chat into the Root Prim tpKey. Notice that you have to have permission set in BOTH.

- In BOTH? Well then this is what I am doing wrong!
- But tell me, why are you sending 1 (LINK_ROOT) to llBreakLink? The Wiki says that this means “send to the root prim” whatever that means. Does that mean unlink the root from all the chidren? It seems I would rather use LINK_THIS, but with a test that had only 2 prims both of these constants do the same thing. Does LINK_ALL_CHILDREN or LINK_ALL_OTHERS do the same thing as llBreakAllLinks? What is the difference between those two?
- By the way, a big thanks for the concise example script! So many samples have huge amounts of unrelated baggage in them. For example, the example in the llBreakLink Wiki page has the break done in a separate sate. Why? Is that necessary to make it work? The same example also calls the new state from inside the run_time_permissions event. Why? Many of the permission examples do this, why? Is it necessary to do it this way? APPARENTLY NOT from you example.
- Your example scripts works when I try it with two simple prims, so I know a simple solution is possible. When I cut and past the code into my teleport pad, it gives me the debug message again, but I’m on the track to figure out why.

Good question on 1 but heck if I know. I was thinking went in order of linkset starting with 0. But it does work as you saw so you could always try it with a set of 3 prims to double check. Glad you are making progress!

- In BOTH? Well then this is what I am doing wrong!
- But tell me, why are you sending 1 (LINK_ROOT) to llBreakLink? The Wiki says that this means “send to the root prim” whatever that means. Does that mean unlink the root from all the chidren? It seems I would rather use LINK_THIS, but with a test that had only 2 prims both of these constants do the same thing. Does LINK_ALL_CHILDREN or LINK_ALL_OTHERS do the same thing as llBreakAllLinks? What is the difference between those two?
- By the way, a big thanks for the concise example script! So many samples have huge amounts of unrelated baggage in them. For example, the example in the llBreakLink Wiki page has the break done in a separate sate. Why? Is that necessary to make it work? The same example also calls the new state from inside the run_time_permissions event. Why? Many of the permission examples do this, why? Is it necessary to do it this way? APPARENTLY NOT from you example.
- Your example scripts works when I try it with two simple prims, so I know a simple solution is possible. When I cut and past the code into my teleport pad, it gives me the debug message again, but I’m on the track to figure out why.

Just tested and that should have been llBreakLink(2);

But the other caveat is that when you initially setup the linkset you need to make sure and select the tp pad as the next to last link, right before the root prim.

- Why do so many examples have that strange order of doing things? When you call llRequestPermissions(), it pops up the dialog ASYNCRONOUSLY and the script continues to run. So you cannot immediately call llBreakLink() because you have not had time to press the button and grant permissions yet. If you really wanted to break a link ASAP, you have to put the call to llBreakLink in the run_time_permissions() event, which will be called as soon as permission is granted. If you are not in a hurry, there is no reason to do this. Request permissions once in State entry() and you can then call llBreakLink() all you want down the line.
- It is not necessary for the root prim you are unlinking from to call llRequestPermissions(). Only the prim calling llBreakLink needs to do this.
- The Wiki page says that llBreakLink() will remove seated avatars, I should have paid attention to that. But as it unseats the avatar it shouts the “you don’t have permission” error on the debug channel, making you think that your RequestPermissions didn’t work when in fact it did.
- The number that you send to llBreakLink() is the link number of the prim you want to unlink, so llBreakLink(llGetLinkNumber()); is the way to unlink yourself. This works no matter where you are in the chain. When you call llCreateLink() you always end up as link number 2 unless you ask to be the root prim. (That I saw in the Wiki).
- The inability to unlink when you hold a seated avatar means that I cannot use llBreakLink() for my original purpose of disconnecting from the room when an avatar sits on my prim. So I have to go find a different way to keep my teleport prim in place on a moving room. But in the mean time I’ve written a cool self organizing teleport network prim. Just rez one and it talks to all the others, picks an unused port number, keeps track of where the rest are when they move, all without requiring any configuration or editing. I’ll post it to the library soon. I’m also going to go add some of the above notes to the Wiki for the next poor sucker who tries to call llBreakLink!