Opening doors from scripts

[animats]

Animesh NPCs can't "touch" things, so opening doors is a problem. Many common SL doors will accept commands on some channel to open them, and my NPCs need to know how to do this.

Major brand door command documentation -- notes from the documents for various doors.

I have NTBI, HD Emergency, and Kool Door covered. What else is out there in quantity that I should know about?  Thanks.

[Nova Convair]

Hmm .. my doors and other stuff does a channel calculation based on owner uuid and some math and a number that defines a logical block so I can have more than one communication cell in a sim. And I always have at least open/close/toggle commands - abbreviations like O,C,T - no need to waste space by writing whole words. Toggle is often not useful in my case. If you try to open an already open door with toggle you will see why.  Of course I only switch that on for doors that need a remote and thats few.

Other scripters will surely have all their own fancy ideas what kind of channel and what kind of comands are implemented.

A door script is no black magic, make your own and add the remote function.

[KT Kingsley]

You'll see a lot of Isil doors in a lot of sci-fi settings.

[Profaitchikenz Haiku]

21 hours ago, animats said:

What else is out there in quantity that I should know about? 

Timeless door scripts abound in a lot of the older stuff, but I don't recall they could be opened by a whispered command. Why not cheat and when they can't open a door work out which axis to use and just setPos inside or outside it?

[animats]

44 minutes ago, KT Kingsley said:

You'll see a lot of Isil doors in a lot of sci-fi settings.

"lsil"? Not finding that as a merchant name or product in Marketplace. Link?

1 hour ago, Nova Convair said:

A door script is no black magic, make your own and add the remote function.

This is about being able to open existing doors. I'm making NPCs that can live in SL as it exists, not just in places built for them. So I want them to be able to open at least the 5 most popular door brands.

 

[Qie Niangao]

7 minutes ago, animats said:

"lsil"? Not finding that as a merchant name or product in Marketplace. Link?

Presumably https://marketplace.secondlife.com/stores/135577  I don't know how common the doors are, specifically, but I guess I have some myself now that I think about it.

Frankly, I wouldn't have expected there to be that many doors that listen to chat (as opposed to link messages), and especially chat from non-avatar sources. 

[OptimoMaximo]

13 hours ago, animats said:

This is about being able to open existing doors. I'm making NPCs that can live in SL as it exists, not just in places built for them. So I want them to be able to open at least the 5 most popular door brands.

