One way wall...?

im looking at this wall in game, its 1 prim, you can walk though one side and not the other how the heck did they do this? I cant figure it out, its like one side is phantom, and the other side isn't. Its a script for sure, but I cant view the script

I saw that too and was wondering how it's scripted. Probably something ridiculously simple that I'm not thinking of, but it's definitely a neat thing, although I can't see much use for it personally.



http://www.secondscripter.com/

It's either normally phantom, and turns solid when an av collides with it from one direction, or vice-versa. There are similar scripts floating around which make a prim selectively phantom or solid depending on, say, group affiliation or the name appearing on a whitelist, etc.

Could it be that a script in the wall sense the nearest AV, find its position and set the phantom true or false accordingly? I guess that would work...
What happens when two AVs approach the wall from each side? will it be phantom or not?

Depends on who it senses first... or more specifically, who it senses second.

I think I walked trough such a door in the Devil's Labyrinth and was totally lost because I couldn't go back..lol

Brasou

I have a door script that can do that, it requires 2 prims though, the 1st for the wall and the second for a remote which is placed a few metres in front of the wall and is transparent.

When the avatar colides with the remote it sends a message to the door script in the wall, through a notecard I can alter the way the door opens (setting it to 0.001 so it opens but would not be visible to the eye) and also set it to phantom on open, this option is used so on an actual doors that open fully they don't bump your AV when opening towards him/her. Once opened an Autoclose feature is enabled so after 20 seconds for example (allowing enough time for an AV to pass through) it will automatically close. Now that you are on the other side there is no remote to open it again so it would appear as a solid prim.


I think it would be cool if used on something like a Labrynth or maze.

Wouldn't a sensor with the arc set to PI/4 or even PI/2 and the arc range facing in the direction of the "incoming" agent open the door for an avatar on one side of the door but not the other?


Or is the visualisation on this page outdated and wrong?
http://rpgstats.com/wiki/index.php?title=LlSensor

Ooooh, I know this one!

One sided walls may have a sensor that is not attached to them in world. More than likely it's hidden, but it basically is something that triggers the script on touch and makes the wall go phantom. The sensor normally goes right up to the wall so it goes back to being non-phantom right when you step through the wall, as you stop having your avatar touch the sensor.

The wall prim itself could have a sensor in it, but collision would probably be more efficient than a sensor.

I made one of these once on a sim boundry.
Made a large solid object and placed it right on the edge of the sim.
When on the same sim as the object.. you hit it. When on the other sim.. you are able to pass through it before your client actually switches to the new sim. This then acts as a oneway door per-say.

you could do some math using "llDetectedRot" and a collission sensor.. so that "if the avatar is facing mostly east, switch phantom."

Be worth experimenting with at least/

Right. Or simply test the position of the avatar on collision. Something like:

(Note: Not yet compiled; may need some minor syntax fixes.)

// Make sure that the wall's narrow dimension is along its x-axis.  Avatars
// will be able to cross when moving in the direction of the positive x-axis
// (in the direction the red axis arrow points) but not the other way.

list passingAvatars = [];
integer nPassingAvatars = 0;

integer avatarCanPass(key avatar)
{
   list details = llGetObjectDetails(avatar, [ OBJECT_POS ]);
   if (llGetListLength(details) == 0)
   {
      return FALSE;
   }

   vector avatarPos = llList2Vector(details, 0);
   vector relPos = (avatarPos-llGetPos())/llGetRot();

   return (relPos.x < 0.0);
}

// Try this velocity-based version too.  See which works better.
integer alternateAvatarCanPass(key avatar)
{
   list details = llGetObjectDetails(avatar, [ OBJECT_VELOCITY ]);
   if (llGetListLength(details) == 0)
   {
      return FALSE;
   }

   vector avatarVel = llList2Vector(details, 0);
   vector relVel = avatarVel/llGetRot();

   return (relVel.x > 0.0);
}

openPortal()
{
   llVolumeDetect(TRUE);
}

closePortal()
{
   llVolumeDetect(FALSE);
   passingAvatars = [];
   nPassingAvatars = 0;
}

