Getting started as a Sloodle programmer
From SLIS Second Life Wiki
You can contribute to Sloodle as either a PHP programmer, an LSL scripter, or both. Always remember to get in touch via Sloodle.org if you need help or ideas.
Contents |
LSL Scripter
LSL is the easier part of Sloodle programming. Most of the objects and scripts distributed through the usual means are modifyable, which will let you explore and play with Sloodle programming right away (see How do I Get Started with Sloodle?).
What can I do?
Modding
LSL scripters can mod (modify) existing Sloodle objects, without actually changing any of the underlying functionality. For example, you might want to create a variant of the Sloodle Quiz Chair, which will respond to user success/failure by building a tower (instead of moving a chair). Alternatively, you might want to make the Sloodle MetaGloss present definitions in a different way.
The possibilities are endless, and as Sloodle becomes more widely used, there is bound to be demand for customized versions of different objects.
Fixing Bugs
Our GoogleCode Issues Tracker shows a list of current issues which need resolved. The bugs cover everything from in-world permissions and LSL script bugs, through to problems with the database and PHP programming. It is worth browsing the list to see if there is anything you can help with.
Making New Objects
You can get involved in the creation of new Sloodle objects. Sometimes we will already have a prototype which simply needs to be improved, or sometimes we might just have an idea which you are free to develop as you like. Creating new objects normally requires some PHP programming, and you are welcome to try this as well, or you can team-up with somebody else who will do it.
When developing objects, it is important to use Component Specifications. Each specification will give a complete and thorough description of the way the object interacts with Moodle, along with expected behaviour on each side.
More....
Feel free to suggest your own ideas for Sloodle.
What do I need?
You do not need much to do LSL scripting. You will sometimes need your own Moodle installation for testing, especially if you are developing new objects. However, if you are only doing in-world modding, then you do not need any specialist knowledge.
It is worth referring to the Sloodle LSL Library for general scripts and functions which will help you when doing LSL programming.
PHP Programmer
Moodle is programmed in PHP, so Sloodle is as well. As with most PHP projects, the Sloodle module is distributed in source-code form, so you can download it directly and look at the code.
Downloading Sloodle
We store the Sloodle source code in a Subversion repository. This is version management software, which helps to make sure the project stays under control. You will need a Subversion 'client' to obtain the source code correctly, and to submit your changes (these operations are called "checkout" and "commit" respectively). Linux typically has a command-line Subversion client, but you will probably need to download something like [TortoiseSVN] for Windows.
The main stable line of development is in the "trunk" folder. However, it is possible that some particularly risky or unstable development will be done in separate branches. Please refer to the Subversion documentation for information on repository layout conventions, and refer to Sloodle Source Code Repository for information on Sloodle's repository layout.
If you want to contribute back to the project, then you will to make a non-anonymous checkout (over https), which requires that you become an official project contributor. Please contact us on the Sloodle forums if you wish to become a contributor (you will need a Google account first).
Database Alterations
It is rare that most programmers will need to alter the database specification (files in the "db" folder). If you do, then you *must* discuss it with the team on the development forums first, and you should be very familiar with the requirements of the database installation/upgrade files for Moodle. Importantly, database alterations should never be done directly on the trunk development line, as a mistake could destroy a user's Sloodle installation if they are upgrading (and potentially their Moodle installation as well).
What can I do?
Fixing Bugs
There are often plenty of bugs to be solved. Once again, see our GoogleCode Issues Tracker for a list of current/past bugs.
Making New Components
Whenever a new component is developed (i.e. a new object or means of interaction in-world), there is typically the need for some additional programming or changes to the scripts in Moodle. This will usually required the development of Linker Scripts which in-world objects communicate with, and possibly also Interface Scripts, which Moodle users will view.
More....
Feel free to suggest your own ideas for Sloodle.
What do I need?
The most important aspect of programming is documentation. You can read the Sloodle PHP API documentation on the wiki here, and you will probably also need to refer to the Moodle API documentation, and perhaps even the PHP documentation.
| This page is part of the Sloodle documentation | |||
|---|---|---|---|
| SloodleDocs Home | User Documentation | Administrator Documentation | Developer Documentation | Sloodle Wiki Home | |||