The thing is, I think, that animesh is too new as a feature to have hit such departments of creation. With this said, I would first try to create a simple model of communication in a custom door script in such a way that it works well with your npc. Once that is established, fill up an instructions note card with your npc open/close requests protocol (like: do they send a request in chat upon collision, or do they check whether it's a door in other ways, etc). Once that is in place, modify an existing major brand door script so that it works as well as your own. Contact that script creator and see if they're willing to adopt such functionality or request permission to redistribute the modified version. You will end up creating an npc creation pack of scripts. If one of the major brands would adopt your solution, the others will come. 

[animats]

14 minutes ago, OptimoMaximo said:

The thing is, I think, that animesh is too new as a feature to have hit such departments of creation.

I know. This, though, is an easier problem than finding animesh character models and clothing.

What I'm working on now is making it easier to prep a sim for use with NPCs. Door handling is part of this.

So I'm collecting enough info that my NPCs can open doors using the APIs of the more popular doors. The main headache is that you have to know info such as door IDs to open them that way, which means more info users have to enter into notecards. That's bad for ease of use.

Most automatic doors don't recognize my NPCs. The NPCs use keyframe animation. They're ordinary non-physical non-phantom objects to the sim. So they aren't detected as "active" by llSensor or as collisions with llVolumeDetect. (Volume Detect and regular collision detection differ on this.)

I have my own door control script, which uses a short range llSensor to detect nearby prims and reads their velocity. If they're seen with nonzero velocity, they're considered active. That seems to be one of the few ways to detect keyframe-driven objects. That script controls the double doors at my workshop in Vallone, which will open for avatars, physical objects, vehicles, and keyframed NPCs. I may use this approach and make it talk to other door brands, so that, rather than configuring the NPC, you configure a door sensor and place it above doors NPCs need to use. Easier to understand than overly complex notecards.

The other door problem is that linked doors and the static navmesh do not play well together. If you set a wall with a linked door as "static obstacle" or "walkable", which is done from Build->Pathfinding->Region Objects, the door cannot move under script control. That setting is for the entire linkset, not per prim. You get an error ""Unable to set prim position or scale: object contributes to the navmesh." if you try to open the door. So doors have to be unlinked separate objects. That's sometimes a pain.

Fortunately, if you set a whole building as "walkable", what actually happens is that floors become walkable and walls become static obstacles. Exactly what you want. Even better, anything below 65 degrees from horizontal is walkable, so stairs and ramps work. Works for both prim and mesh linksets.  The wiki does not tell you about this very convenient feature. For most buildings, once you've dealt with the door problem, it Just Works, as long as the physics model is reasonable.

(I'm not turning on built-in pathfinding, but I am using the static navmesh, querying it with llGetStaticPath. That gives me a path to start from, which is then checked with many llCastRay calls and modified by a maze solver to go around obstacles up to 10m-20m wide. The static navmesh is cheap to use, because it only changes when somebody manually edits a static object, then rebakes the navmesh by clicking on the triangle with winding arrow icon in the viewer.)

 

[ChinRey]

19 hours ago, Nova Convair said:

Hmm .. my doors and other stuff does a channel calculation based on owner uuid and some math and a number that defines a logical block so I can have more than one communication cell in a sim.

Yes, that is a bit of a challenge. You can't really have one universal door open channel/code combo since there's a good chance there will be several doors within chat range. My door script (Bel's Menu Door) has multiple access/lock modes too and the variant that sells the most is the CaspeLet compatible one, adding even more complexities.

I won't have time to do anything about it this side of christmas.

[animats]

6 hours ago, ChinRey said:

You can't really have one universal door open channel/code combo since there's a good chance there will be several doors within chat range.

The NPC can get close and do llWhisper.

[Qie Niangao]

12 minutes ago, animats said:

The NPC can get close and do llWhisper.

Or presumably llRegionSayTo() : it'll have llCastRay'd around the joint enough to decide this hunk of stuff might be a door, so it must have its UUID handy.

[ChinRey]

1 minute ago, animats said:

The NPC can get close and do llWhisper.

That's still 10 m but yes, it would help. But like Qie I was thinking more of how we can "pair up" doors and NPCs and better define which door which NPC opens which door when.

There are several ways that can be done but it would require a bit more than the basic listens some comemrcial door scripts come with now.

Btw, it is possible to add NPCs compatibility to a door even if the door script doesn't allow it. Just add a separate script that opens the door for the NPC. It's hardly an ideal solution but worth considering if it's the only option.

[Profaitchikenz Haiku]

As a thought, could the NPC move right up to the door to collide with it? There are many mesh houses out now where the doors work on collision. (Although I don't know if they would activate when a non-avatar collides with them).

[Mollymews]

15 hours ago, animats said:

I have my own door control script

i think this most probably the solution over the long term

a NPC-friendly door recognition/operating protocol.  If this protocol (with a script example) was made publicly available  then people into NPCs would most likely include it in their own doors

[animats]

19 hours ago, Mollymews said:

i think this most probably the solution over the long term

a NPC-friendly door recognition/operating protocol.  If this protocol (with a script example) was made publicly available  then people into NPCs would most likely include it in their own doors

Why that doesn't work. From XKCD. (This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License.)

[Profaitchikenz Haiku]

This shouldn't be a complicated issue, it all depends on the people present.

If there's nobody present, the NPC can try to open the door using what standards it knows, and if that fails, then I see no problem with it setting position to just inside/outside the door. Who's going to get offended?

If there is somebody else present (within chat range) and the NPC can't open the door, then the NPC simply asks for assistance, "Knock-knock". No need to alter any scripted doors.

Edited December 18, 2019 by Profaitchikenz Haiku

[Mollymews]

1 hour ago, animats said:

Why that doesn't work. From XKCD. (This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License.)

RLV/RLVa, AvSitter, Intan