2 Commits
3 changed files with 74 additions and 7 deletions

No files matched your search

@@ -47,7 +47,7 @@
<h2>Warp Requirements</h2>
<p>You need to be the owner of the claim your warp is placed in. It should look good, and be as finished as
your warp type allows you to have it. Safety is an important aspect as well, visitors should not be
accidently dying by falling in dangerous areas or having mobs spawn on them. Phantoms are an exception to
accidentally dying by falling in dangerous areas or having mobs spawn on them. Phantoms are an exception to
this rule as you can't easily prevent those spawns. Your warp should be in one claim*, and divided with
subclaims if you need to allow different levels of trust in different areas (house plots in towns, shop
plots in malls, etc).</p>
@@ -64,8 +64,7 @@
chunkloaders.</p>
<p>It's important to make sure your warp is as lag friendly as possible. Our rules on lag can be found here on
the <a [routerLink]="['/lag']">lag</a> page. If we find your warp creates more lag than necessary for its
function
we will deny the application.</p>
function we will deny the application.</p>
</div>
<div class="columnContainer">
<div class="columnParagraph">
@@ -115,16 +114,18 @@
<p><span style="font-family: 'opensans-bold', sans-serif;">-</span> Smaller shop warps are limited to 1 shop
per type. For example, only 1 warp for redstone-related shops.</p>
<p><span style="font-family: 'opensans-bold', sans-serif;">-</span> In order to always keep our warps fair
and updated, we will automatically remove a warp if the warp owner has been offline for 30+ days. We need
to be able to contact our warp owners in a timely manner incase any issues with the warp happen to pop up.
and updated, we will automatically remove a warp if the warp owner has been offline for 45+ days. We need
to be able to contact our warp owners in a timely manner in case any issues with the warp happen to pop
up.
If we notice that a player is fairly inactive and another warp application comes in for a similar warp,
the application will be more likely to be accepted if the warp meets all of our requirements. If you plan
on being gone for an extended period of time, 14+ days, you can let a staff member know and they will note
it down and try to work with you.</p>
<p><span style="font-family: 'opensans-bold', sans-serif;">-</span> The staff team does weekly warp checks
<p><span style="font-family: 'opensans-bold', sans-serif;">-</span> The staff team does bi-weekly warp
checks
to make sure our warps continue to stay up to meet our requirements. They will mail a warp owner if they
notice an issue (low stock, sudden lighting issue, farm isn't working, etc.), and we expect all issues to
be fixed within a week of receiving that mail. If an issue goes unfixed, we will remove the warp due to
be fixed within 2 weeks of receiving that mail. If an issue goes unfixed, we will remove the warp due to
the lack of upkeep. If the issue is something you need help fixing or you're unable to work on it during
the week, you can reach out to any member of the staff team and they will work with you!</p>
</div>
+2
View File
@@ -105,6 +105,8 @@ paths:
$ref: './schemas/chat_info/chat_info.yml#/PartyName'
/api/site/chat/player/{uuid}/name:
$ref: './schemas/chat_info/chat_info.yml#/UserName'
/api/site/chat/history:
$ref: './schemas/chat_info/chat_info.yml#/ChatHistory'
/api/site/chat/send-message/{server}:
$ref: './schemas/server-message/server-message.yml#/sendServerMessage'
/api/site/chat/send-admin-chat/{server}:
@@ -44,8 +44,72 @@ PartyName:
description: Invalid ID
"404":
description: Party not found
ChatHistory:
get:
tags:
- chatInfo
summary: Get chat messages in a range
operationId: getChatHistory
parameters:
- name: from
in: query
schema:
$ref: "#/components/schemas/DateTime"
- name: to
in: query
schema:
$ref: "#/components/schemas/DateTime"
responses:
"200":
description: Chat history
content:
application/json:
schema:
type: array
items:
$ref: "#/components/schemas/ChatMessage"
components:
schemas:
DateTime:
type: string
format: date-time
ChatMessage:
type: object
required:
- uuid
- message
- server
- type
- timestamp
- blocked
properties:
uuid:
type: string
format: uuid
message:
type: string
server:
type: string
type:
type: string
enum:
- PUBLIC
- GLOBAL
- PARTY
- GAC
- MSG
- CUSTOM
channel:
type: string
maxLength: 36
receiver:
type: string
maxLength: 36
timestamp:
type: string
format: date-time
blocked:
type: boolean
PlayerName:
type: object
required: