FYI Many things below are pending the next update:

I thought I would explain to modders different things that this mod can bring to the doors you add. Most of which can be done without knowing LUA at all. Just adding/changing some attributes in your .object files will suffice. For the most part, I'm not covering the advanced stuff that was already possible in vanilla. If you add these attributes, the people who use your mods won't REQUIRE this mod, except that they won't experience the changes you added. I don't believe any of this would trigger a crash - with the possible exception of targeted scriptedEntitly calls. But if you understand how to do that, you probably understand why already.

"defaultLocked" : true|false
if set, your doors will not open unless there is a wire signal on input node 0 and 1. DO NOT USE THIS if your door doesn't have at least 2 input nodes, else it will be impossible for players to open. Using this is sort of like adding an AND switch into your door. But also it means your door can't operate absent the wire inputs. This is intended mostly for easier wiring on dungeon doors(tile protection thus no wire tampering).

"queryOpenRadius" : 1|inf
This is the scan radius for your door aka how far away from the center of the door will be scanned. You don't actually need to set this really unless you hate the default range. Note though that this attribute will be entirely ignored if the radius isn't at least half the distance of the door's longest dimension. That is a hard minumum to ensure that the player will be detected at any point along the door.

"scanTargets" : ["player", "vehicle", "mobile", "creature", "monster", "NPC", "object", "stagehand" ]
These are the things that will be scanned for, and therefore trigger the door to open. There are probably more valid types than that you COULD use if you so desired. Many of those probably aren't useful things to search for in a door, and yet you can if you want. But you might want a trap door that only detects "monster" for example, and therefore only opens when a monster stands on top. By default it will look for [ "player", "vehicle" ] which is probably optimal for most cases.

"detectBoundMode" : "position"|"collisionarea"|"metaboundbox"
"collisionarea" is the default, but you could use a different method if you wanted.

"noAutomaticDoors" : true|false
I'd say this is obvious enough. Say you want some of these features, but have a good reason this door should not be automatic. Set this, and it won't be. Seems like an obvious thing necessary for hidden doors. Note that this will also prevent the door from acting as a proximity sensor as it shuts down the detection too.

"closedMaterials" : ["someMaterial", "someOtherMaterial"]
This allows you to have the door 'made' of some other material than the default "metamaterial:door", "metamaterial:lockedDoor" while the door is closed. The first is the regular material, and the second is primarily when the door is wired on input node(0). This is an easier alternative than building a big "closedMaterialSpaces" table structure, although as in vanilla this is also fully supported.

However using "closedMaterials" will make everything the same material, so this isn't desirable if you are making some spaces different than others. For example a damaged door that only opens half way (thus requiring you to ball morph in order to pass). But for all other cases of needing to use a different material, this may be more desirable. I might also note the actual material switch(thus collision changes) should be a bit faster now as compared to vanilla. Chucklefish sure likes to re-calculate values rather than save and reference.

"openMaterials" : ["someMaterial"]
Works like "closedMaterials", but effectively only the first material will actually be used. This is if you want to have the open door be 'made' of a different material than nothing. I use this for my doors which don't allow liquid to pass - in addition of course to making a custom tile which carries this attribute. This is an alternative to building an "openMaterialSpaces" table.

"platformDoors" : true|false
Added this for the Platform Hatches mod, but anyone could use it. By default, any horizontal door(automatically determined) will use the center(x, y) - (0, radius) as the scan radius center. So it won't scan above the door(which could get annoying, fast) but will open from below and close after you jump through. If you set this, the scan radius will use the true center instead. Since that mod adds platforms to the openMaterialSpaces, this is a more desirable way to operate.

"noNPCuse" : true|false
This is sort of a special use thing. You probably would use this in combination with the vanilla
"interactive" : true|false
to have a 'door' (or not quite a door) that cannot be opened by NPC nor player. Absolutely cannot. The openDoor() function now transfers to another function... unless this is set. The NPC's requests will be ignored. To actually open the door, you'd want to do a scriptedEntity() call to realOpenDoor(direction). So you can do this from a mission, or maybe put together a custom script that calls it based off of say... Universe flags. Or maybe the ship's AI menu - that's what I intend to do for my forthcoming ship-to-station deploy-able airlocks.

Speaking of custom functions, there is an added blank function aptly named extraFunction(). If you add an extra script to your object (after door.lua) then you can just redefine the function itself within your own script. I believe they should share a common environment per object. And update() should already call this function just so long as "noAutomaticDoors" isn't set. Easy hook right out of the box. Assuming you need multiple functions, just use this one as a control function for the others.

Now I'm going to cover some behavioral changes versus vanilla. Besides the obvious automatic functionality of course.

