Improving the Program
Contents |
[edit] For non-programmers
Even if you don't know how to program, and don't want to learn, you can still help us. Just download the latest nightly build and test it for bugs. If you find a bug, report it.
Improvements to the documentation (F1 help files), the plotscripting dictionary (plotdict.xml), and the wiki are also very welcome. You can also submit new script commands which are implemented as scripts in plotscr.hsd (please include plotscripting dictionary entries).
[edit] For programmers (and people who want to learn)
If you want to become an OHRRPGCE developer, you must know how to program. We use mostly FreeBasic as the language (with portions of C++, C, Objective C, and Euphoria), so knowing that helps, although the syntax is easy enough to pick up if you're familiar with any other language. For certain specific tasks like improving HSpeak (written in Euphoria), or gfx_directx (written in C++), FB knowledge is not needed. Use of FB is also not required for new self contained code (say, a new backend for MIDI playback) and we are increasingly using C and C++.
The next thing you need to do is become familiar with the project. Know what the engine can and cannot do. Use Subversion (or Git!), and check out a copy of the source code. Try to get it to compile. Once you have successfully compiled game and custom yourself, you are ready to start making changes to the source code.
Finding the place in the source code that you want to change is probably going to be the biggest challenge for a beginner. The code is not well organized, so discovering which routine in which file is responsible for the part of the program you care about can require a lot of detective work. Don't hesitate to ask on the list.
[edit] Bugfixes
If you write a patch to fix a bug, we will love you. In a metaphorical sense, of course.
Check out the Buglist for a list of outstanding bugs. Be sure to read the comments that people have left on the bugs, so that you know what we've tried or not tried thus far.
Once you fix the bug, you then need to test it. This cannot be stressed enough. You need to make sure that:
- The bug is, in fact, fixed
- You did not introduce any other bugs
If you didn't fix the bug, or if you introduced other bugs, or worse, did both, we cannot accept the patch.
Once you've determined the quality of the patch, attach it to the bug report. One of the developers will review it, and then either accept it and commit it to the source, or reject it, and tell you what's wrong with it.
[edit] New Features
If you've hacked a new feature in to the OHRRPGCE (and by hacked, I mean written in a non-hackish way), you can submit it as well. File a bug report with severity "enhancement", and then attach your patch.
But, make sure you've tested it, and that it doesn't break other things. We've been bitten by this before: too many new features + not enough testing = bad release.
Also, if you change anything, you should update (or add...) the relevant Documentation as well.
[edit] And...
If you prove yourself to be a worthy developer, by fixing bugs and adding new features, you may become a full developer with direct write access to the source code, so you don't have to keep submitting patches, and bothering us waiting for us to review it.
