Rail Docker Logic Controls

[Lone_Puppy]

Main idea is to allow for logic control to turn Dockers on your ship on/off. Especially if you have more than one.
This would be seen in the hotbar as a faded icon or something to indicate it's inactive/disabled.

Useful for;
- preventing theft
- preventing mothership recall docking problems when drone/ship has multiple dockers (Shuttles)

Sensor connectivity could be useful.
Maybe have ability to sense connected/disconnected.

 

[DrTarDIS]

Sensor connectivity could be useful.
Maybe have ability to sense connected/disconnected.

Current ways to "mostly" do what you're talking about.

C -> V from rail to an activator block. Can be green docking rails.
**Lets you know if the rail is in use.
**Can connect multiple rails to a single block

C whatever activator you connected from that length of rail. --> V onto a "not" Block.

C "not" -> V to the pickup point.

This setup automatically turns the nav icons for pickup points(visible when you have docker selected in hotbar) on/off and dis/enables the pickup latching of the point itself. Very useful for multiple drones on recall to the same pickup point. Less useful than having multiple Pickups with similar logic for rail speed or orientation.

IIRC there's examples of exactly this type of rail logic implemented in the abandonware link in my footer. 80% sure the "front" drone racks have it all setup and debugged as of the last upload. If not completely debugged, the logic itself is setup and debugged in the "example" rooms around the center docking area for you to pick apart if you're interested.

TLDR: Rails are sensors and logic blocks in of themselves, if you use them right. You can even block a Docker with a rail block and convert it between Greay-solid-no-pickup-allowed and green-passthough-ok you can dock.

 

[Dr. Whammy]

Main idea is to allow for logic control to turn Dockers on your ship on/off. Especially if you have more than one.
This would be seen in the hotbar as a faded icon or something to indicate it's inactive/disabled.

Useful for;
- preventing theft
- preventing mothership recall docking problems when drone/ship has multiple dockers (Shuttles)

Sensor connectivity could be useful.
Maybe have ability to sense connected/disconnected.

I did an experiment a while back with anti-dock logic that performed these functions.

Basically you:
- Create a basic clock (a NOT signal cross-connected to a DELAY) then turn on the clock.
- Connect either clock-block and an ACTIVATION module to an AND.
- Connect the AND to your rail or docker.
- Hide you logic assembly somewhere out of the way so it's hard to see, shoot, torch, etc. It's pretty easy to hide with just 4 blocks.

When the ACTIVATION module is turned on, it will use the clock circuit to send a signal to the rail once per second that will force an undock. This worked well for rails but I also remember this working for dockers as well, since my primary motivation was anti-theft.

Give it a try. Just keep in mind, after a certain point, bugs may start to manifest if too much logic is used with rails.; especially on larger builds.

 

[Lone_Puppy]

I have actually used logic before in many ways, to achieve the functions you suggest. Both sensing and reject docking
The main problem I have is I want specific recall docking orientation of the docking entity, that has multiple dockers.
Pickup points use to work well in the early stages of development.

Here's my main use case scenario.
I have a shuttle with docker on the bottom and a docker on the rear hatch USD style.
I want the shuttle do dock with the rear hatch on recall, not the docker underneath.
There isn't room for logic.

 

[DrTarDIS]

I have actually used logic before in many ways, to achieve the functions you suggest. Both sensing and reject docking
The main problem I have is I want specific recall docking orientation of the docking entity, that has multiple dockers.
Pickup points use to work well in the early stages of development.

Here's my main use case scenario.
I have a shuttle with docker on the bottom and a docker on the rear hatch USD style.
I want the shuttle do dock with the rear hatch on recall, not the docker underneath.
There isn't room for logic.

Ahh, You're running into issues with the drone-AI just latching the frontmost docker all the time?
Ok, I get you.
+1 agree useful finction to have.

Work around of shifting the "docking arms" of pure green rails to "floating" so the USD docker alligns anywys (even if it's not the one that's in-use) not viable for you?