☕️⚡️TShock предоставляет серверам Terraria серверных персонажей, античит-программы и инструменты для управления сообществом.
dee2c1a9f4
Refactored method names to be consistent with function e.g. Off -> ServerOff
Added new endpoints:-
/v2/server/status - Status query including player and rules matching common query tool requirements such as qstat. The json returned uses native types e.g. int's where possible
/v2/groups/list - Lists groups
/v2/groups/read - Query group detail
/v2/groups/destroy - Remove a group
/v2/groups/create - Create a group
/v2/players/list - Lists players including basic details
/v2/users/create - Create a user
/v2/users/list - Lists users basic user details applying a filter if specified.
Refactored missing parameter and error handling to use common utility methods RestError, RestMissingParam which ensures consistency across all functions and protects against null object references
Removed maxplayers from /status to ensure 100% compatibility, this and more details can be found in the new end point /v2/server/status
Protected against null names in user/activelist
Refactored variable checks to use string.IsNullOrWhiteSpace where applicable to capture errors early in the RestAPI
Added the ability to location users by "id" matching the underlying API.
Refactored locating players, bans & users to utility methods to ensure consitency across the api and eliminate duplicate code making for easier maintainence
NOTE: Duplicate and invalid DB entries currently can still be made if the DB format hasn't been updated to with missing unique and not null constaints
Removed { RequiresToken = true } from RestCommand constructors as this is the default anyway.
Optimised function calls so that tests are processed sequentially avoiding unnessasary operations in failure cases
Cleaned up formatting ensuring consistent line endings, indentation and single line if layout
Fixed ServerCommand duplicate key issue for multi line returns, now uses a single "response" string with embeded newlines
Fixed PlayerKill output using verb instead of parameters for "from" option
|
||
|---|---|---|
| Build | ||
| DBEditor | ||
| HttpBins | ||
| LuaBins | ||
| release-docs | ||
| SqlBins | ||
| TerrariaServerBins | ||
| TShockAPI | ||
| UnitTests | ||
| .gitignore | ||
| COPYING | ||
| Local.testsettings | ||
| README.md | ||
| Terraria.csproj | ||
| Terraria.vsmdi | ||
| TraceAndTestImpact.testsettings | ||
| TShock.sln | ||
TShock is a server modification for Terraria.
Continuous Integration: http://ci.tshock.co/
Support Forums: http://tshock.co/
Wiki: http://ci.tshock.co:8080/
Helping out
If you'd like to help out, the best thing you can do is to fork this repository, add changes, and request a pull back in. Try to make your changes on the latest code possible so that merging doesn't take ages, but other than that we accept any improvements or changes.
Teamspeak
We communicate on the ShankShock Temspeak server whilst programming.
IP: ts3.shankshock.com
Port: 9987
IRC
We love IRC (although a little less than Teamspeak). If you need support, or just want to hang around, feel free to join.
IP: irc.shankshock.com
Channel: #terraria-dev or #terraria
Pull Request Dev Guidelines
These guidelines are for contributors. If you do not follow these guidelines your commits will be reverted.
Required:
- Follow the code style. We generally use microsofts except for m_ infront of private variables.
- Do not push unfinished features to the master branch, instead create a remote branch and push to that.
- Do not push untested code to the master branch, instead push to the test branch.
- Document all compatibility issues in the COMPATIBILITY file. (IE file formats changing)
- DO NOT MASS COMMIT. Commit changes as you go (without pushing). That way when you push we don't get a thousand changes with a 1-3 line commit message.
Optional:
- Build Version Increment (http://autobuildversion.codeplex.com/).
Dev Team Guidelines
These guidelines are to be followed by all developers with commit level access to this repository:
- Do not, for any reason, submit code to the master branch before it hits the development branch first. If the development branch is far ahead, and a new bug fix is going out, branch master, then merge with master and remove your branch.
- If you are found to do this, you will be the person merging and rebasing your code to fit general-devel.
- Prior to posting any version on the website, you must tick the version in AssemblyInfo.cs. This is the versioning formula:
- Major.Minor.Revision.BuildDate (tick Revision if you're fixing prior to an actual planned release)
- Do not release any development builds on the forums without consulting another developer first.
- Document code prior to marking it done in JIRA
- Move any un-tested code to the "Needs Validation" section on JIRA prior to marking it as done.
- Do not push changes to any branch without a proper issue being assigned in JIRA. If a feature isn't planned for this release, it shouldn't be in the repo about to be released.
- Submit all pull requests to the general-devel branch prior to the master branch, or you will be ignored.