Create some function which for example's sake i will call "logd_yourfunction"
In plugin_init() after you register "logd_yourfunction" with admin mod, you may inform logd that you wish it to use "logd_yourfunction" to notify your script of events that occur. So for example you may want logd to inform you when a kill occurs and you want it to use "logd_yourfunction" as the message carrier. The correct procdure is to issue the command "logd_reg" via the "exec" function for scripts.

Example:

The actual format of the logd_reg function is:
logd_reg <Code> <Function>s

• Code is an Event Code
• Function is the Full command required to pass the information to the function you want to LogD to call. For admin mod scripts this means you are required to use "admin_command" in front of your function expression.
• For admin mod scripts you can call the function logd_reg using the exec() function provided by admin mod.

int he example above 57 is the event code for the "kill" event. The rest of the string after 57 is then interpreted by LogD as the function to call. So LogD determines that the function to call is "admin_command logd_yourfunction". Because LogD is a dll running with the server "admin_command" IS necessary for admin mod scripts to be called correctly. So in a nutshell the example is telling logd that on the kill event, the script wants LogD to pass information via the scripts "logd_yourfunction" function that it has.

• The information LogD passes to a fucntion (to notify it of an event) is the paramters to that function
• To provide reliablility a "paramter format" for each event is decribed here so your plugins know what to expect.
• What follows is an explanation of how to understand the parameters.

In the Parameter Format comment, names are symbolic to the meaning of the data it represents, so "killerIndex" from the kill event refers to the "UserIndex" of the person who invoked the kill event (in other words he killed someone)

If something is specified within single quotes it is to be taken as a literal character and not a symbolic name.
Example:
's' means the literal character s

The server/mod might decide to put extra non-standard information at the end of a log message. Im going to call these OPE and that stands for Optional Parenthesised Expressions. This means on certain mods, this information might be there, where on other mods it doesn't exist.
Example:
"Seraphin<1><95578><TERRORIST>" attacked "[RETIRED]Psychowombat<2><772258><CT>" with "deagle" (damage "health:66") (damage "armor:0") (health "34") (armor "0")
The ending is all OPE
(damage "health:66") (damage "armor:0") (health "34") (armor "0")

Because LogD is not mod-specific a special scheme was developed to deal with OPEs which is discussed in the next secion.

• The parameters of an event function will always be separated by a space. Spaces are to be considered delimiters and will never be used to represent data in any way.
• Double quotes (") will never be passed to an event function.

If a string value on the server (such as from a name, world event, or team trigger) contains a space in the log message, that space will be converted to the dollar character ($). Ex: the name "Bob Smo" is converted to "Bob$Smo" before being sent to the appropriate event function.

If a string of an event always contains spaces (such as the message of a chat event), and you are worried about the performance of reconverting the string to use spaces, consider using another method to acquire the data (such as hooking the say command in admin mod). Spaces are converted to $ in order to preserve spaces as delimiters AND to make the data sent to the event function un-ambiguous.

For optional parenthesised expressions (see the standard format), they appear as (key "value") or (key) in the normal log message. When they are sent as parameters to the event function. Parenthesis will be stripped, quotes will be stripped, spaces in the value string will be converted to $, spaces outside the parenthesis will be left alone the space between the key and value will be converted to a #.

For example in the log message

Team "TERRORIST" triggered "Terrorists_Win" (CT "4") (T "6") (CT "4") (T "6")

(headshot) becomes headshot and (someKey "some value") becomes someKey#some$value. The output to the event funtion would be

CT#4 T#6

Parameters that are currently sent to these functions will always be sent to these functions and in the same order (The exception is optional parenthesised expressions, because each mod controls their order.)

In the future it is possible that more parameters will be sent to these functions. In that case, the new parameters will be after the existing parameters (exception: optional parenthesised expressions will always occur as the last parameter set due to their optional nature by mods).

If a function is marked "Dormant", it means that the parser is not able to receive that kind of a log event at this point in time.It may or may not become "Active" in the future, but I don't guarantee anything. The reason the function still exists in this file is merely for completeness of Standard Log Format parsing.

Some sample event strings will be included in the release package, do not ask for more, consult a log file if you need more.

If it is possible for you to take shortcuts when doing string comparisons, do so.
Many plugins string matching will cause lag on the server. Do as little string matching and in as little effective instructions as you can to minimise the load.

If you want to "simulate" a log event to test your script(s) either:

1. invoke your script directly using necessary data
2. invoke them indirectly by calling one of the function by passing it data as it would be passed to it by the parser.

The "Standard Log Format" is an open logging standard for Half-Life;servers to reduce ambiguity in log messages.
It can be found here at http://www.hlstats.org/logs/
If you do not understand the "reasoning" behind certain parameters and log message you encounter consult that web page.