Docked Entity Rail Transfer/Transition

[TheOriginalBIT]

Backstory / Use case

I've been working on some fairly compact and complicated rail systems and there are times when a docked entity needs to be transitioned between rails; for example the entity travelling horizontally and then needing to travel vertically. To achieve this I created the below setup

(this is a simplified representation for demo purposes, in actual usage there are several blocks adjacent to the rail docker preventing the supported transition the below could actually achieve)​

So when the entity hits the last rail block it gets undocked, after the 4 second cool-down the pickup rail brings the entity up to the vertical rails, luckily before the magnetic docking pulls it down to the horizontal rails.

There are three issues with the above setup

1. The entity was undocked and has the 4 second cool-down, creating huge physics problems if the mothership was in motion;
2. Being undocked also creates (undock) notification spam and radar (diamond) spam; and
3. It is only unidirectional, there is no way (that I can think of) to make this bidirectional;

Solution / Suggestion

The ability for a docked entity to continue along any adjacent rail, regardless of whether the rail is on the same entity, would solve this issue.

This is the setup that I see fixing the above issue, if docked entities could transition between parent entities

Currently a docked entity will stop here

However if we allowed it to continue just one rail block further (onto another docked entity) it would trigger the activation module and this would happen.

(obviously I'm having to manually trigger it in this case, but you can see what would happen)​

The docked entity would then transition once more back onto the original docked entity and be travelling vertically.

The benefits of this system means that nothing ever needs to undock so there are no longer physics problems or any notification/radar spam (issues #1 and #2). If you add some extra logic to switch the rails direction this can also be made unidirectional (issue #3) reducing on space requirements for this 'complicated' rail usage.

Let me know what you all think.

 

[Jaaskinal]

[SUGGESTED]<multiple times>

 

[TheOriginalBIT]

[SUGGESTED]<multiple times>

Apologies, I went through the first 10 pages of suggestions and couldn't see anything related to this.

 

[Lone_Puppy]

I thought inter-entity rail transfer is planned.

 

[Jojomo]

Apologies if I've misunderstood and this doesn't apply here, but Bench's tutorials include rail travel that goes from horizontal to vertical:

 

[TheOriginalBIT]

Apologies if I've misunderstood and this doesn't apply here, but Bench's tutorials include rail travel that goes from horizontal to vertical:

Yeah I had a little footnote under the first image

This is a simplified representation for demo purposes, in actual usage there are several blocks adjacent to the rail docker preventing the supported transition the below could actually achieve​

The particular case I'm using this technique in it is actually a small fighter I want to transition from horizontal rails to vertical rails, the docker never gets anywhere near to touching the other rail.​

 

[Madman198237]

This is a note for everybody else: This idea is for the transition between docked-entity ORIENTATIONS, not between rails. If you have a three-dimensional structure moving on a two dimensional plane, you can't go 3-d with your docker being somewhere odd. Like, on-the-edge-of-the-bounding-box sort of odd. This usually isn't all that possible in good-looking designs.