User:Larix/MPL/5

5. Assessment of Minecart Pathing Logic. Strengths, weaknesses and peculiarities.

Minecart Pathing Logic can perform the basic logic operations, it can be used to store, write and read data, it allows building individually adressable memory banks, repeaters, counters and adders. It is a fully valid DF computing discipline. It needs no fluids, the ramp-based designs need no power, either, and the circuits have an aesthetic appeal - i find that they remind of electronic circuit plans. MPL circuits take signals as input and directly generate signals as output, needing no additional conversion steps. The circuits can be compartmentalised and walled off - they can keep functioning without maintenance and without the need for power or water supply lines.

On the downside, Minecart Pathing Logic is slow and "short-sighted": unlike mechanical logic, which transmits power through a gate or circuit instantly, or creature logic, where the "computing entity" will calculate its full path to a goal whenever it makes a pathing choice, minecarts take between six and twenty-five steps to react to the open/closed state of a hatch-switched ramp and only react to the conditions of the tile they currently occupy and the tile they try to enter. When faced with a four-input OR gate, power will instantly flow or not flow through a mechanical gate, a goblin will perform a pathing calculation and directly follow the path corresponding to the true/falseness of the logic condition. A minecart will have to check each input transmitter individually and sequentially, spending almost a hundred steps to determine that none of the four inputs are on.

Minecarts, especially when propelled by ramps, are inherently dangerous to any creature they might encounter. An unlucky hit to the face even by the lightest cart will instantly slay a dwarf. And dwarfs don't take the presence of a busy minecart track into account, they will try to collect stones from a pit and sometimes even path through a circuit on a hauling job. Minecart computing areas require special care to keep the dwarves out of harm's way.

Minecarts on closed circuits, kept in perpetual motion by ramps, generally do not stop by themselves. If any kind of maintenance or reconstruction is desired, the carts must be stopped first, preferably by track stops or similar "full-stop" buildings installed ahead of time. If you neglected to build such safeguards into your circuits, getting a cart to stop gets a lot harder. Throwing extra carts into the circuit only rarely puts a stop to misbehaving carts, the perpetual motion will usually be capable of keeping _both_ carts going. The deconstruction-teleport bug can and will grab minecarts and can teleport them to the tile of the dwarf performing the deconstruction job; a moving minecart may move off the teleport target square, but the deconstruction worker will generally not be harmed.

In MPL, a cart can only hold a plate down by constantly moving across it. In most cases, carts will always be in motion, checking and re-checking the status of their inputs or keeping their connected output in the correct state. This can result in rather large numbers of minecarts moving around constantly, and this will put a strain on FPS. In active operation - when circuits get switched - the state changes of buildings will lower FPS much more. The latter is specifically only a disadvantage compared to mechanical logic, fluid and goblin logic should have the same "switching" issues.

Adressing multiple switches by unified commands requires much more in material and work than what mechanical logic can get away with: if you want to switch a dozen gear assemblies, you can run them all through a single power supply and build one connection to turn power at the root on or off. If you want to switch a dozen hatches by the same signal, you have to link every hatch individually, spending twenty-four mechanisms and the possibly very long time required for twelve linkage jobs.

Minecart Pathing Logic is very speed-sensitive. The acceleration gained in straight ramps can easily put carts past the derail threshold, which lets them ignore corners and further ramp openings. Even before derail speed is reached, the high exit speeds can slam carts into ceilings or let them jump over corners. Corner ramps in pits can cause diagonal movement, resulting in a wide variety of possible misfunctions. All presented circuits have been tested and proven functional in long-term operation, but they are the results of a long trial-and-error process. If you endeavour to design your own MPL circuits from scratch, be prepared for inexplicable failures and misbehaviour. Regulating speed and trajectories is a third of MPL, and another third is figuring out the actual reasons of errors and possible remedies.

MPL can conceivably also be performed by high-speed carts, propelled either by long downward ramps or impulse ramps. Due to their high speeds, dwarfs must be safely kept out of such circuits, most circuits must be surrounded completely by walls (because carts will derail and go flying off the course otherwise) and only doors and maybe raising bridges can really be used for switching. I have done next to no work in that direction, but computing devices based on derail-switches have been built and have performed satisfactorily.

MPL only really makes sense if it's based on perpetual-motion carts - using the ramp acceleration bugs to provide speed without consuming power. As such, it is built on the abuse of a blatant bug in the game, making it a morally questionable discipline. Furthermore, if Toady gets around to fix ramps so that they behave in a more realistic manner, this kind of computing will be a thing of the past.

Designing working logical devices often requires out-of-the-box thinking: a "full" memory cell should be read- and writeable, but in DF it may be better to build very simple memory cells and build the read-/write-logic in a completely separate device. My adder design doesn't consist of actual binary adders, it's a weird kind of incrementer with directly adressable bits.