F_Handler

Well, lately I was bored and decide to take a view at my libraries, and while surfing the code of F_Handler, I was seeing a lot of stuff that needed to be changed, and well, my boredom is gone.

The result is the following updates, that at this time are already uploaded to the hub.
If you haven't updated yet, and you are making use of this library, I suggest to do so as soon as possible, and to read the last updates and documentation.

A brand new information has been added, and a few of it is yet to be implemented, but I will do it in the following days.

This is the change log so far:

Version: 1.6 (BUILD 1.6.7.09) - 05th, July - 2014

** Fixed a design problem about the _handler_add() procedure, where you weren't able to
pass a list as an argument, now this problem has been solved.

** GameHandler/proc/_handler_add() now returns either a list of datums of type /Handler,
or a single /Handler datum, depending on how you called the procedure.
If you passed a list (Meaning your intention was to add and create more than one Handler at once), then you will get a list.
If you passed a type, id and tick_lag arguments, then you will get a single /Handler datum containing these variables.
NOTE: The datum the procedure returns is stored in GameHandler/var/list/_handlers[], be carefully to not manually add the
returned datum to said list again.

** GameHandler._initialize() and Handler._initialize() now returns either TRUE or FALSE, on success/otherwise.

** No errors will be thrown at initialization to the world.log if the DEBUG flag is not defined. This is a security measurement.

** _handler_activate() now triggers every (world.tick_lag + handler.tick_lag) instead of (handler.tick_lag)

** Multi-Handler demo changes:

(*) Modified all the documentation with a lot more comments and explanations, I included a few advises to keep in mind
when working with the library.(*)

(*) Modified the method used to define new handlers at initialization. You will now use _handler_add instead of
manually creating the object. This now also shows you how to manage exceptions when a creation fails.(*)


(*) SEE multi-handler demo/demo.dm

** Custom Handlers demo changes:

(*) Modified handlerReaction() accordingly to the last updates. It now takes an ID too.

(*) Introduced a few more comments, and modified some that where phased out.

(*) Modified the initialization of the GameHandler datum. It was phased out. It is now up to date.
It also includes two examples of how to manage initialization, one using a list, and another an if() statement.

(*) SEE custom-handlers/demo.dm

Version: 1.6 (BUILD 1.6.2.0) - 05th, July - 2014

** The procedure handlerReaction() now takes an extra argument, 'id'. It's new behavior is as follows: entry:handlerReaction(id,world.time)

** You can now specify a different reaction on each datum depending on the handler that triggered the reaction.

** Default id for the _add_to_queue and _remove_from_queue procedures is now '_default_handler_id' instead of '1'.

** All demos have been updated with the latest improvements.

** Improved queues.

** If the 'type' argument's value given to GameHandler._handler_add() returns false or is not a valid path,
the proc will stop immediately.

** GameHandler._handler_remove() now returns 1 on success, 0 otherwise.