Carts and Trucks

Back in the day I made a Factorio mod:
Logistic Carts https://mods.factorio.com/mod/logicarts 

The plan was to come up with a short-range logistics option somewhere between belts and robots -- small automated carts that follow painted paths around the factory. It worked ok in the end and people used and enjoyed the mod. The limitations encountered were mostly around Lua on_tick() overhead from moving carts around, which is fair enough because Factorio wasn't designed to support it. Plus there were also graphical challenges at the time (~ Factorio 0.16).

Factropy resurrects the idea of Logistic Carts: small automated vehicles that follow coloured routes around the factory.

Carts

Carts are pretty simple; they just follow a single route colour. The logic for controlling carts is in the stops and way-points they encounter. They can be told to do stuff like:

• change direction
• change route colour
• wait on conditions like full or empty
• respond to wifi signals

One of the things I dislike about Factorio vanilla trains is that the route logic is attached to the vehicle, not to the route itself. Train routes in a modern city aren't individually hard-coded in each locomotive, and it kind of goes against the idea of automate everything if every train needs configuration applied. Feels like manually controlling the items on a belt rather than the belt itself. Mods like LTN are essential there.

Routes

Logistic Cart routes are intended to resemble a coloured subway or light-rail map. They're one-way and usually laid out in loops. Direction of travel is the same as the order of construction. Start by placing a cart stop, and subsequent placements will automatically link up. Finish the loop by linking back to the first stop. 

• Switch between stops (big octagons) and way-points (small) with cycle [C]
• Switch route colours with red [1] , blue [2], green [3]
• Carts follow red routes by default
• Change or extend routes by re-linking existing way-points with [L]
• Stops have three modes:
• Inactivity, cart wait for 3s after last item insertion or removal
• Full, cart wait until its storage is full
• Empty, cart wait until its storage is empty

Original Use Case

Carts make great ammunition carriers. A few carts stocked with ammo following a route around the factory can keep many gun turrets supplied, avoiding the requirement for long perimeter belts. Easy to expand or move the route as the base grows: just [L] the last stop, add in a few more and reconnect to the beginning of the loop.

Engineer Carts

These guys come with drones. Useful for things like deconstructing trees along routes in advance of other carts; patrolling distant areas of the factory with repair packs; or avoiding stops altogether and using logistics drones to interact with containers while on the move.

Logistic Trucks

After some of the higher game goals are met the player unlocks bigger, faster trucks that work on the same principles. Though individually still fairly slow, a fleet of trucks is a cheap method of bulk resource transportation.

Design Decisions

Carts take their direction from each way-point and move in a straight line until they encounter the next way-point. Technically they're not actively scanning the coloured route like a robot in a factory probably would, but for the purposes of the game it's fine. It's convenient because the player need not make sure a route is empty before changing links. It's also very efficient since each tick a cart entity just updates its position by a pre-computed direction vector of length "speed". 

Collision avoidance while travelling is a periodic look-ahead for other entities, which is a spatial-index intersection query. This could get expensive with many carts moving so carts maintain a pointer to the guy ahead of them if they can, as well as a log of their own activity for the guy behind. Since you're following a route, whatever the guy ahead just encountered is probably what you're going to encounter next; if he encountered nothing amiss and no other entities have been newly placed nearby then the way is probably still clear... so keep going and hope for the best :-)

Collision avoidance at way-points and stops is trickier since carts could be arriving and departing at different angles if many routes converge, and could collide. Way-points have a reservation system and carts won't proceed onto a way-point entity unless they can reserve it.

Head-on collision -- or worse, not-quite-head-on collision -- is impossible to resolve without making carts into fully-fledged self-driving Teslas and incurring a huge UPS hit. Therefore carts just stop if they're blocked. it's up to the player to consider angles of approach and departure at stops. That's pretty forgiving since cart-to-cart collision is based on a bounding sphere somewhat smaller than the normal entity collision box.