mirror of
https://github.com/2006-Scape/apollo.git
synced 2026-07-03 00:38:21 +00:00
Merge pull request #326 from Major-/getting-started
Add 'getting started' section to README
This commit is contained in:
@@ -1,5 +1,4 @@
|
||||
Apollo
|
||||
======
|
||||
# Apollo
|
||||
|
||||
Apollo is a high-performance, modular RuneScape emulator with a collection of utilities for managing data files and plugins.
|
||||
|
||||
@@ -7,41 +6,17 @@ Apollo is a high-performance, modular RuneScape emulator with a collection of ut
|
||||
|
||||
Most discussion related to the development of Apollo happens on the IRC channel _#apollorsps_ on _irc.freenode.net_. If you have a problem and can't get in touch with anyone, create a GitHub issue. If making a pull request, please make sure all tests are still passing after making your changes, and that your code style is consistent with the rest of Apollo.
|
||||
|
||||
### Private server development today
|
||||
### Getting started
|
||||
|
||||
How are most servers private servers developed today? Typically, a user might download a server, read through tutorials, and apply their modifications or write their own code on top of it. Eventually, this server gets released and the process repeats, resulting in a complete mess of servers, all created from cobbled-together code.
|
||||
Apollo uses the [gradle build tool](https://gradle.org), so this must be installed in order to build Apollo.
|
||||
|
||||
### What Apollo does different
|
||||
1. Run `gradle build` in the Apollo directory to download dependencies and build Apollo.
|
||||
2. Place the full cache of the client revision you want to target in `data/fs/[revision]` - by default Apollo is compatible with the 377 revision, so the cache would be placed in `data/fs/377`.
|
||||
3. Place an `rsa.pem` file containing the RSA private key to be used by the server in `data/`. Apollo comes with a generator that will write the pem file to the appropriate location - see `org.apollo.util.tools.RsaKeyGenerator`. If you use the generator you must replace the public key and modulus used by your client (the tool will print the new values).
|
||||
4. If you are targeting a different client revision, run the `EquipmentUpdater` (in `org.apollo.cache.tools`), which identifies the appropriate combat skill levels required to wear equipment. Note that you may have to update the tool yourself if the revision contains equipment not found in 377.
|
||||
|
||||
At its core, Apollo provides the necessary features for a simple private server to operate. With the plugin system, it becomes easy to add extended functionality, much like a package manager. Instead of copying and pasting lines of code from a tutorial, new features can be implemented by using the package manager. A new feature is as simple as downloading a plugin into the appropriate folder, and configuring it. No need to modify any code -- the feature gets implemented straight away without any hassles. Plugins are currently written in Ruby, but more languages will be added later.
|
||||
Apollo is now ready, and can be started using `gradle run`. You may wish to change the player serializer defined in `login.xml` - by default player data is not saved, and all users who log in will have administrator rights.
|
||||
|
||||
Another aspect of Apollo that is done differently is that the core server is easily upgradeable, only requiring the new jar to replace the old, and restarting the server. This makes the server less vulnerable to fatal mistakes at the core.
|
||||
### Contributing
|
||||
|
||||
Some of the more prominent core features include:
|
||||
|
||||
- Packet encoding/decoding has been split from the representations of the packets themselves. This allows the potential for encoding/decoding to go on in parallel and also allows multiple revisions to be supported. Currently 317 and 377 are both completely supported.
|
||||
- Update server support (JAGGRAB, ondemand and HTTP).
|
||||
- Packet handler chaining: this allows multiple plugins to be able to intercept a single packet and deal with it appropriately. For example, a quest plugin could intercept searching a bookshelf for instance, if the behaviour needed to change in certain cases.
|
||||
- Parallel execution of player updating for multi-core machines.
|
||||
|
||||
|
||||
Along with these features comes the bog standard stuff:
|
||||
|
||||
- Login
|
||||
- Multiplayer
|
||||
- Walking/running
|
||||
- Rights management
|
||||
- Travel back algorithm for movement
|
||||
- Character design
|
||||
- Full player updating
|
||||
- Npcs (and full npc updating)
|
||||
- Commands
|
||||
- Inventory support
|
||||
- Equipment support
|
||||
- Action system
|
||||
- Working distanced actions
|
||||
- Task scheduler based on game ticks
|
||||
- Saving/loading with a custom binary format
|
||||
- Skill levels/experiences
|
||||
- Plugin management
|
||||
- Item, npc and object information reading (from the cache)
|
||||
Please see [contributing to Apollo](#CONTRIBUTING.md).
|
||||
|
||||
Reference in New Issue
Block a user