Read by Council Pathing block (a new type of rail)

[Achriel]

So many applications for rails that are not straight lines, or right angles. So I was thinking perhaps we can use something like the 'tubes' that connect logic blocks to set a path for a docking module to follow (visible or not).

Lets call it a 'Pathing block' in this description to keep it from getting confusing

The idea would be to place a Pathing block and link it to another Pathing block (but only 1) using the usual C & V and use logic to reverse the direction (high/low) as needed. When a rail block route ends pointing to a Pathing block it start to follow the 'tube' from Pathing block to Pathing block, when that path ends in a rail block it docks and follows the rails again.

By connection a Pathing block to rails (or in relation to them) we could adjust the path using logic without having to connect to the calculated route.

What this allows is guided travel through 'empty' space. We could have two types of Pathing blocks, visible and non-visible. The only difference is being able to see the route outside of build mode.

 

[nightrune]

The devs have already talked about how NPCs and possibly how other AI will navigate your ship. Its likely to be something along these lines.

 

[Gunseng]

That should be interesting when they start implementing more AI options. Not sure about long distance "pathing" but here's what I'm thinking for an automatic "docking procedure."

I like how the docking module in From the Depths works so taking a couple ideas from it. A player could place a "Docking Beacon" block behind a basic rail that has an interface with 2 modes and 1 setting players can adjust.

Transmit Mode

• Safe Flight Zone Radius - This will set an area (sphere) for AI to avoid around the station.
• The Front Face of the Docking Beacon(like a camera) will "draw a line" out to that radius as a Docking Angle.

Receiver Mode - Placed on the ship behind the docking Module with no settings, it just picks up the Safe Flight Zone radius settings and instructs the AI to move to the Docking Angle which then turns the ship so that the Docking Beacons are facing each other. Then the ship closes on the angle to dock.

 

[Achriel]

I can totally see this as a method to allow NPC movement but in this suggestion I was thinking more an extension of the actual RAILS system.

Imagine you have a platform that moves across a hanger in 2 or 3 dimensions. Currently in rails means some large structure is hidden elsewhere while the platform (using displaced blocks) does the actual visible movement. Using 'invisible' non-colliding paths (in that the blocks are like cargo space or area triggers) this movement is greatly simplified. Diagonal movement (to & fro) with less logic, triggers and blocks required. Much simpler to understand, easier to hide and no substantial additions/changes to existing code.

I make the coding assumption because we have all the elements currently. Speed control, logic to change directions and the docking module which is what actually follow the path (and joins/leave the rail, if that element is incorporated).

 

[jayman38]

This would definitely be neat. Builders could come up with all kinds of ways to use this.

It would probably need some limitations.
1. No other blocks allowed along the path, or else the movement is stopped. (precision entity placement? Could provide exciting new design concepts)
2. Maybe require rail blocks adjacent, all along the path of travel, to ensure the rail has a theoretical mass to "grip" as it travels. (adjacent to the path's bounding box, so that 3-D travel is allowed, not limited to a 2D plane of movement) (This second limitation might be silly, unnecessary, and unreasonably limiting to builder creativity, but might be needed to balance potential exploits.)

It could very well be the exact same building-mode block used by the AI.

Edit:
I recommend that the docked entity travel towards the next "activated" entity along the current connected path.
Example: A and B pathing blocks are connected bi-directionally. The entity starts at point A. Block B is activated. The entity travels towards it. To simply get it to change direction, merely activation Block A, not Block B. Suddenly the path is simply going the other direction, and with it, the docked entity.

This will allow multiple paths to be made from a single point, so logic can activate different "destinations".

With this, I think bidirectional linking should be automatically implemented whenever one instance of C-V linking is used, so that you don't have to do the same thing twice on the same path to get it to go the opposite direction. It will be up to logic to determine the direction.