LNR Script Framework - Neikun/Legends_of_the_Northern_Realms GitHub Wiki

General Notes Regarding the LNR Scripting Framework

The LNR Script Framework is the core of the code behind LNR. It contains script modules and concepts that facilitate things like creating NPCs and their interactions with the player, world and other NPCs. It also provides the Data Storage and Retrieval System for keeping LNR custom data persistent across gameplay sessions, provides NPC dialog and quest functions and GUI methods for things like shop and service interfaces.

Please refer to this document for all of your scripting questions. It will be updated regularly and should be considered the main info document for all scripting done by the scripting team.
Should you have scripting ideas or requests, please post them on the Scripting Requests page (non-contributors may PM or email one of the scripting team).
Should you have a question that is not answered here, please feel free to contact Centauri Soldier or any other of the scripters detailed in the Official Thread.

Overview
This is a scripting reference intended for the level designers. If you would like something added or clarified, please use the method(s) mentioned above.

Purpose
This contains general instructions on how to implement scripts during level design and detailed info on those scripts.

DSRS
Data Storage and Retrieval System.
This is the system that allows the saving and loading of data that is superficial: any data that the game does not save by default, like party gold, NPC behavior, quest status and so on.

Why Not an Object Oriented Framework?
As much as the idea is appealing from a programmer's point of view, this framework is designed to cater to the needs and convenience of level designers who (although some may) may not know lua or OOP. The idea is to make this as easy to use and learn as possible. So, being able to create an NPC simply by ID and having the ability to reference that NPC by its ID in any script without needing to declare a global variable is much simpler, more expedient and far more convenient for the level designers than the alternative offered by OOP.

Some Terms
Though some of you may already be familiar with some or all of these terms, they will be listed for clarity for those who are not yet familiar. Below is list of common terms you'll see throughout the LNR Script Framework wiki.
Module - this is a file such as NPC.lua. It contains all of the functions needed to handle the objects with which it is associated.
Class - This is the namespace (such as NPC) whose children are the methods of that module.
Method/Function - used interchangeably for this application. These are the calls the level designers will use to create and modify the world.

Installation
This framework is not yet ready for use so please do not install or use it. The classes and methods are subject to change until the skeleton of the framework is complete. The estimated release date for a fully-functional version of the framework is January 28th, 2013. The script team does not recommend level editors attempt to incorporate it into the dungeons until the release date as many things will be changing in the meantime.

Usage
See Installation

---

###Adding a Class (module)
First, please always check to see that the module does not exist before adding one.

Adding Methods to Existing Classes

First, please always check to see that the method does not exist before adding one.

Basic Information Regarding Script Module Layout
All methods should have a header with the following information.

COMMENT BLOCK START (This is a quick reference for anyone looking through or editing a method in this module.)
Class.Method(arg1type,arg2type,etc)
Return Type: string, nil, number, table, boolean or function
Method Type: internal or external
Function Notes
COMMENT BLOCK END
Function Script

Class.Method
The Class is the name (and namespace) of the module while the method is the specific function that's to be called.

Arguments
The arguments' types and numbers will range depending on the method. If one of the arguments is 'variable', that means that it may be any of the types listed above under "Return Type".

Return Types
These also will vary depending on the method. This is the value that the function will send back to the caller when it has terminated.

Method Types
The external method type means that the function was designed to be used by you to design levels. The internal type means that it is used by other functions and should not be used by you as they are not "safe", meaning that conditions and argument types or values are not checked since they are assumed by the calling functions: It is not recommended that you use these. If you need to use one of the internal methods, please notify Centauri Soldier or another member of the scripting team and a "safe" version of the function will be created for you.

Function Notes
Anything that may not be intuitive or explicit may be declared here so others reading your code (or you, a year from now) will be able to quickly understand the intention and usage of the method.

---

Modules in the Framework

Please see the sidebar on the right side of this page for a list of modules.