-
Notifications
You must be signed in to change notification settings - Fork 27
Contributions Guide
This document is a collaborative draft and not final!
All code needs to go through code formatting to match a unified style, mostly because it needs to remain maintainable by everyone, and to avoid whitespace churn.
We use astyle for this, with the following settings:
--style=kr
--lineend=linux
--break-blocks=all
--indent-spaces=4
--indent-switches
--max-code-length=100
--pad-header
--pad-oper
--unpad-paren
This is just a partial set to get started and can probably be improved upon.
Please make sure to commit all your files in UTF-8. Special code sequences that need to be ASCII should be given in escape notation.
All plugins should have a README.md describing what it does, how it can be configured, and so on.
All new plugins are required to use the new 2.8-style API (found in api/). PRs for new plugins using the old includes will be rejected.
Likewise, all plugins are required use the new cmake system. PRs not providing a CMakeFiles.txt or describing a Makefile will be rejected. Not all plugins will be used by everyone, so please inform the user of any missing dependencies without halting the build.
NWN includes, wherever needed, should go into a "nwn" subdirectory for each plugin. The main include should be named after the plugin, for example nwnx_chat.nss. This is useful for a build process that collects includes and artifacts automatically.
Please include a nwnx2.ini file with a description of all plugin specific settings and sensible defaults for any new plugin, if any.
Plugins can export events through the provided PluginLink interface. All neccessary includable structs and definitions need to be in pluginlink.h in your plugin root.
Naming events works as follows: Plugin/Event. Examples include: Chat/Message, Resources/DemandRes. It is recommended to keep names simple and in camelcase. You are free to group events as you see fit, for example in sub-categories as needs warrant.
Every event needs to have a defined constant matching the naming scheme: EVENT_CHAT_MESSAGE, resolving to the actual string literal.
The associated C definitions (structs) are named similarly patterned as well, with the slash removed and "Event" appended, like so: ChatMessageEvent.
Core events by nwserver are under NWServer/*, for example: NWServer/RunScript and their definitions are in core_pluginlink.h in the repository root.
NWNX-related events are grouped under NWNX/*, for example: NWNX/PluginsLoaded.
Plugins using events sent by other plugins would #include "pluginname/pluginlink.h", since the plugins directory is added to the search path. Do not use "../".
Services follow the same naming scheme as outlined above. They are grouped into plugins, core, and nwnx itself.
Every callable service as a () appended to it's event name. For example, a service provided by the chat plugin to send messages could be named Chat/Message(). The related struct would be ChatMessageService.
Plugins using services by other plugins would #include "pluginname/pluginlink.h", since the plugins directory is added to the search path. Do not use "../".
You are strongly discouraged from using string literals to reference events and services. Use the provided constants instead, to catch typos and dependency errors at compile time.