Clone this wiki locally
About as complete as a slice of swiss cheese.
For Server Owners
The console variable
sv_gmod_language is available. This will adjust your server console's language the same way
gmod_language does to a player.
Almost everything in this this project is contained in the PYRITION table. There are exceptions as some additions to improve the programming experience have been added. Most notably:
LocalPlayer now exist on the server. The language used can be changed with
sv_gmod_language and the
LocalPlayer function returns the world entity.
It's probably a good idea to check out the Glossary too.
This project uses my flagship loader, Preconfigured Loader. Check out a few examples for making extensions there. Unless your extension only needs a single file, please place all of its contents in its own folder inside
Naming scheme for keys in the table is your path in
CamelCase followed by a name describing what the value is (don't just put a single letter or some short acronym). There are exclusions if the file name is common or a realm. For example, a table containing a player's history of teleporation would be named
PlayerTeleportHistory as the path is
server is a realm.
If a table's main purpose is to hold methods, the naming scheme is
SCREAMING_SNAKE_CASE. You will see this with commands (
COMMAND), stream models (
MODEL), and more.
For comments, whitespace is placed before the comment and no white space is placed after the
--. Multi-line comments for debug may end with
--]] to make toggling of the encapsulated portion easy.
Some comments may have start with
WORD: . These comments are the way I highlight code on my to-do list.
||Immediately after module is written|
All functions prefixed by Pyrition will automatically have a function generated for them without the prefix. This new function will do a
hook.Call with PYRITION as the gamemode table. This makes it easy to add and remove
hook.Call functionality to a function in Pyrition without mass replacing of code.
Any function or value prefixed with an
_ is not a method (meaning first parameter is not PYRITION) and has a good chance of being internal. These functions may be useful in specific cases outside of the file the originate in. A great example is
_RecipientPairs provided by
net/server.lua which is identical to
ipairs but can also take a
Player type. The standard for creating these is to always call them as a local function, but to store them inside
PYRITION so other files can cache and use them.
An internal function you may find useful in debugging is _drint. Cache it at the top of your code
local drint = PYRITION._drint and it functions like a normal
developer convar for the messages to be visible. In release versions of Pyrition, these will be commented out entirely to save on performance.