This is a feature that I've been working on for a while, it's quite complex but does I think have the potential to be very useful.

(copy, switch tabs, paste:)



== 1.1 Build logging and rewind capability =======

=== Links ===============
http://www.bandstand.org.uk/~benm/trem/buildlog964-6.patch
http://www.bandstand.org.uk/~benm/trem/buildlog964-clipped-1.patch
http://www.bandstand.org.uk/~benm/trem/unclip.patch

=== Summary =============
SVN: 964
Status: Released with moderate testing (version 6)
Admin flags: UR
Admin commands: !buildlog, !revert
Cvars: g_buildLogMaxLength ("25")

Every event that changes the buildable layout, buildings, deconstructions, and
destructions, is logged: this log can be read by the !buildlog command, flag U.
!buildlog takes one argument of the form (number)(a|h) where number is the 
position to start reading from and a|h filters the log by team.
Build log entries can be reverted with the !revert command (flag R) which also
takes one argument of the same form to indicate number of reversions or team
to revert. If reverting the removal of a buildable would conflict with a 
currently existing buildable (rare but possible), a warning is printed. The 
admin may then do the same command with an ! appended to the argument to 
override the warning and permanently overwrite the existing buildable.

=== Description =========
This is my most complex patch to date, requiring four helper functions, a new
struct and enum, and pointers all over the shop. Past versions have caused 
segmentation faults, infinite loops, and memory leaks, so although I am fairly
confident I have stamped out all the potential problems I still feel a 
compulsion to label it as a beta release or some such nonsense.
If a buildable is taken down to zero health, the destruction is logged then, 
and not when it explodes. If this destruction is reverted immediately the dead
buildable is quietly removed and no damage is done. If a player is standing 
where the buildable was, then the buildable is placed intangibly and players 
inside it are ejected with considerable force. When the buildable is clear,
it solidifies and resumes normal function.
To help evade abuse, a message is printed to the whole server every time
either of these commands are used, and !revert prints every action that was
undone.

==== Issues ========
Reverts are irreversible: if an admin accidentally reverts an important 
destruction or build, the action cannot be undone.
It is possible to abuse reversion and buildlog: if you suspect a move by the
enemy, you can use the log to choose a prime moment to attack or better still, 
!revert the reactor away mid-build; if your own move runs into problems, simply 
revert back to default base and all is well, and one more: 1) grab psaw 2) find
egg 3) saw 4) !revert 5) saw again 6) ??? 7) profit!
If a buildable is overwritten by a revert then its build remains logged and 
cannot be reverted, preventing the reverting of any earlier events. This is a 
bug.