Help:Editing

ASH Scripting

Adding New Function Pages

For a list of functions that don't have a page, please see: Ash Functions. All red links mean the page doesn't exist; if you click on one, you'll have the option to create it.

For information on how to add new functions to the wiki according to our current standards, please refer to Template:FunctionPage as well as the additional templates referenced on that page.

Also note that you can click "Edit" on an existing page, and it will list all templates in use by that page at the bottom.

IMPORTANT!: If you add a new function page, please make sure to either add the function to the category-like pages linked to on the main page using the {{Flink}} template OR set the category of the function to "Uncategorized."

Information Only

If you'd like to help provide information for a page, but don't feel like diving into the ins-and-outs of our template system, please feel free to edit in whatever information you'd like! If the page already exists, please do all of your edits on the page's Discussion page. If the page doesn't exist, feel free to edit the page itself. Either way, please copy & paste the following somewhere on the page you edit so we can keep track of where we need to add formatting: {{Format}}

Updating Current Pages

Quite a few pages exist, but are in need of some help.

Request for Information

Anything listed here: Category:Request_For_Information is missing important information on how the function operates. Please add in anything you can.

If you've filled in all of the requested information, please remove {{RFI}} from the bottom of the page.

Code Samples

Anything listed here: Category:Needs_Code_Sample either needs a code sample, or needs improvements made to its current code samples.

Please refer to Template:CodeSample for information on how to add them to pages.

Formatting Requested

Anything listed here: Category:Formatting Needed has information, but lacks page formatting. If you'd like to edit the page so that it includes any appropriate templates, please do so (and remove the line that reads {{Format}} when done.

Datatypes

We need a deep overhaul of these. Currently, various templates link to each as if it's on its own page, but this is possible to change if we find it necessary. However, each having its own page would result in better search functionality.

Also, we should clarify the difference between say, "class" the datatype and "$class" the built-in way to cast to and from "class" with strings / etc. I don't really grok the programming philosophy and jargon well enough to handle this myself.

Versions

Please note; eventually, all mention of "as of version..." will become somewhat out-of-date. I'd like to propose that from here forward, we only mention versions if there are things missing from a list that are included in more modern versions (ie the Master Function List should mention when it was last updated); I'd prefer to add in a general note somewhere along the lines of "unless noted otherwise, all documentation refers to the latest daily build." Thoughts? --StDoodle (#1059825) 15:48, 30 April 2010 (UTC)

Main Interface

CLI Commands

While the CLI Reference is a great start, it would be nice to:

• See this information presented in a "cleaner" format (I'm thinking each parameter should be a list item with its own explanation, probably).
• Show examples for as much as possible, saying what that example will do.

Other

The Adventuring, Item Manager, etc. windows / tabs could use more documentation. Sally's guide is a nice start, but eventually it would be nice to have comprehensive pages for everything.

Miscellaneous

Preferences

The List_of_KoLmafia_Properties is a nice start, but an explanation of what each option does would be ideal. Again, this will probably require something beyond a table; probably a list of what each option is and does following the preference.

Jargon

I know, but not everyone visiting this wiki will understand, that:

• Seeing a parameter in square brackets means it's optional.
• "Returns success" for a boolean function means you'll get true if the function does what it thinks it should and false otherwise.
• If a function returns void, you can't check its value, but otherwise, you can assign a function to a same-datatype variable.
• If a function returns anything but void, it must include a "return" statement outside of all inner-logic sections.
• If blocks only need curly braces if more than one statement is to be executed based on their resolution.
• Countless other things that I can't come up with at the moment (feel free to add them here).

It would be great to have a page explaining these things, or linking to other pages that do, linked to on the front page.

Format-breaking

Here is an incomplete list of known issues with wiki-markup which lead to erratic formatting (and fixes):

• Ending a function description with a list will break the whole page, if a code sample is present.
  • Get around this by either using HTML, adding " " on a new line right before the "|", or not ending a description with a list (avoid the problem in the first place!)
• Multiple code samples on a single page lead to some extra tags.
  • Remove everything between the "</syntaxhighlight>}}" and the "{{CodeSample|", leaving one line break between these two lines.
• Lines that start with an asterisk ( * ) are automatically added to a bulleted list (like this one here) whether you want it or not.
  • If you don't want it to be part of a list (see Cli for an instance of this), surround the asterisk with <nowiki> tags, as such: <nowiki>*</nowiki>

KoLmafia Guide

Sally's Guide is a special case as far as this wiki goes; please see the talk page for the guide for info on its editing guidelines.