This supports more than 1 input and output node in a meaningful way.

input node 0 will operate as you expect now. When connected, doors will stay closed until there is a signal. No automatic doors. No interaction.

input node 1 will cause the door to open when there is a signal, but won't otherwise affect operation of the door. Still automatic(if it otherwise was) and still interactable(ditto). Supposing you wanted multiple doors to open or close together, this is the most ideal option. Additional nodes (2, 3, etc) will all operate the same way. Thus you could consider anything higher than node 0 as acting in an 'or' switch manor.

output node 0 will send a signal if the door is open, and nothing if not. What's more, the door will NOT automatically shut when the player opened it when this is wired. Mostly for the Avian mission, but also so that you can more effectively use the doors as a switch if desired. It will then maintain the state until the player(or NPCs) manually close the door.

output node 1 sends signals not based off of the door's actual state, but when it detects the entities it is looking for as determined by "scanTargets" above. Thus the door can double as a proximity sensor when a 2nd output node is present. Again by default it only looks for ["player", "vehicle"] and thus this doesn't trigger from NPCs by default... of course you can adjust as desired.

From the LUA side, if a different object/npc/etc wants to know if a particular door is CURRENTLY operating in an automatic fashion, you can use hasCapability("automaticDoor") in the same way the vanilla use of "lockedDoor", "openDoor" etc. For example if input node (0) is wired, this will return false. Ditto if automatic functionality is disabled otherwise or this mod isn't installed at all. So it isn't a problem of assuming this mod is installed. You'll just get false from this function even in vanilla.

I might add for those that are messing with colonies - I completely changed the implementation of doorOccupiesSpace(position)
Nothing new you have to do on your end, but know that it should result in far less lag from all the repeated calls. It still couldn't hurt to turn down the frequency of these integrity checks. But you 'might' want to recommend this mod as a compliment for that reason alone.

Up til now, these things can be used without without necessarily knowing if your end users are also using Automatic Doors - without fear of any undesirable effect in any case. Vanilla doors.lua will ignore these things. Past this point, using these things will require you to either:
1. Require the Automatic Doors mod
2. Rename the files and include them with your mod. Preferably to avoid conflicts do this -
change
"scripts" : [ "/object/wired/door/door.lua"]
to
"scripts" : [ "scripts/mod_AuthorName_here/individualName.lua" ]

Now if you are including this in a mod that isn't open permissions, please add at least that this portion of your mod(these assets) are open permissions - even if you modify them. The rest of your mod can be whatever permissions you like. Both lornlynx and bk3k are in agreement that this mod and its assets are open permissions. End of story.

"openingAnimation" : "someAnimationState"
"lockingAnimation" : "someAnimationState"
"lockedAnimation" : "someAnimationState"
defaults to
"openingAnimation" : "open"
"lockingAnimation" : "closed"
"lockedAnimation" : "closed"

This is for those using custom .animation files. For example the vanilla doesn't have a separate "opening" state as compared to "open". In my case I wanted a separate opening animation sequence. For some doors I actually have a looping animation for "open" thus the need to be separate. And thus I needed to add a new state name. I have a locked animation frame for when the door is locked, or closed because of input node 0 not having a signal.

You CAN still sort of not require Automatic Doors and set up your animation to use alternate state names - provided the vanilla names are present in your .animation file. But absent this support the end users will be missing animations and things just won't look right without.

There are some included packages you could use for any other mods too.

bk3k-cMath2d.lua is for easy math dealing with tables you know to be coordinates. 2 dimensional (x, y) obviously. I think the use of this is pretty straightforward and obvious. It could save you some time and clean up your code. Fairly complete but if you have some requested additions, I'd be glad to entertain them.

bk3kLogger(0.1).lua is not feature complete/finalized and probably has bugs/errors. But it can be useful enough to dump tables into the log in an easy to parse format. In particular you would probably want to dump storage and self, plus perhaps any tables you have made. This is a debugging aid. Look within door.lua to see how this is used currently. You can set the context(a table of strings that will be automatically joined together) as well as sending the tables. You could conceivably even call this from anything via scriptedEntity() call upon any door and pass your debugging tables and context(also a table) as arguments.

I intend to add to this things such as sending it data, it stores the data, send it more, etc. Then dump what's there at any given point/trigger. Or clear it etc. A data sanitizer(complete with reporting of what's wrong/what needed sanitized) that would be somewhat expensive to run but useful for debugging ...or just not failing when it rightly should. Things like that.

And lastly let me ask, are there things that you (our fellow modders) could use? From door.lua? From the complimentary packages? Things that would allow you to take your modded doors(or similar collision/state-changing objects) that much further? Any reasonable request will be honored. After all some things just work better when integrated from the start.