SRL Archive - SRL Development and Help

Introduction

---

[INDENT]
This is a very simple guide that will help you write code for SRL. It will cover standards, using Git, and some information about file structure. If you have any questions, please post here or create a new thread in this section and someone will reply as soon as possible.
[/INDENT]

Git

---

[INDENT]
As most of you know, SRL uses the version control system, Git. Git is simple to use once you get used to it. If you aren't interested in using Git, you can always post code and/or bug fixes in the SRL Bugs and Suggestions project, otherwise, here are some helpful links:

• SRL Repository
• An Introduction to Git and GitHub
• If you're like me, and prefer GUI over command-line, check out the GitHub app in the above link, or TortoiseGit.
• Git and GitHub are pretty widely used; Google is your friend. ;) Use it if you need help.

[/INDENT]

Standards

---

[INDENT]
The SRL standards are pretty straight forward. In addition to the following, we encourage neat, organized code with a suitable amount and use of white space (empty lines). If you want to see what we mean, take a look at any file currently in SRL. :)

• Global constants, variables, and types will go in their respective files (i.e. var minimap: TRSMinimap; goes in minimap.simba).
• Constants will be in ALL_UPPERCASE.
• Function/procedure and variable names will be camelCapped (first letter lowercase).

// wrong
var
  ExampleVar: integer = 0;

function TRSMinimap.SetAngle(ang: integer): boolean;

// right
var
  exampleVar: integer = 0;

function TRSMinimap.setAngle(ang: integer): boolean; 

• All SRL files disable Lape's auto-invoke feature, meaning round brackets () are required after all function/procedure calls:

// wrong
minimap.getAngleDegrees;

// right
minimap.getAngleDegrees();

• Use UPPERCASE enums, and remove them from the global scope:

{S+}
type
  TFruit = (BANANA, APPLE, MELON, PEAR, WATERMELON);
{S-}

// can only be referenced like TFruit.BANANA

• Types that are specific to Runescape will have the prefix "TRS" (see any file in lib/interfaces/).
• And of course, all the regular standards - begin..end, repeat..until, etc. line up vertically and code in between is indented 2 spaces; variables should have names meaningful to their purpose; code should be commented for easy updating.

Not too many rules, I hope. :) I highly recommend taking a look at some of the SRL code if you're unsure about some of the above standards.
[/INDENT]

Debugging

---

[INDENT]
SRL has a great debugging system, and we want to take advantage of it. Scripters have the option to completely disable it, so don't worry about debugging too much. For debugging guidelines, check out the debug.simba documentation.

WARNING: If you use TDebug.HEADER, you have to use a TDebug.FOOTER, otherwise the debugging won't line up properly.
[/INDENT]

Documentation

---

[INDENT]
We always want to keep SRL's documentation as up to date as possible. If you update a function, update the "Last Updated" line, if you add a new function add the documentation. The documentation is parsed by a script and requires a very specific syntax, so be sure to follow the examples in SRL closely.

Alternatively (or if you've created several functions/an entire file), you can use a java program I wrote that automatically adds documentation to an SRL file. I do plan on converting it to an extension, eventually, but for now, it'll have to work.

• Download [ATTACH]22140[/ATTACH] and extract the .jar (source file is included in the archive).
• If double clicking it doesn't bring up the console, run it through your console:

C:\>srl_source_parser.jar

• Follow the prompts. Be sure to enter a valid file name, otherwise it will crash. There is no error handling.

Also, we don't want internal data showing up in the documentation (since they're not meant to be used outside of SRL), so the headers for these will be inclosed in { } comment tags rather than (* *). This is done automatically in the program above.
[/INDENT]

Interface Structure

---

[INDENT]
@Zyt3x; came up with what I think is the best feature of SRL-6: the TRSInterface record. It allows for a very dynamic system for literally all of Runescape's interfaces, from the lobby to the gametabs to the bank. For consistency and structure, each TRSInterface should have the following structure:

(*
Example
=======

Description of the file here.  All SRL files should be able to compile on their
own.

The source for this file can be found
`here <https://github.com/SRL/SRL-6/blob/master/lib/interfaces/example.simba>`_.

*)

{$include_once interfaces.simba}
// + any other files that need to be included

{$f-}

type
  TRSExample = record(TRSInterface)
    __placeholder: byte; // only if there are no other attributes required
    exAttribute: TBox;
  end;

var
  example: TRSExample;

{$IFNDEF CODEINSIGHT}
procedure TRSExample.__init();
begin
  with self do
  begin
    name := 'RS Example Interface';
    ID := ID_INTERFACE_EXAMPLE; // ID will need to be added to lib/interfaces/interfaces.simba
    parentID := -1;
    static := true;

    // + initiate any other global attributes
  end;
end;
{$ENDIF}

{$IFNDEF CODEINSIGHT}
function TRSExample.__find(): boolean;
begin
  // code that finds the interface
end;
{$ENDIF}

function TRSExample.isOpen(): boolean;
begin
  self.__find(); // may not necessarily be this, but it most cases it will
end;

function TRSExample.open(): boolean;
begin
  // code that opens the interface (if applicable)
end;

function TRSExample.close(): boolean;
begin
  // code to close the interface (if applicable)
end;

begin
  example.__init();
end;

Please refer to any of the files in lib/interfaces/ for more information.

Also, to keep SRL as dynamic as possible, all coordinates should be relative to the interface's bounds. This means that if you call getColor, for example, on a point inside the interface you need to do:

getColor(self.x + 25, self.y - 50);

This keeps it relative to the interface, meaning if the interface ever moves, your functions don't break. :)
[/INDENT]

Conclusion

---

[INDENT]
Obviously, it is easiest for the developers if you open a pull request, but if that isn't an option, please post a thread in the SRL Bugs & Suggestions page. Also, if you plan on taking on a large project (such as a new file), we highly recommend creating a new thread in the SRL Development Help section for discussion. This also lets other users know what you're working on, so no two people are doing the same thing.

I hope you enjoy coding for SRL as much as I have. :)

Enjoy,
The SRL Devlopement Team
[/INDENT]