These are classical ``cascades'', and variations developed from it.

The first of which are the most commonally used in the current crossfire maps. It is also probably the neatest, but with a lot of programming.

This cascade I think is the most useful for controlling sequences of functions. -- The reason is that at each point the boulder pauses longer, giving enough to allow any other connected spikes to roll an item off it. -- The classical cascade can not do this. -- Also only one button is required to keep the cascade in motion. Better than the two required for the classical. and easier to program. -- Also as all spikes are up by default a cascade loop does NOT require fencing in the middle of the loop!

By adding a second button to lower the gates two squares ahead of the boulder the cascade speeds up to the equal of the classical cascade, but with spikes up. -- Better to use a classical `down' cascade instead. The exception is for very large loops where with care at the corners you can compact the loop into a tight space without needing extra internal fencing.

A trial variation I just threw in to see what happens. I expected it to have a speed between the first two cascades. -- Unexpectantally however, this cascade is FASTER than the original cascade. -- The reason is that the `up' spikes never fully lowerer before receiving the boulder (or token object), and so rolls the object off faster!

Teleport cascades 'port the boulder from one position to another. In fact other than to initialise the cascade fences are NOT required, and the teleports to not have to be in any order or even near each other. -- The disadvantage however is that you can't just cut and paste the cascade to a different location as you can with the other cascades. -- Note the cascade in this direction (right to left) is by default, instant. Presumably as the crossfire server processed the map objects from bottom right to top left. As such the boulder teleports through ALL the teleports in the same server `tick', as all the teleports `activate at the same moment. -- This is NOT a problem in other direction (left to right, or top-down) where the boulder jumps over `update wave'. See the example in `special_objects' map for the other direction. -- A couple of solutions to this `update wave' is availble none of them very nice. The solution I am using is to set the initial ``speed_left'' to .5 for every second teleport in the cascade, to place them half way out of phase with the others on either side of the cascade sequence. -- Arrgghh more programing

These are very very slow due to the long timeout period of a trigger gate. This time out does not seem to be modifiable at this time. But for long timing sequences this is probably unbeatable. (Slow fuse anyone?)

Its a bit faster than the above trigger gates, but not by much!

This cascade is a bit faster still, and uses only 4 buttons in stead of 8 or 16. -- It relies on the fact that trigger gate timer is reset (re-triggered) when the boulder rolls off the connected button. as such each button will setup a `surge' of boulder movement over 2 squares. -- In fact if the trigger gate time period can be set to an exact time period, it would be posible to run a whole cascade with just the initial `trigger' signal! And have total control of the time the boulder sits in each location as well. The ideal solution. As it is we have only boulder surges. which is not a great deal of use.