a few important changes!! MOST IMPORTANT: dlls built from this source forward will _NOT_ work unless you're running latest beta of source sdk base mp 2013, which will go live on the 22nd (see Joe's email on hlcoders) - valve named their hl2dm VPC projects. has annoying side effect of breaking our remove by '$Project' default name. this basically means we cant include the whole file as a start, and then remove files from our FF VPC with -$File. Basically server_ff.vpc, client_ff.vpc are standalone now, with ALL files/defines in em, so update that one file as we go. probably easier this way now. - IF YOU USE WINDOWS: when you're checking out the valve git tree, absolutely turn off 'auto crlf' or you will end up with diffs on nearly every single file. you can do it from 'git bash' by doing this 'git config --global core.autocrlf false' - vpc uses VS2013 by default for project target now, so if you want 2010 projects pass /2010. I updated the batches - when you copy pasta the valve code over ours, prepare to undo a lot of ff_sh_player -> hl2dm_player changes - valve turned 'treat warnings as errors' on by default for 32 bit builds. I turned off only in lua and luabind |
||
---|---|---|
mp/src | ||
.gitattributes | ||
.gitignore | ||
CONTRIBUTING | ||
DOCUMENTATION.md | ||
LICENSE | ||
README.md | ||
thirdpartylegalnotices.txt | ||
vpc-notes.md |
Fortress Forever (Source SDK 2013)
Committing
- Always make sure the code you are committing compiles
- Try to commit changes separately, rather than 20 files at once. This means we can easily revert certain pieces if we don't like them, rather than going through manually to remove stuff
- Be descriptive in your revision comments.
- If you aren't sure you're doing something the best way, comment it in code and possibly comment ("First pass, needs cleaning up!" for e.g.)
Code
- Avoid making changes in the base Source engine files; always try to move those changes into a FF-specific source file that derives from the base class.
Syntax
Variable and Function Names
- TODO Decide on a naming convention
- Always make variable and function names as descriptive as possible (if 'i' stands for 'currentPlayerIndex' then use 'currentPlayerIndex')
Class Names
- New classes should always start with CFF_, followed by either SV_ for a server-side class, CL_ for a client-side class, or SH_ for a shared class, and then the ClassName
- Example: CFF_CL_Player, CFF_SV_Player, and CFF_SH_Player
- Note: Shared classes usually will have #define aliasing such that a class with the SH_ prefix won't actually exist, but instead will always be mapped to the respective CL_ or SV_ class
File Names and Directory Structure
- Always put FF code files in the src/game/[server/client/shared]/ff/ directory.
- TODO Decide on a subdirectory scheme
- Always prefix Fortress Forever code files with ff_
- Add a secondary prefix depending on the usage of the file; for client-only files, use cl_; for server-only files, use sv_; for shared files, use sh_
- Example: the "player" source files would be named: ff_cl_player, ff_sv_player, and ff_sh_player
Adding/Removing Files
Solution and makefiles are no longer stored on the repo, they are generated using VPC. To add/remove files from the project, you must edit the game/client/client_ff.vpc and/or game/server/server_ff.vpc files and then execute createallprojects(.bat) in the src/ directory. To remove a non-FF-specific file from the project (like HL2DM files), add exactly what you would to add the file (or copy the line from the .vpc that includes it), but put a - before "$File".
Documentation
DOCUMENTATION.md
For documentation of general Source engine things or of implemented features, commit to the develop branch. For each feature branch, document the in-development feature as it is worked on; the documentation will get merged along with the feature once it is complete.
Doxygen Inline Commenting
Note: only use Doxygen commenting as necessary (see section Variable, Function, File Names and Directory Structure)
To describe classes/functions/files (List of available @ commands):
/// Brief description. (optional)
/** Detailed description.
@param parameterName Description of the param
@returns Description of the return value
*/
To describe member variables:
int var; ///< Detailed description of the member variable
///< and more if needed