default
{
   collision_start(integer nDetected)
   {
      integer i;
      for (i = 0; i < nDetected; ++i)
      {
         key id = llDetectedKey(i);
         if (llGetAgentSize(id) != ZERO_VECTOR &&
             llListFindList(passingAvatars, [ id ]) < 0)
         {
            if (avatarCanPass(id))
            {
               passingAvatars = (passingAvatars=[])+passingAvatars+[ id ];
               ++nPassingAvatars;
            } else
            {
               closePortal();
               return;
            }
         }
      }

      if (nPassingAvatars > 0)
      {
         openPortal();
      }
   }

   collision_end(integer nDetected)
   {
      integer i;
      for (i = 0; i < nDetected; ++i)
      {
         key id = llDetectedKey(i);
         integer index = llListFindList(passingAvatars, [ id ]);
         if (index >= 0)
         {
            passingAvatars = llDeleteSubList(passingAvatars, index, index);
            --nPassingAvatars;

            if (nPassingAvatars == 0)
            {
               closePortal();
               return;
            }
         }
      }
   }
}

Ah, but what if the av backs into the wall?

Take the dot product of the wall prim's (for example) fwd axis vector and the difference between the avatar and wall position vectors. If positive, avatar is on the +x side. If negative, on the -x side. Switch phantom on or off accordingly.

init()
{
    llSetPrimitiveParams(
        [PRIM_COLOR
        ,   ALL_SIDES // faces
        ,   <1,1,1> // color
        ,   1.0 // alpha
        ,PRIM_COLOR
        ,   4 // JUST the door face
        ,   <1,1,1> // color
        ,   0.75 // alpha
        ,PRIM_TEXTURE
        ,   ALL_SIDES // faces
        ,   "7bef5e2f-40a2-d753-42e9-4b2a04df0d7b" // texture
        ,   <1,1,0> // repeats (ignore z)
        ,   <0,0,0> // offsets (ignore z)
        ,   0.0 // rotation
        ,PRIM_SIZE
        ,   <0.10, 1.50, 3.00>
        ,PRIM_FULLBRIGHT
        ,   4 // face
        ,   TRUE // toggle
        ]); 
}

permit()
{
    llTriggerSound("0cb7b00a-4c10-6948-84de-a93c09af2ba9", 1);
    llSetAlpha(0.25, 4); // open door
    llSetStatus(STATUS_PHANTOM, TRUE);
    llSetTimerEvent(1);
}

block()
{
    llTriggerSound("be582e5d-b123-41a2-a150-454c39e961c8", 1);
    close();
}

close()
{
    llSetAlpha(0.75, 4); // close door
    llSetStatus(STATUS_PHANTOM, FALSE);
}

default
{
    state_entry()
    {
        init();
    }
    
    on_rez(integer startparam)
    {
        init();
    }
    
    collision_start(integer num_detected)
    {
        vector angle = llRot2Euler(llDetectedRot(0) / llGetRot()) * RAD_TO_DEG;
        if (llDetectedType(0) & AGENT)
        {
            if (angle.z > 55 || angle.z < -55) block();
            else permit();
        }
    }
    
    timer()
    {
        close();
    }
}

Here's what I came up with. pretty simple. The avatar CAN "walk backwards" to go back through the doorway. I'm sure there's some math-fu that can be done with llDetectedVel(0).. or perhaps as simple as a simple comparison of llGetPos (on the door) and llDetectedPos(0) (of the avatar) to determine if they are on "X side" or "Y side"

If the wall is only a single prim, then yes it probably uses a sensor set this way. The sensor only scans on one side of the wall so won't detect avatars on the other side.

If it was two prims then I would say it's using a collision detector in the second prim which is only on one side of the wall.

heh, it can be done even more simply


use llDetectedPos() and llDetectedVel() in the collision_start event to determine where and which direction the avtar is travel from and to when it collides. if it's headed in the right direction from the correct side, then turn phantom, if not, then stay solid.


you can also use this with volume_detect on a prim that stays phantom to shove the avatar in the correct direction, or bounce it away if it's coming from the wrong direction (assuming push is enabled for you on the parcel)

Yes. Yes, you could do something like that.

this one worked great, and it's quite simple, i recomment using PI/4 instead of PI/2 to centralize it more in front of the door