Scripting Conventions

Because this is a volunteer project, and the turnover of volunteers is can be high, it’s important that your contributions are able to be continued by another if necessary, and easily maintained afterwards.

This is why we have developed certain conditions and conventions we’d prefer (read: use them or suffer some dire consequences I’ve yet to think up) you use when scripting.

STRUCTURE

Your scripts should aim to be in a format which reflects the order shown below:

  1. Name

  2. Properties

  3. Events

  4. Functions

This makes it much easier for anyone trying to find a certain property, as they’ll know exactly where to look in the script for what they need.

READABILITY

These may seem a little OCD, but bear with me okay?

You code needs to have the following:

  • Proper indentation of your code

  • Parenthesis around if and while clauses

  • Fields are in CamelCase, and locals are in camelCase

  • Comments where functions that are not self-explanatory (just one line explaining what the function does should be sufficient)

  • Comments otherwise are of course welcome.

NAMING

A consistent naming convention makes it easier to find files in huge directories.

This is the basic format: fbmw_<Context><Description><BaseScript>

  • <Description> is a general description of what the script does.

  • <Context> describes where it is used.

  • <BaseScript> describes what kind of object this should be attached to (optional).

For example: a script that describes certain scripted events that outdoor vendors have to follow based on other event could be named fbmw_MarketMerchBehaviourActorScript.

SCRIPT TEMPLATE

Scriptname fbmw_Example1aQuestScript extends Quest

{This is the main script for ExampleQuest1. It may or may not compile.

This iteration was developed for Skywind v0.9.7.1}


;/

Contributors: myname

Last Updated: YYYY/MM/DD on Skywind 0.9.7.1.

Notes: This is your average developer note.

/;


; --------- PROPERTIES ---------


quest Property kMyQuest Auto

{description of the property}

int[] Property iyIndex Auto

{description of the property}


; --------- GLOBAL VARIABLES ---------


bool bFound

float fInitialValue


; --------- EVENTS ---------


Event OnActivate(ObjectReference akActionRef)

;/

Use comment blocks for any large descriptions of what's going on.
Typically only needed in major game mechanics scripts.
/;

; Use regular comments throughout to describe what you're doing.

Debug.Trace("Activated by " + akActionRef)

EndEvent


; --------- FUNCTIONS ---------


Function MyFunction(string sArgument)

; Use trace functions and regularly check your Papyrus logs.

Debug.Trace("MyFunction was passed " + sArgument)

EndFunction