Page Comparison

Syntax

registerDiagDiag.add(name, routine);

Parameters

Parameter	Type	Mandatory	Notes	Diag Ver
name	String		Name of the diagnostic routine Must not contain any spaces! Will always be converted to lowercase.	0.1
routine	Function		The function that performs the diagnostic	0.1

Return values

Example

// define a diagnostic routine function
var myDiagFn = function bar(name, param1, param2) {
  // do stuff
  // return either a string or an array of strings
  return "my name is "+name;
}
 
registerDiag("foo", myDiagFn); // register myDiagFn under the name "foo"

diag("fooFoo", true, "bleh"); // my name is foo

Notes

When defining your diagnostic routine the first parameter will always be the name you used when registering the routine. You can use this, for example, to create a single function and then register it multiple times under different names and have it act differently depending on the name.

You can specify any number of additional parameters in your diagnostic routine function – whatever is passed in to diag Diag() will be passed through to your routine. A good example of fairly complex parameters can be seen in the Process API Diagnostics (all handled via a single diagnostic routine defined at the bottom of Process.js).See EggPlant Diagnostics for a list of currently defined diagnostic routines.

Assume string parameters – this is because the in-game chat interface will be able to trigger routines in Warzone 3.2 and above. So, if you want a parameter to be a number, you'll have to use parseInt() or similar inside your routine to make sure it's a number. If the routine is called directly from code then different data types can be passed in, but it's best to code routines with the assumption that all parameters will be a string.

Your diagnostic routine function should return either a string, or an array of strings, to relay the results back to the calling script (which will in many case be relaying them back to the end-user via in-game chat).

If your routine requires multiple parameters, assume the end-user might get them wrong when they call it via the chat interface. Errors should be relayed to the user via normal return values, not exceptions. A simple approach is to relay a google search to the user if they get things wrong, for example: "Google 'Warzone Process API Diagnostics' for usage instructions" – much easier to do a google search than try and type in some long cumbersome URL to get the docshuman-friendly strings and not exceptions if practical to do so.

Where possible, name the function (eg. "bar" in the example above) – if there's an error running the diagnostic, the function name will usually be shown making it easier to track down bugs.

Diagnostic routines are always run in the global scope. If you want your routine to run in a different scope, use a closure.

EggPlant follows a convention of defining diagnostic routines near the bottom of the API sandboxes. For more info on sandboxes, see Code Conventions.