diff --git a/doc/applied/reset b/doc/applied/reset
new file mode 100644
index 0000000..db08bec
--- /dev/null
+++ b/doc/applied/reset
@@ -0,0 +1,37 @@
+SYNOPSIS
+        void reset(int arg)        /* compat mode */
+        void reset(void)           /* native mode */
+
+DESCRIPTION
+        The H_RESET hook defines the function or closure to be called
+        when the driver needs to reset an object. In older drivers
+        this was hardwired to the lfun reset(), and a lot of hook
+        implementations still follow this tradition.
+
+        In compat mode, reset() was called with arg 0 after the object
+        was compiled, and with arg != 0 every once in a while.        In
+        native mode, create() is called after compiling, and reset()
+        is called without arguments every once in a while.
+
+        So, if the argument is zero, the parser is running in compat
+        mode, and reset() may call your create() code. If create() is
+        called, you're on the new version and reset() is not called
+        for object creation. You may call reset() from create() and
+        vice versa, but make sure they do not call each other
+        recursive on either type of driver.
+
+        reset() will be called only in objects that have been used
+        since the last call to reset(), i.e. a function in them was
+        called (other than reset() or clean_up()), or it was moved
+        around.
+
+        This function can be used to reset the state of the object or
+        do some checks or what ever. The game wouldn't be fun if no
+        challenges remained.
+
+        For 3.2.1, the mudlib can be programmed to call an other lfun
+        than reset() to reset an object.
+
+SEE ALSO
+        clean_up(A), heart_beat(A), call_out(E), create(A), __INIT(A),
+        reset(H), hooks(C), initialisation(M), native(C)